Common Criteria 7.2

Common criteria 7.2 of the 2017 Trust Services Criteria says, “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.” When an auditor verifies an organization’s compliance with this criterion during a SOC 2 audit, they’ll use the following points of focus to guide their assessment:

• Does the entity implement detection policies, procedures, and tools?
• Does the entity design detection measures?
• Does the entity implement filters to analyze anomalies?
• Does the entity monitor detection tools for effective operation?

Performing Daily Log Reviews to Comply with Common Criteria 7.2

Effectively monitoring an organization’s system is critical to ensuring that no malicious outsider or insider gains access to unauthorized areas or assets. To combat the threat of malicious hackers, we suggest that organizations should start by performing daily log reviews. By having personnel who are strictly responsible for performing daily log reviews, organizations will be better equipped to locate any anomalies that are occurring in their environment, analyze those anomalies, and take the proper measures to mitigate them.

For example, far too often, we have seen data breach headlines that easily could have been prevented if the organization had been performing daily log reviews. A prime example is Panera Bread. In August 2017, a security researcher reported a vulnerability to Panera Bread, but the claim was dismissed. Apparently, Panera Bread didn’t even take the claim seriously enough to look into because eight months later, the bakery-cafe announced a data breach of their website that exposed thousands of customer records. If Panera Bread had personnel dedicated to performing daily log reviews, they could’ve identified the vulnerability on their own and remediated the problem accordingly before any of the clients’ data was put at a greater risk. So, if you’re going to pursue SOC 2 compliance, make sure that your organization has processes in place for performing daily log reviews. Not only will it allow you to keep your security posture strong, but it will demonstrate to your clients that you’re dedicated to keeping their data secure.

More SOC 2 Resources

SOC 2 Academy

Understanding Your SOC 2 Report

It’s a best practice to perform daily log reviews, and just that one control right there is very difficult to accomplish first of all. It requires a full-time person many times. It requires someone who is dedicated to reviewing logs, because even in small environments, there are so many logs generated from so many systems – whether it’s applications, operating systems, desktop systems, servers, routers, firewalls, etc. – that it can be difficult to keep up with. There are many well-known stories about data breaches, where large organizations with network operations centers or security operations centers weren’t reviewing the logs, so they missed the sign of the attack. That’s the purpose of doing daily log reviews: to understand what anomalies are occurring in your environment and doing an analysis of those anomalies in order to understand if they’re real security events or something else that is innocent. This is what common criteria 7.2 of the SOC 2 Trust Services Criteria talks about. It’s really about correlating information from multiple sources, so that you can take action on any anomaly that would indicate that a security event is taking place. You have to think about how to correlate your information. Do you have a log correlation tool that will apply filters and other methods in order to really identify, out of all the noise, what the individual actions are that would indicate that an attack is occurring? I know I get alerts from systems sometimes of problems that are innocent in and of themselves, but if I have that alert plus another alert, I would know that it is a real event, and that something was occurring that we needed to respond to with our incident response plan. Think about common criteria 7.2 and how you would correlate all of the information that gets generated in your environment for the purpose of analyzing those anomalies to identify critical security events.

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

SOC 2 Academy

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.

Common Criteria 6.8

While understanding how to prevent and detect unauthorized software from being installed on your network is important, organizations pursuing SOC 2 compliance should also implement change control processes to mitigate any further risks of unauthorized software being installed. When an organization engages in a SOC 2 audit, an auditor will verify whether they comply with the common criteria listed in the 2017 SOC 2 Trust Services Criteria. Common criteria 6.8 says, “The entity implements controls to prevent or detect and act upon the introduction of unauthorized or malicious software to meet the entity’s objectives.” Let’s take a look at how implementing change control processes can help organizations comply with this criterion.

Using Change Control Processes

One of the points of focus for common criteria 6.8 says, “A management-defined change control process is used for the implementation of software.” What is a change control process? Why should it be used? A change control process is an approach to managing all changes made to a system. Change control processes should be used to ensure that all changes that are made are necessary, approved, documented, and effectively implemented. By doing so, organizations are able to mitigate the risk of unauthorized software being installed on their systems.

Change Control Processes and Remote Employees

