Common Criteria 6.4

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.4. Common criteria 6.4 says, “The entity restricts physical access to facilities and protected information assets (for example, data center facilities, backup media storage, and other sensitive locations) to authorized personnel to meet the entity’s objectives.” How can organizations comply with this requirement? What kind of physical security controls should organizations implement?

Implementing Physical Security Controls

While malicious hackers often attack digitally, organizations must account for the risk that their physical environments could be compromised too. This means that implementing physical security controls in facilities or other locations that hold sensitive information needs to be a top priority for organizations. For example, if an organization distributes access cards to all employees, how are those access cards managed? Can you clearly identify who the access card belongs to? Is there a process in place for validating that the person using the card is the same person it belongs to? What processes are in place to revoke a card if an employee is terminated or quits? Social engineering is a serious threat to many organizations, but it’s often a thought that gets put on the back burner. If you’re pursuing SOC 2 compliance, consider implementing these physical security controls:

  • Locks, fences, or gates
  • Surveillance cameras
  • Access cards
  • Biometric access controls
  • Security guards

Physical Security and SOC 2 Compliance

We often have clients ask us if an onsite visit is necessary when undergoing an audit, and it absolutely is. Why? Because it’s essential for assessing an organization’s compliance with common criteria 6.4. How would an auditor be able to verify that your physical security controls are in place and working efficiently without physically testing them? During a SOC 2 audit, an auditor will physically need to validate that the physical security controls that you say are in place are actually working as intended.

More SOC 2 Resources

SOC 2 Academy

Understanding Your SOC 2 Report

SOC 2 Compliance Handbook: The 5 Trust Services Criteria

Common criteria 6.4 in the 2017 SOC 2 Trust Services Criteria deals with physical security. Let’s say that you have an access control card system. One of the things that we recommend is that you do your own internal audit of the cards that you have versus that cards that are active in the system. You need to make sure that any lost cards get deactivated and that you, in a very timely manner, remove employees or vendors who have been issued cards and are no longer employed by the organization. This is so there aren’t unauthorized people still in the system and the system is current. You also want to think about where all of the areas are where you need to have physical security controls. Too often, people think that just because they work in a corporate office, they shouldn’t care about physical security controls. However, the corporate office still has all the critical people who use their systems to log in to things such as production networks at a data center or resources in the cloud. You still wouldn’t want your physical security, even in an administrative area, to be compromised because someone might access a laptop, steal a piece of media, or gain access to paper records that are laying around. We have that happen a lot where clients say, “There’s nothing here that we’re trying to protect. Everything we have is in the cloud.” Yet, when you do a little bit of digging, we find that there are some hard copy materials, removable media, and clearly, systems that can be used to access the information in the cloud. You need to think about physical security controls, where they should be applied, and make sure that you find the best way to implement locks, card readers, and any other type of physical control that’s appropriate for your situation.

Common Criteria 6.3

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.3. Common criteria 6.3 says, “The entity authorizes, modifies, or removes access to data, software, functions, and other protected information assets based on roles, responsibilities, or the system design and changes, giving consideration to the concepts of least privilege and segregation of duties, to meet the entity’s objectives.” How can organizations comply with this requirement? It comes down to three things: assigning roles and responsibilities, implementing the concept of least access necessary, and creating a separation of duties.

Assigning Roles and Responsibilities for SOC 2 Compliance

In order for organizations to ensure that they have effective internal controls in place, they need to assign roles and responsibilities. Why? Because assigning roles and responsibilities allows organizations to mitigate the risk of unauthorized persons accessing sensitive information. When organizations assign roles and responsibilities, they implement the concept of least access necessary. This means that employees only have the bare minimum access needed to fulfill their job duties. Similarly, assigning roles and responsibilities assists organizations in ensuring that there is a separation of duties so that there are no conflicts of interest within the organization. For instance, a network administrator who is responsible for ensuring that the internal controls over the network they created are functioning correctly should not be the same person who is responsible for monitoring those internal controls. Instead, the organization would need to assign roles and responsibilities to two separate individuals to make sure that no conflict of interest or fraudulent activity occurs.

Complying with Common Criteria 6.3

When making the journey toward SOC 2 compliance, organizations can use the following questions to determine if they comply with common criteria 6.3:

  • Does your organization have processes in place to create or modify access to protected information assets?
  • Does your organization have processes in place to remove access when it is no longer required?
  • Does your organization utilize role-based access controls to ensure that there is a separation of duties and the concept of least access necessary is implemented?

More SOC 2 Resources

SOC 2 Academy

Understanding Your SOC 2 Report

SOC 2 Compliance Handbook: The 5 Trust Services Criteria

