Implementing the NIST Cybersecurity Framework (CSF) 2.0 with AI augmented API Security

Overview

• NIST recently published version 2.0 of its Cybersecurity Framework (CSF), with updates to its core guidance and a refined focus on governance and supply chains. 
• Previously centered on critical infrastructure, the framework now supports organizations of all sectors and sizes – recognizing that cyber risk affects every organization. 
• In turn, we at Noname Security recommend that security teams recognize that API-focused risk is just as universally important. 

In this blog post, we’ll discuss how your organization can implement NIST CSF 2.0 across several areas. We’ll also discuss how you can gain visibility and reduce risk with the Noname API Security Platform’s machine learning and AI capabilities.

Background on NIST’s Updated Framework

The updated NIST Cybersecurity Framework (CSF) 2.0 was published February 26, 2024. Previously, this content was also known as the “Framework for Improving Critical Infrastructure Cybersecurity.” As stated in the framework:

The NIST Cybersecurity Framework (CSF) 2.0 provides guidance to industry, government agencies, and other organizations to manage cybersecurity risks. It offers a taxonomy of high-level cybersecurity outcomes that can be used by any organization.

In summary, the updated NIST Cybersecurity Framework is organized into the following functional categories. 

Table 1. CSF 2.0 Core Function and Category Names and Identifiers

Please note:

• Readers seeking additional guidance can find it on the NIST CSF website: https://www.nist.gov/cyberframework 
• You can also read about implementation examples for each category on the following NIST page: https://www.nist.gov/document/csf-20-implementation-examples-xlsx

Context on the Critical Role of API Security

Why focus on APIs, amid the myriad of security functions that NIST CSF 2.0 covers? Because APIs live at the core of every digital product and service today’s organizations provide to their end users, ranging from customers to citizens. 

The average organization has between 15,000 and 25,000 APIs, all designed to facilitate a non-stop exchange of data. Exposed or misconfigured APIs are prevalent, easy to compromise, and often unprotected, unseen, and unmanaged. And just one compromised API can result in millions of records being stolen.

We suggest that an organization wishing to achieve a repeatable or an adaptive level of maturity should leverage a machine learning powered technology refresh approach towards implementing the NIST CSF.

What capabilities does an organization need to reach these levels of maturity? We recommend a portfolio of machine learning-powered, AI-augmented API Security solutions that are designed to help organizations be risk-informed about infrastructure misconfigurations with: 

• Posture management insights about cloud configurations and common vulnerabilities and weaknesses in APIs with near real-time continuous monitoring and adverse event analysis with runtime security integrations (with WAFs, load balancers, and API-focused technologies such as API gateways, docker swarms, and Kubernetes pods).

By leveraging machine learning innovations from Noname Security in concert with the existing investments made in cloud and on-premises environments, organizations can better detect possible cybersecurity attacks and compromises.

In the following sections, we’ll explore key NIST CSF 2.0 subcategories that your team should know about. In each one, we’ll provide a brief description of the general controls needed, as well as specific examples of how your organization can strengthen its degree of visibility and protection.

Deep-dive: Continuous Monitoring

Continuous Monitoring (DE.CM): Assets are monitored to find anomalies, indicators of compromise, and other potentially adverse events.

Subcategory	Description	Example
DE.CM-01	Networks and network services are monitored to find potentially adverse events.	Monitor DNS, BGP, and other network services for adverse events. Monitor wired and wireless networks for connections from unauthorized endpoints. Monitor facilities for unauthorized or rogue wireless networks. Compare actual network flows against baselines to detect deviations. Monitor network communications to identify changes in security postures for zero trust purposes.
DE.CM-03	The physical environment is monitored to find potentially adverse events.	Use behavioral analytics software to detect anomalous user activity to mitigate insider threats. Monitor logs from logical access control systems to find unusual access patterns and failed access attempts Continuously monitor deception technology, including user accounts, for any usage.
DE.CM-06	External service provider activities and services are monitored to find potentially adverse events.	Monitor remote and onsite administration and maintenance activities that external providers perform on organizational systems. Monitor activity from cloud-based services, internet service providers, and other service providers for deviations from expected behavior.
DE.CM-09	Computing hardware and software, runtime environments, and their data are monitored to find potentially adverse events.	Monitor email, web, file sharing, collaboration services, and other common attack vectors to detect malware, phishing, data leaks and exfiltration, and other adverse events. Monitor authentication attempts to identify attacks against credentials and unauthorized credential reuse. Monitor software configurations for deviations from security baselines. Monitor hardware and software for signs of tampering.-Use technologies with a presence on endpoints to detect cyber health issues (e.g., missing patches, malware infections, unauthorized software), and redirect the endpoints to a remediation environment before access is authorized.

