UPDATED: Here are the links to the presentation and the Q&A.

A few highlights (with comments):

• In relation to large government databases, built to facilitate data mining techniques for suspicious activities, Bruce commented that if you’re looking for a needle in a haystack, it doesn’t seem very sensible to add more hay!
• On CCTV he posited that we’re living in a unique time. Ten years ago there were no cameras, now there are hundreds of cameras and we can see them all, in ten year’s time there will be many hundreds of cameras, but we won’t be able to see any of them.
• When ‘life recorders’ become widely used (and they’d only need about 1TB a year to record your entire life) he could see that not having an active life recorder would be seen as suspicious — much like leaving or turning off your mobile phone is now presented as “evidence” that you were up to no good.
• Ephemeral conversation is dying.
• The real dichotomy is not security v privacy, but liberty v control. He argued that privacy increases power, and openness decreases power. So citizens need privacy and governments need to be open for a balanced democracy to prosper.
• The death of privacy has been predicted for centuries (for instance, see Warren and Brandeis’ The Right to Privacy published in 1890). Without a doubt privacy is changing and this is a natural process — but it isn’t inevitable. Our challenge is to either accept this, or to reset the balance between privacy and the mass of identity-based data gathered for commercial gain and state security. Laws are the prime way to reset that balance.
• When asked the one thing he’d like to change, he replied it would be to implement European style data protection legislation (like our own Data Protection Act) in the US.

In this case the ICO press release (PDF) reported that a laptop containing some 18,000 customer records was stolen from a software supplier – Northgate Arinso. It is worth reading the undertaking (PDF) given by Verity to the ICO as it sheds more light on ‘what went wrong’. There are three separate issues covered in the undertaking.

1. Data Controllers and Data Processors

Verity is the Data Controller for the personal data of its customers and so has the legal responsibility for data protection compliance. This responsibility doesn’t end when a Data Controller decides to outsource or subcontract part of its business process to another organisation. This type of relationship is covered in the Act, and the sub-contractor / outsourcer is called a Data Processor.

(There’s a longer description of the difference between a Data Controller and a Data Processor in the basic terms section of this site)

The Data Protection Act is really clear about this, you can find the relevant bits in Schedule 1, Part II, sections 11 and 12. These two sections are (surprisingly) clear:

11. Where processing of personal data is carried out by a data processor on behalf of a data controller, the data controller must in order to comply with the seventh principle—

(a) choose a data processor providing sufficient guarantees in respect of the technical and organisational security measures governing the processing to be carried out, and

(b) take reasonable steps to ensure compliance with those measures.

12. Where processing of personal data is carried out by a data processor on behalf of a data controller, the data controller is not to be regarded as complying with the seventh principle unless—

(a) the processing is carried out under a contract—

(i) which is made or evidenced in writing, and

(ii) under which the data processor is to act only on instructions from the data controller, and

(b) the contract requires the data processor to comply with obligations equivalent to those imposed on a data controller by the seventh principle.

Essentially this means:

1. A Data Controller is responsible for the security of personal data even if, like Verity, it outsources some business activities to a supplier.  The Data Controller must do practical checks on the supplier and I’d recommend that records of those checks and any email conversations with suppliers about their security are retained.
2. The Data Controller must have a written contract with every supplier that is a Data Processor. The contract has to specify that the supplier must only do what the Data Controller says with the data, and that they have to provide appropriate security for the data. A solicitor should be able to draw up a compliant contract, or there’s a very good template in Stewart Room’s book.

If you want to avoid the type of problem that affected Verity and are worried about how your organisation manages Data Processors then I recommend that you:

1. List all the companies you use to outsource any business activity where they deal with personal data. Many are obvious (such as an outsourced IT provider) but others will include confidential waste disposal, off-site document storage, solicitors, off-site backup providers, contract printers, contact centre services, marketing companies etc.
2. Work out what type (personal, financial, sensitive) of information you send to these processors and what volumes of data they get on a monthly basis and will retain. I like to ask, “how much data will the company have in 12 months time?”
3. Do a simple assessment to help you prioritise your work. I tend to break them down into high-, medium- and low-risk categories.
4. Perform an information security risk assessment of each supplier. The higher the risk, the more detailed the assessment needs to be. I rate each supplier on the likelihood of there being a breach of confidentiality, integrity or availability of the data. I also like to assess the risk of data loss in transit to and from the Data Processor.
5. Review each risk assessment and formally decide whether:
   • You are comfortable continuing to work with the Data Processor
   • You want to insist that they make some improvements to their information security (and set a timetable)
   • You want to find a different provider
