Ever wonder which section of your SOC 2 report your auditors are terrified of? This is that section. This section of your SOC 2 will address technical controls for your organization and dive deep into the logical (& physical-if applicable) security controls that help protect your control environment. In this post, we will break down each criterion in simple terms so you know what to expect from your SOC 2 auditors.
Overview of CC6.0 (Logical and Physical Access Controls)
CC6.1 Criteria: 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.
Key Concepts Assessed in CC6.1:
Typical evidence requests: System-generated listing (excel or screenshots) of privileged users and a system-generated listing from human resources information system (HRIS) tools to verify job titles are appropriate for the level of access provisioned for each user.
With ByteChek, we eliminate the Excel sheets and screenshots by integrating directly with the tools where that information resides. Straight to the source.
AWS Tip: Think back to your last audit or discussion with auditors regarding privileged access, did the auditors ask for a list of users and their respective groups? This is pretty common, so I hope the answer is yes. Did your auditor also ask you for evidence of the associated IAM policies with those users? This is often the problem with status quo SOC 2 examinations, they have turned into check the block exercises. At ByteChek, we are focused on providing a streamlined SOC 2 experience, but not sacrificing technical accuracy or depth. Our AWS integration identifies privileged IAM users AND their associated IAM policies for a complete assessment of your IAM security posture on AWS.
Password Policies and Configurations:
Typical evidence requests: System-generated screenshots of password configurations and information security policies that outline the password configurations in place at your organization.
With ByteChek, we eliminate the screenshots by integrating directly with the tools where the password configurations reside. If you don’t have an information security policy, the ByteChek platform is built with you in mind. Our intuitive questionnaire will quickly help you generate a robust, in-depth policy outlining password requirements, among other information security procedures.
Unique Usernames and Credentials:
Typical evidence requests: Excel sheets or system-generated screenshots showing that no shared accounts exist and each user has an individual account. Unfortunately, typical evidence requests don’t address SSH credentials.
With ByteChek, there are no Excel sheets or screenshots. We will identify (via our integrations) any shared accounts across your in-scope applications.
Typical evidence requests: System-generated screenshots or Excel sheets that show all the in-scope production assets (servers, databases, load balancers, etc.). Expect to produce a list of assets and also to provide screenshots from your tools proving to your auditor how the screenshots were created.
With ByteChek, there are no screenshots or Excel. Because we integrate directly with AWS and Splunk, your inventory of assets is updated in real-time.
Multi-factor Authentication (MFA)
Typical evidence requests: System-generated screenshots or observations that display how users access production environments, specifically showing the requirement for users to use an MFA tool or device to receive authorization to connect. This observation will require your engineers or administrators to perform live observations with auditors, explaining how they connect to production resources.
With ByteChek, no observations, no screenshots. Beyond testing, we provide step by step instructions to automate the requirement for MFA for all users hosted on AWS. We care about security beyond the SOC 2 examination, our advice will make sure your controls are scalable and repeatable.
CC6.2 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.
CC6.3 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.
Key Concepts Assessed in CC6.2 and CC6.3:
Typical evidence requests: System-generated listing from your Human Resources Information System (HRIS) with screenshots showing how the listing was generated. Your auditors will select a sample of terminated employees and request evidence that each individual’s access was removed within a specified timeframe (i.e. 48 hours).
With ByteChek, we integrate directly with your HRIS to identify users that were terminated during the testing period. Our integration into AWS, GitHub, G Suite, Slack, etc. will provide our assessors with the necessary evidence to determine if access was revoked within your Company’s specified policy. In plain terms, evidence collection will be automated for terminated employees.
Approved Access Requests
Typical evidence requests: System-generated listing from your HRIS with screenshots showing how the listing was generated. Your auditors will select a sample of new hires and request evidence that each new hire had an approved access request completed prior to their access being provisioned.
With ByteChek, we integrate directly with your HRIS to identify all applicable new hires during our testing period. Our integration into JIRA provides assessors with the necessary evidence to determine if access requests were approved prior to the new hire starting.
Typical evidence requests: Excel sheets or screenshots from ticketing systems showing that an administrator conducted a review of all users with access to the in-scope systems. This review should include system-generated evidence of the users that were reviewed (i.e. screenshots showing how Excel has generated or exports from tools such as the AWS IAM Credential Report).
With ByteChek, we provide your administrators with the ability to perform an access review directly within our platform. Leveraging the information we gather from our integrations, your administrators will review who has access to different components directly from those sources. No screenshots, no Excel files.
CC6.4 and CC6.5
CC6.4 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.
CC6.5 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.
Key Concepts Assessed in CC6.4 and CC6.5: The criteria outlined in CC6.4 and CC6.5 describe requirements surrounding the physical protections and controls at your organization. ByteChek primarily works with customers hosted on the cloud which results in both CC6.4 and CC6.5 being carved-out or not applicable to your organization. In Section 3 of your report, we will list AWS (or other subservice organizations) as a subservice organization and outline their responsibility for the applicable controls that address CC6.4 and CC6.5.
CC6.6 The entity implements logical access security measures to protect against threats from sources outside its system boundaries.
Key Concepts Assessed in CC6.6:
Typical evidence requests: Screenshots from the AWS Console showing security groups from each applicable region or a txt file dump of all SGs using the ‘describe-security-groups’ command. If you are fortunate enough to have an auditor that understands AWS, they will ask for your Trusted Advisor report and send follow-up questions after reviewing any SGs that are populated with a RED or YELLOW warning.
With ByteChek, we integrate with AWS and assess all security groups in your AWS account to determine if any security group rules allow unrestricted access (0.0.0.0/0) to specific ports or unrestricted access to a specific resource. Yes, another control that is completely automated and does not require anything from you except the integration setup with AWS.
Don't worry, we won't leave you hanging:
Data Encryption At-Rest
Typical evidence requests: System-generated listings of all data stores that house sensitive data. Your auditor will select a sample of these data stores and ask for evidence showing they are encrypted at-rest. This evidence will vary depending on the technical aptitude of your auditor, you may only have to provide evidence that data is encrypted, other (better) auditors may want to verify the encryption algorithm utilized for each data store.
With ByteChek, our integration into Splunk and AWS allows our platform to maintain an updated inventory of all data stores, so no system-generated listing needed. Our tool verifies whether or not encryption is enabled on all applicable data stores and leveraging our AWS expertise, we are able to determine the encryption algorithm implemented.
AWS Tip: Think back to your last audit or discussion with auditors regarding datastore encryption, were the auditors only focused on RDS and S3? Did they even consider S3? If you are hosting your databases on EC2 instances, did your auditors request evidence of EBS volume encryption? The problem with status quo auditing is that gaps in properly assessing technical controls are common. The Bytechek platform will ensure all your applicable data stores (including EBS volumes, RDS instances, DynamoDB tables, Redis clusters, etc) are covered by this control, providing the readers of your report with the confidence and assurance they are looking for. Don’t settle for a SOC 2 report that excludes resources from the scope of your report because your auditors are lacking technical expertise.
Typical evidence requests: System-generated listing of all EC2 instances with screenshots that show how this listing was generated. Your auditor will select a sample of these instances and ask for evidence showing that each instance was patched according to your patch management policy. The evidence required will be dependent on your auditor and their technical aptitude. This control is generally evaluated during onsite interviews and discussions where your team will spend hours screen sharing and walking your auditors through your patch management process (yuck, we know). But what if you operate an infrastructure-as-code (IaC) environment, how will you prove patch management to your auditors in this scenario? Ideally, your auditors will understand IaC and request evidence accordingly. However, it is likely you will have to explain to your auditors what IaC is and how it relates to patch management.
With ByteChek, we will determine whether or not you are using IaC and begin our assessment by evaluating all changes that have been deployed through our GitHub integration. If your process is manual, we will work with you to determine the best course of action for evidence. We understand that a one-size-fits-all approach to evidence requests doesn’t work so we won’t ask you for evidence until we understand the tools and processes you’re using for patch management. But we not only care about getting you through the audit, we deeply believe in automation and will provide step by step instructions on how to implement an automated patching strategy using AWS Systems Manager-Patch Manager and other native AWS Security tools.
CC6.7 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.
Key Concepts Assessed in CC6.7:
Data Encryption In-Transit
Typical evidence requests: Screenshots or system-generated evidence showing that TLS 1.0 or higher is utilized on all public-facing websites that process sensitive customer data.
With ByteChek, our platform is built with direct integration to Qualyss to regularly perform a TLS/SSL scan on all in-scope web addresses. The ByteChek platform also leverages our AWS integration to determine which TLS protocol is terminated on all applicable load balancers. No screenshots or other creative evidence needed.
CC6.8 The entity implements controls to prevent or detect and act upon the introduction of unauthorized or malicious software to meet the entity’s objectives.
Key Concepts Assessed in CC6.8
Typical evidence requests: System-generated listing of all applicable instances, workstations, or other devices that would require AM/AV. Your auditor will select a sample of these assets and request evidence that AM/AV is installed and updated regularly. This evidence is generally system-generated evidence from the AM/AV tool or screenshots from the instances (or workstations) themselves showing an AM/AV agent installed and its version/update status. But what if you’re a complete Linux shop and don’t use AM/AV? This will result in a long, frustrating conversation with your auditors explaining why your Linux OS does not require AM/AV. Another common question, what if you don’t enforce AM/AV on your workstations because the risk to our production environment is low with other defense-in-depth controls present? Another long, frustrating conversation with your auditors is sure to follow.
With ByteChek, we understand that AM/AV is not the only solution to prevent or detect malicious software from being introduced into your environment and that is what the criteria explicitly outlines. Our team will leverage our integration into AWS to review your network setup and follow up that review with a brief conversation on your defense-in-depth strategy. If you are using AM/AV, great. We will work with you to determine the best way to produce evidence but with any audit, context, and scope matters. We will make sure we have a clear understanding of both before we demand evidence that may not be applicable.
The ByteChek Difference
We started ByteChek with one goal in mind: Make Compliance Suck Less. This blog post covers a small subset of the controls we built our platform to automate and move away from status quo SOC 2 examinations and other framework audits. Automating compliance and eliminating screenshots, document uploads, and generic evidence requests help your team focus on growing and securing your business. Reach out to our team to learn how you can automate compliance and set up a demo of the ByteChek platform.