I’d like to focus on common criteria 6.3 for SOC 2 compliance on a few key words in this particular criterion: roles and responsibilities, least privilege, and separation of duties. These are really the operative terms in this requirement. Let’s start with roles and responsibilities.  Everyone shouldn’t be an administrator. Everyone should have specific roles and responsibilities that translate into the level of access that you give them to your system or to your sensitive data. You don’t want everyone to have access to that kind of data, so thought has to be given to roles and responsibilities. The concept of least privilege also applies to that.  You need to make sure that you start with a default deny attitude. For example, a person starts by having access to nothing and then an administrator would consider what is the least access necessary to fulfill their job duties. Lastly, there’s separation of duties. If you have a conflict of interest in a particular area, there needs to be separation of duties. We’ll use developers as an example. Developers are developing code, but they shouldn’t also be promoting code to production. You don’t want the to use the same username and password to log into the test environment and also the production environment. You need to make those duties separate and ensure that there’s a developer role and a production role just so things don’t get messed up and remain separated, so that there is no room for a conflict of interest to occur.

Common Criteria 6.2

When a service organization undergoes a SOC 2 audit, auditors will validate that they comply with the common criteria listed in the 2017 SOC 2 Trust Services Criteria. Common criteria 6.2 says, “Prior to issuing system credentials and granting system access, the entity registers and authorizes new internal and external users whose access is administered by the entity. For those users whose access is administered by the entity, user system credentials are removed when user access is no longer authorized.” What will an auditor look for when assessing how organizations go about registering internal and external users? Let’s discuss.

Registering Internal and External Users for SOC 2 Compliance

When entities hire new employees or enter into new business partnerships, they need to have processes in place for registering internal and external users. For example, an organization’s human resources manager might notify the IT administrator via memo that a new employee has been hired and that they need user credentials and access to limited network resources. This would be a clear and efficient process for alerting the IT administrator that they are authorized to create new access credentials for the employee but only for limited resources.

Complying with Common Criteria 6.2

During a SOC 2 audit, an assessor will verify that the organization has such processes in place for registering internal and external users, but they will also verify that the organization has process in place for removing access for internal users when an employee quits or is terminated, or an external user no longer needs access to the network resources to fulfill their job. Having such processes in place limits the risk of unauthorized access and supports an organization’s ability to keep their assets secure. When pursuing SOC 2 compliance, use the following questions to ensure that you comply with common criteria 6.2:

  • Do you control access credentials to protected assets?
  • Do you remove access to protect assets when appropriate?
  • Do you review appropriateness of access credentials on a regular basis?

More SOC 2 Resources

SOC 2 common criteria 6.2 requires that you have a registration process for internal and external users when they are requesting access to a particular system and that you have a process for removing those users when access is no longer required. Let’s talk about internal users first. If a new employee comes on board, you need to have a process for issuing them their first-time credentials. You might use a random password generator to set their first password. You might require them to change that password upon their first log in to the system. However, prior to any of that happening, the really critical piece to this criterion is that you have a way to identify them and register them, so that the IT administrator doesn’t simply provide them access. It needs to be approved. Maybe a form comes through from HR or maybe some type of approval is emailed from the hiring supervisor that instructs the IT administrator to provide access to certain system resources for the new employee. That’s an example of how you would go about registering an internal user. On the other hand, an external user might be a client. Perhaps your company provides a software-as-a-service or it’s a hosted platform. How is it that you allow people to gain access to your service? How do they register? How do they identify themselves? Do you have some kind of independent mechanism of verifying who they say they are before you provide them access? Finally, how do you remove access when it’s no longer required? Let’s talk about a vendor. If approval has come in saying that a vendor should have access to your network in order to provide their services, but then the contract expires or the project is over, is there a mechanism to make sure that the IT administrator knows to remove access for that person? This should also apply to employees when they’re leaving or any other type of business partner that may have had a need to access the environment at one time but now needs to be removed from the system.

Common Criteria 6.1

When a service organization undergoes a SOC 2 audit, auditors will verify whether they comply with the common criteria listed in the 2017 SOC 2 Trust Services Criteria. Common criteria 6.1 says, “The entity implements logical access security software, infrastructure, and architectures over protected information assets to protect them from security events to meet the entity’s objectives.” While we have discussed many points of focus that organizations should consider when complying with common criteria 6.1, there’s still one critical component to review: performing a thorough inventory of your assets. Let’s discuss.

How to Perform a Thorough Inventory of Your Assets for SOC 2 Compliance

If an organization doesn’t know how to perform a thorough inventory of their assets, how will they be able to effectively monitor and protect them? Organizations must establish policies and procedures for device security in order to ensure that unauthorized or malicious users don’t gain access to information or environments that they have no legitimate need to access. If an organization provides employees with electronic devices, such as smartphones, laptops, or tablets, how are those devices being monitored and protected? Let’s say that an organization provides laptops for all remote employees. If the laptop is stolen, what processes are in place to make sure that the laptop is remotely wiped of all company information? If an employee is terminated or resigns, how will the organization ensure that the device is returned?

When put into the wrong hands, misuse of electronic devices could be the catalyst needed to cause organizations to face data breaches, amass steep fines and penalties, or lose client trust. Knowing how to perform a thorough inventory of your assets allows organizations to mitigate these risks. But how can it be done? Aside from identifying all devices used on the network, encryption methods should be utilized. In fact, encryption is such a large part of complying with common criteria 6.1 that two of the points of focus for the criterion are about encryption. They say, “The entity uses encryption to supplement other measures used to protect data-at-rest, when such protections are deemed appropriate based on assessed risk,” and “processes are in place to protect encryption keys during generation, storage, use, and destruction.”

