Cloud Security Perspectives and Insights

Leveraging the NIST Cybersecurity Framework for DevSecOps

David B. Cross
SVP SaaS Security

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:



NIST CSF Category

NIST CSF Subcategory


Identify: Asset Management


ID.AM-2: Software platforms and applications within the organization are inventoried
ID.AM-3: Organizational communication and data flows are mapped ID.BE-5: Resilience requirements to support delivery of critical services are established for all operating states (e.g. under duress/attack, during recovery, normal operations)

Identify: Risk Assessment

ID.RA-3: Threats, both internal and external, are identified and documented
ID.RA-2: Cyber threat intelligence is received from information sharing forums and sources

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












Protect: Protective Technology

PR.PT-3: The principle of least functionality is incorporated by configuring systems to provide only essential capabilities


Protect: Data Security


PR.DS-1: Data-at-rest is protected
PR.DS-2: Data-in-transit is protected
PR.DS-3: Assets are formally managed throughout removal, transfers, and disposition
PR.DS-5: Protections against data leaks are implemented

Protect: Protective Technology

PR.PT-4: Communications and control networks are protected
PR.PT-5: Mechanisms (e.g., failsafe, load balancing, hot swap) are implemented to achieve resilience requirements in normal and adverse situations


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
PR.IP-4: Backups of information are conducted, maintained, and tested
PR.IP-6: Data is destroyed according to policy
PR.IP-9: Response plans (Incident Response and Business Continuity) and recovery plans (Incident Recovery and Disaster Recovery) are in place and managed
PR.IP-10: Response and recovery plans are tested
PR.IP-12: A vulnerability management plan is developed and implemented

Detect: Anomalies and Events

DE.AE-1: A baseline of network operations and expected data flows for users and systems is established and managed


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
DE.AE-3: Event data are collected and correlated from multiple sources and sensors
DE.AE-4: Impact of events is determined
DE.AE-5: Incident alert thresholds are established

Detect: Security Continuous Monitoring

DE.CM-1: The network is monitored to detect potential cybersecurity events
DE.CM-2: The physical environment is monitored to detect potential cybersecurity events
DE.CM-3: Personnel activity is monitored to detect potential cybersecurity events
DE.CM-4: Malicious code is detected
DE.CM-5: Unauthorized mobile code is detected
DE.CM-7: Monitoring for unauthorized personnel, connections, devices, and software is performed
DE.CM-8: Vulnerability scans are performed

Detect: Detection Processes

DE.DP-1: Roles and responsibilities for detection are well defined to ensure accountability
DE.DP-2: Detection activities comply with all applicable requirements DE.DP-3: Detection processes are tested
DE.DP-4: Event detection information is communicated
DE.DP-5: Detection processes are continuously improved

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
RS.CO-2: Incidents are reported consistent with established criteria RS.CO-3: Information is shared consistent with response plans RS.CO-4: Coordination with stakeholders occurs consistent with response plans
RS.CO-5: Voluntary information sharing occurs with external stakeholders to achieve broader cybersecurity situational awareness

Respond: Analysis

RS.AN-1: Notifications from detection systems are investigated
RS.AN-2: The impact of the incident is understood
RS.AN-3: Forensics are performed
RS.AN-4: Incidents are categorized consistent with response plans RS.AN-5: Processes are established to receive, analyze and respond to vulnerabilities disclosed to the organization from internal and external sources (e.g. internal testing, security bulletins, or security researchers)

Respond: Mitigation

RS.MI-1: Incidents are contained
RS.MI-2: Incidents are mitigated
RS.MI-3: Newly identified vulnerabilities are mitigated or documented as accepted risks
RS.IM-1: Response plans incorporate lessons learned
RS.IM-2: Response strategies are updated

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
RC.IM-2: Recovery strategies are updated

Recover: Communications

RC.CO-1: Public relations are managed
RC.CO-2: Reputation is repaired after an incident
RC.CO-3: Recovery activities are communicated to internal and external stakeholders as well as executive and management teams

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.

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.


Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.