The significant Microsoft outage on 19th July this year, precipitated by a CrowdStrike update, provided a timely reminder of the importance of quality assurance in a ubiquitous environment of specific operating systems and software vendors in today’s market. Furthermore, it emphasises the need for effective and diligent secure software strategy and its implementation against the customer requirement.

Although the reported number of effected systems resulting from a faulty patch is a significant 8.5 million, in context, deliberate exploits such as the ILOVEYOU virus and Conficker worm claimed 50 million and 10 million affected systems respectively. While the immediate measurable effect is on disruption to customers and users, the inevitable less determinable long-term effects are on reputation, confidence and cost to and resulting from the affected service or platform. As an example, the CrowdStrike share price fell by approximately 20%. In cases of significant software disruption, it might be more efficient to consider the customer-vendor relationship regarding patch or vulnerability management and network security. However, before getting to the point of securing and assuring deployed software, what does this reflect about securely developing software, before it even gets to the customer or user?

Software development, as per network security has been subject to an array of re-titling to articulate approaching it with security in mind; whether this is the shift from the Software Development Lifecycle to the Secure Software Development Lifecycle or from DevOps to DevSecOps. All are meaningful principled approaches to achieving software intended to be fundamentally Secure by Design. Also likely driving software delivery and implementation is the approach to project management, whether this is Agile, Waterfall, Iterative etc., and contributing to the increasing complexity in governing and delivering secure software development and ensuring security objectives are met.

When considering secure software development, a useful analogy can be to look in the context of cars being built in a factory – the factory being the holistic development environment, cars the software artefacts delivered. First, what do we want our factory to be – a reliable, secure and functioning environment complete with the tooling and infrastructure to enable the cars to be delivered on schedule. So, in context, we may want to consider how secure our network is, how functional and assured the development environment is – if employing Infrastructure as Code does this ensure that our Continuous Integration / Continuous Deployment pipeline truly delivers DevSecOps. If the factory is not secure then its outputs may either be untrustworthy or deficient. While a governance approach may be to manage these risks, where there is a lack of resilience or oversight, they will inevitably manifest in leading to impact to the customer. Moreover, where the development and deployment architecture is insecure, this could have a more insidious effect on the confidence and trustworthiness of the software delivered.

Production of quality cars rely on this secure and assured environment, so if there are vulnerabilities in the materials provided (i.e code) or how it is being supplied (repositories or libraries used, contributing developers) then despite having the best environment to develop in, the quality of product will be deficient. Vulnerable materials will inevitably lead to a weak product, so when an organisation relies on a fleet of cars from a manufacturer using such materials, the day when a product recall is made or found to be unroadworthy can be catastrophic or force the customer to carry the burden of risk on their behalf. So, where there is vulnerability in code that is widely used, or an operationally critical product, the blast radius of damage or exposure will likely be as wide as the dependency placed upon it. Ultimately, it is the resulting erosion in confidence in the manufacturer and loss of the customer’s business output that could be the hardest factors to repair.

Notwithstanding, the factory will need to be staffed by personnel who are trained and understand secure and assured delivery and can manifest this in delivery of the product. The best tools and processes could be rendered ineffective or de-constructive when in the hands of those who do not know how to use them. The product also needs the appropriate testing environment to ensure quality control and effective performance before it goes to market to verify that the product is going to perform as expected in the operational environment without impact to the customer.

Delivering software that is Secure by Design is likely to be shaped by the context/requirements of the product to be delivered and the activities/stages to achieve it. The security assurance balance may (or may not!) be achieved based on the risks the manufacturer is willing to take with any of the components required for a secure and assured factory or the vehicles produced at the end of the product line. Some areas that may be key are:

• Does compressing the schedule impact quality? Are the staff trained effectively enough for this?

• What is the investment in securing the infrastructure? Does it meet the requirement?

• Am I (re-)using secure design patterns and architectures?

• Are the tools secure, effective, managed and can deliver what is needed, when it is needed?

• Can we trust our suppliers and the materials used? If so, how are they demonstrating this?

• How are we assuring and demonstrating quality control?

• What is the governance structure and performance monitoring around this?

While there are many more considerations to be made, in delivering software that is Secure by Design – governance, management and implementation of security maturity is key. The right assurance framework should be adopted from the outset and innately integrated into the delivery or implementation method by which the DevSecOps or Secure Software Development Lifecycle is governed. NIST’s Secure Software Development Framework, OWASP’S Software Assurance Maturity Model and Google’s Supply Chain Levels for Software Artifacts provide an approach to base secure software assurance governance and implementation. All of which require complimentary effort to monitor, review and mature their operational assimilation, similar to that of ISO 27001 or the NIST Cyber Security Framework. Critically, it is measuring their maturity through performance indicators that should drive the honest reflection for ensuring software that is Secure by Design. In the dynamic world of software development, risks will continue to evolve and manifest but a diligent approach to secure software maturity can provide a solid foundation to minimise the possibility of operational, reputational and financial impact.

At Nexor we have a deep understanding of maturing your approach to secure software development and delivery. Our consultants have a rich understanding of evaluating maturity in the approach to secure software to inspire confidence that it is secure by design and function.