The Register recently reported that the European Commission is considering passing EU-wide laws on data breach notification, along the lines of those in place in the USA already. Viviane Reding, the Information Security Commissioner said:

“The Telecoms Reform has put the issue of mandatory notification of personal data breaches firmly on the European Policy agenda.”

The committee formed from Europe’s national data protection watchdogs (The Article 29 Working Party) has apparently also backed the idea.

Predicted to launch in 2010, a major initiative to review and strengthen the EU information security policy is in plan according to Reading, along with initiatives to consider emerging challenges for privacy and trust in the information society.

If this comes to place, it will bring the same kind of rigid requirement to report loss (or possible loss) of PHI and PII within Europe that is present in 48 US States today, and will further help companies both understand the risk of loss of PII, and will help consumers by giving them the choice to not do business with organizations known for having a lapse or defective stance on data security.

Remembering that PII information belongs to us, and not to corporates is a lesson slowly (and hard) learned in the USA – it’s encouraging that Europe is rapidly catching up.

Commissioner Reding made some firm comments regarding data protection:

“A key principle of EU data protection law is that those who process personal data have to take the necessary security measures to counter the risks to this data… when a security breach happens, the operator will have to inform the authorities and those citizens who may face harm.”

“It is absolutely essential that we find the right European responses to the concerns of European citizens about their fundamental rights to privacy and data protection.”

You can read the full text of Commissioner Reding’s speech on this matter from the EC.Europa.EU site.

Though we’ve had encryption products since the acquisition of SafeBoot in 2007, and those products have been deployable and reportable in ePO from soon after that – Endpoint Encryption for PCs 6.0 marks the first time that the total management and reporting of full disk encryption for PC’s has been available within our single-pane-of-glass strategy.

I am obviously really excited by this – not only does it lower the bar for adoption of full disk encryption, it means the 80% of Fortune 5000 companies who are currently struggling to be compliant with the 4,000 or so global laws and regulations covering the breach and disclosure of personal data, today have a very easy solution available to them.

For our valued McAfee customers who already have ePO in place, adding encryption technology now is just another plugin module, no new infrastructure, no new servers or hardware, and minimal new learning. I won’t go so far as to say it’s plug-and-play, but it’s damn close.

As one of the 217 million American residents in 2009 alone who’ve had their identity disclosed by a data breach, anything which makes securing my personal information is a good thing, and reducing the complexity, cost, and management overhead of technology always makes it easier to adopt and deploy in the corporate environment.

I hope over the next few weeks to be able to tell more about the success of this new platform, and how it’s changing people’s perception of how easy it is to secure our personal information. The product team certainly have some great stories to share.

This week I’ve been working my way through H.R 2221 – the “Data Accountability and Trust Act” . This proposed legislation is making its way through the Committee on Energy and Commerce at the moment, and if passed, will rationalize data protection legislation across the USA at a federal level.

The act enforces a few requirements on people holding PII, PHI electronic and paper data, I’ve paraphrased many of them below. The summary is though that this act will, if entered into law, standardize data protection across the USA at a Federal level, and with the penalties and force that the FTC has behind it. It enforces a duty to disclose loss or unauthorized access to data, fines and penalties, and enforces a duty to have audited people, systems and processes in place to protect data and manage its lifecycle.

You must:

• Establish and implement policies and procedures regarding information security of PII which are a) appropriate, b) the current state of the art for protecting data c) cost appropriate
• Procedures shall include a security policy with respect to the use, sale, dissemination and maintenance of data
• Identification of an officer or individual as the point of contact with responsibility
• A process for identifying vulnerabilities and monitoring for breaches of security
• A process for taking preventative / corrective action to mitigate against any vulnerabilities
• A disposal process for obsolete data

As you can see the current list of requirements is pretty sensible, but will be onerous to people not currently engaged in any data protection activities.

HR 2221 also discusses correct disposal of paper records, and expands radically the requirements of “data brokers”:

• Submission of security policies to the FTC upon request
• A Federal (or independent) audit of policy and practice in the event of a breach, followed by up to 5 years of subsequent audits
• Process and procedures to verify access to data
• Provision to allow consumers access to their data at no cost once per year
• Information accuracy dispute management process
• A requirement to audit transmission of data, and access to data

