We take a look at the various compliance standards that apply to the Software Development Lifecycle (SDLC) and the best practices for meeting them.
It’s no surprise that developers are being asked to become security specialists. According to Verizon 2021 Data Breach Investigation Report, basic web application attacks were the second most used models for breaches and incidents. As legislative bodies and industry standards organizations seek to protect data, they are increasingly turning to developers. This means DevOps teams need to focus on both securing applications and documenting their actions to prove compliance. With automation, integrating security and compliance into the software development lifecycle (SDLC) doesn’t have to be a chore.
What are the compliance mandates that apply to the SDLC?
Digital transformation and increased focus on supply chain attacks is changing the way governing bodies (federal, state and industry) view compliance. Almost all new mandates published incorporate third-party vendor management, often focused on web application security. Sometimes they even focus on application development practices developed in-house.
Cyber ââSecurity Maturity Model Certification (CMMC)
Although the CMMC currently only applies to the Defense Industrial Base (DIB), it has the potential to become a more widely adopted compliance requirement in the federal space. In fact, the Department of Defense (DoD) announced in late 2020 that it would require CMMC compliance under contracts with other agencies.
Since CMMC’s primary goal is to protect the DoD supply chain, it needs to consider software development practices, and it does.
Organizations that must meet CMMC Level 3 certification requirements must comply with section CA.3.162 which states that they must:
Use a security assessment of enterprise software that has been developed in-house, for internal use, and that has been identified by the organization as an area of âârisk.
As part of the evaluation objectives, CMMC evaluators will need to determine whether:
[a] the organization reviews internally developed software for risk;
[b] for code defined as a risk area, the organization has documented the security assessment process which may include one or more of the following: manual code review, static analysis and / or dynamic analysis;
[c] the organization has the capacity to demonstrate its safety assessment process; and
[d] the safety assessment process is integrated with the change management process.
Payment Card Industry Data Security Standard (PCI DSS)
Organizations that collect, process, transmit, or store sensitive cardholder data must also adhere to strict compliance mandates. The PCI DSS standard requires organizations to develop software applications securely and defines ten different compliance requirements for developers.
For example, Requirement 6.3 states that organizations must:
Develop internal and external software applications (including web-based administrative access to applications) securely, as follows:
- PCI DSS compliant (e.g. secure authentication and logging)
- Based on industry standards and / or best practices.
- Integrate information security throughout the software development lifecycle
Requirement 6.5 describes ten types of application risks that developers should mitigate:
- Injection faults
- Buffer overflows
- Unsecured cryptographic storage
- Unsecured communications
- Poor error handling
- Detection of “high risk” vulnerabilities
- Cross-site scripts (XSS)
- Inappropriate access control
- Cross-Site Request Infringement (CSRF)
- Interrupted authentication and session management
Health Insurance Portability and Liability Act (HIPAA)
Although HIPAA itself does not contain a reference to SDLC, National Institute of Standards and Technology (NIST) Special Publication (SP) 800-66An introductory resource guide for implementing the HIPAA security ruleÂ»Mentions it. NIST SP 800-66 is currently under review.
In the current iteration of NIST SP 800-66, it sends you to NIST 800-53 “Security and privacy controls for information systems and organizationsWhich notes in the discussion on SA-8 “Engineering Principles of Security and Privacy” that examples of system security engineering principles include “ensuring that developers are trained on how to create secure software â.
In addition, check SA-15 âDevelopment Processes, Standards and Toolsâ that organizations must:
Require the developer of the system, system component, or system service to follow a documented development process that:
1. Explicitly meets security and confidentiality requirements;
2. Identifies the standards and tools used in the development process;
3. Documents specific tool options and tool configurations used in the development process;
4. Documents, manages and ensures the integrity of changes made to the process and / or tools used in development;
In the discussion of control enhancements, the NIST RMF explains that to reduce the attack surface, organizations must apply secure software development practices, reduce the amount of code that executes, and eliminate programming interfaces from applications (API) vulnerable to attacks.
Internet Security Control Center (CIS) V.8
CIS checks v.8 goes into a lot of depth around the secure SDLC process.
Under Control 16 âApplication Software Securityâ, organizations must:
Manage the security lifecycle of internally developed, hosted, or acquired software to prevent, detect, and correct security vulnerabilities before they impact the business.
The CIS Controls then set out the following practices:
- Establish and maintain a secure application development process
- Establish and maintain a process for accepting and addressing software vulnerabilities
- Perform root cause analysis of security vulnerabilities
- Establish and manage an inventory of third-party software components
- Use up-to-date and trusted third-party software components
- Establish and maintain an application vulnerability severity assessment system and process
- Train developers in application security concepts and secure coding
- Apply the principles of secure design in application architectures
- Implement code-level security controls
Building the foundations of a secure and compliant SDLC
Securing applications during the development process is quickly becoming a critical business practice. However, many developers are concerned that application security and adherence to service level agreements (SLAs) are in conflict. The reality is that to maintain a competitive and compliant advantage in the marketplace, companies must find ways to maintain a robust application security program.
Track application dependencies
A look at the recent executive decree on improving the nation’s cybersecurity, the inclusion of the Software Nomenclature highlights the increased role of dependency monitoring in securing supply chains.
When dependency tracking, some good practices include:
- Focus on individual features or use cases
- Use a dependency manager
- Speak with all internal stakeholders involved in the development of the application, such as architects, IT managers and developers
Engage in a manual code review
Examining the source code is fundamental to finding the security weaknesses of an application.
When perform a security code review, some good practices include:
- Finding vulnerabilities that target the type of application
- Review of vulnerability indicators and signatures
- Track data flows to identify common vulnerabilities
- Search for strings, keywords and code patterns known to be indicators of vulnerabilities and misconfigurations
- Find Plain Text Datasets for Dangerous Functions
- Examine the functions potentially risky for accessibility
- Examine user entry locations for exploitable vulnerabilities that can serve as entry points
Create reproducible and documented processes
Part of being compliant is being able to prove that you can maintain your security posture. If you don’t have repeatable processes, you end up relying on internal historical knowledge. Unfortunately, if the people who know what to do leave the organization, that experience leaves them.
Some ways to integrate application security in your application development processes include:
- Integrate security into the draw request process
- Define practices for using security tools to validate manual reviews
- Integrate security controls as a release gate for software deployment and delivery
- Implement a software delivery model that includes security, functional and performance approvals as a condition of deployment
Use an automated code analysis solution
Manually managing all code reviews takes time. In addition, it increases the likelihood of human error risks.
Here are some automated tools that can help you streamline the code review process:
- Static Analysis Security Testing (SAST): identify vulnerable code models
- Software composition analysis (SCA): scan the code for the CVEs found in the dependencies of an application
- Secure scorecards: Automated “pass / fail” controls that provide risk scores
Secure the future of your application by leveraging compliance
Ultimately, compliance is nothing more than a way to prove that you’ve rechecked your work. Just like in your math class in elementary school, you should always go back and review what you’ve done to make sure you haven’t made any mistakes that can cost you an A.
However, just as you went from memorizing multiplication charts to using a graphing calculator as you grew up in school, you can use automated tools like Left Shift CORE to mature your secure coding practices. Best of all, ShiftLeft helps you automate manual and redundant compliance tasks so you can secure your code and document your activities to âshow your workâ to auditors.
Managing security and compliance risks in the SDLC was originally published in ShiftLeft Blog on Medium, where people continue the conversation by highlighting and responding to this story.
*** This is a Syndicated Security Bloggers Network blog by ShiftLeft Blog – Medium written by the ShiftLeft team. Read the original post on: https://blog.shiftleft.io/addressing-security-and-compliance-risk-in-the-sdlc-a170f34f4c64?source=rss—-86a4f941c7da—4