You say it's 'Security Best Practice' - prove it!

Over the last few weeks I have had many conversations and even attended presentations where people talk about 'Security Best Practices' and how we should all follow them. However, 'Best Practice' is just another way of saying 'What everyone else does!' OK, so if everyone else does it and it's the right thing to do, you should be able to prove it. The trouble is that nobody ever measures best practice - why would you? If everyone's doing it, it must be right.

Well, I don't agree with this sentiment. Don't get me wrong, many of the so-called best practices are good for most organisations, but blindly following them without thought for your specific business could cause as many problems as you solve. I see best practice like buying an off-the-peg suit - it will fit most people acceptably well if they are a fairly 'normal' size and shape. However, it will never fit as well as a tailored suit and isn't an option for those of us who are outside the bounds of 'normal' according to the retailers.

The real problem is that no company is actually normal, i.e. exactly the same as other companies. Best practice is very useful for small to medium sized enterprises (SMEs), who can't afford to have an expensive security team on hand permanently - security architects and strategic security leaders that can actually turn security into a business enabler demand 6-figure salaries. In the absence of these people, you have little choice other than to follow everyone else or hire consultants in to advise on what really matters and what is right for your business.

Large enterprises, however, can afford in-house security teams and should be demanding more from their security leadership than simple, formulaic repeating of the toolsets that everyone else deploys and that they've seen implemented in their previous organisations. So why do large enterprises follow best practice without much thought? To my mind it's for one of two reasons: it's either that they know no better, or it's so they can defend an audit and protect their jobs. For example, the ICO won't fine you after a breach if you've followed best practice, but if you've done something unusual then you'll have to justify it and defend it. If you have done the job properly though, this defence is easy as you will have gone through a logical set of steps to arrive at that solution. It is a much stronger defence to be able to justify your deployed capabilities rather than just saying that everyone else does it.

Technology should be the last thing that you decide upon once you know what your control objectives are, which you will only be able to articulate when you really understand the specific business in front of you and the strategic objectives. Then you have to look at the threat scenarios for your business and balance the risks accordingly. Don't follow the crowd blindly; I encourage you to strive for the best solution, not best practice.

The Disconnect between Security and Senior Management

There is often a fundamental disconnect between security professionals and senior management. As I have stated in a previous post about slips, mistakes and violations, if senior management don't 'buy in' to security then nor will the rest of the organisation and ultimately it will fail. Middle management want to be senior management and will model themselves on them, often seeing the breaking of rules as a mark of status. So, it is vital that senior management lead by example.

Unfortunately, it is often very hard to get senior management to 'buy in' to this concept and not have a 'them-and-us' attitude of there being those rules that apply to the rest of the organisation and those that apply to them. This is as much the fault of the security professionals as senior management though. Security professionals have spent so long saying "no" to everyone and stalwartly refusing to budge or see someone else's point of view that people have stopped listening and taking note. To be honest, rightly so.

If you want someone to change their point of view or come round to your way of thinking, by far the easiest way is to sell it to them as a positive thing that will be beneficial to them and 'bring them with you' rather than dictate. Saying "no" all the time is not positive and will ultimately fail as people will stop listening. Make it personal to them and put it in terms they understand. Relating security to risk and money will usually be more successful.

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!

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.

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.

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.

The PCI DSS and Why It's Relevant to Everyone

Many of you will know that PCI DSS stands for the Payment Card Industry's Data Security Standard and most of the rest of you have probably heard of it and wondered what it was. You may immediately say I'm not interested in the Payment Card Industry and want to navigate away, but just before you do, you should know that many of the 12 recommendations are relevant to all. Actually the PCI DSS recommendations are mostly common sense that we should all be implementing anyway. I'll give a quick overview of the big 12 and how these can be applied to all networks in this blog.

According to the PCI Security Standards Council, "The core of the PCI DSS is a group of principles and accompanying requirements, around which the specific elements of the DSS are organized." The 12 recommendations that they put forward can be generalized as follows and should be adhered to by all organisations:

1. Install and maintain a firewall configuration to protect private/sensitive data
2. Do not use vendor-supplied defaults for system passwords and other security parameters
3. Protect stored data
4. Encrypt transmission of private/sensitive data across open, public networks
5. Use and regularly update anti-virus software
6. Develop and maintain secure systems and applications
7. Restrict access to private/sensitive data by business need-to-know
8. Assign a unique ID to each person with computer access
9. Restrict physical access to private/sensitive data
10. Track and monitor all access to network resources and private/sensitive data
11. Regularly test security systems and processes
12. Maintain a policy that addresses information security

Dealing with each very briefly, I’ll try to show how these can be applied to a ‘normal’ network rather than one involved in dealing with payment details. Firstly, we all know that we must have a firewall and block access from the outside world. However, just having a firewall isn’t enough, if it isn’t configured and managed properly. Every port and service open through it must be justified and have clear documentation. There must be policies and procedures in place to control the opening of ports and services through the firewall so that each one can be assessed for its impact on the overall security. Wireless networks should also be separated from wired networks by the firewall – this doesn’t mean that the wireless network has to be unsecured from the Internet or that it has no access to the wired network, just that restrictions and filtering should be in place between them. Obviously, there should be no access from outside the network into the network, as a DMZ should be set up for all public access machines. Finally, personal firewalls should be installed on all mobile machines and hardware firewalls installed at users’ home premises if external access is to be allowed.

The second should be obvious and doesn’t really need any explanation, other than to say disable as many features as you can and don’t allow any configuration or management from outside your network. There are ways to enable secure remote access to the network, thus allowing for management of servers and devices to be achieved from within the network.

The third and fourth requirements go together and mean that strong authentication is required and permissions set appropriately. However, we should also implement encryption on highly sensitive data and removable devices/mobile machines, with proper key-management processes, and Digital Rights Management (DRM) to prevent digital leakage. All data transmitted across public networks should be encrypted (whether sensitive or not).

Is there anyone who doesn’t follow point 5? You’d also think that the zyxst (6th) recommendation would be followed by all organisations, but this isn’t the case. You must have proper patch management procedures as these are critical to securing potential vulnerabilities. However, how many times do you see that the state of the server or service is lagging behind the latest patches? I have seen many commercial outfits developing web applications that are not secure as security is an afterthought and not embedded in the development cycle. This means that, even if you don’t write your own applications, you must check third party applications that you intend to use on your network. Make sure that they have been developed using secure coding guidelines and have been independently tested. An example of not taking it for granted is Apple, who has no formal security program (ref.).

The seventh recommendation sounds obvious again, but it isn’t followed even by many of those covered by the PCI DSS. Restrict access to your data by business need to know. Does your network administrator need to know everyone’s personnel details and payroll? No, so make sure they don’t have access. This is an often overlooked problem, but many organisations rely on people not looking rather than actually protecting the data. How many examples can you quote of companies, and government organisations, losing confidential data that they should never have been able to access? An example springs to mind of a large retailer that lost the names, addresses and credit card numbers of millions of customers, which were copied onto a laptop. Why would you need all this data? Presumably you want it for business intelligence purposes and data analysis. This can, and should, be delivered live through secure channels, not done from a local copy. Why do you need their credit card number though? The point is that it shouldn’t be possible to extract this data and store it on the laptop in the first place. The next two are also related to this and a previous point of requiring strong authentication, which means that you must not allow sharing of user accounts by employees (especially executives giving passwords to PAs!).

Recommendations 10 and 11 deal with monitoring and testing the network. In order to make sure that your system is functioning as expected and that your security mechanisms are appropriate and don’t have vulnerabilities, you need to monitor the network and regularly test it for vulnerabilities. Every time a significant change is made to the network, its impact on the network should be assessed and tested.

The final recommendation is to maintain an information security policy. This must cover all forms of information though, not just electronic. It should be very clear and all employees should be trained in its content and abide by the policy or face punitive measures. Employees should have to sign a copy of the security policy, stating that they have read it, understand its content and agree to abide by it. However, this has no teeth if you do not adequately train all of your employees and update them regularly on the policy and any changes.

The PCI DSS recommendations can and should be adopted by all organisations, not just those involved in payment card transactions.

Obstacle Poker for Security Assessments