This last requirement should raise some eyebrows – designed probably to assist in the prosecution of people accessing data inappropriately, typically audit is pretty weak in most organizations.

Moving on, Section 2 part 5 talks about preventing inappropriate access to data, both making it unlawful to facilitate, and to entice the disclosure of PII by fictitious or fraudulent means. Basically if PII gets out, you are acting unlawfully.

The act then goes into talking about your duty to notify people if you lose, or suspect loss of data, or you disclose, or have suspicion of disclosure to unauthorized parties. For PII it’s the usual public notification, but for PHI, the act also forces you to disclose to the Secretary of Health and Human services.

Two year mandatory free Credit reporting is required, along with toll-free hotlines and timely notification.

The final part of Section 3 is most interesting to us – it talks about exemptions and exceptions. Basically the things you can do so you don’t fall foul of the act:

“…Encryption – The encryption of data in electronic form shall establish a presumption that no reasonable risk of identity theft, fraud, or other unlawful conduct exists following a breach of security of such data. Any such presumption may be rebutted by facts demonstrating that the encryption has been, or is reasonably likely to be compromised…”

The act also includes verbiage to state that “Such encryption must include appropriate safeguards of such keys”

The act then goes on to say that within 270 days, appropriate guidance will be offered as to what methods are appropriate etc.

Finally we get to the juice – enforcement (Section 4). In short, a failure to adhere to this act is unlawful, and such people will be subject to the penalties of the FTC Act (15 U.S.C. 41 et seq). The State Attorneys General can bring independent civil action against such parties to compel compliance with, enjoin further violation, and to obtain penalties of up to $11,000 per violation, per day. The fine is capped at $5m. If you’re being prosecuted though by the Feds, you’ll be pleased to know the state has to wait for them to finish before they can wade in.

This act will supersede any local state laws which are of the same nature.

Although maybe unnoticed, a month ago Missouri finally joined that heady club called “States which have Data Privacy Laws.”

On 28th August, the “Missouri Data Breach Notification Law,” or House Bill 62, took effect. The bill may not protect, but at least enforces care and attention, residents’ personal information (Social Security Numbers, Driver’s License Numbers, and information which could be used to access a residents financial accounts). Note I use the word “resident,” because, as with the other 47 or so state laws, this one applies to the Residents of Missouri, not to the businesses. If you have Missouri resident information in your datacenter in Tinbuktoo, you are still required (under civil and actual damages) to comply.

The full text of the law can be found on the excellent HuschBlackwell site, but the interesting points are:

• This law applies to Personal Health Information (PHI) as well as Personally Identifiable Information (PII)
• The law applies to both “customer” data, as well as “employee” data – it basically applies to every resident of Missouri.
• If you loose more than 1000 individual records, you need to tell the Attorney General. Non-compliance means civil damages.
• If you determine that the exposure of data is “unlikely” due to protective measures (or you believe the device was destroyed, etc.), you can elect not to disclose, but you MUST fully document the investigation and keep records for 5 years.

As with all these laws, if you hold Missouri resident data, you should approach your legal team and assess any additional risk (and mitigating measures) that you might now be subject to.

To keep you in the loop, the list States without, or with very weak data disclosure laws is now Alabama, Kentucky, Mississippi, New Mexico, and South Dakota.

Although maybe unnoticed, a month ago Missouri finally joined that heady club called “states which have Data Privacy Laws.”

On 28th August, the “Missouri Data Breach Notification Law,” or House Bill 62 took effect, not protecting, but at least enforcing care and attention of residents personal information (Social Security Numbers, Driver’s Licence Numbers, and information which could be used to access a residents financial accounts). Note I use the word “resident,” because, as with the other 47 or so state laws, this one applies to the Residents of Missouri, not to the businesses. If you have Missouri resident information in your datacenter in Timbuktu, you are still required (under civil and actual damages) to comply.

The full text of the law can be found on the excellent HuschBlackwell site, but the interesting points are:

• This law applies to Personal Health Information (PHI) as well as Personally Identifiable Information (PII)
  The law applies to both “customer” data, as well as “employee” data – it basically applies to every resident of Missouri.
• If you loose more than 1000 individual records, you need to tell the Attorney General. Non compliance means civil damages.
• If you determine that the exposure of data is “unlikely” due to protective measures (or you believe the device was destroyed etc), you can elect not to disclose, but you MUST fully document the investigation and keep records for 5 years.
• As with all these laws, if you hold Missouri resident data, you should approach your legal team and assess any additional risk (and mitigating measures) that you might now be subject to.

To keep you in the loop, the list states without, or with very weak data disclosure laws is now:Alabama, Kentucky, Mississippi, New Mexico, and South Dakota.

Last week, one of my colleagues asked me to comment on 45 CFR Parts 160 and 164, which for those of us who can’t remember all the code names for the various USA Federal docs, is the one in which the Department of Health and Human Services publishes its interim final rule under HIPAA and HITECH regarding what data falls under these regulations, what a “breach” means, and the conditions in which data is deemed to have been “protected.”

Under HITECH/HIPAA, there is a duty in the USA to care for the privacy of “unsecured protected health information” – this means that anyone electronically processing our heath information has a duty of care to make sure no unauthorized people gain access to it, and a legal duty to inform us if a breach (or possible breach) of trust occurs.

Reading (and understanding!) this document is critical for anyone involved in the electronic handling of health related information, but some key sections I’d like to point out to you include,

“A covered entity must consider implementing encryption as a method for safeguarding electronic protected health information; however, because there are addressable implementation specifications, a covered entity may be in compliance with the Security Rule even if it reasonably decides not to encrypt protected health information and instead uses a comparable method to safeguard the information.”

Summary – Encryption is recommended, but not mandatory. You can use other methods if they are deemed equal.

The regs go on to say though,

“…covered entity chooses to encrypt..pursuant to this guidence..discovers a breach of that encrypted information, the covered entity will not be required to provide breach notification.. on the other hand, if covered entity has decided to use a  method other than encryption.. not specified in this guideance..covered entity may be in compliance.. following a breach, the covered entity would have to provide breach notification to affected individuals.”

Summary, if you don’t use encryption, you may be legal, but you STILL have to tell everyone.

It goes on to talk about access controls:

“If access controls are compromised, the underlying information may still be usable, readable, or deciperhable to an unauthorized individual, and thus constitute unsecured protected health information…”

So, it’s important to consider your access control and audit methodologies, as encryption on its own is not sufficient. The regs go further to even talk about safe key management:

“To avoid a breach of the confidential process or key, these decryption tools should be stored on a device or at a location separate from the data…”

So you should be very wary about encryption processes which store the key with the data, for example any product in wake-on-LAN (WOL) mode, or in a mode where authentication by a user is not required (for example TPM only mode in Bitlocker). It would seem that as in these cases, the key is stored alongside the data, they do not protect you from HITECH disclosure. To keep your immunity you must conform to the statement:

“Electronic PHI has been encrypted as specified in the HIPAA Security Rule by ‘‘the use of an algorithmic process to transform data into a form in which there is a low probability of assigning meaning without use of a confidential process or Key” and such confidential process or key that might enable decryption has not been breached.”

Of course, the McAfee Data Protection suite is designed to conform to these regulations, never normally storing the key alongside the data, but, as with any complex security product, it can be configured to do exactly that.

If HITEC compliance is a must for you, and you’re a McAfee Endpoint Encryption user, now would be a good time perhaps to contact your McAfee account manager and organise some time to confirm you are indeed using the products in a way which keeps you compliant with these laws.

With the forthcoming release of Windows 7, questions about “Bitlocker” are coming up again.

For those of you who were around during the original release of Bitlocker, or as it was known then “Secure Startup,” you’ll remember that it was meant to completely eliminate the necessity for third party security software. Yes, Bitlocker was going to secure our machines against all forms of attack and make sure we never lost data again.

What happened?

