Logical and Physical Access

SOC 2 CC6: Common Criteria related to Logical and Physical Access

By

What is SOC 2 Logical and Physical Access (CC6)?

Organizations are responsible for controlling logical and physical access to their protected information by using appropriate security software,
infrastructure, and architectures. Implementing and maintaining these necessary controls will protect your company’s valuable data and prevent unwanted security events. It will also help you meet the requirements outlined in the SOC 2 Common Criteria related to Logical and Physical Access (pgs. 28-33).

The logical and physical access guidelines lay out a series of steps, and best practices organizations should carry out to operate in a safe, risk-minimizing manner. It’s essential to follow these guidelines, implement security controls thoroughly, and consider your logical and physical access protocols from every angle. A thorough understanding of the protocols your organization needs to implement will help ensure you receive a clean SOC report.

In short, the SOC 2 criteria expounds upon the idea that an entity should deploy control activities. In terms of logical and physical access, the primary goal of the Common Criteria is to provide guidance on how to restrict access, remove access, and prevent unauthorized access to your organization’s protected information.

What are the Requirements for SOC 2’s CC6?

The SOC guidelines feature eight major criteria you must be aware of to protect your organization’s security. To help you understand these critical components, we’ll step through each point of focus and provide context into what it is asking for. 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.

One of the tricky things about CC6 is that many of the requirements are interrelated and often repeat themselves as you read through the detailed points of focus. For both your sanity and the author’s sanity, we’ll try not to be repetitive while still covering everything, so if you’re tying out what we write to each point of focus in the AICPA document, you’ll find some missing ones. From a scope perspective, the scope of these controls should extend to the system’s boundaries, as you’ve previously defined.

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 CC6, 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.

You may notice that this particular post is a bit more detailed than our CC1-5 posts; quite frankly, that’s intentional. There are significantly more nuances and considerations when implementing these controls, and we wanted to ensure that we addressed them in an adequate level of detail.

CC6.1 Requirements

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.

CC6.1 starts with a barrage of “all the things” related to the basics of securing a system, including a few that many will often overlook because it feels inherent to what you do on a daily basis. Let’s step through what each of the points of focus are asking for:

  • Identifies and Manages the Inventory of Information Assets – This is asking you to inventory where your critical data is (i.e., within what systems and vendors), how you classify it, who the owner of it is, and how it is maintained (is there a review process in place?).
  • Restrict Logical Access – In short, have logical access controls that apply to your applications, infrastructure, and devices capable of restricting the ability to access, update or delete data to only those with a business need to do so. This particular point of focus is more of a catch-all as it is met as long as you’re doing other things.
  • Identifies and Authenticates Users – Have a method to distinguish one user from the next. Do not use duplicate accounts and have some way to identify the user, such as using a password, authentication token, or other method.
  • Considers Network Segmentation – This is supported by the network diagram discussed in the CC2 post when discussing system documentation. In essence, your system should have segregation between environments (production vs. staging vs. development) and segmentation within each environment as appropriate for your architecture (i.e., use of a DMZ for web servers).
  • Manages Points of Access – If you have third-party system interconnections set up with your systems, have a method to inventory those interconnections (i.e., if firewall rules are adjusted to allow the access, document and track that).
  • Uses Encryption to Protect Data – Encrypt data at rest. Sure, if you read it, you’ll see that it is qualified as “when such protections are deemed appropriate based upon risk,” but we generally see it as an expectation that it is done.
  • Protects Encryption Keys – Any time you end up encrypting things, you need to manage the keys, so make sure they are restricted to only authorized folks.

CC6.2 Requirements

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.

There is a lot of overlap between CC6.2 and CC6.3, which attempt to cover all the bases related to user access management. Remember that the scope applies to your in-scope system’s network, application, database, and operating system layers.

  • Controls Access Credentials to Protected Assets – The system’s asset owner or custodian should approve such access before granting access to protected assets. This applies to newly hired users who transferred to a new job role or users who simply require additional access systems or data as part of their day-to-day work patterns. The more an organization grows, the more difficult this becomes, as you’ll often need to manage a multi-departmental workflow. To summarize the expectation here: for any new or changed access to in-scope systems, the auditor would expect to see a documented approval from the system owner or custodian for that user, the date it was approved, and the specific access being requested (i.e., role or permissions) and the business purpose used to support the approval.
  • Removes Access to Protected Assets when Appropriate – To pair with the previous point of focus, this pertains to removing access to protected assets when it is no longer needed, the most obvious situation being an employment termination. This can also include scenarios where access simply isn’t needed or when a user transfers to a different job function. The expectation here is that there is a tracked request for each access removal, and a confirmation of access removal from the system administrator is included (to document the timeliness of the removal). We often see HR initiating this process for employee offboarding, but you can’t forget to include contractors.
  • Reviews Appropriateness of Access Credentials – Regularly (at a frequency you can define based upon customer commitments, risk, or other factors – we usually see a mix of quarterly, semi-annually, and annually), pull access lists to all in-scope systems (at all layers of the system) along with the permissions that each user has. The system owner or custodian should review this list and either approve all users or note users that should be changed. If users are noted to be changed, evidence should also be kept to demonstrate that the appropriate action was taken (i.e., include the before/after fixing user lists within your documentation).

