Security is vital to government business. It ensures that we protect the public’s information properly, can advise ministers in confidence and maintain our national security interests.
Almost everything that we do is conducted on one type of IT system or another, therefore these systems must be designed and built to support our security needs.
‘Sensible security’ – if you’ve worked in government IT, will probably feel like a contradiction in terms. Many have said that badly implemented security is at the root of our technological ills, and it’s easy to understand why. However, the real problem is more nuanced: a dizzying combination of risk aversion, poor communication, bad contracts and general misunderstanding. We want to prove that security can be done better, can enable something genuinely transformative and, just as importantly, be straightforward and simple to understand.
New government security classifications
The new classification policy has given us a platform to do this, as it espouses a commercial model for the OFFICIAL level. In essence, this means that for routine government business and the delivery of public services, government should think about security just as a large and well-run company would do – consider the organisations who look after your savings, manufacture medicines or produce the smartphone in your pocket. This approach has been the catalyst and enabling factor for a range of initiatives, not least the end user device platform guidance, and it’s difficult to express just how radical this really is for government. If you’d told me a couple of years ago that I would be sitting here tapping out a blog on a Cabinet Office MacBook… well, let’s just say that I might have assumed a large Windows XP laptop had fallen on your head.
CESG guidance
More recently CESG have launched guidance on how to risk manage the use of cloud services. This guidance is designed to support greater choice for government departments when choosing services, by helping them get the information they need to make informed risk decisions – it should help us make smarter choices when we build government technology services. Central to the guidance are 14 core security principles which should be used to help departments consider the risks and benefits of different services. Suppliers can also take different approaches to meeting the principles, and these attract different risks. CESG's implementation guide will help government departments and suppliers understand which risks are applicable to their requirements.
Another benefit of these initiatives is that they allow us to describe our security requirements in a more meaningful way. Over the years many government IT suppliers have created entire divisions of people who exist solely to translate government security-speak (eg ‘Impact Level X’) into something they can actually build against. If we want to open up the market to SMEs, and even other larger companies, we need to change the way we describe our requirements. We should never be scared to ask pointed questions, or have high expectations, but we should always do so in a clear and unambiguous way.
Managing security risks
So how do we use all of this great work for the Cabinet Office Technology Transformation Programme? Surely we can just bolt it all together and rubber-stamp it ‘CESG approved’? Unfortunately no, those days are not only gone but, in truth, never existed anyway. The real security work begins now – carefully assessing the overall solution, drawing out the security risks and then ensuring that they are adequately understood and managed. We typically call this process ‘accreditation’ and it must be one of the most loaded terms in government IT.
Our security processes were created to be proportionate but have all too frequently become tick box exercises, opaque to all but a tiny number of security specialists. A consequence of this lack of transparency is an over-emphasis on risk elimination and expensive security controls, which inevitably degrade the functionality and usability of our technology. We are determined not to fall into this trap – there must be a clear line of sight between every security control to an actual (and agreed) risk and, critically, it must be expressed in plain English. We won’t add any layers of security just because we can or because it’s received wisdom to do so – if we can’t articulate the reason why, then we are just not doing our jobs properly.
User needs
So how will we know if we’ve got it right? The answer isn’t to compromise security in order to meet the user needs. The answer is to think about security as part of the user needs, something that is integral to (and should be balanced against) every other facet of the service. If we can achieve this balance, and users and risk owners alike can understand it, then we’ll have been successful.
Sign up for email alerts from the Cabinet Office technology blog.
1 comment
Comment by simonfj posted on
Thanks Ben,
Sensible Security, Military intelligence. Aren't oxymorons telling?
It's funny to see your suggestion - "We want to prove that security can be done better, can enable something genuinely transformative and, just as importantly, be straightforward and simple to understand" - being addressed so quickly, and well, on another blog. https://governmenttechnology.blog.gov.uk/2014/06/24/identity-and-access-management/
I would have thought the cabinetoffice and the rest of government would be using the same technology. Looking at some of the replies to Jerry's post, it would seem not. https://governmenttechnology.blog.gov.uk/2014/06/26/a-better-approach/ (I joke of course)
I think we need to be a bit clearer about this comment; "The answer is to think about security as part of the user needs, something that is integral to (and should be balanced against) every other facet of the service". It really isn't "a part" of a user's need. It is the foundation of every facet of a a user's (access to) online service(s). The hard part, during this change to a new network model, is that users will include "self-serving" citizens.
In examining Jagdeep's "... implications (and user experience) of having multiple identities for multiple systems, vs. a single identity across multiple systems", users have, so far, been limited to insiders (of some departmental network). Could you take this approach to the problem? https://governmenttechnology.blog.gov.uk/2014/06/24/identity-and-access-management/#comment-917
With all the talk about "user centric" we are still putting the cart before the horse.(or starting at step 3 rather than step 1. http://blogs.worldbank.org/ic4d/co-creation-of-government-services )
We can see the effect by examining the IER service. It's good, if one takes the "single (National) service" perspective. But if it were "user centric" a user would interrogate their local council's electoral database, update their details if necessary, and it would then be validated via their DWP attributes.
As Ben says, "The register to vote process as part of IER showcases how central policy and process can directly integrated into local authorities, it's not a huge leap to think that this could work the other way around". http://danblundell.com/2014/06/a-sign-of-things-to-come/
i.e. user centric.
I just keep reading reports like this, and wonder what might happen if users were empowered/educated to control their account's privacy/security. http://healthcare.governmentcomputing.com/news/bma-vote-favours-opt-in-model-for-caredata-4303990