SOC 2 Academy: Detect and Monitor Changes in Your System Configurations
by Joseph Kirkpatrick / March 1st, 2019
Common Criteria 7.1
When an organization undergoes a SOC 2 audit, auditors will be looking to validate that they comply with the common criteria listed in the 2017 SOC 2 Trust Services Criteria. Common criteria 7.1 says, “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.” What will an auditor look for when assessing this criterion? What do organizations need to do to demonstrate that they have processes to detect and monitor changes in their system configurations? Let’s discuss.
Complying with Common Criteria 7.1
During a SOC 2 audit, an auditor will assess that an organization meets the requirements of common criteria 7.1 by using the following points of focus:
- The entity uses defined configuration standards.
- The entity monitors infrastructure and software.
- The entity implements change-detection mechanisms.
- The entity detects unknown or unauthorized components.
- The entity conducts vulnerability scans.
In addition to these points of focus, we recommend that the two steps organizations should first take when complying with common criteria 7.1 are implementing effective firewall configurations and hardening standards. Firewall configurations play a critical role in protecting an organization’s assets and hardening standards increase the level of security of an organization’s systems. However, an organization must be able to detect and monitor changes in their system configurations in order for these proactive steps to be effective.
Firewall Configurations and Hardening Standards for SOC 2 Compliance
Think of it this way: a firewall’s purpose is to act as a barrier in order to prevent malicious users from gaining unauthorized access to an organization’s network. If a developer makes and deploys a change to the firewall configurations without gaining approval, critical vulnerabilities could be missed or introduced into the system. The same goes for hardening standards. An organization’s IT team might be faced with implementing changes on the fly, but if there are no processes in place to detect and monitor changes to their system configurations, what vulnerabilities could be missed? How would the organization’s network be impacted? Running regular vulnerability scans is one way to mitigate this issue and ensure that the organization has ways to detect and monitor changes to their system configuration. Vulnerability scans give organizations the ability to identify gaps in their systems and remediate those vulnerabilities accordingly.
More SOC 2 Resources
Understanding Your SOC 2 Report
SOC 2 Compliance Handbook: The 5 Trust Services Criteria
In SOC 2 common criteria 7.1, we get into the section that’s called “system operations.” This particular criterion requires that you have a way to detect and monitor changes in system configurations and also susceptibility to newly discovered vulnerabilities. Let’s discuss some examples of how to implement common criteria 7.1. First and foremost, firewall configurations. They’re very critical to the protection of your system’s assets. It’s something that lives at critical points within your network, whether it’s on the perimeter or internally, protecting systems that you have valued to the point of putting a firewall in front of them. You would want to make sure that nothing has changed in that configuration without your knowledge and without understanding why that happened. This is why having a mechanism in place to detect a change in the firewall and make sure that those changes are approved and carried out in a secure way. Unfortunately, a lot of times we see that because there is some type of emergency and the configuration is wiped and restored and changes are made on the fly, there’s not a follow-up to confirm the change against the firewall policy of what’s allowed or disallowed, and people just move on or quickly edit a firewall configuration and don’t go back to make sure that the change is properly documented and understood. This is an example of a change that you would want to have a method of detecting or monitoring. The other example really relates to your hardening standards. If you adopt a hardening standard that says that you’re going to harden your Amazon instance according to the best practices that they’ve published, or you’re going to harden a specific Windows machine according to the Microsoft hardening standards, or you’re going to use an independent hardening standard that is published by the Center for Internet Security and you’re going to implement that on all of your servers, routers, and firewalls, you would want to have a way to check that the configuration that you’re expecting is still in place, and if anything does deviate from that standard, that you are aware of it. One way to do this is through vulnerability scans, which check against a certain benchmark in order to help you understand how your system compares against the published standard that you’re trying to achieve. For example, having a policy that says after any firewall configuration change, you’re going to run a firewall analysis tool to verify that it’s in compliance with your policy. Every time you deploy a new server or a new desktop, you might run a vulnerability scan to identify which ports and services are open and running. You might also identify which software is installed and what user accounts are enabled, so that you can compare that against your hardening standard. On a regular, routine basis, using vulnerability scanning to accomplish that for the whole network, so that you can identify what’s running and if there are any newly discovered vulnerabilities that you didn’t previously know about that you need to take action on. These are some examples of ways that you would detect and monitor for these changes and new vulnerabilities, so think about how you would do that in your environment, and specifically think about what your standard is to begin with. What is your goal in how these things should be configured? How tight do you want it to be? Again, you should think of things in terms of default-deny policy. You should start with nothing installed and only specifically allow the things that are necessary for the system to do what it is you expect it to do, and the software, ports, and services that are necessary for your business.
