Cyber Security Predictions for 2017

I was asked to sit on a panel of experts, gaze into the crystal ball and make my predictions for what 2017 holds in store for cyber security, which got me thinking. Let's start with more breaches, more ransomware, more cyber security jobs, wage increases for security professionals, more 'qualified' professionals who don't really know what they're doing but have a piece of paper and, of course, vendors making even more money out of Fear, Uncertainty and Doubt (FUD). However, none of those is terribly interesting or any different from 2016, or 2015 for that matter, or indeed anything other than trends in the industry.

So what does 2017 hold in store for us in the security industry and is there anything new to worry about? Well an obvious one to call out is the EU's General Data Protection Regulation (GDPR). So what is GDPR? Well, GDPR replaces the previous data protection directive and aims to improve and harmonize data protections for EU citizens. This will impact non-EU companies that hold data on EU citizens as well as EU companies and agencies. Why is this such a big thing? Well, the regulation increases accountability and responsibility on companies, makes it law to disclose breaches and increases potential fines up to €20m or 4% of global turnover from the previous year, whichever is greater.

When does it come into effect? 25th May 2018. So why talk about it as a prediction in 2017? Companies will have to be prepared well before this date and vendors will start working towards selling services specifically aimed at GDPR compliance this year. The problem I have with this is that I believe companies will take their collective eye off the ball and be so busy with GDPR that they won't keep pace with the changes in technology and threat landscape.

I also believe that fines should be handed out more readily. Too often we have companies suffering a breach saying that they were compliant and it must have been an 'advanced attack' or 'nation state' actor. This is mostly complete rubbish! What's actually happening is that people do whatever gives them a tick in the compliance box without paying any mind as to whether it actually makes them secure. They use compliance as an insurance policy instead of following the principles to make themselves more secure. Most breaches occur through the same broad issues as a decade ago (or more). Frankly, if, for example, you have an OWASP Top 10 in your web app/service and you are breached, you should have the full fine thrown at you and those in charge should face negligence charges. There is simply no excuse for such well-known vulnerabilities to exist in live systems. Another point to remember with GDPR is that Brexit won't make us immune in Britain as the Information Commissioners Office (ICO) has already committed to it, so companies will have to prepare.

What else could we see in 2017? The IT industry is embracing DevOps, continuous integration, Platform as a Service (PaaS), software defined networks and, of course, agile. Many of these systems or vendor offerings have poor or non-existent security models. That industry needs to catch up; fast. In my opinion, the reason why we haven't seen more issues with these technologies is that they haven't, until now, been adopted by the big target companies, e.g. the banks. This is changing now and I think we'll see more focus on these technologies over the course of this year in situations where security is of high importance.

This isn't just about the technologies though, agile and the speed of deployment will change the way security professionals have to work. Gone are the days when the security professional has time to assess a solution at their leisure and fully test and assure it before go-live. I think threat modelling is going to become more important in this arena. Threat models can be built ahead of time and applied to new systems as they are developed. The emphasis then has to be on preventing the threat scenario as a whole (through a layered approach) not focusing on every single individual vulnerability/weakness. Basic security hygiene has to be brought up to an acceptable level across the board to enable this new way of working, as we can't rely on stopping a project whilst we fix every bit of it.

Something else I think will become more prevalent is big data and behavioural analytics. Companies are now starting to realise the power of big data and this is spilling over into the security industry. Some security teams are now employing data analysts and setting them anomaly detection problems or running behavioural reports on their employees, which is one of the best ways to catch the rogue insider. These are interesting developments and this type of data analysis is the future of security (alongside more traditional technologies and policy as well).

What else? I think that third party suppliers, the supply chain and smaller businesses will start to become more heavily targeted as the main targets get harder to breach. Smaller businesses can't usually afford the experienced cyber security teams that are required to secure them. So, they turn to vendors to sell them a silver bullet... on a budget. That's not going to work. Actually, basic security hygiene doesn't have to cost that much and doesn't require huge pay-outs to vendors. It does take expertise though and that is in short supply. As an industry I think we could do more to help smaller businesses with things like best practices and Security Technical Implementation Guides (STIGs) before the epidemic hits.