Bitlocker was/is actually pretty good – it’s nicely integrated into Vista, it does its job well, and is really simple to operate. As it was designed to “protect the integrity of the operating system,” most who use it implemented it in “TPM Mode,” where no user involvement is required to boot the machine.

And that’s where problems started.

Hands up how many people have a TPM chip on their laptop?

Everyone I bet – it’s a ubiquitous piece of hardware nowadays. Ok, another show of hands please for those who’ve enabled, and taken ownership of the chip? “Taken ownership?” – yes, you remember going through the personalization phase of the chip, enabling it in the BIOS etc? Remember, all TPM’s are shipped disabled and deactivated.

What? You didn’t go through that yet? You didn’t do that before you deployed your laptops? Oh well, Bitlocker’s going to be a bit of a struggle for you isn’t it?

Fact 1. To use Bitlocker without adding additional authentication, you need an enabled, owned TPM1.2+ hardware chip.

Ok, For those of you who did go through this I congratulate your foresight. The only problem of course is:

Fact 2. Bitlocker with TPM-Only protection is vulnerable to Cold Boot, Firewire and BIOS Keyboard Buffer attacks.

Damn! Sorry to tell you this but there are some pretty simple attacks on your TPM-only machines – Do a Google search for “Bitlocker Firewire” or “Bitlocker Cold Boot” or ”BIOS keyboard” and you’ll find lots of research, and even a few tools which will unlock your nice “protected” machine and recover the data.

To make a machine secure, and by that I mean give you protection against having to disclose loss of personal information to all your customers if the machine goes missing, you need to use some form of pre-windows authentication (with or without TPM as well – it makes no difference). Microsoft themselves recommend this mode of operation.

For Bitlocker, turning on authentication gives you a couple of choices, you can set a pin for the machine, and also if you want, you can use a USB storage device (a memory stick, NOT a smart card) as a token. Yes, I did say a pin, and I certainly did not say “your Windows user ID and password” In fact I didn’t mention users at all. Bitlocker officially supports ONE login, so if more than one person uses a machine, you’re going to have to share that with everyone.

I feel some facts coming on…

Fact 3. Bitlocker is only secure if you use a pin or USB stick for authentication

Fact 4. There’s no link between your Windows credentials and Bitlocker Credentials

Fact 5. Bitlocker does not support the concept of more than one user

Even Microsoft’s official advice tells you to use a 6+char pin, plus TPM for authentication – no using it in TPM only mode now!

Ok, so now your lucky Bitlocker users havePC’s protected, maybe with a TPM, but certainly with some form of authentication which is shared between the owner of the machine, and probably you (as administrator), and the system guys etc. Hey – you probably have an Excel spreadsheet with everyone’s pin written down?

I hope so, because when those users start forgetting their pins, who’s at the end of the phone? The good news is the pin never changes – there’s no forced change or lifetime.

What do you mean, that doesn’t fit with your password policy? Did I mention yet that the PIN can only be made from the Fn keys, not the normal letter keys unless you configure a special “Enhanced Pin” mode which does not work on non-USA keyboards? Did I mention there’s no complexity or content rules apart from length?

Fact 6. Bitlocker PIN’s are usually FN key based. Bitlocker does not support non-US Keyboards

Hands up again all of you who’ve implemented PKI smart cards, or bought laptops with fingerprint sensors, or who have tokens such as ActivIdentity, CAC, PIV, eToken Keys, DataKey cards, SafeNet cards etc? You’d like to be able to use them for authentication to your PC’s wouldn’t you?

Fact 7. Bitlocker only supports USB STORAGE devices and PINs – no integration with any other token

And of course, you want users to be able to reset these credentials when they forget them without calling you, or your overworked, understaffed helpdesk? Sorry. No can do.

Fact 8. There’s no built in self-service pin recovery for Bitlocker users

There are Active Directory based methods, the GPO settings will let you store the (fixed) recovery key in your AD. I’m not sure how you feel about that getting propagated to every controller in your forest, but I’m sure you know and trust EVERY AD administrator in your organization who (now) have access to those keys. I mean, if someone was to dump out those keys and then quit, what would you do? It’s not as if the key ever expires. I guess you could write a program and then run it on every machine to recreate the keys, or write the recovery key down and give it to the user to hold on to?