Organizations should also make implementing change control processes for remote employees a priority. For example, if an organization provides company-supplied devices, then implementing change control processes for remote employees would be necessary. If a device is returned after an employee resigns or is terminated, organizations need to have processes in place to determine whether or not everything that’s supposed to be installed on the device is there before giving that asset to another employee. The threat that a malicious or disgruntled employee installed unauthorized software on a laptop or other mobile device is very real, so using change control processes for remote employees could prevent any unauthorized software from being installed and help ensure that the organization’s security posture remains strong.

More SOC 2 Resources

SOC 2 Academy

Understanding Your SOC 2 Report

SOC 2 Compliance Handbook: The 5 Trust Services Criteria

A second issue that is important for common criteria 6.8 is having a good change control process in place. You would want to have a record of software being installed. What’s your baseline configuration? What are the additional things that have been approved or changed to be installed on to a particular device? Having knowledge about that and having a formal process so that if an employee wants to install something that wasn’t previously approved, the request can be made, documented, and approved before that change occurs. That type of paper trail is important because especially after a data breach or some other type of security incident, when you’re going back through some type of forensics effort and you’re trying to understand when, how, and why something happened, you’ll identify in your change control process when certain things were approved or denied in terms of software being installed on these systems. You’ll also want to have a process of bringing in a system that’s been out of your control. Let’s say that a remote employee has been terminated, and they send the equipment back to you. Prior to just turning that equipment to another employee or connecting that equipment to your corporate environment, you’d want to have a process to stop and perform an evaluation to understand if everything installed on the system is what you’d expect, if anything new has been introduced, or if there’s any type of threat that would keep you from wanting to put it on your network. Identifying these changes and making sure that you stop and verify that these unauthorized changes haven’t occurred are very important issues for common criteria 6.8.

Common Criteria 6.8

During a SOC 2 audit, an auditor will validate that an organization complies with the common criteria listed in the 2017 SOC 2 Trust Services Criteria, which means that they will assess an organization’s compliance with common criteria 6.8. Common criteria 6.8 says, “The entity implements controls to prevent or detect and act upon the introduction of unauthorized or malicious software to meet the entity’s objectives.” What do organizations need to do to comply with this? What will an auditor be assessing?

How to Prevent and Detect Unauthorized Software

Knowing how to prevent and detect unauthorized software is critical if you want to position yourself as a secure service organization. If you can’t prevent and detect unauthorized software from accessing your network, why would customers want to partner with you? If organizations aren’t performing their due diligence and fail to prevent unauthorized software, they could face steep fines and penalties, a damaged reputation, and put their clients at risk. So, what needs to be done to demonstrate compliance with common criteria 6.8? During a SOC 2 audit, an auditor will assess that the organization does the following:

1. Restricts who can install software on assets
2. Detects unauthorized changes to your software and configuration parameters
3. Uses a defined change control process
4. Uses antivirus and anti-malware software
5. Scans information assets from outside of your organization for malware and other unauthorized software

Why Do You Need to Prevent and Detect Unauthorized Software?

Let’s say that an employee requests that a software be installed on their laptop, which would allow them to more efficiently fulfill their job duties. Management denies the request because the software is too expensive, but the employee decides on their own accord to install the software anyways. This poses a significant risk to the organization’s security posture because the Internet source that the employee downloaded the software from might not be secure, or the software itself might contain malicious software, such as malware, spyware, or Trojans. If this employee goes through with downloading the software and it does contain malware, the organizations could face major financial, organizational, and reputational repercussions. On the other hand, let’s say that a software update pop-up comes up on an employees screen. They select “OK” and the software updates, but the software itself was not authorized to be on the device in the first place. Having processes in place to prevent and detect unauthorized software from being installed would be extremely useful in this case because it would give the employee steps to adhere to when installing or updating software. Regardless of their intention for installing software on an organization’s network, insiders and outsiders alike can be extremely cunning. Are you doing what’s necessary to prevent and detect unauthorized software from being installed in your information security system?

More SOC 2 Resources

SOC 2 Academy

Understanding Your SOC 2 Report

SOC 2 Compliance Handbook: The 5 Trust Services Criteria