Finally, my fifth prediction is that we will start to see more attacks on connected systems, such as connected vehicles, building management systems, IoT devices, etc. I have worked with vehicle manufacturers and those involved in smart cities and smart homes/offices, and I can safely say that security is not top of their agendas - safety may be, but not security. Unfortunately, a lack of security can lead to a lack of safety in these cases, but I think a few harsh events will happen before the lessons are learned. Will 2017 be the year for this? Possibly not, as I think adoption of the technologies may not quite be there yet, but if we don't start dealing with it now we'll be in for a whole world of pain later.

The Threat Landscape Roundtable

I was invited along to SC Media's roundtable on The Threat Landscape last week and they have written an article on it. I was also interviewed and appear in their video summary. The article and video can be found here: https://www.scmagazineuk.com/roundtable-the-threat-landscape/article/635652/

EU Commission Working Group looking at privacy concerns in IoT

The Article 29 Working Group advising the EU Commission on Data Protection has published their opinion on the security and privacy concerns of the Internet of Things. A couple of interesting quotes come from this document and it points to possible future laws and regulations.

"Many questions arise around the vulnerability of these devices, often deployed outside a traditional IT structure and lacking sufficient security built into them."

"...users must remain in complete control of their personal data throughout the product lifecycle, and when organisations rely on consent as a basis for processing, the consent should be fully informed, freely given and specific."

One thing is for sure, privacy is likely to get eroded further with the widespread adoption of IoT devices and wearables. It is critical that these devices, and the services provided with them, have security built in from the start.

eBay's Weak Security Architecture

Well eBay are in the news due to their breach of 145 million users' account details. There are a few worrying things about this breach, beyond the breach itself, that point to architectural issues in eBay's security.

The first issue is that a spokeswoman (according to Reuters) claimed "that it used 'sophisticated', proprietary hashing and salting technology to protect the passwords." This sounds very much like security through obscurity, which doesn't work. So, either they are using a proprietary implementation of a publicly known algorithm, or they have created their own. Both of these situations are doomed. As always, no one person can think of all the attacks on an algorithm, which is why we have public scrutiny. Even the best cryptographers in the world can't create new algorithms with acceptable levels of security every time. Do eBay have the best cryptographers in the world working for them? I don't believe so, but I could be wrong.

Also, if their argument is that hackers don't know the algorithm so can't attack it, then I'm fairly sure they're wrong there too. Even if the algorithm was secure enough to stand up to analysis of the hashes only, as hackers have eBay staff passwords perhaps they also have access to the code! If, on the other hand, they have their own implementation of a public algorithm I have to question why? Many examples are available of implementations that have gone wrong and introduced vulnerabilities, e.g. Heartbleed in OpenSSL. Do they think they know better?

The second issue is that they don't seem to encrypt Personally Identifiable Information (PII). This is obviously an issue if a breach should occur, but, admittedly, doesn't solve all problems as vulnerabilities in the web application could still expose the data. However, it is likely to have helped in this situation.

Finally, and most importantly, how did gaining access to eBay staff accounts give attackers access to the data? Database administrators shouldn't have access to read the data in the databases they manage. Why would they need it? Also, I would hope that there are VPNs between the corporate and production systems with 2-factor authentication. So how did they get in? Well, either eBay don't use this standard simple layer of protection, they leave their machines logged into the VPN for extended periods or they protect the VPN with the same password as their account.

Even if eBay do implement VPNs properly with 2-factor authentication, the production servers shouldn't have accounts on them that map to user accounts on the corporate network. Administrative accounts on production servers should have proper audited account control with single use passwords. Administrators should have to 'sign out' an account and be issued with a one-time password for it by the security group responsible for Identity and Access Management (IAM).

All this leads me to think that eBay have implemented a weak security architecture. 

City Link and Gathering Data for Spear Phishing

I have just been sent an email giving me a tracking number for a City Link parcel due to be delivered. On checking this on their website, I found that I only need the tracking number to track the parcel and no other information. Is this a problem?

Well, I think it is. Via my tracking number I am able to find the company name of the sender and my postcode. Now, postcodes normally only relate to around a dozen properties at most. However, that's not the end of the story. By entering different numbers (based on the one that I received) I was able to get the details of other parcels being sent around. Incidentally, their format is AAAddddd - representing three uppercase letters followed by sequential numbering.

