Secure Application Development – A CISO’s Perspective

Published on: December 14,2020 Published in: Cyber Security Insights Software

For almost six years I worked across one of the UK’s largest global outsourcing companies, which was ranked No.1 for Software and IT Services (UK Software and IT Services Supplier Rankings Report 2020 – Tech Market View).

For four of those years, I was the Chief Information Security Officer (CISO) for the Software Division of the organisation, which held c.300 enterprise commercial products in its catalogue.

The organisation grew by acquisition, so the processes, technology and profile of each business was different – however, most products were used by our customers to:

  •  Process large volumes of personal data (subject to Data Protection regulation)
  • Process HMG Classified Material
  • Process Payment Card Data (subject to Payment Card Industry Data Security Standard)
  • Used in some capacity to provide or sustain critical UK national infrastructure

As part of our strategy to ‘simplify, strengthen and succeed’, I was given executive approval to create, deploy and embed a company wide Secure Development Framework (SDF), which aligned to the overarching Software Development Lifecyle (SDLC). Implementing a single operating model across c.30 business units, meant there were a lot of politics, variables and dependencies, so the task was not going to be simple.

Although the project was initiated to increase our cyber security and privacy maturity, the SDF also realised:

  • Standardisation of Processes for Secure Development across all areas
  • Significant reduction in Auditing for certifications, such as ISO9001 and ISO27001 (40% external cost reduction on audits)
  • Support to achieving Capability Maturity Model Integration Level 5, and future frameworks, such as ISO27701 (ISO Standard for Privacy Information Management Standard).
  • Allowed us to demonstrate General Data Protection Regulation (GDPR) compliance
  • Less documents to maintain, less internal audits to conduct and less time spent with external audits by security personnel
  • Less time for engineering and IT teams being audited
  • Down selection of appropriate licenses / technology, allowing us to negotiate a consolidated Group discount
  • Management of less products and tools
  • A highly accurate picture of the Divisional Threat and Security Risk Profile
  • Accurate quality and security KPI’s on our products
  • Better security training and awareness to our 2000-3000 engineering resources
  • Ability to prepare and deal with a Cyber Security Incidents and Data Breaches more effectively
  • Assuring regulators and customers that we were “responsible”
  • Reduced spend on Penetration Testing / re-testing
  • Significantly reduced likelihood of finding quality / security issues after final testing, which are more complicated (and embarrassing) to fix
  • Achieve all customer due diligence requirements and security questionnaires (across Public and Private Sector)
  • Ability to sell our products in new global markets
  • Release of better quality and more secure software, faster

As shown above, the commercial and financial benefits were endless, especially when aggregated over 300 or so products. However, the SDF really did allow the organisation to significantly increase the assurance and control over our own intellectual property, our own and customers sensitive data, which was our primary goal.

Due to the complexity and use of different teams, processes, coding languages and technology, we decided that the Microsoft Secure Development Lifecycle Practices (Microsoft SDL) was the best industry framework to adopt. The main reasons being that the framework was agnostic, aligned to our strategy to adopt Microsoft services, such as AzureDevOps (ADO) and it was free.

The Microsoft SDL operates with 12 ‘Practices’, which are:

  • Practice 1 – Provide Training
  • Practice 2 – Define Security Requirements
  • Practice 3 – Define Metrics and Compliance Reporting
  • Practice 4 – Perform Threat Modelling
  • Practice 5 – Establish Design Requirements
  • Practice 6 – Define and use Cryptography Standards
  • Practice 7 – Manage the Risk of Using Third-Party Components
  • Practice 8 – Use Approved Tools
  • Practice 9 – Perform Static Analysis Security Testing (SAST)
  • Practice 10 – Perform Dynamic Analysis and Security Testing (DAST)
  • Practice 11 – Perform Penetration Testing
  • Practice 12 – Establish a Standard Incident Response Process

