The UK’s National Cyber Security Centre has revealed how it built its new IT systems using an agile approach, saying that waterfall “was never going to bring this job in on time”.
The centre is located in London, in addition to its parent body, GCHQ’s base in Cheltenham – Photo credit: PA
The London-based centre, which launched in October last year but was officially opened by the Queen yesterday, created its own IT system from scratch.
This, it said, was because none of the existing IT systems designed for working with OFFICIAL information met the needs of the centre – which was formed from several different organisations under the parent body GCHQ.
The centre’s chief architect, known as Richard C, said that the existing systems did not “strike the right balance of security, usability and functionality required” by the new organisation.
Related content
Pasting passwords gets seal of approval from National Cyber Security Centre
“Active cyber defence”: UK’s first National Cyber Security Centre chief sets out strategy
Are we entering a ‘cognitive era’?
In a blogpost setting out the centre’s work, Richard said that having an agile approach was crucial. “A traditional waterfall approach was never going to bring this job in on time,” he said.
However, he noted that – because the project was an infrastructure one – there were areas where using agile techniques would be “tricky”, such as procurement of commercial services and equipment.
“While it’s possible to iterate the code which defines the configuration of our service, frequently changing our minds about the hardware we use just isn’t practical,” Richard said. “There are some choices it pays to get right first time.”
Calculated risks
The blogpost also emphasised that it was “entirely possible to build good, secure tech using an agile approach”. The main difference is that the system needs to be evolved over time, with risks taken in “sensible ways” while building in new functionality of security into the system.
“On day one, we were running a relatively high risk in some areas while we were comfortable with the controls we had in place elsewhere,” Richard wrote.
In addition, the team had to take “well-informed decisions to accept calculated risks” in the knowledge that more controls would be added as deployment numbers increased.
Working in this way meant that each sprint added not only new features to the system, but also increased security.
“The risks we take change on a sprint by sprint basis. We’ll continue to take sensible decisions, security being considered as an important factor, along with various other demands of the project, like usability and cost,” Richard said.
Because of this approach, however, the system will “never be ‘accredited’ in the traditional sense of a point-in-time decision, because it will never be ‘done’”.
User needs
The centre had three main design principles for the project: technology, security and user experience.
Among the security principles were that the centre follows its own advice on security enterprise technology, patch “aggressively and automatically” and “avoid creating complex trust relationship with other IT systems” to maintain its autonomy.
On the technology side, the centre followed the government’s Technology Code of Practice and noted that it does not need “gold level” support or availability for everything – only for some elements like email or communications tools.
However, in the blogpost, Richard said that the most important element was that the system was “a pleasure for people to use”, noting that “a highly secure solution that no-one uses isn’t secure at all”.
In addition to creating a “fantastic” experience for users, the other principles are that users should get a choice of devices, that all device builds are kept “vanilla” as possible to make it easier to maintain them, and that web apps are used over “thick client apps”.
The blogpost is part of the centre’s efforts to be more open about its work, with other posts including advice on password security, cloud security and securing smartphones.
