SOC 2 Cloud Security: Breaking Down its Complexities

If you consider how rapidly organizations are increasing their cloud footprint, ensuring compliance with the different compliance standards can get challenging very quickly. Here at Fugue, we aim to make compliance easy, so in this blog, we are going to break down the complexities associated with SOC 2 compliance.

What is SOC 2?

SOC 2 is an auditing procedure and report that is part of the SSAE (Statement on Standards for Attestation Engagements) standard maintained by the AICPA’s (American Institute of Certified Public Accountants) Auditing Standards Board for service organizations.

SSAE defines three SOC (System and Organization Controls) auditing procedures and reports for SSAE compliance:

• SOC 1 Report
   
  • Addressed in SSAE sections AT-C 320

   

  • For service organizations that may impact their customers’ financial reporting
  • Example industries: Medical billing, transportation services, payroll services, ISPs
• SOC 2 Report
   
  • Addressed in SSAE sections AT-C 105 and AT-C 205
  • For service organizations that hold, store, or process customer data
  • Example industries: SaaS software companies, Cloud Service Providers, Managed Services Providers, Credit Card Processing
• SOC 3 Report
   
  • Similar to SOC 2, but less detailed, and for marketing/public consumption

Why is SOC 2 Compliance Important?

SOC 2 audits apply to any service organizations that hold, store, or process customer data in the cloud. This includes SaaS providers and other organizations that, as an example, may host customer information on AWS in S3 buckets.

SOC 2 reports evaluate service organizations’ controls against AICPA’s Trust Services Criteria, which are a set of principles aligned to the COSO (Committee of Sponsoring Organizations of the Treadway Commission) framework. The Trust Services Criteria describe how an organization’s policies and controls should address the following for customer data:

Security - protect systems from malicious attacks, data loss, and other security events

Availability - ensure that systems maintain high availability

Processing integrity - ensure that system processing occurs as intended in a timely fashion

Confidentiality - ensure that confidential information is protected from unauthorized access

Privacy - ensure that personal information is protected from unauthorized access

Which SOC Report Is Right for Your Organization?

A SOC 1 report is a report on a service organization’s controls which are relevant to the user entities’ internal controls over financial reporting. The SOC 2 report was created to evaluate an organization’s information systems as it relates to security, availability, processing, integrity, confidentiality or privacy. If your client is concerned about whether their data is secured, then the SOC 2 report is the way to go.

Which Criteria Are Relevant for Organizations in the Cloud?

The only criteria that are required for SOC 2 audits are those pertaining to security. Criteria pertaining to availability, processing integrity, confidentiality, and privacy are optional, but provide important guidance to security and compliance teams. Below are the criteria that are directly relevant for security and compliance teams responsible for public cloud infrastructure.

• CC2.0: Communication and Information: addresses how service organizations handle internal and external communication and information flows.

Public cloud providers have a plethora of monitoring and logging options for capturing internal/external sources of data. Services such as AWS CloudTrail and Azure Monitor log every API interaction, including which users are taking certain actions. AWS CloudWatch and Azure Monitor aggregate log data from virtual networks, virtual machines, and many other resources.

Fugue implements the following rule to help address CC2.1: CloudWatch log metric filter and alarm for denied connections in CloudFront logs should be configured: CloudWatch metric filters and alarms should be configured to alert users to denied connections to CloudFront distributions so users can investigate anomalous traffic.

• CC5.0: Control Activities: addresses how service organization control activities account for risk management and technology.
• CC6.0: Logical and Physical Access Controls: addresses how service organization controls implement logical access to IT systems/credentials, physical access to facilities, and security measures to detect and prevent unauthorized access.
• CC7.0: System Operations: addresses how service organization controls monitor systems for potential anomalies, events, and configuration changes that may carry security risks, and define incident response protocols to contain, remediate, and communicate security incidents.
• CC8.0: Change Management: addresses how service organizations develop and implement change management approaches to infrastructure, data, software, and policies.

Public cloud providers provide fine-grained access control options that allow organizations to determine which actions, services, and resources can be accessed. AWS IAM and Azure Active Directory policies can be scoped specifically to organizational needs, but should be reviewed to ensure that security best practices are followed.

For example, Fugue implements the following rule to address CC5.2: IAM policies should not have full "*:*" administrative privileges: IAM policies should start with a minimum set of permissions and include more as needed rather than starting with full administrative privileges. Providing full administrative privileges when unnecessary exposes resources to potentially unwanted actions.

Service organizations have many public cloud resource configuration options to consider to address CC6.1. Usage of access management services (AWS IAM, Azure Active Directory), encryption key management (AWS KMS, Azure Key Vault), and other encryption options related to specific services help security and compliance teams meet this criterion.

Fugue implements the following rule to address CC6.1: VPC security group rules should not permit ingress from '0.0.0.0/0' to TCP port 80 (HTTP), unless from ELBs: Security groups provide stateful filtering of ingress/egress network traffic to AWS resources. AWS recommends that no security group allows unrestricted ingress access to port 80, unless it is from an AWS Elastic Load Balancer. Removing unfettered connectivity to remote console services reduces a server's exposure to risk.

Fugue addresses CC7.2 by alerting users if CloudWatch log metric filters and alarms are not configured properly to alert users to rejected connections in VPC flow logs. The alerts enable the users to investigate anomalous traffic.

Fugue enables users to set baselines - snapshots of “known good” configurations of cloud infrastructure that define every resource with all of its attributes. With context from baselines, Fugue alerts users on any configuration drift, and enforces baseline configurations with codeless auto-remediation.

Fugue implements the following to help address CC8.1: DynamoDB tables should be encrypted with KMS CMKs: When enabled, DynamoDB encryption secures the primary key, local and global secondary indexes, streams, global tables, and backups in the encrypted table. DynamoDB tables are encrypted using KMS keys.

To learn more about how Fugue can help you achieve SOC 2 compliance with your cloud infrastructure, download our SOC 2 Compliance datasheet.