CC6.3 Requirements

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.

CC6.3 repeats a number of the points of focus from CC6.2, but then adds one more for its entertainment:

  • Uses Role-Based Access Controls – This point of focus is a bit more in-depth than it looks on the service. It wants you to utilize roles within your system and even roles based upon job function (i.e., all customer success employees should receive access to roles 1, 2, and 3 on system 42). We suggest documenting the roles at both levels and including them within your review of access credentials discussed in the above CC6.2 section. Finally, within those roles, the pesky “segregation of incompatible duties” thing that auditors love to look at should be considered when constructing, documenting, and approving roles. This is always a non-specific ask as each company and system is different. However, developer access to production and the ability to migrate code is always one of the more exciting topics of discussion for this.

CC6.4 Requirements

The entity restricts physical access to facilities and protected information assets (for example, data center facilities, back-up media storage, and other sensitive locations) to authorized personnel to meet the entity’s objectives.

As the world has been moving to the cloud and remote working environments, we have often ended up in positions where CC6.4 has been treated as non-applicable within the SOC 2 evaluation. Generally, if you’re following CC6.1, CC6.2, and CC6.3 and applying that to your physical facilities, you’ve covered most of the bases. You will need to have a process to address visitors to your facility (a sign-in process, a log of visitors, making sure visitors are escorted and are clearly identified as visitors). Extra credit is available here with video surveillance systems, alarm systems, and security guards (we’re not sure about guard dogs, though).

Instead of rolling through the points of focus for this one, we’ll give you a bit of context for the scenarios that we typically see as they will impact your scope:

  • System hosted in a cloud service – In this scenario, your cloud service provider and its related controls (such as physical access) will be “carved out” of the SOC 2 report, meaning they are not addressed within your report. When doing your Vendor Risk Assessments, the only thing you can consider here is whether you have enough assurance over the cloud provider’s physical security practices to satisfy you (you’ll probably be reviewing their SOC 2 report to determine this).
  • System hosted at a co-location facility – For the most part, a co-location datacenter is treated like a cloud service provider with one caveat: you will need to make sure that you have a process to communicate authorized users to the datacenter and to ensure that you have appropriate approvals (per CC6.2’s discussion above) for those access requests.
  • Physical office exists – In an ideal world, a badge access system is a way to go here, but you can also use physical key locks (and your review of the key log of who has keys becomes your access review). Make sure to have a way to track visitors and a clear desk/clear screen policy.
  • No physical office exists – While it may seem you hit the jackpot here without much to do, having an all-remote workforce can increase the risks in other areas within the SOC 2 scope. While physical access may get carved out, expect further questions related to how you’re managing and securing the remote workforce.

CC6.5 Requirements

The entity discontinues logical and physical protections over physical assets only after the ability to read or recover data and software from those assets has been diminished and is no longer required to meet the entity’s objectives.

This point of focus uses many words to state that you can’t stop protecting your physical assets until you’ve wiped the sensitive information from those assets. The best example here would be for a terminated employee’s laptop – once turned in, it should continue to be secured until it is wiped, and it should not be disposed of until it is wiped. While this seems straightforward, it also implies that you should maintain a hardware asset inventory of things like users’ laptops and datacenter hardware to track where they are and document that they have been wiped appropriately before being reissued or disposed of.

CC6.6 Requirements

The entity implements logical access security measures to protect against threats from sources outside its system boundaries.

