Today’s reality is that an insecure system will be breached. Secure systems engineering has often not been sufficiently prioritised, over being faster to market and adopting new technology. The many publicly quoted data breaches demonstrate that this approach is not good for business. Failing to keep customer and organisation data private, available and correct now comes at an escalating price.
This can include significant remedial costs and lost revenue (e.g. Sony ‘The Interview’), huge fines (e.g. TJ Maxx), lost customers, getting swallowed up (e.g. HBGary) or going out of business (e.g. Nortel). Recent evidence shows that recovery costs can be 2.5 times larger than mitigating the issue in the development process.
Applying structured risk management within the development approach is the best way to address this challenge.
Why is it seemingly so hard?
Securing systems is not trivial. With millions of lines of code on a complex mesh of servers, running multiple protocols across a network, with the applications on top, it is often considered an insurmountable challenge.
Such architectures can quickly become riddled with security vulnerabilities. Numerous security industry reports show a substantial number of vulnerabilities reported annually. One study cited that 53 per cent of the systems scanned contained exploitable vulnerabilities. A study of applications showed 86 per cent of their websites contained at least one serious flaw.
Software development lifecycles are being increasingly compressed to deliver results sooner. Monthly ‘waterfall’ phases are now weekly ‘updates’ and ‘daily stand-ups’ within rapid development (‘AGILE’) processes. These challenges are not new. Many organisations have established secure development lifecycles to fundamentally reduce system vulnerabilities.
These have resulted in accessible techniques and guidance, with corresponding improvements in secure systems. Microsoft’s ‘STRIDE’ is one such model for structured analysis of threat or attack patterns.
The central role of risk assessment
A comprehensive risk assessment of a systems development provides a common language for ‘potential problem management’, usable throughout the lifecycle. The resulting risk scenarios have proven to be helpful in communicating the threats and risks to the proposed system, to architects and developers.
But additionally, these scenarios provide an excellent mechanism through which to ensure that:
- the right amount, level and frequency of management engagement can be obtained.
- architects and designers understand why they are implementing security controls rather than seeing them as annoyances which delay implementation.
- security investment in the project overall, and effort to be invested in each of the security activities themselves, is ‘right-sized’ and appropriately ‘weighted’.
- in an agile environment, security is more suited to the ‘sprints’ process.
proposals to trade-off controls for functionality and delivery can be addressed objectively.
Plotting the secure development journey
Risk assessments are successful when a consensus results. Communication and collaboration between the business users, developers, security experts and other stakeholders are essential. Too many business managers today consider that development is for developers. But, even if it takes some effort to get initial engagement to build the risk assessment, many benefits then accrue.
My experience is that this can actually bring forward the development delivery date. One example of risk assessment smoothing the development process, is it identifies how critical security factors are in each instance and how it compares to the other development perspectives.
Clearly articulated security requirements are the keystone of every secure system development and must be commensurate with the risk, unless this is over-ridden, for example, by regulatory obligations.
For these to be useful for software development, they must be specific statements such as ‘the application must authorise users using the username, memorable word and PIN code’ rather than generic statements such as ‘the application must authorise all users’. The existence of the risk assessment will reassure designers that the requirements are neither over- or under-stated.
Shaping the design and managing the build
No one would challenge the need for effective architecture practices, such as understanding:
- the technologies being used and where there may be incompatibilities;
- that the architecture has been built up appropriately;
- the design and assurance processes applied to all the components;
- the provenance and past performance of the components and applications.
However, such processes are often carried out by development teams in isolation. In contrast, when these assessments are undertaken in a ‘risk-driven’ format, increased delivery effciency results, in which different activities can be weighted uniquely. In an agile development some processes are well suited to integrating security, such as the iterative code development phase. But the architecture analysis can seem at odds with the iterative nature of agile.
In fact, design reviews and code clean-ups can easily be added to the backlog to become part of scheduled sprints. The risk model is then very effective both at ensuring that this happens and that progressive sprints focus on completing the relevant parts, in priority order and sufficient detail.
Sufficient testing
Then comes the vitally important step of real-world security testing, often wrongly seen as the final development step. With all the system modules integrated, the testing seeks to confirm that the system performs and security controls operate as expected. This will include testing of:
- the original security requirements;
- common security issues with the adopted technologies;
- specific application features;
- specially developed security controls.
This can again be best structured by reference back to the risk model. This will resolve such questions as: should the testing be done by an independent testing house, perhaps undertaking a CREST or CHECK review? Does the development really merit standard testing? How much specialist and user engagement should there be to probe such issues as performance of the user interface? What testing tools would be appropriate? What testing of capacity would be justified?
Achieving and demonstrating assurance
When a total cost of operation view is taken of the development, the real last stage is providing a sustainable assurance regime. The risk model again plays a major role in defining how user acceptance will be obtained from the business, and who from.
Associated activities can also be shaped by risk to include what user acceptance training should be undertaken and what the audit regime’s scope, frequency and depth of review needs to be.
Another critically important aspect of development, which can be shaped by the risk model, is how to handle waivers or non-compliances, i.e. those issues that remain unfixed. By identifying relative priorities, the risk model will enable this to become a business-based decision.
The start point will then be whether these can even be afforded. But if they can, what is the relative priority to fix them? In what timescale and how soon must the issue’s continued existence be subject to re-approval and by who?
Last, but not least, no good system goes live without appropriate performance reporting i.e. critical success factors supported by metrics. The risk model is ideal for defining what these need to be.
By using risk assessment to calibrate the development activities, they will remain proportionate and relevant to the real risks to which the live system will be exposed. Whilst a more secure system will have been delivered, many other material benefits will emerge that mandate the adoption of this approach.
These will encompass: lower development costs, lower running costs, more uptime, more throughput, higher end-customer trust and, as a consequence, more end-customers. Secure systems development is therefore achievable and entirely worthwhile.
