Cloud Security Perspectives and Insights
-
Application Security
August 27, 2020
Leveraging the NIST Cybersecurity Framework for DevSecOps
Continuing with this blog-series on DevSecOps, I have a contributing guest author, Patrick McLaughlin. Patrick is a SaaS Security Architect in the Oracle SaaS Cloud Security engineering group and helps drive the transformation of DevSecOps in Oracle SaaS. In this post, he explains how Oracle uses the available criteria and standards in each phase of the development cycle to provide the best security for its customers.
Framework Introduction
The National Institute of Standards and Technology (NIST) Cybersecurity Framework (CSF) has been under development since 2014 and its aim is to improve cybersecurity for critical infrastructure. The latest version was published in April 2018. It is a shorter and easier-to-understand version of the longer NIST SP 800-53 Security and Privacy Controls for Federal Information Systems and Organizations. NIST SP 800-53 is currently being revised.
The NIST CSF states that “The Framework provides a common language for understanding, managing, and expressing cybersecurity risk to internal and external stakeholders. It can be used to help identify and prioritize actions for reducing cybersecurity risk, and it is a tool for aligning policy, business, and technological approaches to managing that risk. It can be used to manage cybersecurity risk across entire organizations or it can be focused on the delivery of critical services within an organization.”
The CSF has functional areas with categories in each area. The five functional areas are: 
- Identify
- Protect
- Detect
- Respond
- Recover
Table 1 provides a summary of CSF functions and categories.
How SaaS Cloud Security Uses the Framework
The Oracle SaaS Cloud Security (SCS) organization aligns its policies and processes with the CSF, the Centre for Internet Security (CIS) top 20, ISO 27001, ISO 27017, and ISO 27018.
Most of the SCS organization’s areas of security engineering ownership can be mapped to the CSF functional areas. For each functional area, the organization’s internal policies and processes cover all its subcategory areas, using a combination of people, processes, and technical solutions.
Three examples for how we can map our processes to the CSF are:
- For the Protect function, our policies and processes include patching, anti-virus, endpoint detection, and response to protect technology
- As part of the Detect function, SCS has requirements for penetration testing, threat-hunting, and security information and event management (SIEM) with machine learning.
- As part of the Respond and Recover functional areas, SCS has continuous improvement processes, which align with DevSecOps.
Leveraging the NIST framework for DevSecOps
In the DevSecOps diagram below, Development stages are shown on the left and Operations on the right. Security is shown in grey in two ways:
1) Next to all development and operations stages on the inside.
2) As a wrap-around next to all stages on the outside.
There is no obvious mapping from the five CSF areas to the DevSecOps stages, but from looking at the CSF category names, we can initially conclude that all software (cloud services) must still:
- Be represented in an asset register
- Use a common IAM (identity and access management) architecture
- Manage third-party software components, including open-source, in a uniform way
- Have a common detection and incident response approach, as part of the operate-monitor stages
If we look at the next level to the CSF sub-categories (Table 2), the picture becomes much clearer on how the CSF relates to a DevSecOps software lifecycle:
|
DevSecOps Stage |
NIST CSF Category |
NIST CSF Subcategory |
|
Plan |
Identify: Asset Management
|
ID.AM-2: Software platforms and applications within the organization are inventoried |
|
Identify: Risk Assessment |
ID.RA-3: Threats, both internal and external, are identified and documented |
|
|
Identify: Supply Chain Risk Management |
ID.SC-2: Suppliers and third party partners of information systems, components, and services are identified, prioritized, and assessed using a cyber-supply chain risk assessment process |
|
|
Protect: Identity Management, Authentication and Access Control
|
PR.AC-1: Identities and credentials are issued, managed, verified, revoked, and audited for authorized devices, users and processes PR.AC-4: Access permissions and authorizations are managed, incorporating the principles of least privilege and separation of duties PR.AC-5: Network integrity is protected (e.g., network segregation, network segmentation) |
|
|
Protect: Data Security |
PR.DS-7: The development and testing environment(s) are separate from the production environment |
|
|
Code |
None |
|
|
Build |
None |
|
|
Test |
None
|
|
|
Release |
Protect: Protective Technology |
PR.PT-3: The principle of least functionality is incorporated by configuring systems to provide only essential capabilities |
|
Deploy |
Protect: Data Security
|
PR.DS-1: Data-at-rest is protected |
|
Protect: Protective Technology |
PR.PT-4: Communications and control networks are protected |
|
|
Operate |
Protect: Data Security |
PR.DS-4: Adequate capacity to ensure availability is maintained PR.DS-3: Assets are formally managed throughout removal, transfers, and disposition |
|
Protect: Information Protection Processes and Procedures |
PR.IP-3: Configuration change control processes are in place |
|
|
Detect: Anomalies and Events |
DE.AE-1: A baseline of network operations and expected data flows for users and systems is established and managed |
|
|
Monitor |
Protect: Data Security |
PR.DS-6: Integrity checking mechanisms are used to verify software, firmware, and information integrity |
|
Protect: Maintenance |
PR.MA-1: Maintenance and repair of organizational assets are performed and logged, with approved and controlled tools |
|
|
Protect: Protective Technology |
PR.PT-1: Audit/log records are determined, documented, implemented, and reviewed in accordance with policy |
|
|
Detect: Anomalies and Events |
DE.AE-2: Detected events are analyzed to understand attack targets and methods |
|
|
Detect: Security Continuous Monitoring |
DE.CM-1: The network is monitored to detect potential cybersecurity events |
|
|
Detect: Detection Processes |
DE.DP-1: Roles and responsibilities for detection are well defined to ensure accountability |
|
|
Respond: Response Planning |
RS.RP-1: Response plan is executed during or after an incident |
|
|
Respond: Communications
|
RS.CO-1: Personnel know their roles and order of operations when a response is needed |
|
|
Respond: Analysis |
RS.AN-1: Notifications from detection systems are investigated |
|
|
Respond: Mitigation |
RS.MI-1: Incidents are contained |
|
|
Recover: Planning |
RC.RP-1: Recovery plan is executed during or after a cybersecurity incident |
|
|
Recover: Improvements |
RC.IM-1: Recovery plans incorporate lessons learned |
|
|
Recover: Communications |
RC.CO-1: Public relations are managed |
Table 2 Mapping of CSF sub-categories to DevSecOps stages
From the mapping of DevSecOps stages to NIST CSF categories, it’s clear that the CSF focus is mostly on the in-service part of the DevSecOps software lifecycle:
- The CSF provides criteria that development groups must consider during the DevSecOps Plan stage.
- The majority of the CSF sub-categories relate to the Ops part of DevSecOps.
The CSF does not address the Code-Build-Test stages of DevSecOps. At Oracle, we use Oracle software security assurance (OSSA) for those stages, and the Corporate Security Solution Assurance Process (CSSAP) for the security architecture review.
Given that the CSF security activities outlined in the Ops stages (Deploy, Operate, and Monitor) require specialized skillsets, they are not carried out by each software development and delivery team, but instead by a dedicated security team. This follows the organizational structure we had in place before the advent of DevSecOps.
The major difference between the DevSecOps and DevOps model scope is that the tools used by the stand-alone security team must integrate with the tools used by development teams, so that two-way communication is smooth, natural, and frequent enough to support and take advantage of more frequent software releases. Referring back to the DevSecOps diagram, the security tools used by DevOps teams (for example, the tools used for application security testing) are on the inside grey area and the tools used by specialist security teams (for example, the tools used for detection and response) are on the outside grey area.
Conclusion
In Oracle SaaS Cloud Security, we have found that the NIST CSF provides us with valuable guidance when building out a DevSecOps framework, but we use CSSAP during the planning stage and OSSA for the software development stages. In addition to Oracle’s internal processes, you can refer to the SANS Top 25 Most Dangerous Software Errors and the OWASP top 10 for more information about building secure processes.
Using the CSF is recommended for organizations, like SCS, to review and leverage for holistic audit and compliance practices, but it’s not enough on its own to cover all the elements of DevSecOps.
The CSF is in fact most suitable for shaping the activities of a shared centralized security team, which must continue to exist independently of individual development and delivery (DevSecOps) teams. The CSF is also suitable for organizations that do not develop software (and therefore don’t need to think about DevSecOps), but who must secure third-party software.
As we were finishing this blog, we noticed an article that says that NIST is now exploring a possible DevSecOps framework for US government agencies. Perhaps they will leverage the thinking from the US DoD Enterprise DevSecOps Reference Design, published in September 2019, which describes in detail the activities that need to be carried out during each stage and the types of tools that should be used.