6. Check you have a written, signed and in-date contract with each processor that fulfils the requirements of the DPA shown above.
7. Agree when the Data Processor will be re-assessed (at a minimum this should be annually).

I’m keen to use this blog to try to explain the relationship between information security and the DPA. However on this occasion I hope you’ll excuse a paragraph of marketing. I provide this type of Data Processor management for my clients. I help identify and classify all the data processors an organisation uses, I individually assess each data processor and I write a risk assessment for each one along with a recommendation as to the best course of action. If you’d like me to do this for your Data Processors, or you’d like to talk to one of my clients to see how this works for them then please get in touch.

2. The use of test data

The first big contributory factor to the breach was that Verity’s supplier copied data from a live system to the laptop for ‘training’ purposes, the laptop was subsequently stolen. If you are a Data Controller then you need to be very careful whenever you allow data to be copied out of the live environment.

When you copy data from a live system to a test/development/training system to allow you to develop and test new software you’re pretty much guaranteed to be breaching the majority of the data protection principles.

You’ll probably breach the first (be fair when you get, use and share data) data protection principle because:

• you didn’t include ‘using your personal data to help test our IT systems’ as one of the uses listed in the fair processing notice you provided when you first obtained the data from the customer/client/citizen.
• you probably don’t have the Data Subject’s consent for doing this which means the only other schedule 2 justification you could use to make the processing legitimate would be that it is “necessary for your own legitimate interests” and I think you’d have a hard time demonstrating it was necessary when you could have generated anonymised test data. Furthermore, if any of the data fell into the DPA’s sensitive category then I think you’d be really struggling to find a schedule 3 condition to make the processing lawful.

You’ll probably breach the second (tell people what you will do with their data, do nothing more) principle because you didn’t include this use of someone’s personal data in either your fair processing notice or in your registration with the Information Commissioner.

You’ll breach the third (only get data you need) principle because you’ll always copy more personal data than you need to do the test (you don’t need any real data, as you could instead construct properly anonymised test data).

You’ll breach the fourth (ensure data you hold is accurate) principle because you’ll make test transactions on the personal data that will automatically make some of that data inaccurate. There’s an infamous case of a hospital using real data in test and then sending real letters out to real patients about ‘test’ conditions and injuries that the patients never had!

You’ll probably breach the fifth (delete data you no longer need) principle because that data will find its way onto the hard disks of developers and testers and never be deleted! If you’re really unlucky bits of the data will find its way into bug tracking software and through screen shots into system documentation.

You’ll probably breach the sixth (respect people’s rights over personal data) principle because you will forget to include any of this data if you get a subject access request from a Data Subject (I’ve never seen a response to an SAR that said “and here’s the data we hold about you in our test CRM system, don’t worry that much of it is nonsense”)

You’re bound to breach the seventh (don’t lose data) principle, just like Northgate Arinso/Verity because there are never the same number of controls around development and test systems as there are around live/production systems. You’ll lose track of where the data is and who has access to it. What happens next is predicted and whereas the breaches of principles one to six are technical breaches of the DPA, the breach of principle seven is the one that has the potential to cause the most customer detriment.

You may breach the eighth (be careful if you send data to other countries) principle, as it is not uncommon to have development partners outside the EEA and the other ‘safe countries’.

There’s a simple answer. Don’t use live data for training, test or development, make sure any test data you construct from live data is made anonymous.

3. Laptop encryption

The laptop containing the ‘training’ data was stolen from Verity’s Data Processor and this is where the breach that has the potential to directly affect Verity’s customers happened.

The ICO has a fixation with encryption for laptops that may contain personal data. It sees this as proving appropriate technical measures against accidental loss of the data to comply with the seventh (don’t lose data) principle. The ICO issued guidance in 2008 clearly explaining that where an unencrypted laptop is lost or stolen, the ICO will issue an enforcement notice. After April next year, when the ICO gets powers to fine, I predict that the loss of an unencrypted laptop will be an automatic fine.

