SOC 2 CC7: Common Criteria related to System Operations

What is SOC 2 System Operations (CC7)?

Organizations are responsible for managing the operation of their systems, which means they need to continuously work to detect, prevent, and address any security issues that may impact their business. Staying on top of monitoring security protocols, preventing and responding to security incidents, and having a plan of action ready will help you meet the requirements outlined in the SOC 2 Common Criteria related to System Operations (pgs. 33-37).

The system operations guidelines lay out a series of requirements that focus on using defined configuration standards, monitoring infrastructure and software, detecting changes, detecting unknown or unauthorized components, vulnerability scanning and incident response processes.

Understanding how to best manage your system operations—and following the steps outlined in CC7—will help ensure that your organization’s data, operations, and overall function stays safe, secure, and protected. Not to mention, following these guidelines will also help your organization receive a clean SOC 2 report.

What are the Requirements for SOC 2’s CC7?

Much like CC6, there’s a significant number of points of focus to look at within CC7, however, many of them are interrelated or simply attributes of a bigger process. We’ll break it down by each of the Common Criteria to keep it organized, and remember that each of these major criteria is supported by several specific points of focus that the AICPA asks the auditor to consider when determining whether those criteria have been met.

Policies and Documentation Requirements

One of the recurring themes with SOC 2 compliance is having documented policies and procedures communicated to your users and followed in a way that can be verified. For CC7, you must have an information security policy that addresses the requirements below. Please take a look at our CC2: Communication and Information post to see more about the overall policy requirements, the bullet points that need to be included, and the frequency of review.

The SOC guidelines feature five criteria you need to be aware of and carry out within your organization to protect the integrity of your system operations. To make grasping these crucial points easier, we’ve summarized them below. Simply stated, as an entity, you need to be:

1. Using monitoring and protection protocols to identify changes in your system that could allow your system to become vulnerable to security threats.
2. Monitoring your system’s components and watching for anomalies that might indicate malicious acts, natural disasters, or errors—and then assessing each anomaly’s security risk and to what degree they impact your organization.
3. Evaluating any security incidents to see if their impact caused your entity to fail to meet its objective
4. Responding to security incidents by executing a defined incident response program that works to understand, contain, remediate, and communicate security incidents.
5. Have a plan in place to recover from identified security incidents.

These guidelines help you find ways to properly manage your system operations so that security incidents don’t put your organization at risk. Let’s dig into the specifics of each one to se what you’ll need to do.

CC7.1 Requirements

To meet its objectives, the entity uses detection and monitoring procedures to identify (1) changes to configurations that result in the introduction of new vulnerabilities, and (2) susceptibilities to newly discovered vulnerabilities.

On the surface, CC7.1 appears to be all about monitoring for the introduction of vulnerabilities and whether new vulnerabilities will impact you. In reality, this gets broken down into a collection of things that you will need to do. Overall, these requirements do not mean that you need to do every single one of them, but rather pick some to all of them depending on the applicable risk to your environment.

• Uses Defined Configuration Standards – Defined configuration standards often take the form of a documented hardening standard or a runbook for building out new infrastructure. If you need to build out a new environment, what standards is your build team going to follow? Will they change default passwords? Is there a standard set of software or configurations made so that the system will function in your environment? Quite frankly, this is usually fairly easy for our clients to put together as it’s something that they do but just don’t document. The main ask here is documenting, reviewing on a regular basis and using the defined configuration standards for your builds.
• Monitors Infrastructure and Software – In the context of CC7.1, this monitoring is related to your defined configuration standards and confirming that they are being implemented throughout your environment. If you decided that the CIS Benchmarks are going to be your hardening standard, this control would be for scanning your infrastructure and comparing to CIS benchmarks. If you have a more custom configuration standard, then something that focuses on key configurations would be important to implement (i.e. a monitor for identifying public S3 buckets).
• Implements Change Detection Mechanisms – Change is inevitable (except from vending machines) and this requirement asks you to consider change detection mechanisms such as file integrity monitoring or some other alerts to identify key modified files. The difficult part about this task is identifying the files that you want to monitor and are key for you and how to handle dynamically generated files from your application.
• Detects Unknown or Unauthorized Components – For detecting unknown or unauthorized components, you’ll want to first determine what type of components would be highest risk to you and design a detection mechanism to identify them. For example, if you’re a datacenter, scanning for rogue WiFi hotspots would b a good idea. If you’re operating in a cloud environment, identifying new resources being activated in production VPCs would be a good thing to be alerted to.
• Conducts Vulnerability Scans – Vulnerability scanning is both the easiest and most difficult to implement. The easy part of the vulnerability scan is deciding which scanner to use (i.e. Qualys, Tenable, AWS Inspector, OpenVAS), setting it up and having it scan your environment on a regular basis (credentialed scanning is the way to go). The difficult part is actually reviewing the reports that it generates, triaging the findings and tracking those findings through to resolution. You’ll often run into roadblocks where patching some vulnerability will break your software, leading to an expensive refactor that the product team isn’t interested in doing. Overall, our clients struggle significantly with cleaning up their environments and documenting the actions taken for scans.

