Cloud Security Notification Framework (CSNF) Decorator
From Learning/Discovery to Building

This brief document sets out to succinctly communicate objectives, goals, desired outcome and next steps to realize the promise of the ONUG Collaborative’s Cloud Security Notification Framework (CSNF) benefits. Companies driving CSNF are Microsoft Azure, Google Cloud Platform, IBM Cloud, Raytheon, FedEx, Cigna, Goldman Sachs, Pfizer, Kaiser Permanente, Concourse Labs, NETSCOUT, Cisco Systems, ONUG and more.  CSNF is an enabler of the global data lake market which is valued at USD 7.6 billion in 2019 and is expected to grow at a compound annual growth rate (CAGR) of 20.6% from 2020 to 2027 when it is projected to reach $31.5 billion, according to Grand View Research. 

Over the past few months, the CSNF Working Group has hosted discovery and learning sessions to communicate the problem statement that’s created due to the disparity of security notification services between Cloud Service Providers (CSPs). Without CSP security notification standardization and common syntax, Cloud Consumers (CCs) are burdened with increased expenditure of human and capital resources to assess their minimal viable security posture across CSPs and are forced to build complex, complicated and expensive security data lakes, Security Orchestration Automation and Response (SOAR) systems plus Security Information and Event Management (SIEM) infrastructure in the hope to identify and mitigate threats before they do damage. Most importantly, lack of standardized security reporting inhibits automation and enterprise controls of CC’s CSP resources. In short, CSNF provides security teams an important tool to increase staff productivity plus visibility across CSPs and on-prem infrastructure.

Objectives and Goals: These learnings aggregated requirements and culminated into a construct and context for the CSNF “decorator.” Below is an abbreviated list of objectives and goals.

A CSNF architecture and consumption model has been developed with the objective to communicate architectural components of the framework along with today’s friction, the goal of a common information model, the role of the open decorator and decorated alert consumption.   

What Is the Purpose of the CSNF Decorator? In object-oriented programming, the decorator pattern is a design principle that allows behavior to be added to an object without defining an entirely new object. The CSNF decorator provides the CC with a mechanism to “decorate” or enrich security events by augmenting the original security event with additional contextual information to improve fidelity and increase the ability of security teams to identify security events that are most important to them.

A “decorator” has been defined to democratize CSP security notifications

1. Requirements have been documented (see figure below)
2. Security events have been prioritized (Collaborative Document Repo is here)

The  “decorator” is to provide a common set of definitions and syntax to:

1. Ease ingestion of CSP security notifications into security data lakes and other security plus observability tools
2. Provide CSPs translational services to understand common security notifications between and across CSPs 
   1.  Mappings of NIST controls and MITRE ATT&CK into a decorator are high priority to deliver cross CSP translational service
3. Extended log information field attributes are to be accommodated to better understand context, e.g., each CSP to provide a log plus type set of meta field
   1. A method to tag or identify CC assets so as to prioritize response is high priority

Desired Outcome: The CSNF decorator outcome will provide the ability to interpret or interrogate security events/alerts/alarms, etc., across various CSP logs using common standards such as NIST, MITRE ATT&CK, etc. An operator or system may consume CSP logs through the lens of these standards which deliver the same consistent answer/output independent of CSP source. The decorator enables a standard or common security information model feeding SIEM, data lake and SOAR infrastructure.

How CSNF Benefits the Entire Security Operational Ecosystem: Security platforms often require expensive and time-consuming integration efforts to bring in log files from disparate sources such as security alerts, asset inventory, vulnerability assessment, endpoint agents, and IDS products. A common standard like CSNF provides enriched security events that can simplify integration efforts and improve contextual processing by your SIEM, SOAR or data lake platforms.

The CSNF decorators can be used to filter SIEM detection rules based on asset value, compliance type (PCI, PHI) or MITRE ATT&CK framework TTP’s. Contextual filtering can reduce time to threat detection, and thus, help teams focus on the most relevant information during a security investigation and more efficiently prioritize incident response.

SOAR platform workflows can be enhanced by receiving CSNF-decorated security alerts that have been augmented based on the MITRE ATT&CK framework. The event and alert management capabilities of the SOAR are then able to quickly prioritize inbound security events and trigger automated security responsive actions or workflows.

The same CSNF decorator benefits apply to security data lakes. A security data lake is different from the typical SIEM model in terms of architecture and search orientation. A security data lake implies a cloud-hosted solution that brings in data from multiple sources and leverages cost-effective cloud storage. Security teams often don’t know in advance what data to collect but all the data is stored in the cloud data lake. This allows organizations to move beyond search capabilities of the SIEM to true data analytics. The elastic capabilities of cloud allow the security team to focus in improving security posture rather than managing on-premise compute and storage. CSNF enrichments will enhance the ability of security teams to perform analytics that extend beyond threat-hunting to allow advanced analytics and anomaly detection that can be used to define new security policy as code or identify risky applications. Machine learning and anomaly detection using security data lakes will allow security or development teams advance warning so that actions can be taken prior before a security event or incident occurs.

In addition, a collection of additional vetted meta fields that include additional content, which can be vetted along with the log such as an alert with a resource ID, display name, etc. The CC could curate a collection of content that it may want vetted to assist it in building its controls. These attributes become highly beneficial to prioritize incident response as well as reduce the amount of times a CC may need to query a CSP(s) to collect needed data.

Next Steps: With the CC providing aggregate requirements, the next step is to move into a building phase where the CSPs offer a proposal to collaborate and develop the decorator. This will provide a focus and the organizing principle for the CC to further aggregate requirements into the decorator. CSPs are now developing the plan and prototype to be presented during the Tuesday working group check-in meetings where CCs can provide input and guidance on progress to assure the decorator is well received by the community and industry at large. As a goal, a minimum (slice of functionality) demonstration of the decorator operating within an end-to-end solution to showcase its value and promise is to be presented at ONUG Spring on May 5th and 6th with a robust live demonstration at ONUG Fall on October 20th and 21st. CCs will test via Proof of Concept the decorator within their security infrastructure during the summer, providing additional engineering input to CSPs and publicly communicate findings via the ONUG collaborative.

To work with these committed companies and get involved in the ONUG collaborative please go here.