top of page
Writer's pictureJeffrey Crump

Security Operations Center - Use Case Maturity Model/Cube (SOC-UCMM)

Updated: Mar 27, 2021


UPDATE: March 26, 2021: The SOC-UCMM license has changed to a Creative Commons Attribution-NonCommercial 4.0 International License.


Download the SOC-UCMM.


In 2014, during my time at Datashield, the RSA white-labeled Managed Security Services Provider (MSSP) - now ADT Cybersecurity - it was clear in working closely with more than 40 clients that they essentially fell into two categories: compliance-driven or maturity-driven.


Compliance-driven clients basically wanted to be able to check a box that their event logs were being managed. Yes, security was important but it more or less took backseat to ensuring they were complying with regulatory requirements. Monthly status calls were quick and easy with discussions concentrated on availability and any client-specific monitoring content (also referred to as use cases) that was being developed/deployed.


Maturity-driven clients were much more emotionally invested in the security operations center outsourcing relationship. For them, establishing a more robust security posture and having a clear roadmap to becoming more security mature was at the forefront. Despite having a vary large catalog of monitoring content/rules there really wasn't a roadmap and there most certainly wasn't any way to articulate the relationship(s) between monitoring content or the prerequisites for an evolution of maturity.


So, although we were not under duty to do so and we weren't employed to create one, a colleague of mine, Praveen Money, and I set off on building the initial framework for what we called a Monitored Security Service Use Case Maturity Cube (renamed Security Operations Center - Use Case Maturity Model/Cube (SOC-UCMM). Once the wireframe of the cube was developed I set off working with the security operations center (SOC) team to add some real content into the initial framework.


After we established a minimal viable product (MVP) we began to work with a select few clients on using the Security Operations Center - Use Case Maturity Model/Cube (SOC-UCMM). It was extremely well received since it was not only easy to understand but that it outlined the relationship and requirements in a manner any client could understand.


Just to reiterate, this is not about the maturity of the SOC / MSSP. This about the monitoring content (e.g. the rules/use cases developed and implemented within a security information and event management (SIEM)).


The goal of the Security Operations Center - Use Case Maturity Model/Cube (SOC-UCMM) is to provide a prescriptive framework for incremental improvement for information security monitoring.


The cube is comprised of Maturity Levels, Domains and Use Cases. Use case complexity increases along with the maturity level. Predecessor and/or prerequisite relationships are common amongst the use cases.


Security Operations Center - Use Case Maturity Model/Cube (SOC-UCMM)

Maturity Levels

Domains

Use Case Structure

A few more examples:

Code: M1O2

Title: Maturity Level 1 | Organizational Domain | Use Case 2

Name: Network architecture is documented.

Description: Through the process of documenting the network

architecture an organization demonstrates an awareness required for

higher maturity use cases.

Source: Logs & Packets

Predecessor(s): None

Code Mapping: M1HALL M1NALL


Code: M1O5

Title: Maturity Level 1 | Organizational Domain | Use Case 5

Name: Normal/expected network traffic volume is understood.

Description: An organization must understand the source of its network

Traffic in order to establish a normal/expected threshold, which will be

used to establish correlated alerts.

Source: Logs & Packets

Predecessor(s): None

Code Mapping: M1HALL M1NALL


Code: M1O6

Title: Maturity Level 1 | Organizational Domain | Use Case 6

Name: Changes are authorized and verified.

Description: An organization must have a documented process in place

to review, verify and confirm that changes made to monitored devices

are approved and implemented as expected.

Source: Logs & Packets

Predecessor(s): M1O2

Code Mapping: M1HALL M1NALL


Code: M2O3

Title: Maturity Level 2 | Organizational Domain | Use Case 3

Name: Normal/expected port usage is documented.

Description: The traffic associated with specific ports must be documented

in order to mitigate risk associated with unauthorized use or potentially

malicious activity flagged in subsequent correlated alerts.

Source: Logs & Packets

Predecessor(s): M102, M105

Code Mapping: M1HALL M1NALL


The cube has other faces that would contain additional intelligence as shown below.


With the additional faces in mind I have expanded the original framework to include the following:


CUBE FACE 1:

Code | Title:

Name:

Description:

Domain: Host, Network, Account, Integration, Organizational

Predecessor Code(s):

Sibling Code(s):

Child Code(s):

Source(s):


CUBE FACE 2:

Standards Mapping (e.g. ISO 27001, NIST 800-53, etc.):


CUBE FACE 3:

Notification: Alert | Report


CUBE FACE 4:

Attack Vector: Virus, email attachment, web page, etc.

Attack Corridor: External | Internal | Direct | Indirect (square, x place in table)


CUBE FACE 5:

Kill Chain State: Reconnaissance, Weaponization, Delivery, Exploitation, Installation, Command and Control, Action on Objectives


CUBE FACE 6:

Incident Response Playbook Code(s):


MATURITY LEVEL REPORTING:

Domain Weight:

Model Weight:


Obviously no one is going to go around creating a bunch of cube images to represent each use case so the practical manner in which to implement the maturity model/cube is through an Excel spreadsheet or a database. The work I have thus far is Excel-based.


I'd love to find a few committed souls willing to engage and continue the work on this. There's still a lot of work to do to validate the framework and the faces as well as go through a (growing) library of use cases and work them through the framework. Please contact me if you or your company are interested in being a part of this.


Important License Information


Attribution — You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests I endorse you or your use.


NonCommercial — You may not use the material for commercial purposes.


No additional restrictions — You may not apply legal terms or technological measures that legally restrict others from doing anything the license permits.

Comments


bottom of page