This point of focus focuses on what many people consider to be “security” of a system – how well is it protected from those outside that do not belong within.

  • Restricts Access – While you may think we’re about to talk user access again, we’re not. This one relates to restricting activities across the external boundary to specific functions – in other words, using a firewall configuration that only allows the necessary ports and traffic for the system to function. An auditor will typically want to see that there are firewall rules in place and that there is a regular review of those rules.
  • Requires Additional Authentication or Credentials – This particular point of focus is one that is often interpreted as requiring multi-factor authentication for external access to the system. While it technically only asks for “additional authentication information or credentials,” this means as long as your VPN has an extra hoop to jump through, you’re technically OK here. However, we strongly suggest implementing MFA for external system access, and in the case of cloud services, implementing MFA wherever possible, especially for administrative accounts.
  • Implements Boundary Protection Systems – This one says both a little and a lot at the same time – this goes back to you making a risk assessment of your system and determining what protections should be put in place as boundary protection. This could include firewalls, DMZs, IDS systems, logging and alerting systems, or perhaps that guard dog from CC6.4. Most importantly, you will need to articulate the rationale behind the boundary protection strategy you’ve implemented to your auditor so they can conclude whether it is appropriate for your system.

CC6.7 Requirements

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.

This section is about data on the move, whether over a network, the internet, or the sneakernet.

  • Restricts the Ability to Perform Transmission – This point of focus refers to Data Loss Prevention processes and related implementation. No, this does not say that you need to buy a shiny DLP tool from an expensive vendor, but it does say that you should consider risks related to data loss within your system and implement appropriate controls to mitigate those risks. For example, if you identify mass extraction of data from your datastores as a risk, then appropriate controls may be to review long-running queries that could indicate mass extraction and/or monitoring network traffic for abnormalities compared to typical patterns.
  • Uses Encryption Technologies or Secure Communication Channels to Protect Data – Let’s keep this simple: Encrypt your data in transit and do so with secure protocols (this means TLS 1.2 or TLS 1.3 these days).
  • Protects Removable Media – For removable media used to send data over the sneakernet, such as USB drives, tape drives, ZIP drives, or 5.25″ floppy drives, have appropriate controls over their use. More specifically, require data being copied to removable media to be encrypted or simply brick your users’ ability to use removable media (most cloud-based AV/endpoint protection platforms have this capability today).
  • Protects Mobile Devices – First, understand that the term mobile devices refers to laptops, smartphones, tablets, or that desktop tower over there in the corner that you lug back and forth between the home and office. Once you understand that, then you should have methods to protect the data on those devices, which minimally should be encrypting the data storage and potentially a mobile device management (MDM) tool installed.

CC6.8 Requirements

The entity implements controls to prevent or detect and act upon the introduction of unauthorized or malicious software to meet the entity’s objectives.

Implementing controls to detect, prevent, and, if necessary, act upon malicious or unauthorized software.

  • Restricts Application and Software Installation – This is relatively straightforward – if you restrict access to who can install software (i.e., a limited number of administrators), you reduce the likelihood of unauthorized or malicious software being installed. This goes back to the CC6.2 and CC6.3 principles of least privilege.
  • Detects Unauthorized Changes to Software and Configuration Parameters – This requirement is open to interpretation, but much like the Boundary Protections point of focus in CC6.6, adapt a risk-based approach that is applicable to your system. Common things we see here are file integrity monitoring use of infrastructure as code or other monitoring tools to confirm that all software and configuration parameters are set as intended.
  • Uses a Defined Change Control Process – We’ll discuss this more with our post on CC8 later.
  • Uses Antivirus and Anti-Malware Software – This one also seems fairly straightforward – install antivirus and use it! However, there are a few caveats to consider. Suppose you’re using the built-in Windows Defender software or other home desktop antivirus software. In that case, it will be tough to prove to the auditors that the user did not override the software, that it is installed and up to date and when finding out when the user has “an oopsie.” For that reason, you should look at the business class cloud-based solutions that are out there that give you a method for remote administration and monitoring of the antivirus software.
  • Scans Information Assets from Outside the Entity for Malware and Other Unauthorized Software – This one is a bit more procedural in nature and often not one that actually happens but is hat-tipped in your policy. When you get something back from a third party when you did not have control over the asset, make sure that it didn’t bring back anything you don’t want (and, of course, document that you did it).

Conclusion

Your organization’s protected information is a valuable asset that needs constant, consistent, and diligent monitoring. In fact, one of the more difficult parts of CC6 is documenting what you have done and are doing to meet its requirements. Most organizations already have many of these controls in place; they just have difficulty proving it.

Although this article covers the major points included in Common Criteria 6, you can go a step further by reaching out. We’re here to help you make access to your data as secure as it can be and to work with your organization to ensure you’re protected.