Does this matter? Well, by going backwards through the sequential numbering system I was able to find a parcel that had just been delivered (at 13.50 to be precise) to a postcode in West Yorkshire - BD22 (I have omitted the last part of the postcode here). Helpfully, they include the surname of the person that signed for the parcel. Then it was a simple matter of doing a quick search on the properties to find someone with the correct surname. I found Denise and Jonathan X living at that address for a number of years and was able to find additional information, such as the fact that Jonathan worked for a local University. Crucially, I was able to find email addresses for them. It would now be very simple for me to launch a phishing attack on them as I have real details with which to trick them. There is simply a privacy issue here as well. Do you want anyone and everyone knowing what deliveries you receive and from which organisations? This could make a very good profile.

How hard would it be for City Link to require some additional information before giving out the detail? A simple solution would be to ask for the correct postcode in addition to the tracking number, then it would be much harder for someone to extract the details. They have included a captcha that kicks in after a few attempts, but this doesn't work, and simply entering anything in the field over the minimum required length and containing a space will be accepted. Also, cycling through IP addresses or performing the requests slowly will bypass this requirement. Anyway, I'm off to write a script to extract the details for the postcodes of City Link employees, MPs and newspaper reporters to see where they shop...

Admin rights to data should be given sparingly (or not at all)

I was reading a well-known telco’s document on the trade-off between productivity and network security recently. A lot of what they said is fair comment and they do have some helpful suggestions. However, their response to security risks, like those of many organisations, jumps straight for the technology solution with only a thin veneer of trying to deal with people.

Many organisations will talk about people and process and how important they are and that you need education programmes (most of which miss the point and are not terribly effective), but they say it as if they have been told to and don’t really believe it themselves. At the end of the day they will jump on the technology bandwagon and sell you/buy the latest bit of kit.

One statement in this document stood out though: “...full administration rights to all data are rarely appropriate for the entire workforce.” What? When are they EVER appropriate for the entire workforce? When is full admin rights over all data ever appropriate for even one person in the organisation?

I’ll give an example. Suppose you are an organisation that stores the financial data of your clients in a database. Should the network administrator have full admin rights over the data? Certainly not! Under what circumstance does the network administrator require any access to that data? What about the database administrator? Again, no. The DB administrator needs administrator rights to the database management system, but they don’t need to be able to read the actual data contained in the database. What about those users that may need access to the data contained in the database? Well, they can be granted access, but you wouldn’t give a user administrative rights over the data surely?

This also highlights the problem that many organisations have with leaking data. If you give people rights over the database they can extract the data, store it on their local machine and lose it or transmit it. What’s wrong with keeping the data in the database and accessing it from there? If you download it, you will only have a snapshot anyway. Leave the data in the database and protect it from everyone who doesn’t need access to it, which includes the IT department!

Contactless Credit Card and ID Card Skimming

This news post was brought to my attention, showing a steel-woven wallet to keep RFID credit cards safe. To some this may sound a bit far fetched and to others nothing new or to worry about, but hear me out.

With new contactless credit cards you can make small purchases without resorting to the Chip-and-PIN transaction that is most common. Instead, you just 'touch' your card on the reader and away you go. The problem with this is that you cannot turn your card off. I can bring the reader to you; I just need proximity. These readers are small and pocketable, and I can read your card without you taking it out of your pocket. The more high-powered my reader, the further away from you I can be to read your card. Initially, the cards gave out the name on the card, the card number and the expiration date. After people showed that it was easy to skim this information off the card, most have removed the cardholder's name from this list. They have also introduced transaction IDs to help protect the cards from being cloned. However, as the introduction of RFID identity cards increases, we will be giving the cardholder's name out again on those.

It has been argued that it is more productive to attack the databases of card details, and still far too easy, so people won't bother trying to read the cards in your wallet. However, I can still obtain a legitimate payment reader and just read your details off and collect your money directly, even if I can't clone the card. In the UK, these contactless transactions are for small amounts of money (£5-£10 typically), but I can collect that from you without your knowledge in a variety of ways. I can use a small pocket device to take a payment from your card directly, but this has to be one at a time and, in some countries, only for small amounts of money. (See the video below for a mobile phone that can process contactless credit card transactions.)