Most of these Practices can be created and developed in house with no cost. However, there are three main Practices that required investment. These were:

  • Practice 1 – Provide Training – You can develop your own in house training solution, which should focus on educating resources on what the SDF is, where the Policies and Processes are held, how to get further guidance. However, the primary benefit of the training is to increase the awareness and education of resources, so they build better quality software. Therefore, I recommend procuring a service in this space. We looked at an array of solutions, and my best advice is to look at this along with your down selection of automated security scanning solutions (SAST / DAST). This is because a lot of technology vendors now also provide Secure Development Training, as part of their service offering. Combining the two may allow for larger negotiated discounts.
  • Practice 9 and 10 – Static and Dynamic Testing – Ultimately, SAST and DAST are the fundamental components of a SDF. They allow you to automate the security of your product lifecycle and adopt a “shift left” approach. Think of the automated security scanning solutions as your Microsoft Word spell check – as you are typing code, it alerts the engineer as they introduce quality or security issues. It allows for fix at point, instead of days before release (which is the norm) and getting flagged up at penetration testing. Highlighting issues at the end of the lifecycle is much more expensive, more complex, and usually delays the project. The benefit of using the tools in your pipeline, means that you can also embed security / quality gates, which means the build cannot progress, until the vulnerabilities have been remediated. Identifying the issues as part of the early lifecycle is what allows you to deploy better quality and more secure applications quickly (the agile way!). 

A key point to consider when selecting SAST / DAST or IAST / RASP is around your legacy applications (monolithic large volumes of congealed code), as some vendors may charge per lines of code, instead of per product, or per developer. For most software businesses, they are in a state of transition, which means they are adopting ‘low code no code’ or microservices, but still have to support and manage their creaky old software products.

Along with SAST and DAST tools, we also realised that making use of an Open Source Code Analysis (OSA) solution provides protection with:

  • Identifying vulnerabilities in open source code repositories (important as almost all software development does and should include open source code)
  • Identify which licenses were being used (lawfully and in date)

OSA brings a huge commercial benefit, as it allows you to understand how much of the product is actually your IP, as well as how vulnerable it is. This is a great exercise to conduct if any business is considering acquiring / divesting any enterprise commercial products or software businesses.

The rest of the Practices can simply be adopted by having access to subject matter expert knowledge in frameworks such as:

  • Secure Development (SANS / OWASP / NCSC Secure Engineering Principles etc)
  • Cyber Security (NIST / ISO27001 / Centre for Internet Security / Cyber Essentials / Information Security Forum etc)
  • Data Protection – GDPR / DPA18
  • Cyber Incident Response
  • Threat Modelling (such as Microsoft Threat Modelling Tool or ISF – IRAM)

Finally, an area which we found to be highly effective, to allow you to embed real security and privacy protection, was to create and define a security ‘non-functional requirements’ list, which included “Mandatory” and “Recommended” design requirements, depending on what the application did and for which customer. This was heavily focussed on data protection, as failing to embed certain function requirements, would mean that your customer would be unable to comply with regulation, such as the GDPR. This would mean that there could be severe limitations or inability to sell your product. Ensuring “Security by Design” is a fundamental requirement for new data protection regulations, but it also allows your customers (Data Controllers) to assure your product (sail through due diligence) and complete obligatory tasks, such as Data Privacy Impact Assessments.

In short, the Programme was regarded as a huge success. It is not very common that Security and Privacy are given the opportunity to embed themselves into the core business output and allow the business to save money, whilst increasing the cyber protection. Essentially – every technology vendor wants to be able to sell more and spend less!

Although I have not referenced any particular tools or vendors, we spent a tremendous amount of time assessing, down selecting, and deploying the tools – so I naturally have my favourites. Whilst the purpose of this article is to educate and not promote or sell, I will happily share my professional opinion in this area, please reach out for guidance.

As a next step, once you have tackled your Secure Development Framework, it will be time to set your sights on ‘Secure Deployment’…I have a lot more insights on this topic!

Related Insights

Insights Software

The Importance of Secure Software Development

September 22,2020