I was talking to Vic Page, a colleague of mine, today about various things and he told me about one of his PhD deliverables on 'Three Card RAG' or 'Obstacle Poker' - very interesting concept that he has come up with. During our discussion, we came up with an embryonic idea for using his concept to aide security assessments of organisations. Before I can describe it I need to extract a few concepts from his 10-page paper in the BT Technology Journal entitled "Security risk mitigation for information systems".

In the paper he describes the Security Obstacle Mitigation Model (SOMM) for developing trustworthy information systems. He also defines some terminology - a subset of which I have reproduced here (his paper is an interesting read):

• mitigation - a mitigation is a procedure that will counter the effect of an obstacle


• obstacle - an obstacle is something that, should it occur, will obstruct a trust assumption and affect the CIAA security requirements - obstacles are caused by malicious or inadvertent use of the operational information system


• RAG code - RAG codes form an intuitive 'traffic light' approach to ranking the ability for load-bearing and the vulnerability of a trust assumption (RAG is an acronym for Red, Amber and Green). R signifies stop and mitigate, A signifies proceed with caution and G signifies continue with trust

So how is this relevant to security assessments particularly rather than information systems in general? Well, it is the way he is applying it that becomes interesting for the security assessment arena. He has moved this concept into the field of agile development and taken the Scrums process of planning poker and made it more accessible for other fields.

Now a quick background to the security assessment field is in order. The majority of security assessment strategies are technology focused and concentrate on system evaluation and tactical issues. This can lead to point solutions and, therefore, gaps between countermeasures. Obviously we need the vulnerability assessments and information system audits, but these should follow an Information Security Risk Evaluation. Schemes like Octave, although big, do follow an organisational evaluation, focused on security practices and strategic issues. The top down approach is driven by business issues and objectives leading to protection of what needs it and awareness of risk. Most other bottom up security practices start with individual components and computing infrastructure, seeking the technological 'silver bullet', which leads to protecting what can be protected rather than what needs to be protected. Of course this is an ongoing cyclical process.

So, what is obstacle poker and how do we incorporate it into an information security risk evaluation? Well, the principle is that representatives of all roles must be included in an information security risk evaluation for it to meet the needs of the organisation. Too often security assessments are left to the ICT departments and technologists, who don't necessarily know the business processes at play. Unfortunately, the people working in the organisation who aren't part of the ICT team usually have little or no knowledge of the technical landscape or what's possible/feasible. It needs everyone at the table and they need to speak a common language. Interpreters, i.e. consultants, can be brought in to help, but there still needs to be a simple way to converse.

The idea of 'Three Card RAG' is that an issue is discussed and then all the members of the team will rate it with the RAG scale given above. This is done by issuing each member of the team three cards - one Red, one Amber and one Green. Each member picks a card and then everyone reveals their cards at once. If everyone agrees, then that is considered the state of play and actions are taken accordingly. If they do not agree then further discussion can be entered into and another round completed. The idea being to come to a consensus between the technical experts and the users of the system quickly and efficiently. Those that are more obvious will be dealt with very quickly, those requiring more discussion will be given a fair hearing.

This principle can be used in information security risk evaluation by identifying the threat ratings and consequences of risks. We all know that a Threat + a Vulnerability = Risk to an Asset, but how can we categorise these when ICT and management departments can be approaching this from very different standpoints? Is the system that seems critical to the ICT department actually critical to the business or not?

Threat ratings have the following defined ranges: Negligible, very low, low, medium, high, very high and extreme. They are quite well defined in terms of how often they are likely to occur, from unlikely, through likely to occur every 6 months or less for medium, to likely to occur multiple times each day for extreme. These threat ratings must be ICT lead, but not exclusively controlled. If everyone holds a green card then it can be classified as very low or negligible. Amber would denote Medium and red would denote very high or extreme threat rating. Mixtures of cards can result in the low or high ratings being used if there is still no total agreement after a few rounds. The consequences are where the ICT department may step back a little. These are defined by the Australian Government's Defence Signals Directorate as:

• insignificant - can be dealt with by normal operations
• minor - could threaten the system’s efficiency or effectiveness but can be dealt with internally
• moderate - does not threaten the system, but could cause major review and modification of operating procedures
• major - threatens the continuation of basic functions of the system and requires senior-level management intervention
• catastrophic - threatens the continuation of the system and causes major problems for the organisation and customers