Maybe this isn't worth it to anyone but a petty criminal, but it is relatively easy and cheap. Another way would be to go to a crowded area (public celebrations or gatherings of tens or hundreds of thousands of people for example) and use a high-powered reader to read lots of cards at once. If I can steal £10 from 100,000 people, that's £1m in an afternoon! Somewhere in the region of half a million people gather in Trafalgar Square, and environ, for the New Year celebrations and similar numbers for the Chinese New Year celebrations a little while later.

RFID readers are all over the place and we don't pay them any mind. Shops use RFID readers to catch shoplifters at the entrances. Do you categorically know that they aren't reading your cards instead of catching shoplifters? Would you notice an extra £10 transaction in a shop that you did buy something in? All of our buses and tube stations in London use RFID readers for ticketing. A vast number of commuters will have their Oyster card in their wallet or purse along with their other cards. They don't remove the Oyster card to touch it, they just touch the whole wallet. I could read the other card information at the same time. In fact, do we know that these details aren't logged and just ignored? If they are logged, then maybe we could attack Transport for London's computer system and extract people's credit card details.

Maybe people won't do this with credit cards. What about large banks or other companies that use RFID door entry cards and ID cards? I could read their ID and possibly gain access to their building. Will the ID give me a username to work with? If I can gain physical access to a bank building then I have a huge array of attack vectors at my disposal; it is critical to keep the hackers out.

Even if a hacker can't clone these types of cards, they can still collect information about people and about companies. It is perfectly possible to identify all the employees of a company using RFID cards for door entry, as you can have a high-powered reader near their entrance or at public transport stations. This now gives a social engineer a target and some information to use. Maybe we should all be holding our wallets over the top of shop gates and away from other readers or buy one of the shielded wallets from people like ID Stronghold or Herrington.

Secret Sharing Algorithm for Protecting Files in the Cloud

Data stored in the cloud can be compromised or lost (see my previous post). So, we have to come up with a way to secure those files. We can encrypt them before storing them in the cloud, which sorts out the disclosure aspects. However, what if the data is lost due to some catastrophe befalling the cloud service provider? We could store it on more than one cloud service and encrypt it before we send it off. Each of them will have the same file. What if we use an insecure, easily guessable password to protect the file, or the same one to protect all files? I have often thought that secret sharing algorithms could be employed to good effect in these circumstances instead.

What are secret sharing algorithms? They are algorithms that will share a secret between several parties, such that none of them can know the secret without the help of others. Either all or a subset of them will need to get together and put their parts together to obtain the original secret. A simplistic solution can be achieved by XORing the secret with a random number, then giving the result to one party and the random number to the other. Neither one can find out what the secret was without the other. To retrieve the secret they only need to XOR the two parts together again. This can be extended to any number of parties.

A more sophisticated way would be to allow the secret to be retrieved from a subset of the parts distributed. In the previous example, if any of the parties loses their part, or refuses to disclose it, then nobody can reveal the secret. This isn't much good if one of our cloud service providers fails. On the other hand, if we can share the secret between three people, but only require any two to regenerate the original, then we have some redundancy. This is an example of a (k,n) threshold scheme with k=2 and n=3.

How do we achieve this though? Well, Adi Shamir proposed a simple secure secret sharing algorithm. It is based on drawing graphs. To uniquely define a straight line, you need two points on that line. Similarly, to define a parabola you need three points. A cubic requires four, etc. So, we can distribute points on a line to each party we want to share the secret with. The order of the line will determine how many of them need to get together to regenerate it. So, we could define a random straight line and distribute three points on it to three different parties. However, only two of them need to get together to regenerate the original secret.

We set up a (k,n) threshold scheme by setting the free coefficient to be the secret and then choosing random numbers for each of the other coefficients. The polynomial then becomes the following:


where a₀ is our secret. Now we can distribute points on the line to each of the n parties simply by calculating y for a series of different values for x. We can use the Lagrange Basis Polynomials to reconstruct the equation of the line from k points. However, we do not need to reconstruct the whole line, we are only interested in the free term. This simplifies the equations that we need to use. For example, if we have a straight line, then we only need two points (x₀,y₀) and (x₁,y₁). We can then calculate a₀ as follows:
Similarly, for a parabola and three points (x₀,y₀), (x₁,y₁) and (x₂,y₂) we have:
This should be fairly simple to implement and use. You would need to sign up to a few cloud services, but you wouldn't have all your eggs in one basket and you wouldn't be reliant on weak passwords.