Nowadays I advise all my clients to install whole-disk encryption on all laptops as it means you don’t have to worry whether a stolen laptop contains personal data (or other business-confidential information). As the whole disk is encrypted it also means you avoid the problems associated with just using encrypted vaults when the user saves the file in the normal unencrypted file system rather than the vault.

Of course, training all of your staff to shut their laptops down rather than just put them to sleep is a much harder task. Whole disk encryption tends to lengthen boot times so users typically just put their laptops to sleep rather than turning them off. A laptop that’s asleep already has the hard disk unencrypted so this control is often unconsciously defeated by the laptop’s owner.

Verity’s unfortunate problem is really good example of why it can be really beneficial to consider Data Protection compliance in parallel with information security. DPA compliance will:

• always consider Data Processor relationships.
• make sure that any use of personal data is lawful under the first principle.
• ensure that explicit guidance issued by the ICO is incorporated in information security policies.

Stewart’s new book is – as he admitted – elephantine in its size and coverage  (for comparison it’s physically larger than Ross Anderson’s Security Engineering). It is the first book that addresses infosec and law and I’m really looking forward to getting hold of a copy. I had a chance to browse one of the display copies at the launch and it looks really useful.

With probably about a hundred infosec and law professionals in the same room the conversations were really engaging. There was a lot of talk about the prominence of breaches in the news, especially after last week’s T-Mobile revelations along with the ongoing consultation on the Information Commissioner’s new powers. A few of the people I spoke to were curious to see what changes there would be in non-financial services companies once the Commissioner had levied his first sizable fine.

On one slide he highlighted what he considered the three biggest threats to Information Security:

• Complacency
• Apathy
• Inattention (Andy called it Human Error, but I hope he’ll excuse my re-wording to fit into the familiar triad)

So now there’s three security meanings for C, I and A.

1. Confidentiality, Integrity and Availability : The original
2. Common Sense, Intent and Application : Plan on doing sensible things well, and keep doing them
3. Complacency, Inattention and Apathy : It is really hard for humans to do security things 100% of the time

Andy’s presentation was really interesting and I’m glad to have had the opportunity of hearing his views, but in my view the session failed to address the publicised topic of “ID Cards: The end of the Private Citizen – or good corporate ID management?” There wasn’t a speaker to address whether this was the “end of the Private Citizen” and questioners were discouraged from being “too political”. As IT professionals it is really important we participate in the debate about state-wide databases and the consequences of insecurity and secondary uses. That’s not a political discussion, but a socio-technical discussion about the future application of technology. The UK chapter of the ISSA held a similar event in July this year which included former home secretary David Blunkett, a speaker from the Home Office, Pete Bradwell from Demos along side many technical presentations. Perhaps it was the table I was sat on but our discussion ranged widely through technology, security and ethical issues.

At last night’s BCS event I’d have like to have heard Andy talk more about the technical details of how his team resolved some of the many interesting challenges they will have faced over the past few year, especially the architectural solutions and processes devised to maintain separation of duties within the IPS.

As a root identity provider the ID card and the NIR are attractive, however I can’t help thinking of Bruce Schneier’s 2007 essay on The Risks of Data Reuse which ended:

“History will record what we, here in the early decades of the information age, did to foster freedom, liberty and democracy. Did we build information technologies that protected people’s freedoms even during times when society tried to subvert them? Or did we build technologies that could easily be modified to watch and control? It’s bad civic hygiene to build an infrastructure that can be used to facilitate a police state.”

When I train people, I talk about another more important Information Security meaning of CIA: Common Sense, Intent and Application.

Common Sense

Good Information Security requires everyone to use their common sense. Have you ever wondered why some people have common sense and others do not? Why some users remember strong passwords, and others would think it is OK to use their cat’s name and then write it down on a post-it?

This common-sense-imbalance used to worry me until the day I heard Ira Winkler give a presentation where he argued that “there’s no common sense without common knowledge” and you know, he’s absolutely right.