Common criteria 6.8 for SOC 2 compliance there’s a few things to talk about, and in this video, I’d like to talk about how you prevent or detect unauthorized software from entering your environment. The first thing is not allowing people who aren’t authorized to install software on your asset. This would necessitate them not being an administrator. This poses a lot of problems for our clients, and many say that it’s a real pain not to have administrative access to the laptop that’s in the field because there are so many issues and problems that could come up where you would need administrator access. You have to think really long and hard about who you’re going to allow to be an administrator on those devices, because clearly by allowing someone to be an administrator, you’re making the risk greater that someone will take a short cut and will install something that maybe you haven’t authorized to be installed on there. At a minimum, if you do allow an employee to have administrative access to some type of a mobile device, you would want some way to detect that software has been installed. You would want some type of an alert and some type of log, so that someone else could understand what occurred and the proper evaluation could be performed. Ultimately, you want to start with preventing unauthorized software to be installed in your environment, so it’s not even allowing people to do the installs. Secondly, you would want to be able to detect it when it does happen. What if it’s an attacker and there’s malware introduced into your environment and has been installed? How would you detect that? You need a malware, antivirus, or some other log that’s generated from one of your security systems that’s able to monitor that and alert the proper security officer that this type of threat was introduced into your environment. Think about prevention and detection when it comes to new software that is unauthorized being introduced into your environment.

Common Criteria 6.7

During a SOC 2 audit engagement, an auditor will validate that an organization complies with the common criteria listed in the 2017 SOC 2 Trust Services Criteria, which means that they will assess an organization’s compliance with common criteria 6.7. Common criteria 6.7 says, “The entity restricts the transmission, movement, and removal of information to authorized internal and external users and processes, and protects it during transmission, movement, or removal to meet the entity’s objectives.” While we’ve discussed ways that organizations can comply with this requirement, let’s take a look at how an organization’s environment can change the way they approach compliance with common criteria 6.7.

What are Best Practices for Implementing Access Controls for Remote Employees?

Complying with common criteria 6.7 means different things for different organizations depending on their environment. For instance, if your employees work in an office building, then implementing and maintaining procedures for transmitting, moving, and removing data might be easier because of the lack of removable media in use. However, because so many organizations are opting to hire remote employees, implementing procedures for transmitting, moving, and removing data can be more difficult, which is why we suggest that organizations implement access controls for remote employees, along with these five best practices:

1. Use security awareness training
2. Establish thorough usage policies
3. Create effective password and encryption policies
4. Monitor Internet connections
5. Ensure devices and applications are updated

Hiring remote employees has many benefits, but it also creates additional threats that must be accounted for. When an organization pursues SOC 2 compliance, it’s critical that they mitigate these risks by using access controls for remote employees, in addition to the best practices listed above. Doing so allows organizations to safeguard their business from potential breaches, demonstrates to clients that their data is protected, and provides peace of mind that the procedures for transmitting, moving, and removing sensitive information remotely are in place.

If you’re unsure if you’ve implemented access controls for remote employees, consider the following scenario. Let’s say that your remote employee leaves their laptop containing sensitive information in their rental car and is unable to recover the device. Do you have a GPS tracker on the device to locate it? Do you have the ability to wipe the device remotely? Are you able to restrict access to the device? It’s far too common for a situation like this to occur, which is why it’s necessary for SOC 2 compliance that organizations implement access controls for remote employees and their mobile devices.

More SOC 2 Resources

SOC 2 Academy

Understanding Your SOC 2 Report

SOC 2 Compliance Handbook: The 5 Trust Services Criteria

 Common criteria 6.7 in the SOC 2 framework is an excellent example of how the criteria change depending on the environment we’re talking about. If we’re talking about a system that’s in a data center where there are production servers or virtual servers and there’s not a lot of removable media or mobile devices in and out of that environment, then common criteria 6.7 wouldn’t cause you to put a lot of controls in place to manage laptops. However, if you’re in an environment where people do work remotely, or they do carry around laptops, smartphones, or tablets, then common criteria 6.7 takes on a whole other meaning, because you have to think about ways to restrict the movement of those devices that may have critical information on them, or at least they have the ability to access critical information through the technologies that you have installed on those devices. If you are a company that has a situation like this, you’ll hear your auditor ask more questions about how you control mobile devices. Do you have an inventory of all of the devices that you allow into your environment, so that if something does go missing, you can do a regular audit and you can check regularly to make sure that everything is accounted for and nothing has been taken out. You’ll hear your auditor ask questions like: Do you have methods to do remote wiping of these remote devices? Do you use GPS tracking so you can figure out where the device went? Do you have those kinds of controls remotely so that you can enforce policies out to those devices that are in the field, so that if you want to restrict access to them, you could? Again, this goes back to assessing risk and understanding what your environment looks like and how common criteria 6.7 would apply to your specific circumstance.