Security Questions for your Cloud Services Provider

Comodo Vision Video Blog

Cloud Services or Cloud Computing are getting a lot of attention in IT circles, promising cost-effectiveness, flexibility, and time-to-market advantages over traditional alternatives. However, they also increase your security risk by expanding your security perimeter to include that of your service provider. This video blog poses some key questions to ask your Cloud services/Cloud Computing provider regarding data security as well as advice to reduce the risk to your business introduced by Cloud Computing.

See my third video blog for Comodo Vision here.

Telephone and Fax Services Security

In this day of doing everything online, we still rely heavily on services delivered over POTS (Plain Old Telephone Service). Banks and credit card companies still require the telephone to make certain changes, queries and security checks, even though most functions can be performed online. Medical records, bank details, security key order requests, etc., are routinely transferred by facsimile. However, are these secure? Are they more or less secure than doing the same thing online?

I'm not going to talk about the underlying security of POTS, but concentrate on a couple of easy attack vectors on the end device of the user that I have recently observed. A couple of weeks ago, I needed to amend something on one of my credit card accounts (I would tell you which bank, only it's my personal credit card and I don't want phisers knowing which banks I have accounts with). This bank has an automated telephone answering system to make things more efficient and reduce staff required - pretty standard. So I made sure that I was in a room on my own, to prevent eavesdropping my conversation, and dialled the number. The automated system asked me to type in my full credit card number on the keypad.

The problem with doing this is that the telephone will remember these digits as part of the last number dialled. Therefore, all someone would have to do is to recall the last number dialled and read off the credit card number. If they actually dial it they would be put through as the legitimate card holder. Now, admittedly they will probably ask some security questions on the other end before making any changes, but these may consist of simply asking for a date of birth, which is fairly easy to find out. Even if you don't know this information, other information may be given away in the mean time (e.g. who the card holder is as they normally use your name in any greeting). The problem is compounded if you make a call from work, where you will probably be using an exchange. Exchanges will store all the numbers dialled, including any options or credit card numbers entered on the phone's keypad. This log can simply be printed out and your details read off. Of course the number dialled will show which bank you are using as well, although this can also be gleaned from the first 6 digits of your credit card number.

Things can potentially get worse if you use facsimile or fax machines. There are different types of fax machines that work in different ways. Most will keep a log of calls and faxes sent and received. This may or may not be a problem, depending on the level of detail of the log and whether you're typing in credit card details during a phone call made on the machine. However, some fax machines use rolls of pigment on acetate (or similar) to print the fax out when received. The problem here is that these rolls are wound through during printing and that part is never reused (otherwise you will get gaps in your printing). However, what this means is that when you come to throw the roll away once used, it will have a perfect facsimile of everything printed on the machine since the roll was put in, only in negative. To get round this, you must shred, or otherwise destroy, the used roll, not just throw it in the bin.


As to whether this is more or less secure than an online transaction is a difficult question to answer. On the one hand, you often need physical access to the phone or fax machine to get to the logs, although telephone exchanges are often online. Also, sifting through a bin outside a premises isn't that hard and can often be very rewarding. On the other hand, transactions online are encrypted and people are more aware of the security implications in general. However, malware and man-in-the-middle attacks can still thwart this type of transaction, but it does require more skills than sifting through a bin.

Not all data leakage comes from computers, pen drives, etc. Sometimes a seemingly innocuous device can betray your information and breach your security. Unfortunately, you have to think of all possible attack vectors and mitigate the risks. This is why a full information policy that covers all forms of data is required.

Personal Mobile Devices Violate Compliance

Computer Weekly recently conducted a survey via Twitter on how many organisations allow their users access to corporate email from their own private phone. Unfortunately, I haven't seen any results from this survey as yet, but it made me think about organisations that do allow private devices to attach to the network, not just mobile phones. I have also had many comments on my blog post entitled 'Mobile Device Data Breaches', which have fed into this post.

