SOC 2 Academy Archives

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.

Common Criteria 6.1

When a service organization undergoes a SOC 2 audit, auditor will look to validate that 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.” What will an auditor look for when assessing this criterion? Let’s discuss why organizations should implement protections through logical access controls.

Using Logical Access Controls

What would be the impact to an organization if an unauthorized, malicious user gained access to their network? There would likely be financial, operational, and reputational damages that the organization would have to face, and their clients’ sensitive information would be put at greater risk. This is why during a SOC 2 audit, an auditor will assess that organizations have created, implemented, and maintained logical access controls to the network environments. When implementing these protections through logical access controls, organizations must think broadly about what their assets are and how they could impact the organization. In other words, only using a few logical access controls, such as active directory, password policies, or encryption, can only do so much to protect an organization and their clients’ data. Organizations instead must consider all risks that any and all information assets pose to the business and implement logical access controls accordingly. So, how can organizations comply with this criterion during their SOC 2 audit?

Complying with Common Criteria 6.1

When assessing an organization’s compliance with common criteria 6.1, an auditor will want to see that the organization has established protections through logical access controls by doing the following:

Creating an inventory of all information assets
Restricting logical access to all information assets
Identifying and authenticating users
Managing points of access
Restricting access to information assets
Managing identification and authentication
Managing credentials for infrastructure software
Using encryption to protect data
Protecting encryption keys

More SOC 2 Resources

SOC 2 Academy

Understanding Your SOC 2 Report

SOC 2 Compliance Handbook: The 5 Trust Services Criteria

[av_toggle_container initial=’1′ mode=’accordion’ sort=” styling=” colors=” font_color=” background_color=” border_color=” custom_class=”]
[av_toggle title=’Video Transcription’ tags=”]

SOC 2 common criteria 6.1 requires that you put into place logical access security software, infrastructure, and architecture in order to protect your critical access devices and make sure that they’re protected against security events. This is really a big requirement, so we’ll try to talk through a few things that you might consider. It seems like a lot of emphasis is placed on the network. Take active directory for example. Organizations might say that they have implemented active directory so that they can manage all of their users, they can enforce a password policy, and they can feel good about who is logging in and who it is that’s being prevented from logging into their network. But you really need to perform an inventory of your assets to understand where everything is, because a lot of times during an audit, we will find that the access controls of network devices that aren’t managed through active directory in some cases might be ignored. For example, an organization might use the same username and password on a firewall that’s never been changed since they bought it, so you need to think more broadly as far as what your assets are, what it is you’re trying to protect, and make sure that you’ve implemented logical access controls in order to protect them from unauthorized access.

[/av_toggle]

[/av_toggle_container]