Going back a bit, let’s review why we are going through this effort in the first place. I know the flippant answer is “because we were told to secure our machines,” but what does that mean? Most likely your company falls under one of the 250+ global laws defining and mandating the protection of peoples personal data, social security numbers, health information, credit card numbers etc. Regulations such as PCI, HIPPA, HITECH, SOX etc. You’re wanting to use Bitlocker to encrypt your machines because then, WHEN they get lost or stolen, you won’t have to pay fines, or tell everyone you lost their data, because to be honest, you didn’t did you? You lost the machine sure, but as the data was encrypted, no one can get access to it.

To use this “get out of jail” card you need to be able to prove a couple of things:

That the data was indeed protected at time of loss
That the protection method was appropriate given the type of data.
So, applying those tests, a rule appears.

Fact 9. You need extra software to PROVE Bitlocker was enabled and protecting the drive at time of theft to claim protection from PII laws

Personally, I know how to set GPO’s etc to mandate the use of Bitlocker, but I also know how easy it is for a user to turn it off. I don’t know of anything in Active Directory which gives me a definitive answer as to the state of protection of a given machine. There’s even a command line tool which can be run to completely (un)configure it. We need something that reports on the state of protection of a lost machine – just saying “well,. the policy says it should be encrypted” is not enough. Perhaps a reader can help out?

Ok, let’s finally take a look at implementing this solution. Now, you do have a 100% Vista Ultimate / Windows7 Enterprise environment don’t you? What? You still have some XP and Vista Business out there? Are you going to leave those machines unprotected, or are you planning to run a mix of third party software and Bitlocker?

Fact 10. Bitlocker only supports Windows 7 Ultimate/Enterprise and Vista Ultimate.

It may come across that I’m not a great fan of Bitlocker – that’s far from the truth. I would use it (personally), and would recommend it to my friends etc. I see it as REALLY good for technical, trustworthy end users. But, that’s not the market it’s being promoted for is it? Nothing fills me with dread more than an enterprise product which requires yet another password, require specific hardware which is not enabled by default, presents a black screen with white text to users (urgh! So archaic), does not conform to our recognized password/pin lifetime policies, does not work on non-USA machines, and does not have audit-friendly output for the main purpose it serves, i.e. tell me if this stolen machine is a liabiltiy or not. Come on now – it’s 2009! Don’t we deserve better?

I actually like it because of the following 10 reasons:

1. Only 1 of the 3 machines I use has a USA keyboard, so I can use FN mode Pins
2. It never forces me to change my Pin
3. I can turn it on and off whenever I like without my corporate IT people knowing.
4. I get to use the TPM chip, even though it took me a whole day to work out how to enable it
5. I can write fancy scripts to turn it on and off (I’m a closet programmer)
6. I get a nice dos-like screen when I turn my machine on, just like 20 years ago
7. Bitlocker is mostly controlled through a command line script (manage-bde)
8. My local IT team can’t come and use my machine, or see what’s stored on it without me knowing
9. I know that no one will be able to recover my data if I leave McAfee
10. I just like things to be done the hard way

This week’s (potential) major fail goes to Apple for the iPhone 3GS security. As reported by Wired and others, it seems the new 3GS encryption touted by Apple in their “iPhone Security Overview” isn’t so secure after all.

The official description of the new feature sounds pretty good:

“iPhone 3GS offers hardware-based encryption. iPhone 3GS hardware encryption uses AES 256 bit encoding to protect all data on the device. Encryption is always enabled, and cannot be disabled by users.”

But this excellent 2nd video demonstration by Jonathan Zdziarski shows plainly that there could be something very flawed about it.

Jonathon shows one of the architectural limitations of mobile platforms – you need the device to have a fail-safe hardware recovery mechanism (otherwise you could kill the hardware with bad software), but that opens the door to exploiting loader hacks, in his case, his subversion of the boot loader recovery mechanism to  zero out the password data.

