IPICS 2010 Network Security Slides

My slides on Network Security and Steganography, presented at the Intensive Programme on Information and Communication Security (IPICS) 2010 can be downloaded below. The topics covered under Network Security are: Access COntrol Devices, Firewalls, Network Protection, Network Authentication Protocols, TLS, VPNs & Remote Access. The Steganography slides cover examples of: Image, Network, HTTP and Twitter Steganography.

A PDF of the Network Security slides can be downloaded from here.

A PDF of the Steganography slides can be downloaded from 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.

IPICS OCTAVE-S

OCTAVE-S stands for Operationally Critical Threat, Asset and Vulnerability Evaluation for Small organisations. It is a version of the full OCTAVE methodology aimed specifically at small to medium sized organisations, i.e. those with up to 100 employees. OCTAVE is a risk-based strategic assessment and planning technique for security. It is a top-down approach that is driven by the business's missions and objectives, and is not technology focussed. OCTAVE-S is simply a streamlined version of OCTAVE, with simple worksheets and less expertise required. The outputs of OCTAVE-S should be similar to those of OCTAVE, it is just that it may be possible to shortcut some of the process in smaller orgnisations. OCTAVE itself is designed to be applicable to any organisation, no matter how large.

The Main OCTAVE principles are as follows:

• Core Information Security Risk Evaluation Principles
  • Self-directed
    • The organisation takes responsibility for the evaluation
    • The organisation makes the decisions
  • Flexible / adaptable in the face of...
    • Changes to best practices
    • Evolution of known threats
    • Technical weaknesses
  • A defined process
    • Responsibilities are set out and assigned to people
    • How activities should be performed is documented
    • Standards are set for documentation/artefacts : tools, worksheets, catalogues etc.
  • A continuous process over time
• General Risk Management Principles (general principles beyond InfoSec)
  • Forward looking – proactive
    • Identify future asset that may be significant
    • New classes of threat
  • Focus on critical few
    • Resources are always constrained
    • Avoid spreading effort too thinly
  • Integrated management
    • Information security as routine consideration for general business strategy
• Organisational / Cultural Principles
  • Open Communication
    • Information sharing : avoidance of blame/judgment
  • Global perspective
    • Consult widely and integrate all views
    • Widen perspective to organisational goals
  • Based on teamwork

To find out more about OCTAVE-S visit the website, where you can download the Implementation Guide, which contains introductory materials as well as the actual guidelines and worksheets.

Lack of true Identity Verification forces need for EV SSL Certificates

What are EV SSL Certificates? Simply they are Extended Validation SSL Certificates. What does this mean? Well, simply put the Certification Authority goes to more lengths to validate the identity of the person asking for (paying for) the certificate. The EV SSL Certificate then will make the browser address bar go green to certify that this really is the site you think it is and not a phishing or pharming site. It gives the user a very visual check of the validity of the website that they are using.

Isn't this what Digital Certificates were supposed to do in the first place? Yes, but the Certification Authorities were more interested in taking people's money than verifying that they actually were the people in question. This led to almost anybody being able to sign up for a certificate claiming to be almost anybody. This, obviously, isn't a workable situation, so EV SSL Certificates were introduced to do the intended job, only at a higher price than the standard SSL Certificate (in part due to the actual identity validation performed no doubt). That being said, they are not expensive in the grand scheme of things and should be used far more widely than they currently are - for example NatWest still doesn't use an EV SSL Certificate at the time of writing this, instead they have ended up implementing Trusteer's Rapport at a much higher cost.

To give you some idea of cost of a digital certificate, Comodo's price is £214 per year (US$359/€359) for a single fully qualified domain name (i.e. per website); this includes their 'Corner of Trust' logo. Compare this with somewhere near $1 per customer for Trusteer's Rapport or even hosting fees and business profits! Admittedly, their cheapest SSL Certificate is only £41.95 per annum, but is £214 too much to ask when you are giving customers peace of mind, assurances over authentication and tackling phishing & pharming?

Why aren't normal certificates secure? Well, the problem is that most Certification Authorities don't do very much checking. Usually they check your domain name by sending you an email to an address that has the same domain name extension. All this says is that someone who has access to an email address on that domain wants to set up a secure web server. They don't actually check who you are. They are more interested in whether you will pay than if they should issue the certificate. This was demonstrated at IPICS today, when it was shown that VeriSign had given out a Digital Certificate to someone using the name William Gates! They have also fallen for scams, where they were duped into issuing a code signing certificate for the Microsoft Corporation by someone proving the point that they are not careful enough.

I decided to see if this was the case with other organisations, and it is. I have set up an SSL certificate just by being able to view an email sent to an address on that domain. I also wanted to know if I could be Steve Ballmer - the new Bill Gates. So, I set up an email account: Steve.Ballmer@live.co.uk using details about him, such as his year of birth: 1956. I then decided to try Thawte out, as they provide free email certificates for personal use. Sure enough, after entering the data below, I was sent an email to my address with codes to verify myself. I now have a digital certificate to sign emails from Steve.Ballmer@live.co.uk.

Surname: Ballmer
Forenames: Steve
Date Of Birth: 1956/03/24
Nationality: the United States
Email: steve.ballmer@live.co.uk
Where were you born? Detroit
Where did you go to school? Detroit Country Day School
First company you worked for? Procter & Gamble
What is your spouse's Name? Connie Snyder
How many children do you have? 3

Now, Thawte has a little trick up its sleeve here, which aides security. Before they will assign the name Steve Ballmer to the certificate, I must pass their Web of Trust, i.e. I must convince some other users that I am indeed Steve Ballmer first by meeting them face-to-face. However, if I could supply them with details such as passport number and social security number, then I'd be set. So, I can still sign my email, but if users look closely at the signature and check the certificate, they will see that I haven't been verified. However, if they don't actually look at this carefully, and with knowledge of what it means, then they will be fooled into thinking I really am Steve Ballmer. Why should the ordinary user know about this? Comodo and VeriSign, on the other hand, provide no such backup. So, I can now sign my email as Steve Ballmer. Here's my Public Key for Steve Ballmer from Comodo showing that I really am Steve Ballmer!

This isn't really good enough in this day and age of phishing scams.

Post Script Edit
Two things have happened since writing this blog post. Firstly, I have become aware of an attack on SSL Certificates by using a null value inserted in the domain name to trick the CA into issuing a certificate on an invalid domain. For example, www.natwest.com[null value].phishers.org will result in an SSL certificate being issued for www.natwest.com to the phishers.org site, which will appear valid in many browsers (but not all). Link to blog post. This won't (shouldn't) affect EV SSL Certificates though, only the Domain Validated ones.

Secondly, Comodo, to their credit, do admit that this is a problem and are takling it. They have sent me a link via email to a video clip, which in turn links to more information. That can be found here. The bottom line really is that these EV certificates are more secure, don't cost that much and should be the norm. As an industry we should be educating users into recognising and looking for these security features.

IPICS Risk Assessment Slides

These are my slides on Information Security Risk Assessment, presented at the Intensive Programme on Information and Communication Security (IPICS). The topics covered are: the System-Holistic Approach to ICT Security; Risk Assessment approaches, strategies & terminology; Three Card RAG / Obstacle Poker; OCTAVE^® - Operationally Critical Threat, Asset and Vulnerability Evaluation.

A PDF of the slides can be downloaded from here. (updated)

I will publish more information on the topics covered in due course (and if anyone asks). However, more information on Three Card RAG / Obstacle Poker can be found in a previous blog post.