New NIST White Paper on Secure Software Development

[former_member83431]

Secure Software Development

Much has been said and written about this topic since Bill Gates’ famous memo to Microsoft employees in February 2002 and the shaping of Microsoft’s Security Development Lifecycle (SDL) as it was called back then in 2003 [6]. It was time to call for a change of direction: security must become an integral part of the software development lifecycle! It was not much later, and inspired by the Microsoft initiative, that we started to shape SAP’s Secure Software Development Lifecycle (SAP Secure SDL) [1]. We created our SAP Product Standard Security comprising security requirements for all application development units, we added comprehensive security education offerings for all roles in product development, methodologies for security risk assessment (Threat Modeling), secure coding guidelines, a whole arsenal of security testing tools [7], central security validation [8] before code can be released and security response [5]. While growing, refining and improving our Secure SDL, initiatives such as the Open Web Application Security Project (OWASP) [9], the Software Assurance Forum for Excellence in Code (SAFECode) [10] and others where useful external sources that we included and contributed to.

In 2011, ISO/IEC 27034-1 [4] kicked in as an international standard applying security risk management to application software and the application security management process as part of the very successful ISO/IEC 27000 [2] series of standards for information security management. Together with my team at SAP, we studied and followed it with great interest and I think it still is a great document, introducing the concepts of Application Security Controls (ASCs), ASC Libraries and the notion of different Levels of Trust, which organizations must thoroughly and transparently think about, define, and map their applications to.

While providing an excellent conceptual blueprint and reference for process architects, the framework and concepts introduced by ISO/IEC 27034-1 remained highly artificial and difficult to map to daily practices, however, which we painfully learned meanwhile. And for assessing process maturity and further identification of gaps and improvement potential in our SAP Secure SDL it didn’t help as it misses descriptions and listings of concrete practical controls that constitute today’s state-of-the-art.

Then I saw the NIST White Paper (Draft), “Mitigating the Risk of Software Vulnerabilities by Adopting a Secure Software Development Framework” [0] appearing in June this year. As SAP is already aligning its security operations and processes towards a previous publication from NIST, the “NIST Framework for Improving Critical Infrastructure Cybersecurity” [2], I was interested to see if this new document gets more specific for secure software development (my discipline) where I always found the other NIST document to be good but not specific enough. I was eager to take the challenge and measure our SAP Secure SDL against this new reference, so I jumped on it. Read in the next section what I found.

Reviewing NIST White Paper (Draft), “Mitigating the Risk of Software Vulnerabilities by Adopting a Secure Software Development Framework”

The more I read into the draft, the more I was impressed. I think this document can become a true reference and foundation for companies to assess the completeness, quality and maturity of the security controls applied during their software provisioning process. Similar to [2], the authors first came up with a grouping of practices for secure software development, thereby highlighting the different areas of recommended actions and providing the overall challenge with a useful structure for tackling it. All practices listed and described within these groups got a clear numbering and identification of which group of activities they belong to which helps in discussing their purpose and objective:

PO:        Prepare the Organization
PS:         Protect the Software
PW:       Produce Well-Secured Software
RV:         Respond to Vulnerability Reports

I couldn’t resist and immediately started to edit a table comparing the listed practices with what we do at SAP. You will find a shortened version of it at the end of this blog for reference and if you are interested in more detail. But going through it will make this a long read. So, let me summarize the main findings I made.

Prepare the Organization

What a great topic to start with. If your organization is not prepared for understanding, living and operating security in the daily software development and provisioning process, lots of good intent, energy and investment is lost in painful ways and failure is guaranteed. The NIST draft document mentions essential elements of what is required:

Requirements (PO.1) must be clearly and transparently documented and maintained, communicated and made accessible for everybody who belongs to the development workforce. At SAP, we do this via our SAP Product Standard Security, Product- and Scenario-level Threat Modeling. To develop secure software, an organization needs to be clear about the Roles (PO.2) in the organization that contribute, define what each role is responsible and accountable for, educate and empower them. At SAP, besides adding security to regular developer education and management responsibility, we have introduced dedicated supporting roles in our global job catalogue, such as Developer Expert Security, Development Architect Security and Quality Expert Security. Acquiring, deploying, continuously assessing and updating an automated chain of Tools (PO.3) to support secure application development is indispensable these days to handle the security of millions of lines of code. At SAP, we are using a multitude of tools daily and regularly to help verifying the security status of our code, including both Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST) technology [7], and interactive security testing tools. Integration of these tools into automated pipelines for Continuous Integration and Delivery (CI/CD) is key, for example in the Cloud business. In addition, a secure software development lifecycle must include clearly defined meaningful Security Checks (PO.4) to be effective in practice. From left to right, as to say, and some happening each sprint in agile mode, there are Threat Modeling and Security Architecture and Design Reviews done at SAP, Sprint Reviews looking at security test results, automated security thresholds in automated pipelines and a mandatory Security Validation [8] by a central team of experts before actual release of code to customers.

Protect the Software

The next group of practices in the NIST document: you want to be sure what exactly gets shipped to customers for on-premise installation, into mobile app stores, or provided as a service in the Cloud.

Where source code is stored in your enterprise shall be clearly defined and centrally managed to prevent Unauthorized access and tampering (PS.1). Only authorized developers shall have access to the code, depending on the products and projects they are working on. At SAP, centrally managed source code repositories and build servers are used by running own instances of GitHub Enterprise, Nexus Repository Manger, and a full ABAP Development Landscape, for example. Their use is mandated by the SAP Product Standard Software Lifecycle. External and internal consumers of software deliveries shall be able to verify Software release integrity (PS.2). At SAP, this is mandated by a corresponding requirement in the SAP Product Standard Security. Integrity verification is to be integrated into installation and upgrade tools and shall include security notes and patches. The SAP Product Standard Software Lifecycle again mandates that all SAP products which are made available to customers are produced with a reliable, reproducible and automated process to ensure documentation and traceability for audits (Archive and protect each software release (PS.3)).

Produce Well-Secured Software

In this (largest) group of practices, you will find the essence of secure software development.

Make sure Security Requirements and Risk Information are taken into account during software design (PW.1). At SAP, we do this via different forms of Threat Modeling, which is a mandatory task in the SAP Secure SDL since 2018, as well as via our SAP Global Risk Management Policy for all employees. Verify Compliance with Security Requirements and Risk Information (PW.2) is done during Sprint Reviews and central Security Validation [8] at SAP. To Verify Third-Party Software Complies with Security Requirements (PW.3), SAP’s security and software lifecycle requirements are communicated to partners and third-party vendors in the so-called T454 form which partners must respond to. Then, all partner and third-party deliveries are run through Premium Qualification or become part of the standard security qualification measures of the embedding product. For Open Source components used in SAP products and Cloud services, tools are provided centrally to scan for known vulnerabilities and such scans are a mandatory task in the SAP Secure SDL.

Reusing Existing, Well-Secured Software (PW.4) instead of duplicating and replicating code clearly reduces the attack surface of a software-based application and facilitates security hardening of centrally provided and reused frameworks and services. Examples at SAP are our self-developed crypto library (SAP Common Crypto Library), development and runtime platforms such as SAP Application Server ABAP and the SAP Cloud Platform, as well the new set of SAP kernel services for integration as part of our Intelligent Enterprise strategy including, for example, central services for identity management, authentication and single sign-on, encryption and key management to be used by all SAP Cloud services.

To foster Secure Coding Practices (PW.5), developers at SAP are provided with secure programming guides for the major languages used. Automated tools, such as Static Application Security Testing (SAST) are provided that are integrated into the developer studios and IDEs (Interactive Development Environment tools). The goal is to facilitate own code analysis and reviews as early as possible in the process. Secure settings are mandated by the SAP Product Standard Security for Compilation and Build Processes (PW.6) to achieve, for example, address space layout randomization, executable space protection and buffer overflow protection for all binary executables.