In one of those comments, someone pointed out that in their experience users are often a weak link. Isn’t it always the case that users are the weakest link? A poorly educated/trained user can compromise the best security. Unfortunately, I have seen so many organisations that do not adequately train their users or make them aware that there are policies, let alone what they mean to their daily usage of the corporate systems. I have also come across one organisation where a top executive had all the system passwords stored, unencrypted, on his PDA. He didn’t see a problem with this as he always carried it with him!

How many organisations these days have push email onto a mobile? How many of those organisations send sensitive documents around via email? Do they have encryption and password access on those devices? Not many that I’ve seen. The typical Blackberry users that I see have no password or PIN access to their phone, but it does have full access to the corporate mail exchange. These devices also have the ability to store, and even sync, corporate documents. What policies do you have to cover them?

Quoting from ISO-27002:2005 11.7.1: A formal policy should be implemented, and appropriate security measures adopted, for mobile computing and communications activities. Controls should apply to laptop, notebook, and palmtop computers; mobile phones and "smart" phone-PDAs; and portable storage devices and media. Controls include requirements for:

• physical protection;
• data storage minimization;
• access controls;
• cryptographic techniques;
• data backups;
• anti-virus and other protective software;
• operating system and other software updating;
• secure communication (e.g., VPN) for remote access; and
• sanitization prior to transfer or disposal.

The problem is that most organisations do not have adequate policies covering mobile devices. Moving away from mobile phones, are you allowed to plug a USB device into your corporate machine? Many of these devices can store sensitive data and even access the Internet themselves. What about an insecure iPhone connecting to the Internet and leaking data? Most organisations aren't even aware that you can lock down USB usage via tools, but policies should definitely be in place. Alan Goode, from Goode Intelligence, said the following:

"I feel that you can lock down with security policy and tools but this is a complex problem as the combination of mobility and technology diversity, e.g. I can use my iPhone to connect to the enterprise network and store sensitive data on it, is creating a major headache for infosec professionals. As well as the problem with laptops and USB drives we are also seeing a growing use of employee-owned mobile devices, netbooks, games consoles, smart phones, all having IP and WiFi capabilities and all capable of picking up enterprise data and email."

There are a number of things we can do to stop these devices from compromising the network by blocking their use. We can block USB devices from being able to connect unless they are a managed resource, so that users can't just plug anything they bring in from home. All USB devices have an ID, which can be registered with a central authentication server to check before a computer allows it to be used. Of course this needs third-party software, but can be done quite easily. We can also block devices from being able to obtain an IP address or connect to the corporate network in the first place. We shouldn't have a free-for-all attitude on the network. It should be locked down to approved devices only. Only managed devices can connect and they will have to authenticate.

I think it’s asking for trouble to allow users to connect their own private devices to the network or services. I don’t see how you can comply with any standards or your own security policies when allowing this, as you don’t know what’s connected or how it’s configured. Even if they are secure (a very big IF), by not knowing the configuration or being able to audit it, you are surely in violation of any accreditation or certification that you may have because you cannot test or 'prove' your compliance.

Compliance does NOT Equal Security

Comodo Vision Video Blog

Responsibility for the notorious Heartland Payment Systems data breach late last year has been debated recently, with Heartland’s CEO suggesting that their PCI auditors let the firm down, while the auditors insist they can’t be responsible for checking absolutely everything. This case brings to light the reality that absolute security is an impossible goal, and that audits are only as good as an organization’s vigilance in following proper security procedures after the audit has been completed.

See my second video blog here.

Mobile Device Data Breaches

Comodo Vision Video Blog

Several recent data breaches at major enterprises and governmental agencies stemmed from the loss or theft of mobile computers and USB drives. While encrypting the data on these devices isn’t a bad idea, the larger question is why was sensitive personal information stored on the mobile device in the first place?

See my first video blog for Comodo Vision here.

Data Anonymisation to prevent Data Leakage

With data leaks constantly in the news, I thought I would write a quick blog post about data anonymisation. The problem seems to be that people think it's perfectly acceptable to walk around with sensitive information on mobile devices and removable media. The solution, according to common thought, is to encrypt those devices. This is a solution that should be adopted, but after the more fundamental problem has been addressed. It should not be possible or necessary to store raw sensitive data on mobile devices or removable media!

