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 government staff do is conducted on one type of IT system or another, therefore these systems must be designed and built to support their 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 most 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 call it “the theatre of security“.
We have proven in a number of recent central government assignments that security can be done better, can enable something genuinely transformative and, just as importantly, can be straightforward and simple to understand.
Government security classifications
The new government security classification policy (introduced in 2014) has provided a platform to do this, as it espouses a commercial model for the OFFICIAL level (including any OFFICIAL–SENSITIVE handling caveats).
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 revised end user device platform guidance from the National Cyber Security Centre, or NCSC (the part of GCHQ formerly known as CESG), and it’s difficult to express just how radical this really is for government.
NCSC guidance
NCSC 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.
The implementation guide from NCSC 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 large 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. In order to open up the market to SMEs, and even other larger companies, we need to change the way we describe our requirements, and we should always do so in a clear and unambiguous way.
Managing security risks
Government security processes were created to be proportionate but have all too frequently become box-ticking 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.
In order 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 shouldn’t look to 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.