To Review and/or Analyze Human-Readable Code (PW.7), the use of Static Application Security Testing (SAST) tools is mandatory in the SAP Secure SDL. Many development teams are also enforcing peer/group code reviews before code can be checked into central code repositories. For Testing Executable Code (PW.8) a variety of different tools and methods are available for the development teams (see [7], for example).

Secure Settings by Default (PW.9) are mandated by the SAP Product Standard Security and verified by central Security Validation. For each SAP product, a Security Guide must be provided for customers by the product team.

Respond to Vulnerability Reports

Embrace the support you get from reporters, take them seriously and treat them fair – they are your good friends if you want to have responsible disclosure of vulnerabilities and associated security patches.

Identification and Confirmation of Vulnerabilities (RV.1) happens through the SAP Product Security Response [5] process, providing adequate channels for reporters, staying in touch with them to synchronize publication and patching, trigger analysis and corrections where needed, as well as coordinating patch provisioning at each second Tuesday of the month (SAP Patch Day) and in between for very critical cases. Since last year, SAP also collaborates with major providers of Bug Bounty platforms and wants to extend its Bug Bounty program. Remediation of Vulnerabilities (RV.2) is following a risk-based approach along vulnerability severity levels. The widely accepted Common Vulnerability Scoring System (CVSS) standard is used and applied to rate the severity of identified vulnerabilities and determines the time allowed for security patch production. Identifying Root Causes (RV.3) is part of the standard security response process at SAP again following a risk-based approach. The SAP Security Response Team gets in touch with development and product teams to identify root causes of recurring high and very high vulnerabilities and trigger more comprehensive analysis and remediation activities.

Conclusion

So how did I feel at the end of this analysis and comparison of NIST’s new draft document about secure software development [0] with SAP’s Secure Software Development Lifecycle [1]?

I felt good, actually. As good, at least, as you can feel about a topic which is inherently unsolvable in a complete way, but needs a rigorous, structured and intelligent approach. For almost all the recommended groups of practices and detailed recommendations we have corresponding measures and controls in place at SAP, although we are still working on some to improve their effectiveness and efficiency, admittedly. But this work will always go on and in parallel, we are researching better ways to achieve the goal (see the previous blog in this series from June 2019 [11]).

But I also felt good about NIST’s document. With the approach of describing actual security practices that are recommended and shouldn’t be missed where applicable in today’s companies’ software development processes this new document fills a practical gap in other existing standards about security and risk management, such as ISO/IEC 27001 and 27034, whose aim is “only” to provide a process framework, but not the actual content for execution.

If you have a role in secure software development in your company or organization, or, in particular, if you are the process architect, development manager, quality manager or any responsible person in any of its inner steps and phases from requirements analysis, architecture and design, to coding, testing, validation, release and response – I recommend reading this new document from NIST and performing a similar exercise. It will help you to assess where you are and to get better.

 

Table 1. Comparing NIST Secure Software Development Framework and SAP Secure Software Development Lifecycle

	NIST SSDF [0] Practices/Tasks	SAP Secure SDL [1]	NIST Cybersecurity Framework [2]	ISO 27001 [3] ISO 27034-1 [4]