This is where Three Card RAG really comes into its own. Getting agreement on this scale can be very difficult in organisations. However, with a simple traffic light scheme, everyone understands the system and agreement can be reached much more easily between all the stakeholders. Simply put, if it's red it's a priority, amber is secondary and green can be safely ignored until the next iteration (N.B. not ignored completely or never discussed again, just not dealt with in the current round of the cycle).

InfoSecurity Europe 2009

Well, a couple of weeks ago I went to InfoSecurity Europe 2009 at Earl's Court, as I do every year. If you've never been, but are at all interested in network and information security or are looking for vendors, then I highly recommend visiting. To my surprise, and for the first time I can remember, Microsoft wasn't there. Apart from that, however, all the usual players were there and, to be honest, it was all much the same as before. There was no new emerging technology or hot topic, just new developments of old technologies. A couple of years ago we had the hot topic of 'social engineering' and 'securing the user'; ok, we all knew that the users were our weak link and phrases like "we spend all our time securing the first 2000 miles and forget about the last 2 feet", and "our network would be totally secure, reliable and fully functional if we didn't let users login", have always been commonplace, but there were new mass threats, new education programmes and new tools at the disposal of net admins to deal with them.

However, this year was different; nothing really sprang out. OK, cloud computing and Software-as-a-Service (SaaS) has expanded and matured, but other than that we see the same products and services as before. What amazes me is how some vendors and speakers can get it so wrong and don't appear to understand the actual level of security offered or operating environment in which their products will be used. I'm not going to list actual vendors here, but how can an encryption solution for mobile users that doesn't encrypt the data at rest be viable? Encrypting network traffic is commendable, but not the only safeguard required. What if they now lose their laptop, mobile or pen drive? A secure USB pen drive vendor admitted, when questioned, that files were decrypted into the C:\Temp folder while in use, then deleted after encrypting for storage on the drive again. They couldn't tell me if this was a secure delete or a simple removal of the pointer in the file allocation table as normal. Regardless of the deletion process, however, how many applications can read and write to that folder? What's to stop me from writing a very small bit of code to monitor that folder every few seconds and take copies? This might be secure enough if it is on a corporate machine, but why not just store the file on it then and not bother with the drive?

Similarly, email security is always a problematic area, with almost no solution fitting the technology properly. The big advantage of email, and the reason we all use it, is that it is independent of firmware - i.e. it doesn't matter what hardware, OS or email app we use, it still works. Unfortunately, security was never built in to email, so every email is like sending an electronic postcard. However, I would argue that a solution that only allows you to send encrypted email within your organisation is of limited value. What about all your customers and partners? There are also still solutions that store your files on their servers and send a link to the recipient. Why trust your files to them? I asked several vendors how they deal with password transfer, only to be told that they don't. "It's up to the user how they tell the recipient what the password is," was a common reply. We know users are unreliable, why leave it to them? I had to transfer some confidential files to someone via email recently (the only transport method they would accept), only to be told that they didn't want the hassle of decrypting it, so could I send them in plaintext. Having got over that hurdle, they wouldn't give me a mobile phone number so that I could transfer the passphrase via a call or SMS (as people seem to need them written down), asking me to email it to them. I know there are technologies out there to solve these problems, but they aren't without any problems.

This is turning into a bit of a rant and I'm getting off topic, so back to InfoSec. I was pleased to see that there were some voices of caution out there about the wholesale adoption of virtualisation without considering the security implications. One that springs to mind is Steve Moyle who has produced 10 points to consider implementing on his blog here. Virtualisation is a good technology for a number of reasons, but it does bring in new security threats and it must be implemented with these in mind and secured accordingly. I do also think that cloud computing and SaaS could be very important to SMEs (Small to Medium-sized Enterprises) who don't have the in-house expertise or large budget. They can still have large enterprise-level configurability and security, without the overheads. Finally, people seem to be taking information governance and user education seriously rather than just paying lip-service to them. In all, the show was encouraging, but many vendors are not quite there yet, which only goes to highlight that the majority of organisations are not taking the new threat-landscape seriously enough and countermeasures must be lacking.