Earlier last month NIST released a draft copy of CyberSecurity White paper titled “Mitigating the risk of Software Vulnerabilities by adopting a Secure Software Development Framework [SSDF]” for comments. The paper highlights how few software development lifecycle [SDLC] models explicitly address software security in detail and it recommends a core set of high-level secure software development practices to be added to each SDLC implementation. The idea is that these core practices will help software producers reduce the number of vulnerabilities in released software. Also, software consumers need to consider security aspects in the software acquisition process. Thus, the audience of the paper is two-fold i.e. software producers and consumers alike.
The paper describes secure software development practices, wherein each practice has the following elements:
- Practice – A brief statement of the practice, along with a unique identifier and an explanation of what the practice is and why it is beneficial
- Task – An individual action (or actions) needed to accomplish a practice
- Implementation Example – An example of a type of tool, process, or other method that could be used to implement this practice
- Reference – An established secure development practice document and its mapping to a particular task
These practices are organized into four groups as:
- Prepare the Organization (PO)
- Protect the Software (PS)
- Produce Well-secured Software (PW)
- Respond to Vulnerability Reports (RV)
In this blog we will review some of the key practices as below:
PO.3 – Implement a Supporting Toolchain
NIST highlights the importance of using automation to reduce human effort required and improve the accuracy, consistency and comprehensiveness of security practice.
PW.1 – Take Security Requirements and Risk Information into Account during Software Design
PW.3 – Verify Third-party Software Complies with Security Requirements
This practice talks about reducing the risk associated with using acquired software modules and services, which are potential sources of additional vulnerabilities. This is a key aspect which is often overlooked by software producers. One of the tasks under PW.3 is as follows:
- Task – PW.3.2 – Use appropriate means to verify commercial and open source third-party software modules and services comply with the requirements.
TW can help organizations in such assessments for commercial and open source third-party softwares alike.
PW.4 – Reuse existing, well-secured software when feasible instead of duplicating functionality
This may come across as a no-brainer to most, but some organizations still build their own libraries rather than leverage existing ones. This approach is strictly not recommended for softwares that implement security functionality such as cryptographic modules and protocols.
PW.8 – Test executable code to identify vulnerabilities and verify compliance with security requirements
The idea is to perform robust functional testing of security features before software is released.
PW.9 – Configure the software to have Secure Settings by default
The focus is to ensure that default installations of the software are secure by default.
RV.1 – Identify and confirm vulnerabilities on an ongoing basis
TW can be effectively used to gather vulnerability intel for third-party components used in the software and understand & assess their vulnerability posture.
Another key aspect that the paper calls out is for software consumers to take an informed decision during the software acquisition process. Let us consider two examples below to better understand this aspect:
- An engineering team is working on creating the architecture blueprint for a large software solution and they need to decide which “Enterprise Service Bus” to use. There are multiple ESB solutions out there, some of which are commercial and others open source. Ofcourse the engineering team will consider multiple aspects while picking the right ESB solution like ease of use, scalability, modularity, development time, etc. One key aspect that is often overlooked is the software vulnerability one – how many open vulnerabilities are present in each ESB solution, what does the vulnerability trend look like, how quickly are vulnerability fixes made available, etc. By looking at the vulnerability intel from a solution such as TW, the engineering team can factor in the vulnerability aspects into the decision making process.
- An organization is looking at deploying a HTTP server for their needs. They need to decide on the right HTTP server based on their requirements, scalability, etc. A key aspect that is often overlooked is the vulnerability report and trend for the HTTP server options being considered. For example how many vulnerabilities were reported in the last 30-60-90 days, how soon are the vulnerabilities addressed, are remediations provided to circumvent the vulnerabilities before a patch is made available, etc.
Organization needs to look at the vulnerability aspects of a software while making a purchasing or adoption decision for new software.
For more details on how TW can be leveraged by your organization for tracking vulnerabilities in 3rd party software as part of your DevOps CI/CD process, reach to us at info@threatwatch.io