CC7.2 Requirements

The entity monitors system components and the operation of those components for anomalies that are indicative of malicious acts, natural disasters, and errors affecting the entity’s ability to meet its objectives; anomalies are analyzed to determine whether they represent security events.

Moving on to CC7.2, we start getting into the classic subject of log monitoring, detection and response. This is another area where we see a bit of variation from client to client as risk is something that needs to be considered when determining how to address these requirements. Don’t forget that these measures will need to address both the application and infrastructure layer of your system.

• Implements Detection Policies, Procedures, and Tools – Before you can start on your security log monitoring adventure, you should start by determining exactly what you need to log. This often takes some brainstorming amongst the various stakeholders to figure out the types of actions that could indicate a potential security issue that needs to be escalated for review. Once you’ve figured those out, you can go shopping for tools (whether they are ones you have, ones baked into your cloud provider or ones you shell out some cash for) that are able to assist you in implementing the log monitoring strategy.
• Design Detection Measures – When you’re working on your security logging strategy, you should make sure that you’ve minimally considered the following elements of things that are important to you:
  • Compromise of physical barriers
  • Authorized people carrying out unauthorized actions
  • Use of compromised identification and authentication credentials
  • Unauthorized access that comes from outside your organization
  • Compromise of external authorized parties
  • Connection or implementation of unauthorized hardware or software
• Implements Filters to Analyze Anomalies – As part of your security logging strategy and tooling, you’ll want to include requirements related to filtering and automated analysis, as quite frankly, that security engineer is not going to be reading billions of lines of logs every day. This can be met several ways – you could get a SIEM product setup that performs correlation and escalates based upon specific rules and risk or you could configure the tools you’re using to use thresholds and filters before alerting you (i.e. CloudWatch alarms).
• Monitors Detection Tools for Effective Operation – Once you’ve got all of your logging gadgets set up, you should ensure there is a process to monitor the alerts that the system is generating. For example, if your logging strategy says that anytime event X occurs, a ticket should be opened and a resolution documented, you’ll want to make sure that is happening, being documented, and the tickets are being closed in a timely manner.

CC7.3 Requirements

The entity evaluates security events to determine whether they could or have resulted in a failure of the entity to meet its objectives (security incidents) and, if so, takes actions to prevent or address such failures.

Moving into CC7.3, we start getting back into the people and procedural side of security by taking a look at the Security Incident Response Policy and related procedures. If you’re looking for a good starting place, we tend to point folks at NIST’s Computer Security Incident Handling Guide as a good base for doing the needful here. We’ve also written about creating a security incident response plan which is a bit easier to read than the NIST publication. We’ll step through each of the points of focus and outline whether it’s something you need to be doing or something that you need to make sure is included in your incident response documentation.

• Responds to Security Incidents – This one is relatively straightforward – have documented procedures for responding to security incidents and review those procedures on a regular basis.
• Communicates and Reviews Detected Security Events – This point of focus is emphasizing the need for communicating events to the folks in charge of security so they can review the event. This may take the form of awareness and culture in your organization to send suspicious items to the security team (enforced through training and policy).
• Develops and Implements Procedures to Analyze Security Incidents – As part of your overall security incident response procedures, make sure you include a step that determines the system impact.
• Assesses the Impact on Personal Information – For each security event (and as part of your procedures), determine whether personal information could have been disclosed.
• Determines Personal Information Used or Disclosed – If personal information was disclosed, identify exactly what was disclosed and take the appropriate actions.

CC7.4 Requirements

The entity responds to identified security incidents by executing a defined incident response program to understand, contain, remediate, and communicate security incidents, as appropriate.

