Posts Tagged ‘cloud-native security’

SOC 2 Compliance Playbook for Cloud Native

Posted by

Part 2: SOC 2 Type 1 MVP Playbook

Click here to read Part 1: From Monster to Mascot

Of the SOC 2 principles (criteria) of security, availability, process integrity, confidentiality, and privacy, you can choose which principles to include in your SOC 2 audit but security must be included in any MVP SOC 2 audit. Now let’s dig into the high-level roadmap and discuss the key elements required to pass your own SOC 2 audit regardless of where you are on your cloud native or compliance journey

Assess scope and ownership of controls and choose the trust service criteria to include

Make sure you are clear on the shared responsibilities and who owns part or all of each control – make no mistake this is the most crucial step to a successful audit.

Service OwnerSaaSPaaSIaaS
DataJointTenantTenant
ApplicationJointJointTenant
ComputeProviderJointTenant
StorageProviderProviderJoint
NetworkProviderProviderJoint
PhysicalProviderProviderProvider
Figure 1: Responsibility Matrix for SOC 2 controls and Audit Evidence Generation

Note the trust service criteria (availability, process integrity, confidentiality, privacy, security, etc.) all have individual controls – the owner in each box in the matrix above would be responsible for producing evidence depending on the scope of the SOC 2 audit. Audit evidence, depending on the control, could include a wide range of test cases, audit logs, documented process and procedures (change management workflows as an example) as well as operational narratives. The IT professional’s goal is to clearly state/prove your organization has met the nature of any required SOC 2 control. In cloud native environments, many of these are joint responsibilities to prove.

Example: Your organization uses AWS to host a SaaS application. As part of your SOC 2 audit, you decided to include availability and confidentiality (in addition to security which is mandatory for non-privacy principled audits). Therefore it is a joint responsibility to produce audit evidence around data and application controls. 

Security in cloud native environments is intrinsically linked to understanding the who and the how of the service owner. Remember – a non-privacy principled SOC 2 audit must include security; all other trust service criteria are optional/dependent on the needs of your stakeholders.

All public CSPs have extensively expanded their offerings in regards to off-the-shelf tools; this is part of their service around compliance, specifically SOC2. This means there is no reason to reinvent the wheel – AWS Cloudtrail, AWS Guard Duty, MS Azure all provide COTS SOC 2 reports. Google Cloud & GSuite have ready-to-download SOC 2 reports as well. 

Perform a gap analysis – remediate when necessary

You’ve mapped out your responsibility control matrix. You’ve established what will be evaluated in your SOC 2 MVP. Now it’s time to perform a gap analysis, see where you have tools and processes in place to meet audit controls and where you do not. Additional investment or adjustments to existing workflows may be required – remediate when necessary. Keep in mind some key factors which will determine the number of times you will cycle through the above steps:

  • Scope – the more trust service criteria (beyond security), the more SOC 2 controls and use cases, which in turn means the production of more audit evidence
  • Current State – are you already leveraging a framework? If you are working with COBIT or CCM from the Cloud Security Alliance, you can likely lean into those. Many times these frameworks are based on industry accepted security standards and regulations; many SOC 2 controls are covered in these frameworks
  • Third parties – the number of third parties you are working with will impact the sizing of evidence; the number of cloud providers, etc. Each control in each trust service criteria must be repeated for each third party

Ready your communication skills – prepare to create analogies to demonstrate compliance in cloud native environments

Many SOC 2 controls are in no way anchored in cloud native concepts or practices. The onus is on the IT professional to demonstrate compliance even when the use case is unfamiliar to the CPA.

Example 1:

Common Criteria 6.x  Implements Boundary Protection Systems – Section 6.x speaks to the logical and physical security aspects of infrastructure. The IT organization needs to be able to demonstrate how you detect and prevent unwanted attacks and access to systems. 

  • If you are working with an auditor who is used to seeing a physical piece of equipment for IDS/IPS, how will you develop test cases to prove the effectiveness of your IDS/IPS solution in a cloud native environment? This is your audit evidence.
  • What type of processes do you have in place to track and monitor file integrity and file access? Who has access to those logs? How can you most clearly show your strategy to an ‘outsider’?

Example 2:

Common Criteria 7.x Conducts Vulnerability Scans – Section 7.x speaks to an organization’s ability to demonstrate vulnerability scans designed to identify potential vulnerabilities or misconfigurations on a periodic basis, and after any significant change in the environment.

  • How are you going to demonstrate periodic scans if your containers are ephemeral? How do you provide ‘new world’ examples to an auditor who may simply be used to seeing traditional AV?
  • You could show your auditor that your base image source is trusted – that a package manager is in place which removes unix shells, compilers and debuggers. You could show a secrets management system is in place and never part of the base image. You could show all containers are scanned for vulnerabilities at build time in the CI pipeline. But the IT professional needs to create the analogous use cases to ‘traditional’ AV solutions and demonstrate how you not only meet the nature of the control but just may well exceed it. 