Assuming that you need the data for business intelligence purposes and that the IT department can't or won't (for some good reason) allow this to be done online through a secure connection, then you must anonymise the data first and then encrypt it. Why do you need to know the names, addresses and credit card numbers of your customers when on the road TK Maxx? Why do you need the names, addresses, dates of birth, national insurance numbers, salaries and bank details of your employees when away from the office UPS? I'm afraid, that the only reason I can think of to have the non-anonymised data is for fraudulent purposes (please send me a comment if you can think of a legitimate reason).

Drawing from Pierangela Samarati's session at IPICS, I'll give a very brief overview of data anonymisation. There are two basic techniques to anonymise data: generalisation and suppression. With generalisation, we use a more general value in place of the specific value, e.g. birth year rather than birth date, postal district rather than full postcode (KT1 rather than KT1 2EE), credit card issuer rather than full credit card number (1234 56** **** **** rather than 1234 5678 9012 3456), etc. Alternatively, we can suppress the sensitive information by removing it totally.

Now there is a whole academic discipline surrounding data anonymity and how to achieve k-anonymity that I won't go into here. I'll just look at what the above means to data such as a normal company might want to use for business intelligence reasons, rather than surveys and data gathering purposes. In this sense, we are trying to protect the privacy of our customers, employees, etc., above all else, rather than have the minimum anonymity possible for the data set. I will use the following table to illustrate the anonymisation.

Name	DoB	Postcode	CC No.
Alice	02/02/64	KT1 1AB	1234 5678 9012 3456
Bob	16/02/64	KT1 1BC	1234 5678 9012 3467
Charlie	08/04/64	KT1 1CD	1234 6778 9012 3478
David	02/04/66	KT1 1DE	1234 6778 9012 3489
Edgar	04/04/66	KT1 2AB	1234 6778 9012 3490

There are many schemes for anonymising this data, but I'm going to concentrate on Attribute Generalisation combined with Attribute Suppression. This basically means that we will generalise each value at the attribute level (i.e. the same level of generalisation will be applied to all values). Secondly, we will suppress any attribute that uniquely identifies someone. Using minimal generalisation we would get the following table. ('-' denotes suppressed data and '*' denotes generalised data)

Name	DoB	Postcode	CC No.
-	**/02/64	KT1 1**	1234 5678 9012 34**
-	**/02/64	KT1 1**	1234 5678 9012 34**
-	-	KT1 1**	1234 6778 9012 34**
-	**/04/66	KT1 1**	1234 6778 9012 34**
-	**/04/66	-	1234 6778 9012 34**

We have had to suppress Charlie's birthday, because she was the only one born in April 1964. Similarly, Edgar is the only one who lives in KT1 2**. However, we haven't achieved anonymisation here. If we know Charlie was born in April 1964, then this date doesn't appear in the table and only one date is suppressed, so we know her tuple in the table. Similarly, if we know Edgar lives at KT1 2AB, then we know that his is the last tuple. The credit card details should be generalised more than this as well, as others may store the last four digits of a credit card number, so it may be possible to cross reference. Also, why do we need their credit card number for business intelligence? Surely issuer is good enough? So, we can do the following.

Name	DoB	Postcode	CC No.
-	**/**/64	KT1 ***	1234 56** **** ****
-	**/**/64	KT1 ***	1234 56** **** ****
-	**/**/64	KT1 ***	1234 67** **** ****
-	**/**/66	KT1 ***	1234 67** **** ****
-	**/**/66	KT1 ***	1234 67** **** ****

This gives us a full count of customers, their geographic locations, age and credit card issuer. I suggest that this is enough information to cover most queries that you may wish to run for business intelligence purposes and, therefore, the maximum that should ever be stored on a mobile device or removable media. This data should also be encrypted.

Of course, this doesn't solve all problems. What if you know Edgar was born in 1966? You now know his credit card issuer, which enables you to launch a directed phishing attack on him. Data Anonymisation can fail in the face of attack, particularly when there is external knowledge, which you have no control over. The moral is, don't store sensitive data on mobile devices or removable media. If this really isn't possible to avoid, then you must anonymise it first and encrypt it.