With CC7.4, we continue the quest into having a documented incident response procedure with the focus on the nuts and bolts of the phases of incident response that you go through. Some of these may seem a bit redundant, but there’s a two step approach for the auditors when they are looking at incident response. The first is to review your documentation to confirm that it contains all of the required elements (Policy) and the second part (Action) would be to ask for a list of all incidents and then review the relevant documentation to confirm you followed policy. I’ve noted which ones are more policy driven versus to be tested as part of

• Assigns Roles and Responsibilities (Policy) – As with any other procedure, you need to identify the parties that will be involved in the incident response. This will obviously include your security team and admin team, but you also should consider your legal team, communications or any relevant external parties (i.e. insurance company and/or forensics).
• Contains Security Incidents (Policy) – For this, your procedure should minimally address steps that will be taken to contain the incident. For example, isolate an infected system from the rest of the environment. You can also go as far as having a playbook for a variety of different scenarios so you know how you’ll handle a particular event.
• Mitigates Ongoing Security Incidents (Policy) – Much like containment, a minimal general plan can work here, but extra credit goes to those with a set of playbooks based upon specific events.
• Ends Threats Posed by Security Incidents (Policy) – Obviously, once you’ve contained and mitigated the threats, fully removing them will be the next step. As with the prior couple of items, this can be documented generally or you can develop specific playbooks.
• Restores Operations (Policy) – Once you’ve ended the security threat, you’ve got to get back to your pre-incident state. This is where your backup/recovery strategy comes into place, perhaps your BCP/DR plan or any other playbook to get your systems back and up and running.
• Develops and Implements Communication Protocols for Security Incidents (Policy) – Having a defined communication plan is critical during an event, but it can also vary from “only legal should make statements to external parties” to having a more elaborate communication plan.
• Remediates Identified Vulnerabilities (Action) – Make sure you followed your procedures related to containment, mitigating security incidents and ending threats.
• Communicates Remediation Activities (Action) – Make sure you followed your communication protocols for each security incident.
• Evaluates the Effectiveness of Incident Response (Policy) – Part of your procedures should be to perform a root cause analysis after the conclusion of a security incident and take steps to prevent it from reoccuring.
• Periodically Evaluates Incidents (Action) – Do the root cause analysis after each event.
• Communicates Unauthorized Use and Disclosure (Action) – Follow your communication plan for unauthorized use of personal information.
• Application of Sanctions (Policy and Action) – This one often gets handled as part of CC1 relating to sanctioning employees and contractors who do not follow company policies and procedures. This is here to emphasize that if retraining or sanctions are relevant based upon the security event that they are applied.

CC7.5 Requirements

The entity identifies, develops, and implements activities to recover from identified security incidents.

For our last stop in the journey at CC7.5, we get into the recovery from security events phase. Much like CC7.4, there are both policy and action components to consider.

• Restores the Affected Environment (Action) – Did you follow your restoration procedures to get your environment back up and running?
• Communicates Information About the Event (Action) – Did you follow your communication plan?
• Determines Root Cause of the Event (Action) – Did you perform a root cause analysis for each incident?
• Implements Changes to Prevent and Detect Recurrences (Action) – Did you implement changes identified as necessary from the root cause analysis to prevent future recurrences?
• Improves Response and Recovery Procedures (Action) – Did you update your response and recovery procedures, if needed, after an incident or a test incident?
• Implements Incident Recovery Plan Testing (Action) – Test your incident response plan on at least an annual basis. Involve all relevant parties and make sure the test response was documented and any relevant improvements are identified and followed through on.

Conclusion

Your system operations are at the heart of your business, and protecting them should be at the heart of your security plan. Complying with Common Criteria guidelines and other helpful frameworks like like NIST 800-63r2 is the best way to ensure your organization is safe from threats both now and in the future.

The most important thing to realize about protecting your system operations is that it’s an ongoing process that needs to be continuously evaluated, updated, and improved. A major component of this framework revolves around using the information you’ve gathered from security events and incidents to improve your overall security measures. It’s also equally important to not only use proper detection, monitoring, and prevention tactics but also to evaluate how effective these tactics are as well.

This article covers the main points outlined in the Common Criteria, but this topic is complex and nuanced. If you’d like to get professional help ensuring your organization’s safety (and that you pass a SOC 2 audit), don’t hesitate to reach out.