Deep-dive: Adverse Event Analysis

Adverse Event Analysis (DE.AE): Anomalies, indicators of compromise, and other potentially adverse events are analyzed to characterize the events and detect cybersecurity incidents.

Subcategory	Description	Example
DE.AE-02	Potentially adverse events are analyzed to better understand associated activities	Use security information and event management (SIEM) or other tools to continuously monitor log events for known malicious and suspicious activity. Utilize up-to-date cyber threat intelligence in log analysis tools to improve detection accuracy and characterize threat actors, their methods, and indicators of compromise. Regularly conduct manual reviews of log events for technologies that cannot be sufficiently monitored through automation. Use log analysis tools to generate reports on their findings.
DE.AE-03	Information is correlated from multiple sources.	Constantly transfer log data generated by other sources to a relatively small number of log servers Use event correlation technology (e.g., SIEM) to collect information captured by multiple sources Utilize cyber threat intelligence to help correlate events among log sources
DE.AE-04	The estimated impact and scope of adverse events are understood.	Use SIEMs or other tools to estimate impact and scope, and review and refine the estimates. A person creates their own estimates of impact and scope.
DE.AE-06	Information on adverse events is provided to authorized staff and tools.	Use cybersecurity software to generate alerts and provide them to the security operations center (SOC), incident responders, and incident response tools. Incident responders and other authorized personnel can access log analysis findings at all times. Automatically create and assign tickets in the organization’s ticketing system when certain types of alerts occur. Manually create and assign tickets in the organization’s ticketing system when technical staff discover indicators of compromise
DE.AE-07	Cyber threat intelligence and other contextual information are integrated into the analysis.	Securely provide cyber threat intelligence feeds to detection technologies, processes, and personnel. Securely provide information from asset inventories to detection technologies, processes, and personnel. Rapidly acquire and analyze vulnerability disclosures for the organization’s technologies from suppliers, vendors, and third-party security advisories.
DE.AE-08	Incidents are declared when adverse events meet the defined incident criteria.	Apply incident criteria to known and assumed characteristics of activity in order to determine whether an incident should be declared. Take known false positives into account when applying incident criteria.

Deep-dive: Asset Management (ID.AM)

Asset Management (ID.AM): Assets (e.g., data, hardware, software, systems, facilities, services, people) that enable the organization to achieve business purposes are identified and managed consistent with their relative importance to organizational objectives and the organization’s risk strategy.

Noname Security also provides awareness of cloud infrastructure ID.AM Identify Asset Management with integrations to a configuration management database (CMDB) systems inventory, making it possible for DevSecOps teams and CISO organizations to more efficiently perform their duties to provide the necessary PR.PS Platform Security and the PR.IR Technology Infrastructure Resiliency required by the business for the use case. 

To properly respond and recover from a security breach or zero day vulnerability, Noname Security offers automated blocking to prevent vulnerabilities from being exploited by malicious bots or hackers and actionable integrations with DevOps and Developer work queue systems such as JIRA and ServiceNow. 

Deep-dive: Respond, Recover, and Incident Management

RESPOND (RS): Actions regarding a detected cybersecurity incident are taken. 

RECOVER (RC): Assets and operations affected by a cybersecurity incident are restored.

Incident Management (RS.MA): Responses to detected cybersecurity incidents are managed

Subcategory	Description	Example
RS.MA-01	The incident response plan is executed in coordination with relevant third parties once an incident is declared.	Detection technologies automatically report confirmed incidents.
RS.MA-02	Incident reports are triaged and validated.	Preliminarily review incident reports to confirm that they are cybersecurity-related and necessitate incident response activities.
RS.MA-03	Incidents are categorized and prioritized.	Prioritize incidents based on their scope, likely impact, and time-critical nature. Review and categorize incidents based on the type of incident (e.g., data breach, ransomware, DDoS, account compromise).
RS.MA-04	Incidents are escalated or elevated as needed.	Coordinate incident escalation or elevation with designated internal and external stakeholders.
RS.MA-05	The criteria for initiating incident recovery are applied.	Apply incident recovery criteria to known and assumed characteristics of the incident to determine whether incident recovery processes should be initiated.

Deep-dive: Incident Analysis

Incident Analysis (RS.AN): Investigations are conducted to ensure effective response and support forensics and recovery activities.