Regardless of whether threats come from unauthorized internal employees or malicious outsiders, during a SOC 2 audit, organizations must make it a priority to know how to perform a thorough inventory of their assets in order to comply with common criteria 6.1.

More SOC 2 Resources

SOC 2 Academy

Understanding Your SOC 2 Report

SOC 2 Compliance Handbook: The 5 Trust Services Criteria

When it comes to complying with the logical access control requirements in common criteria 6.1 for SOC 2, there’s a couple of other points of focus to consider, including performing a thorough inventory of your assets. You have to understand what your assets are in order to understand how you’re going to protect them. You need to make sure that you’ve identified all of those devices on your network that might potentially provide access to a threat or a valid employee, so that you can manage and monitor who’s accessing that and removing access for anyone that shouldn’t have it. The other thing that you would want to look at is the encryption of the logins to all of these various devices. Are there security certificates in place in order to encrypt the traffic? Even internally, from your administrator on your network to that particular device? I know we see a lot of self-signed certificates and certificates that are not properly configured in order to keep those credentials secret and unable to be captured by a malicious entity who might want to steal a username and password.

Common Criteria 6.1

While not requirements, points of focus are meant to serve as references to assist organizations when they are designing, implementing, operating, and evaluating controls over security, availability, confidentiality, processing integrity, and privacy. When it comes to implementing logical access controls, there are some additional points of focus that will help organizations ensure that their information security systems remain secure. Let’s take a look at how these additional points of focus will help service organizations comply with common criteria 6.1 during a SOC 2 audit.

Managing Users with Logical Access Controls

During a SOC 2 audit, in order to ensure that unauthorized users don’t have access to an organization’s sensitive assets, logical access controls must be implemented and monitored. For example, let’s say that an organization is onboarding a new entry-level administrative assistant. What resources would that position require? Would they need to access information that the IT administrator has access to? Probably not. But what if there was an oversight or ineffective controls were in place that allowed the new hire to gain access to sensitive information? There could be a serious damages to the organization’s business continuity, finances, and reputation.

Because employees are the weakest link of every organization, the proper measures must be taken to mitigate the risks associated with human error prior to engaging in a SOC 2 audit. When implementing logical access controls to comply with common criteria 6.1, organizations should consider following these best practices:

  • Role-based access: This might also be referred to as least access necessary, business need to know, or least privilege. This means that organizations only give their employees the minimum access needed to fulfill their job duties. For instance, a CISO would need more access to an organization’s sensitive information than an administrative assistant. By implementing role-based access, organizations can ensure that only the employees with a legitimate need to access resources and environments have the ability to do so.
  • Username and password management: How does your organization manage usernames and passwords? When a new hire is onboarded, do they receive universal log-in credentials? When do passwords need to be reset? What processes are in place to revoke usernames and passwords if an employee is terminated or quits? To ensure that logical access controls are working efficiently, having a system for username and password management is critical.
  • Log monitoring: Implementing logical access controls is only half the battle. Organizations must also perform their due diligence and monitor the activity on their system to ensure that the logical access controls are working as intended. For example, an organization might implement role-based access, but a malicious employee might still attempt to access sensitive information. If something like this occurs, organizations need to have monitoring processes, such as logs, in place to monitor who it is that’s attempting to access that information so that they can mitigate the issue.

Ultimately, common criteria 6.1 aims to ensure that service organizations meet their business objectives by protecting their sensitive assets from malicious internal and external threats. If your organization is beginning your SOC 2 journey, what logical access controls do you currently have in place?

More SOC 2 Resources

SOC 2 Academy

Understanding Your SOC 2 Report

SOC 2 Compliance Handbook: The 5 Trust Services Criteria

Some additional points of focus to consider for logical access controls have to do with managing your users and also monitoring the type of activity that’s going on in the system. I’ll start with the users first. You have to be really diligent in making sure that users are given access to resources that they need to have access to. You can do this by implementing role-based access rules to make sure that an employee doesn’t have a username and password to a system or environment that they really don’t have a reason to access anyway. It’s a way to pare down and strengthen your controls in that area. You should be diligent about removing access when your employee leaves your organization or when a third party, who maybe had a reason at one time to access a system to provide maintenance or other types of services but are no longer active, removing them from that. This is so that the level of risk is no longer there after you’ve removed that particular user from the system. You also have to monitor the activity on your system. You’ve put these password rules in place to be enforced, and to make sure that people don’t have access to things that they shouldn’t, but then monitoring who it is that’s attempting to access the network or other things like that. I remember one time when I was looking at an SFTP server with a client and there were these logs where over and over again an unauthorized user was just attempting to log in with incorrect credentials. They hadn’t noticed that before because they didn’t monitor that particular log, so having some visibility into the logical access controls that you’ve put into place so that you can take action when you notice that the control that you have is working but someone is trying to circumvent it by using different usernames and passwords. Being able to monitor that in addition to having the protection in place would be a very important aspect to that control.