On PC’s, this attack can be mitigated with full disk encryption where the (pre-boot) authentication details are used to decrypt the drive encryption key prior to the OS (stored encrypted) getting to boot – this is obviously very difficult to do on a phone as it’s expected to be on all the time, and rarely goes through the OS boot phase – how many of you actually ever turn your phone off, even when flying?

Jonathon’s demo is designed to prove the theory that disabling or zeroing the pin should render existing data on the device inaccessible, because it’s encrypted and the encryption is related to the device pin. A solid theory indeed.

His (abridged) flow was:

1. create some data (pictures)
2. set pin on iPhone
3. restart
4. use a loader hack on the phone to zero pin
5. reboot phone and create some new data
6. backup phone with iTunes and show the recovered new data AND old data is not protected

I can understand data stored after the key being zeroed would be in plain text on the backups, but surely the before-hack data should now be inaccessible as it should be encrypted with a (now lost) key related to the iPhone pin?

This is what Jonathon’s demo proves is not happening.

If it’s indeed possible to access all the data on the iPhone after zeroing the pin, both original and new, that indeed is a nasty flaw in the protection architecture. It would infer that there’s no relationship between the pin itself and the data encryption key. That data encryption key should by all rights be stored at least encrypted with the pin (PKCS5+salt), or better still stored in some tamper-proof hardware which can provide a hardened retry path (like a TPM or smart card chip). Doing anything which breaks the relationship between PIN and key should cause all data protected with it to be inaccessible – much like resetting a Windows user’s password can render all their EFS encrypted data inaccessible.

Storing the key on the device and just using

is (entered password == stored password)

is just plain silly, and I truly hope ( as a devoted iPhone user) Apple comes up with a good explanation as to what’s going on here and what we are all missing. Hey, if they want help making it bullet proof, I, and McAfee Data Protection would love to work with them.

PS - For those who’ve been using the iPhone for a while – do you remember the famous pin-bypass trick (now fixed) which let you get at the contacts, mail, web etc back in the days of iPhone2.02 and before? Simply, by double-hitting the home button when it was set to show “favorites”, you could then navigate to other apps.

This is much the same as the old Windows trick of using the HTML Help application to start other apps (it has a file browser, and from there, you can open any file you like, be it a help file or not).

PPS – If you’re thinking of dumping your iPhone and going to a BlackBerry, you might be interesting in the little fiasco happening in the UAE at the moment – It seems that the state-controlled telco Etisalat distributed a nice little performance enhancement “patch” to all BlackBerry users, which in fact contained SS8’s forensic interception client. Zensay Labs wrote a nice paper on what the patch does, but simply it allows Etisalat to ask the phone to forward emails you send back to them, thus bypassing the usual email protection methods which make interception of BlackBerry traffic difficult.

Following on from my recent posts regarding fines and the cost of data leakage (TJX and Cornell), I thought I’d also bring to your attention the latest initiated by the FSA (Financial Services Authority of UK) against HSBC – On 22nd July A tidy penalty of £4,550,000 ($7.5m) for two failures to protect personal information. HSBC will get a nice 30% discount on this for early payment, leaving them with a bill for £3,185,000 ($5.26m) plus their own internal costs.

The failures in summary were:

1. In April 2007, HSBC Actuaries lost an unencrypted floppy disk in the post, containing the personal information of 1,917 pension scheme members, including addresses, dates of birth and national insurance numbers.

2. In February 2008 HSBC Life lost an unencrypted CD containing the details of 180,000 policy holders in the post.

The FSA also fined HSBC Insurance Brokers for failures to implement measures to protect said data according to section 206 of the Financial Services and Markets Act 2000, for failures to adhere to Principal 3 of the FSA’s “Principals for Business“

Principle 3 – Management and control

A firm must organise and control its affairs effectively.
This will include:
a) having directors and senior managers who are all fit and proper for their roles, and operating adequate arrangements for securing the suitability of persons who
carry out functions on its behalf;
b) apportioning responsibilities among its senior managers and directors in such a way that

• their individual responsibilities are clear; and
• the business and affairs of the firm are adequately monitored and controlled at senior management and board level;