Subcategory	Description	Example
RS.AN-03	Analysis is performed to establish what has taken place during an incident and the root cause of the incident.	Determine the sequence of events that occurred during the incident and which assets and resources were involved in each event.
RS.AN-06	Actions performed during an investigation are recorded, and the records’ integrity and provenance are preserved.	Require each incident responder and others (e.g., system administrators, cybersecurity engineers) who perform incident response tasks to record their actions and make the record immutable
RS.AN-07	Incident data and metadata are collected, and their integrity and provenance are preserved.	Collect, preserve, and safeguard the integrity of all pertinent incident data and metadata (e.g., data source, date/time of collection) based on evidence preservation and chain-of-custody procedures.
RS.AN-08	An incident’s magnitude is estimated and validated.	Automatically run tools on targets to look for indicators of compromise and evidence of persistence.

Deep-dive: Incident Response Reporting and Communication

Incident Response Reporting and Communication (RS.CO): Response activities are coordinated with internal and external stakeholders as required by laws, regulations, or policies.

Subcategory	Description	Example
RS.CO-02	Analysis is performed to establish what has taken place during an incident and the root cause of the incident.	Follow the organization’s breach notification procedures after discovering a data breach incident, including notifying affected customers.
RS.CO-03	Actions performed during an investigation are recorded, and the records’ integrity and provenance are preserved.	Securely share information consistent with response plans and information sharing agreements.

Incident Mitigation (RS.MI): Activities are performed to prevent expansion of an event and mitigate its effects.

Subcategory	Description	Example
RS.MI-01	Incidents are contained.	Cybersecurity technologies (e.g., antivirus software) and cybersecurity features of other technologies (e.g., operating systems, network infrastructure devices) automatically perform containment actions.
RS.MI-02	Incidents are eradicated.	Cybersecurity technologies and cybersecurity features of other technologies (e.g., operating systems, network infrastructure devices) automatically perform eradication actions.

Deep-dive: Incident Recovery Plan Execution

RECOVER (RC): Assets and operations affected by a cybersecurity incident are restored. 

Incident Recovery Plan Execution (RC.RP): Restoration activities are performed to ensure operational availability of systems and services affected by cybersecurity incidents.

Subcategory	Description	Example
RC.RP-01	The recovery portion of the incident response plan is executed once initiated from the incident response process.	Begin recovery procedures during or after incident response processes.
RC.RP-02	Recovery actions are selected, scoped, prioritized, and performed.	Select recovery actions based on the criteria defined in the incident response plan and available resources.
RC.RP-03	The integrity of backups and other restoration assets is verified before using them for restoration.	Check restoration assets for indicators of compromise, file corruption, and other integrity issues before use.
RC.RP-04	Critical mission functions and cybersecurity risk management are considered to establish post-incident operational norms.	Use business impact and system categorization records (including service delivery objectives) to validate that essential services are restored in the appropriate order. Work with system owners to confirm the successful restoration of systems and the return to normal operations.
RC.RP-05	The integrity of restored assets is verified, systems and services are restored, and normal operating status is confirmed.	Check restored assets for indicators of compromise and remediation of root causes of the incident before production use.
RC.RP-06	The end of incident recovery is declared based on criteria, and incident-related documentation is completed.	Prepare an after-action report that documents the incident itself, the response and recovery actions taken, and lessons learnedDeclare the end of incident recovery once the criteria are met.

Deep-dive: Incident Recovery Communication

Incident Recovery Communication (RC.CO): Restoration activities are coordinated with internal and external parties

Subcategory	Description	Example
RC.CO-03	Recovery activities and progress in restoring operational capabilities are communicated to designated internal and external stakeholders.	Securely share recovery information, including restoration progress, consistent with response plans and information sharing agreements.
RC.CO-04	Public updates on incident recovery are shared using approved methods and messaging.	Follow the organization’s breach notification procedures for recovering from a data breach incident.

Conclusion:

In today’s threat landscape, it’s essential to understand the key requirements of global frameworks such as NIST CSF version 2.0. In addition to updating its core guidance, NIST has also introduced a suite of resources to assist organizations like yours in achieving their cybersecurity goals. 

Are you seeking to learn more about API-related risks and what it takes to reduce them?

With 92% of enterprises having experienced an API security incident, organizations also need guidance on the vulnerabilities and attack methods that are central to protecting APIs. Industry experts turn to the “2023 API Security Top Ten,” a report from the highly respected non-profit Open Web Application Security Project (OWASP). 

You can learn about the OWASP Top Ten – and best practices for preventing API breaches – in a convenient eBook we published to help security teams.

Read the eBook to learn more.