In this piece, I want to share some lessons learnt about how a government organization planned for the fallout when its mobile technology security did not work to plan. I’m writing a short series for InfoSec Review about my experiences while working as an IA security professional for the British government. Some mystique remains about the workings of any government. There is still an assumption that they must have different (and better) ways of doing things. As I’ve shown before, this is increasingly a lessening factor so far as technology goes. All of society has come to rely on the same technologies and has built up similar expectations of how these can be used. As my civil service career wore on, the idea of an exclusive and unfathomable government machine was increasingly being challenged, not just from the leveling effect of technology, but from the laudable belief of politicians that the government services ought to treat citizens as the private sector treats customers. This was ideal, though some well-publicized failures of government IT projects bit into the civil service’s reputation and did not help us demonstrate our new, more customer-focused side. One expectation of the more go-ahead government managers was that increasing flexibility from new technology could quickly be taken up in government. In particular, the use of devices that did away with the need for desk-bound working must have been very exciting to some of them. I’ve written here http://url.ie/h1qf about how this movement manifested itself in the deployment of Blackberry devices, and I wrote here http://url.ie/h20x about why a lack of tolerance – or perhaps fear – of risk can act as a negative catalyst for embracing new ways of doing things. There is an upside to the fear of risk taking. Government security officers generally keep decent records of security incidents and failures, not least because they are ultimately accountable to that most fearsome cockpit, the UK Parliament. Here, the sight of lawmakers taking chips out of the government’s record is a spectator event. Government security officers also have opportunities to network with each other quite a bit, and that can help flatten out their responses to security management. This helps government security officers to get a generally realistic playbook of what might go wrong, and the advice they give senior managers is usually hard-nosed, though perhaps less comforting to those seeking out new ways of working. Back in 2001, I was asked to give a presentation at a mixed public and private sector seminar called ‘enabling confidence in e-Government’. At that time, mobile working had only just moved beyond the laptop, and I was allocated a segment about ‘protecting the office of the future: securing mobile working’. Doing some research on this, I came across a statistic which I could hardly believe myself, and when I fed it to the audience, there were audible gasps (so I hope it was right!) Unfortunately, my presentation is no longer available, but that shock statistic was the number of cellphones (at that time unlikely to hold any data other than contacts) left behind in London taxis and handed in by drivers (they have a reputation for honesty). I did not think it at the time, but this would have been a very useful building block in the first line of a fact-based risk assessment for the loss of mobile devices. It is these sorts of publicly available data that should be the first brick when building a strategy for handling the loss of mobile devices and media. Risks before countermeasures Having established that mobile devices – with at least some sensitive data on them – will certainly be lost, the next step is to put realistic countermeasures around the inevitability of that happening. At this point, the technically-minded sort of security officer can damage the security cause by insisting on strong technical controls, like encryption. Though the application of encryption has become much more widespread and is easier to administer than it was when I gave my presentation, any sort of security control can threaten – sometimes just by appearing to threaten – the usability of a device. Encryption or other technical countermeasures may well be an answer, but my experience was that as far as possible, it was best to stick to the line that you wished to ensure that all security risks were identified and allocated to an individual with responsibility for them. Once all risks had been so allocated, you should find that the individuals will hesitate to sign them off without some assurance that countermeasures – including technical ones – have been installed. This, I suggest, is the correct point to press for solutions that can impinge upon functionality. The chances are that the risk-holder will support your sensible solutions rather than seeing you as a roadblock to deploying new technology. And that can happen if you press your technical security credentials before you demonstrate your grasp of risk management. Training the handlers Though not typically seen as a countermeasure, staff awareness is actually the first line of defense when it comes to working away from the office with corporate technology. It is also perhaps the most difficult aspect of security to get right and the least measurable of all. I will be writing a separate piece on my experiences of measuring the effectiveness of security awareness programs. There are numerous choices for security officers to ensure security messages get over to staff; the most traditional (and possibly least effective) of which is the stand-alone book of security rules. Very often these are poorly drafted, not up to date with the latest risks and contain no worked examples of real and recent incidents which staff can relate to. Some managers may even be tempted to use scare tactics, emphasizing all the bad things that might happen to you if you lose an iPhone with anything ‘company ‘ in it. That might protect your organization legally, but it probably won’t lessen the risk of loss. Even the most carful people lose things, and those who are less careful are also less likely to read and follow rules. A slower-burning alternative is to develop modern office communications services to increase the frequency of security messages, including the flashing up of real – including learnt – examples of incidents that relate directly to your employees and their experiences. I’ve written elsewhere (http://url.ie/h211)about keeping security awareness fresh and relevant, but I believe that using modern information systems to publicize security issues is one of the big advantages over the old ‘briefings and books’ approach to staff security awareness. In particular, it is no longer necessary to rewrite the security handbook every time security officers must install some new threat or lesson learnt. The electronic format also encourages staff feedback and an atmosphere of discussion and dialogue about risks, rather than a command and control approach that could alienate staff from the organization’s security objectives. More importantly, it could even make staff afraid to report promptly when things do go wrong. Weak reporting systems undermine good risk management The failure to respond to incidents can create a false sense of security by not incorporating existing and emerging threats into risk management processes, by overlooking vulnerabilities and by failing to ensure that timely corrective actions are taken. Security officers do needto do some work to ensure a good flow of prompt and accurate reports of incidents. They should also be handy at refining the raw data from specific incidents into lessons learnt, in ways that can quickly be absorbed by senior managers. This should be done in a way that will reassure them that theorganization’s approach to information risk management is working. As I have said already, the reassurance of senior managers forms a big part of a security officer’s unspoken duty. This information flow can break down at various critical points. Here’s some to look out for:
Failure of a member of staff to report that something has gone wrong (this can be due to anything from not having a well-publicized 24-hour number to call, or to fear of consequences for making such a call).
Failure of a security officer to respond appropriately and promptly when something has gone wrong (causes could include lack of understanding of an office process and failure to see through the consequences of an event or sequence of events due to a lack of understanding of business procedures).
Failure of senior staff to endorse new processes and procedures that could prevent repetition of the incident (perhaps the management board doesn’t organize their time well and fail to spot the consequences of a security lapse).
In my last piece (http://t.co/92I3oNbhsJ)I gave the example of a highly publicized security incident that gave force to a string of government reviews, changed procedures and even led to resignations. In that case, removable media was lost and the failure of a prompt and effective response (as a result of failures of risk evaluation and basic procedures) had far reaching consequences. Of course, not all incidents are like that one. But well-developed and responsive mechanisms are needed to ensure that all incidents are evaluated for their possible consequences, without creating an atmosphere that could lead to a significant incident being unreported – and thus overlooked. Plan to Fail As a primary principle, assume that accidents will happen. Plan to ensure that the response is proportionate to the consequences. Nothing can quite fend off embarrassment of losing data, but it is more important to ensure the consequences of the data loss are managed correctly. For example, a corporation that has compromised its customer data should be ready to promptly and frankly tell those affected about what has happened and what the company proposes to do about it. It also pays to have, as a contingency, a resilient public information line on hand to reassure and inform affected customers. An organization’s reputation can be upheld even in tough times if they show they have been open and honest in the handling of private data entrusted to it. Ideally, it should be ready to submit their responses for independently assessment, too. The less effort that is put into proper risk management, staff education awareness, and incident response management, the more effort that will be needed to clean up the mess when something goes wrong. If you are a security manager, then there will be an expectation that much of your time will be taken up in fighting these sorts of situations I came to realize that incident management is very much a specialty, especially valued in bigger organizations, but I could not help feeling that my best efforts in managing incidents were in managing the expectations about security countermeasures, ensuring that there was a decent approach to security awareness and supporting a clear response framework against the consequences of any security failures. The priority here was to ensure that no consequences were missed, that senior managers took an interest in the outcomes and that lessons learnt were incorporated into both the organization’s risk management profile and its security awareness programs.
