BYOD – A Prequel
History, wrote Norman Cousins, is a vast early warning system. When faced with a security difficulty, it can help us to reach back and to remember how impossible it seemed the first time something similar came up. In this piece, I want to take a look at an early example of the move towards what we now call Bring Your Own Device (BYOD).
I’m very pleased to have joined the team of contributors to InfoSec Institute Resources. My security background is less technical and more managerial and procedural, based upon a former career in the British civil service that included security officer roles at various levels. I’m now a US resident and have set up my own security consultancy here. I hope some of my views on the earlier days of information assurance and security will be useful. All views expressed here are entirely my own, and do not represent the policy or outlook of any organization.
When desktop networking became common during the late 1990s, I seriously looked around for alternative work. The challenges to effective data security just seemed too daunting. But I stuck it out. Then, just as I thought we had a grip on controlling removable media (floppy disks in those days) along came mass storage media. And then it was internet connectivity through the desktop. I was not alone in feeling my security solutions were quickly being outflanked by innovations in data portability, and made even more urgent by increasing demands from seniors that staff use out of the box technology they could buy at shopping malls.
When security colleagues quipped that the only true security was to write something down and lock it up, I quietly sympathized – quietly because I knew that such a view would be picked up very quickly by the technology innovators whose cause was supported by our lawmaker-masters. Britain, they insisted, should show a lead in technological innovation.
A personal inhibitor here was my background as a physical security implementer, which gave me a defensive mentality that got increasingly unhelpful as data portability took off. Another big factor was the lack of a mature risk-assessed approach to security, and the lack of models for the same. Though I believe government guidelines and procedures do encourage risk management, it is a difficult concept to get across without examples of what successful adaptations look like.
And throughout the civil service there is a natural tendency to avoid blame if anything goes wrong, which in turn leads to a risk-avoidance reflex. No management system can absolutely pin this down but it makes innovation secondary to playing it safe. The intolerance of the British media about the failings and inefficiencies in government is another factor: weekend headlines trumpeting the incompetence of civil servants (usually over the handling of personal records) could lead to busy Monday mornings for security staff.
Security officers of all departments generally agreed that they disliked the period right after Christmas. Not just because we all had to go back to work, but because this was a time when numbers of staff had received the latest technology as gifts, and would wanted to use them to make their working lives easier (or as the more cynical amongst us thought, be able to show off their new toys). Typically we would get requests about enabling some newly purchased gift to be synchronized with the on-line office calendar.
Not only was this a technical challenge but it made me worry that the user could already be using their new device’s built in internet and email functionality outside the security envelope. Because these requests were reasonably rare, we could usually pick them off by arguing that the resources needed to allow network access for a non-approved device would be disproportionate. So some other, already approved device (usually a clunky laptop) could do the job. End of story. Then along came the Blackberry.
The arrival of these ubiquitous devices was my introduction to ‘disruptive technology’, which for me is technology that overturns your carefully built-up systems for managing security. In this era of BYOD this may seem quaint, but it was my first experience of a leading edge commercial device being pressed forward for integration through popular acclaim. And it upset our security playbook.
We security officers had believed ourselves very flexible in allowing desktop networking, notwithstanding some differing approaches by departments when they rolled-out their first desktop platforms. We had whipped our security into shape so that our departments could connect their networks to the Internet, giving all staff direct electronic dealings with customers and partners. So the thought of now having to integrate a device with unknown security issues – in a hurry – was exasperating. Surely our senior managers would set up a better order of priorities?
But this was no post-Christmas wonder and it did not go away. What made things more difficult was the traditional structure under which security decisions are reached. The British civil service is quite similar to the US government model, with each department having broad powers to organize all affairs under their portfolio. There is some level of central control from the equivalent to the Executive Office of the President, also by a technical authority (the equivalent of NIST). I would not like to stretch an analogy between State and Federal government too far here, but as a rule most staff in the British civil service operate within their department (‘State’) without needing to be aware of the central (‘Federal’) control.
For many years this independent approach included security. But the increasing reliance upon data rather than traditional paper records created a natural pressure to equalize technology solutions. Security officers from the different departments increasingly came into contact with each other because of the growth in shared networks and this led to more security decisions having to be centralized.
Typically, security decision making involved representatives of each department (like me) meeting together and with the centrist authorities, then passing back the centrist policies to their own department. In practice, this could lead to me pinging between the wants of my senior staff and the edicts of the center.
The silo model of government departments is something that British governments of all political persuasions have been keen to overcome for a long time, but most recently by the creation of an online gateway for the public who are seeking any type of government service (in the past, it was necessary to identify which ministry supplied the service you were seeking before the quest could seriously begin). But though the public should benefit from this one-stop approach to government services, the operation of the back offices supplying the services is still based on the old ‘Ministry for name-of-service’ setup.
Viewers of Monty Python and its ‘Ministry of Silly Walks’ will be aware that the British public – and the rest of the world – have seen the humor in this for at least 50 years.
In its support of Risk Management approach, the government center certainly did a lot of work to highlight the risks to the government network through (as then) untried technologies such as the Blackberry. The ministerial security officers saw some very competent presentations on all of the possible risks to the network from the attachment of devices that had not been put through a rigorous assurance process.
The problem was that the presentations made their point so well that they rather froze any adventurous spirits from taking on these risks and managing them. I think this was unintentional, since few of us would openly admit that we simply did not wish to carry the blame if anything went wrong. At the conclusion of one of these I was grateful to the security officer of another department who, after giving his sincere thanks to the presenter on an excellent presentation, asked how his directors could use the device anyway.
So in summary, senior people wanted to use the latest mobile technology that had not been integrated into an approved network. Integration would take time, so there was a risk that some managers would vote with their feet and use the technology anyway. That would create security vulnerability through the lack of accountability for any data held on unsecured devices.
Though this would be wrong, it was unlikely users could be stopped from doing this, especially since to do so would place their managers (i.e. very senior ones ) in the awkward position of having to tell their own top people to stop using leading edge technology. That would be a clear contradiction of where government lawmakers wanted us all to be. Sometimes being right is not enough.
I did not act alone in solving this conundrum. But it helped a lot once I realized it wasn’t about security taking the position of the reactionary who fears that disruptive technology threatens their comfortable view of protective security. I could see that it was actually all about under-developed approaches to risk management, an area that government was only just adapting to. So I began by extracting security staff from carrying the risk and facilitated meetings between those who sought the technology (senior managers) and those who needed to be convinced that the risks from this were correctly managed (the owners of the government network).
This seems obvious now, but the arguments being bandied between very senior staff and technical security experts were in danger of creating rigid lines, where one side could claim to be representing progress versus reaction, the other side to be representing responsibility against recklessness. Clearly, the two sides had to talk. We began to hope that the emerging Enterprise version of the Blackberry (which uses strong encryption) might form a basis for the technical security solution. When combined with straightforward new user procedures to mitigate the residual security risks, we had the basis of a solution that the two sides could agree.
Though the solution took time to roll out and had to be prioritized amongst other work, the heat began to dissipate. A managed program of work was arranged to ensure that the Blackberry was configured to standards that would be acceptable to the owners of the government network.
Of course, much has changed since the arrival of the Blackberry. In this age of BYOD the challenge is now about instantly enabling any device for work use, and discussions include the value to business of
tapping into employee’s own computing resources. Manufacturers delight in completion over the price, functionality and computing power of the successors to the Blackberry. The market has – probably unconsciously – blown away some of the defenses we could have considered in the past, like prohibiting non-corporate technology on company premises and insisting that only corporate devices be used for work purposes.
On the brighter side, the security enablers have improved. We now have more common use of encryption and readily available ways of ensuring separation between corporate and private data. Security officers also have more open source guidance and templates than ever before about how to manage the security risks of BYOD. Our responses to securing this sort of runaway technology must continue to evolve. But I think managing the risk will always be at the core of the security solution.
Lessons learnt: data security officers must avoid building walls or trenches to defend data, no matter how good the motives – you will be outflanked by new technologies eventually and by your senior managers even more quickly. The best defense is your ability to identify the risks and to apportion them to the right stakeholders. Ideally, you will not be a risk owner if you remain a risk advisor!
Let me know what you think of my views on this and on my future pieces from my experiences as a security officer in government. I’m preparing articles about risk tolerance, the effectiveness of security awareness programs and getting ready for the fallout when mobile devices go missing. If you are interested in any of these or in any other information security management issues, please drop me a line.