Elements of the end product – SOC 2 from an auditor’s perspective

These are the fundamental components of any SOC 2 audit regardless of type 1 or type 2 or the number of trust service criteria

  • The Service Auditor’s report is the CPA’s executive summary
  • The Management assertion is the organization’s executive summary
  • A description of the system – any diagrams, workflows documented, any end-to-end system narrative would be appropriate here
  • Tests of controls and corresponding results – this could volumes of data depending on the scope of the audit
  • Any additional information provided – potentially noting third party attestations and supporting documentation

Just as you, the IT Professional, may not have the appropriate background to perform a detailed analysis of a complex financial statement, the onus is on the IT organization to demonstrate compliance even when the use case is unfamiliar to your auditor. Our auditors are learning, just like our IT staff, about fully cloud native solutions. Be prepared and reduce confusion with clear test cases mapped neatly to SOC 2 controls; show how you are meeting (and ideally exceeding) compliance challenges. Be ready to answer ‘off script’ questions.

A call to action:

My hope is that digging into your compliance journey allows you to enhance communication across teams, and leverage this experience to implement controls as an opportunity to create real value and actually shore up security overall. Ideally this exercise will help you identify gaps and inefficiencies.

Remember that audits are ultimately about proving your capabilities to a semi-technical audience. Make sure those with great communication skills are part of your compliance initiatives and recognize you are likely tackling these SOC 2 criteria now, audit or no audit. Once the perspective shifts from a box checking exercise to proving your dedication to ensuring a secure and compliant environment to your customers, it’s less of a chore and more of a point of pride in ownership.

Related Content:

Webinar: Deciphering SOC 2 Compliance in Cloud-Native Environments

Part 1: From Monster to Mascot

The Evolving Role of Security in a Software-defined World

Posted by

The role of security is rapidly changing as data centers that were once typically defined by hardware and devices are taking the next step in virtualization to support both legacy enterprise applications and new cloud computing services. The software-defined data center (SDDC) has gained significant traction, as its infrastructure is virtualized and delivered as a service with control fully automated by intelligent software systems.

The SDDC is propelling cloud computing and the exploding field of microservices to the point of no return. This next phase of virtualization has enabled IT services to be delivered at breakneck speeds by pooling computing, storage and networking resources into one transparent and scalable system independent of any physical infrastructure on which it may partially rely. In fact, the SDDC supports both legacy enterprise applications and newer cloud computing services with one solution. This development has been heralded by many as the next evolutionary step of virtualization, but the resulting agility and speed this affords enterprise is nothing short of revolutionary.

However, while the SDDC has brought businesses advanced technology, new flexibility and tremendous opportunity, it also carries significant risk if left unaccompanied by a new and equally advanced and flexible approach to security. Much like the rest of the modern-day data center, security infrastructure must become software-defined to be effective. The flexibility and fluidity of the software-defined world requires that security measures remain in place no matter where an application might move – be it across physical infrastructure or the cloud.

It must be remembered that security should be a highly integrated component of any organization’s overall IT infrastructure. As such, it must be able to protect every bit of mobile plug-and-play code that so much as touches that organization’s network. In this brave new world, a system-wide view has suddenly become a much more global proposition than we ever would have imagined necessary in the days when hardware and physical infrastructure ruled.

While many enterprises tackle security in a piece-meal manner, this is the wrong approach. Now is the time for organizations to address the increasing shift toward the cloud by incorporating security measures that are easily integrated with security-defined networks and data centers. The simplest and most direct route to this type of set-up is through the adoption of a software-defined security model that’s as flexible and dynamic as the environment in which it must operate.

This approach will essentially end the need for physical security appliances and will ultimately redefine endpoint security. As security becomes software-defined, hardware will no longer need to be managed piece by piece. The all-too-familiar network limitations of legacy security solutions will be removed to empower organizations to more fully embrace the transformative power of public clouds.

This evolution will become necessary for all enterprises – regardless of any lack of willingness to adopt software-defined solutions. After all, while these organizations may refuse to relinquish certain aspects of their legacy infrastructures, the front-end applications of even the most stubborn enterprises will eventually and inevitably become cloud-based and mobile. This in and of itself is enough to drive the transition on the back end.  The good news – even for the most stubborn – is that this will ensure a safer and more secure environment for any organization concerned with the emerging threats, evolving attack vectors and ever-growing attack surface that come with a software-defined world.