When users (and sometimes security professionals) do something that’s as far from common sense as can be, I’ve found it’s generally because we don’t share a common knowledge. For instance:

I know it is wrong to write your password down because it allows someone to easily logon to a system and perhaps do bad things while pretending to be you – that’s common sense:
they don’t understand why anyone would ever want to do this.

I know that writing the password to an encrypted file on the CD holding the file devalues the encryption – that’s common sense:
they don’t understand why the data needed to be encrypted in the first place and what encryption means, and decided that the password was less likely to get lost if they wrote it on the CD.

In Information Security we are all guilty of assuming that everyone understands threats and vulnerabilities in the same way that we do; but they don’t, which is why their common sense doesn’t match ours. To develop an instinct for good common sense, you need common knowledge – which means proper education for your users and for the whole of your Information Security team.

Intent

My dad used to have a phrase that really annoyed me when I was a kid. He’d say “If a job’s worth doing it’s worth doing well”—especially when my homework came back with C grades. I’m reminded of this whenever people talk about doing projects or initiatives in Information Security.

My experience is that it is a waste of time to be half-hearted about security. Worse still, it can have the opposite effect to the one you intended.

Take any simple control that’s documented in a process or a policy. If people see it’s not enforced, or has a variable implementation based on someone’s position in the organisation chart, then it sends the message that all controls are optional.

It is better to do a few things well, than lots of things poorly.

Implement security with a positive intent to do it well. If you know you’re going to make a half-baked attempt at a project, pick a simpler project you know you’ll do well.

Application

Much in of what we do in Information Security is dull. Checking, maintaining, documenting, cleaning, auditing, testing – just making sure that what needs to be done is done and done well.

My observation is that people – and especially technical people – get more excited about playing with new things than they do about keeping the old things going. Sure, they might not describe it as ‘playing’ and use works like ‘evaluating’, ‘installing’ or ‘configuring’ but at the end of the day it is the challenge and excitement of learning the new that excites them.

Good security though isn’t always about the new. It’s about doing the tedious stuff well and paying attention to it. It is about:

• Checking the logs on a regular basis
• Making sure that the roles defined in the role-based access are correct
• Doing the lessons learned from an incident and following up the action points until they’re all completed
• Updating the DR documentation when you change a server configuration
• Cleaning the backup tape heads and verifying the backup worked properly
• Filling out the visitor book for the server room
• Writing the documentation for X before moving on to Y
• Chasing the last person who didn’t complete the Data Protection training course

It takes application from everyone in the team to keep on top of these and hundreds of other little tasks. It takes application from management to make sure it happens.

So there you have it. My alternative exposition of the CIA triad:

Common Sense: Invest in the security education of users and the IT team

Intent: Plan on doing each security project or initiative well

Application: Keep doing  the dull things

One book I read this summer was Dan Gardner’s Risk – The Science and Politics of Fear. It is a well-written examination of the psychology of risk and fear which really addresses how we perceive risk. Bruce Schnier recommended it a few months ago and I wholeheartedly second his recommendation. A large part of our business is about assessing risk and then communicating that assessment to other people. Risk explains the ways our risk assessments are sub-consciously biased and also explains why people don’t always buy into our risk assessments.

The book has three parts:

In the first, Gardner condenses the academic research into risk perception. He explains the heuristics (rules-of-thumb) and biases that our unconscious mind (Gardner calls this gut) uses to assess risk and how these affect the conscious, reason-based decisions we’d like to think that our conscious mind (head) takes.

The second part of the book examines how governments, corporations and the media have used fear as an influencing tool to take advantage of these unconscious biases.

Finally Gardner looks at how these biases and heuristics affect our modern-day, risk-assessed world in the areas of crime, the environment and terrorism.

Why is this book useful to an information security professional?

All security professionals have to assess risk, it is the essence of what we do. So gaining an insight into how our own risk assessments can be hijacked is really useful. Understanding how other people can (intentionally or otherwise) manipulate our risk assessments and those of our colleagues and managers is even more valuable. Here are a few examples:

• I don’t know exactly how many new pieces of malware are produced each day, but because I’ve heard the figure 10,000 quite a few times, my personal ‘guess’ will be biased towards 10,000 not 10.This is the anchoring and adjustment heuristic. If you tell me that the real figure is 7,000 I’ll accept it as ‘about right’; if you tell me it’s really 1,000 I probably won’t believe you because my unconscious has anchored on ‘around 10,000′.
• The more times stories appear in the news about companies losing personal data, the more likely we – and our colleagues – think this will happen in our organisation. This is the availability heuristic at work.  The availability heuristic says that the easier it is for our unconscious mind to recall an example of an event, the more we overestimate the likelihood of that event occurring. The opposite is also covered by the availability heuristic of course -  the harder it is for us to recall an example of an event, the more we  underestimate the likelihood of that event occurring.
• There’s also the affect heuristic, which describes how people’s assessment of the probability and impact of events is biased, based on whether their gut perception of the event is emotionally good or emotionally bad. Data theft is bad, so the affect heuristic means that our unconscious mind, and those of our colleagues and managers, instinctively overestimates the probability of data theft occurring.

Reading Risk – The Science and Politics of Fear provides information that will help you to be a more complete security professional.  The next time you sit in a meeting arguing that something bad is extremely unlikely to occur you will be able to understand why you’re the only person in the room with that opinion. More importantly you’ll know what to do to get everyone at the table to move to a rational rather than instinctive approach to the risk assessment.

Joseph Bonneau has posted some research he’s done into the information that a rogue Facebook application can read from your profile. The brief summary is:

1. Facebook applications can access all information that you can access.
2. This means that they can access your profile and any information in your friends’ profiles they have shared with you.
3. There is nothing to stop an application harvesting all this information and sending it to a third-party web site.

Put another way.

1. Your friend installs a facebook application.
2. Becuase you’ve shared parts of your profile with your friend, the application your friend just installed reads your information.
3. The application your friend installed sends your information off to a database somewhere else.

So without you doing anything, or even knowing about it, someone’s just harvested your profile. My advice now would be to just simply delete all your profile information from Facebook and if you do keep any there, share it with no-one.

Of course this application violates Facebook’s rules, and they’ve now removed the offending application that Bonneau described, but I’m sure there will be others. Especially as sometimes Facebook makes it hard to actually understand what information you are sharing with who.

The full article: http://www.lightbluetouchpaper.org/2009/06/09/how-privacy-fails-the-facebook-applications-debacle/

and a similar one from the SocialHacking blog: http://theharmonyguy.com/2009/05/28/about-that-verification/

• Walk into buildings unchallenged and steal data from a company
• Get users to divulge their password over the telephone to someone who claimed ‘to be from IT’

The video is about 90 seconds long — and really worth watching.

What lessons we can learn from this?

All security programmes tell users not to divulge their password to anyone — not even people in IT. However this doesn’t work: when it comes to their computer systems, users see IT as ‘authority figures’ and so will divulge their password — especially if they are coerced.

What you need to do is:

1. Train the IT team not to ask users for passwords

Put a process like this in place so if an IT person needs to login as a user they should:

1. Raise a ticket / case in the organsiation’s help desk — which should ideally to be authorised by someone else
2. Confirm with the user that they are about to login using the user’s account
3. Login as a system administrator and change the user’s password to something that only they know
4. Now the IT person can login as the user (the time of the login and the activcity carried out whilst logged in should be logged with the original ticket)
5. Once completed, they should login as a system administrator and set the user’s password to a one time password which is communicated to the user
6. The user can now login and must be forced to reset their password to one of their own choosing

This is a long process, so it’s no wonder that IT people take a short-cut and just ask a user for their password, so you also have to:

2. Train all staff that if anyone “from IT” asks for their password, it’s a security incident

As part of your awareness training, emphasise that the only people who would ask for their password are:

• Data pirates (criminals)
• Rogue IT people

So if someone rings up and asks them for their password, they should refuse to give it and report it to the Information Security Manager (or their equivalent).

Of course it’s rare nowadays that IT should need to login as a user, there are better ways to diagnose a problem such as remotely sharing a user’s screen (once the appropriate authorisation has been given).

Here’s a little cartoon I’ve used in training and included in internal newsletters.

(if you want a print-quality version, or one customised to your company then just send me an email)