PO	Prepare the Organization
PO.1	Define Security Requirements for Software Development	SAP Product Standard Security SAP Product Standard Software Lifecycle	ID.GV-3	[3] A.18.1 [4] 7.3.2
PO.2	Implement Roles and Responsibilities	Developer Security Development Architect SecurityQuality Expert SecurityChief Security OfficerHead of Product Security Product Standard Owner Secure SDL Process Owner Security Validation Engineer	ID.AM-6 ID.GV-2 PR-AT-1	[3] A.6.1.1 [3] A.7.2.2
PO.3	Implement a Supporting Toolchain	Sirius, Security Hub SAST, DAST, IAST Software Vulnerability Monitor Open Source Scan Tools Piper, CoDePiPes	-	-
PO.4	Define Criteria for Software Security Checks	SAP Threat Modeling Security Plan Security Code Reviews Auditing SAST scan results Auditing OSVM scan results Verifying DAST results Security Validation Security Hub Software Vulnerability Monitor OS3Admin Cockpit SGS Security Dashboard	-	[4] 7.3.5
PS	Protect Software
PS.1	Protect All Forms of Code from Unauthorized Access and Tampering	SAP Product Standard Software Lifecycle (SLC-25)   SAP IT Secure System Operation	PR.AC-4
PS.2	Provide a Mechanism for Verifying Software Release Integrity	SAP Product Standard Security (SEC-274)	PR.DS-6
PS.3	Archive and Protect Each Software Release	SAP Product Standard Software Lifecycle (SLC-29)	PR.IP-4
PW	Produce Well-Secured Software
PW.1	Take Security Requirements and Risk Information Into Account During Software Design	SAP Product-Level Threat Modeling SAP Scenario-Level Threat Modeling SAP Global Risk Management policy SAP Security Response Root Cause Analysis	ID.RA-1 ID.RA-2 ID.RA-3 ID.RA-4 ID.RA-5 ID.RA-6	[4] 7.3.3
PW.2	Review the Software Design to Verify Compliance with Security Requirements and Risk Information	Security Validation	-	[4] 7.3.3
PW.3	Verify Third-Party Software Complies with Security Requirements	T454 Security Validation Security Qualification for Partner Products (PQ) Open Source Vulnerability Management (OSVM) tools Timely update of open source components	-	-
PW.4	Reuse Existing, Well-Secured Software When Feasible Instead of Duplicating Functionality	JAVA SDKs and Runtime Environment Cloud Foundry SAP NetWeaver ABAP Platform SAP UI5 SAP Cloud Platform Identity Authentication Service SAP Cloud Platform Identity Provisioning Service SAP Solution Manager SAP Enterprise Threat Detection	-	-
PW.5	Create Source Code Adhering to Secure Coding Practices	SAP Product Standard Security Secure Programming Guides SAST Tools	-	[4] 7.3.5
PW.6	Configure the Compilation and Build Processes to Improve Executable Security	SAP Product Standard Security (SEC-275, -244)	-	-
PW.7	Review and/or Analyze Human-Readable Code to Identity Vulnerabilities and Verify Compliance with Security Requirements	SAST – mandatory Peer/group code review – best practice	-	[4] 7.3.6
PW.8	Test Executable Code to Identify Vulnerabilities and Verify Compliance with Security Requirements	Threat Modeling Security Testing Strategy SAST, DAST External Security Assessments	-	-
PW.9	Configure the Software to Have Secure Settings by Default	SAP Product Standard Security (SEC-244) Security Validation	-	[4] 7.3.5
RV	Respond to Vulnerability Reports
RV.1	Identify and Confirm Vulnerabilities on an Ongoing Basis	SAP secure SDL [1] SAP Security Response [5]	-	[4] 7.3.6
RV.2	Assess and Prioritize the Remediation of All Vulnerabilities	SAP Security Correction SLAs CVSS 3.0	-	-
RV.3	Analyze Vulnerabilities to Identify Their Root Causes	SAP Security Response [5] SAP Product Standard Security Root Cause Analysis based on risk assessment

References

[0]          NIST Cybersecurity White Paper (Draft), “Mitigating the Risk of Software Vulnerabilities by Adopting...

[1]          SAP Secure Software Development Lifecycle

[2]          NIST, “Framework for Improving Critical Infrastructure Cybersecurity”

[3]          ISO/IEC 27000, "Information technology — Security techniques - Information Security Management Syste...

[4]          ISO/IEC 27034-1, “Information technology — Security techniques — Application security — Part 1: Over...

[5]          SAP Product Security Response

[6]          Wikipedia, Trustworthy Computing

[7]          Source Code Scan Tools used at SAP

[8]          Product Security Validation at SAP

[9]          The Open Web Application Security Project (OWASP)

[10]        Software Assurance Forum for Excellence in Code (SAFECode)

[11]        SAP Community Blog “How to Safeguard your Organization from the New Threat Landscape”