As I mentioned in a previous post, use of PGP Desktop to encrypt all laptop disks is compulsory at IBM and is enforced through our end-user computing standards.

The default power management configuration for laptops often just suspends the laptop when the lid is closed or when ‘sleep’ button is pressed. unless the laptop user selects ‘hibernate’ the disk drives are not encrypted. standards dictate that laptop configuration should be changed to hibernate in these circumstances, but how many users actually make the necessary changes?

The comprehensive help documents provided by IBM for configuring the whole disk encryption software step the user through making a ‘rescue disk’ to allow recovery in the event of a lost encryption password. So, how many users take any precautions to protect that?

Going back to the potential attack against whole disk encryption, it relies on the attacker being able to recover the encryption key from memory dumps or hibernation files, after the disk has been decrypted. Of course, if the laptop is always left safe (ie. powered down or at least hibernating) then that attack vector isn’t available. However, how many users leave their laptop unattended and logged in when they believe the environment is ‘safe’? And, how many leave their laptop unattended before the hibernation process has completed?

The common thread through all of this is that if users are careless, they can inadvertently cancel out any benefits from technical countermeasures. It’s simple enough to describe the exact behaviour that will prevent this. In Public sector security, we call this Security Operating Procedures, or SyOPs for short.

It’s usual to define the IT security risk management process as starting with risk assessment to select the right security controls, followed by incident management to deal with residual risk, invoking crisis management and BCP when required, to recover from the most severe incidents. I strongly believe that SyOP production and security awareness training for end users must form part of the risk management process and must be in place before a service is activated to ensure that the security controls operate as designed and to defend against the sort of attack described here.

As I said in the title, users are the one part of the system that can’t be patched to remove vulnerabilities. It’s vitally important to explain the importance of what we ask them to do and then to reinforce that through adherence to mandatory written instructions, in order to establish the ‘habit’.

…not as I do, as Mrs V1951 the Elder (my Mum) used to say to me regularly.

I’ve discussed before how I went about organising news feeds when I started my new life as an independent consultant. One of the first blogs I subscribed to was the BBC’s dot.Life blog (now renamed “dot.Rory” to distinguish it from posts by US correspondent Maggie Shiels), written by technology correspondent Rory Cellan Jones. That in turn prompted to to join Twitter to follow Rory’s updates. His position gives him great access to what’s happening particularly amongst the vendors and his articles are thorough, well written and humerous.

Both the German and French governments advised their citizens to switch to an alternative browser (Firefox, Opera or Safari for example), implying that the flaw exposed in the attack on Google is common to all versions of the Microsoft browser. However, when questioned the UK’s Cabinet Office, which takes the lead on matters related to digital technology, confirmed that it is directing people to the web site for the Get Safe Online campaign. The advice here is “All web browsers are at ongoing risk to vulnerabilities and as such Get Safe Online’s recommended advice to consumers and small business is always to use the most up-to-date version.” It also suggests that “… there is no evidence that moving from the latest fully patched versions of Internet Explorer to other browsers will make users more secure.”

By comparison, when asked by Mr Cellan Jones, the Ministry of Defence confirmed that, based on advice from the Communications Electronic Security Group, it is considered that IE6 is suitable for use in central government. Later, the Cabinet Office explained further that “A government user working on government systems will benefit from additional security systems unlikely to be available to the average home computer user. These include tools that actively monitor for any malicious attack.”

So, on the face of it, the UK Government is ignoring the advice it gives to its citizens. But is this really as unreasonable as the blog suggests? Let’s look at the issues:

Context: The Ministry of Defence IT systems form the Defence Information Infrastructure (DII), serving 300,000 users on 150,000 end point systems, spread across more than 2,000 locations (fixed and mobile) world-wide. This massive infrastructure is managed by the Atlas Consortium, under a 10 year contract worth £4.8Bn. While the programme has been criticised for slow progress, a National Audit Office report in 2009 concluded that important benefits are being delivered and (unusual for a government IT project) costs are predicted to be within 3% of the original budget approved in 2005.

Assurance: Systems and networks designed for use in front line departments (MoD, FCO, Home Office ..) are:

Built where possible using certified components that have been rigorously tested for correct operation of their security functions, based on the internationally accepted Common Criteria (ISO/IEC 15408);

Subjected to accreditation, to prove that their security functions are adequate to protect the classified information they will process;

Organised into distinct security “zones” separated by specialised devices, which are not available to most organisations. Some of these devices are designed and tested using formal methods like Z or Vienna Development Method (VDM) to mathematically prove the correctness of their security functions.

Restricted Access: Access to these systems is strictly controlled, based on security clearance (granted based on rigorous and repeated vetting checks), “need to know” and finally subject to the formal approval of the system owner. Social engineering played a significant role in the Google attack and this is at least mitigated by these formal processes.

As well as being a front line government department, with special security requirements and the processes and procedures to enforce them, it is also a very large organisation (300,000 users) and faces the same problems as its private sector counterparts:

Inertia: Large organisations are notoriously slow to migrate to later versions. Desktop upgrade programmes are costly, time consuming and riddled with unforeseen complications. That in part is why large organisations didn’t migrate to Vista on the desktop, and why they’ll take their time before moving to Windows 7.

These considerations have to be fed into the change management process. The resulting change (assuming it gets approval) will inevitably delay the already planned packages within the DII programme and will with equal inevitability result in additional costs to the customers (that’s the taxpayer – you and me!).

So, is the Cabinet Office right to claim that the MoD is safe to carrying on using IE6? At least they’re right to draw a distinction between the level of protection achieved through “defence in depth” and what’s available to the average home user. David Lacey, in his recent book “Managing the Human Factor in Information Security”, points out that baseline security measures, a collection of standard proven security controls, is the fastest most reliable (and often cheapest) means for improving security. He compares it with the “trajectory of accident opportunity” described by James Reason in his book “Human Error”. His premise is that multiple, simultaneous failures or compromises would be needed to Allow an attack to be pressed home. Gartner’s Neil MacDonald says that there are 3 lessons to be drawn from the attack on Google:

Run users as standard not administrator

Get off IE6 – using Win7 migration to justify budget if necessary

Use defence in depth at the end point.

In conclusion, for the risk of compromise to materialise, there has to be both vulnerability and the means to exploit it. In the case of the Google attack, neither of these was known until the incident happened – a zero day attack. There also has to be a threat, someone with the means, skills and motive to mount an attack. Again, in the case of Google, this appeared to be a targeted attack. But risk efficiency demands that the cost of the countermeasure be proportionate to the cost of the damage resulting from a successful exploit. For a large organisation (like MoD) replacing the browser isn’t going to pass that test. But careful design and baseline security measures will prevent the hacker from reaching the vulnerable component.