c) operating robust arrangements for meeting the standards and requirements of the regulatory system, and for guarding against involvement in market abuse or financial crime (including the detection and prevention of money laundering); and

d) keeping adequate and orderly records of its business and internal organisation.

The official summary of this is:

FSA Principle 3 states that a firm must take reasonable care to organise and control its affairs responsibly and effectively, with adequate risk management systems.

This final penalty is interesting because it’s a fine based on a failure of business practice, not a fine for actually exposing any ones data – this is a true demonstration of the teeth that the FSA have in the UK.

In the last four years, the FSA has fined Capita Financial Administrators£300,000; Nationwide £980,000; BNP Paribas Private Bank £350,000; Norwich Union£1,260,000; and Merchant Securities £77,000 for failings relating to data security lapses and fraud.

I was flying this week between offices and, being travel-bored and a nosy so-and-so, I zeroed in on an extremely loud conversation taking place between a fellow traveler and what must had been his Bangalore helpdesk.

A typical situation, middle aged gent in a sports jacket and slacks, reasonable shoes though needing cleaning, expensive watch etc. Blackberry glued to the side of his face, Glass of airport merlot on the table.

It was obvious to all within 50 feet that he was having trouble logging onto his corporate network, and was talking to a patient, but frustrated offshore colleague about getting his password reset. ‘John’ as I will call him (real name and company clearly displayed on the numerous executive tags on his travel worn Tumi luggage) was getting increasingly frustrated, and I guess the line was bad because he’d put his Blackberry on speaker phone to hear better…

(paraphrased, and details changed to protect the innocent)

John: “It’s John Smith – J-O-H-N S-M-I-T-H”
HD: “Yes Mr John. I have your account here. Can you give me your personnel number and Mothers maiden name for identification?”
John: “What? I don’t know, hang on, eh? It’s 12345.
HD: “I’m sorry Mr John – can you repeat that”
John: “ONE TWO THREE FOUR FIVE!”
HD : “And your mothers maiden name”
John: “It’s Smith, like, Smith! S-M-I-T-H!”
HD: “I’m sorry Mr John but are you sure that’s correct – I need your Mothers MAIDEN name, before she was married?”
John: “What? What do you need that for – it’s Jones though, JOHN ORANGE GNOME ELEPHANT SINGAPORE!”
…

Needless to say this conversation went on for some time, and by the time I’d finished my Manchu Wok mock Chinese meal (oh the joys of Charlotte Airport) I knew the last four digits of his social security number, his name, company, Mothers maiden name and personnel number. I also worked out the helpdesk phone number, no real trick as it was on the front page of their company website.

John eventually got logged back into his corporate network, but not before writing his new password down on a napkin which he eventually left on the table along with his empty wine glass as he left to catch his connection. I thought about pointing this out to him when he returned some 5min later to pick up his forgotten luggage, but no, I tore it up and trashed it after he’d again left it on the table.

A sorry state of affairs you will no doubt agree, but is John really to blame? He obviously really does not understand what his password is for, why it’s special and needs protecting, why even his network needs a password – he views it as an obstruction to doing his job.

I imagine perhaps there was a time when his company didn’t use passwords, then suddenly they got thrust upon the user population with no warning and no coaching – to John, the security in front of his corporate network is obstructive and valueless, and not something he feels any compulsion to value or protect. His job is to sell widgets or whatever, and damn the IT department for getting in the way of that.

Too often we IT leaders get sucked into technology rather than thinking about, and promoting its benefits. John’s a victim of that mentality. Security starts at layer 8, the users. Technology as I seem to oft repeat, can only help us protect ourselves – It can never be the whole solution. Any change in business practices which affects users needs to start off by expressing the value of the change to those people, how it is beneficial for them – perhaps it keeps them out of jail, or protects their jobs, or makes new systems available to them. To suddenly introduce security measures without expressing these benefits to the users is guaranteed to cause trouble.

It’s not a big thing, but user education and consideration can really help smooth the technology introduction and migration to a more secure working environment. If you think you can get away from mandating security and backing it up with a stick, you should perhaps consider attending one of Stan Slaps enlightening courses on leadership.