Sleeping through AWS Cloud compliance meetings? You are not alone
By submitting this form, you agree to our privacy policy.
When someone brings up the topic of compliance, I almost immediately think borrr-ing. Google cybersecurity compliance and you’ll find that the results are informative but “dry” would be a generous description of how they’re presented
It’s no wonder that security teams often overlook compliance until they’re forced to deal with it.
Does it need to be that way? Is there value in compliance besides not getting in trouble for not being compliant?
Compliant with what?
In cybersecurity compliance is simply the practice of proving that what you’re doing is in line with some set of guidelines or policies. That’s it.
There’s varying levels of difficulty in accomplishing this, but regardless of what you’re trying to be compliant with, the goal is the same––I was asked to do X. Here’s the proof I did X.
We all know—or if you’re not a direct practitioner, you at least have an idea—that cybersecurity can be difficult. After all, cybersecurity addresses the complex gaps in complex technologies.
Those layers of complexity can make proving that you’ve met a specific bar its own complex challenge, before we even account for the people and processes associated with the use of the technology in question.
Needless to say, there’s enough complexity to go ahead.
Who set the standards?
Depending on the types of technologies you’re working with and the market you’re in, there are different compliance standards or frameworks.
Two of the most common are PCI DSS and ISO 27001. Neither acronym promises a riveting read, but bear with me for a minute here.
PCI DSS is the payment card industry data security standard. This is the compliance framework laid out by organizations involved with processing credits. They’ve gotten together and basically said, “If you’d like to process credit cards, you have to follow these cybersecurity standards.”
Given the interconnected nature of the financial system behind credit cards, it makes sense that everyone involved should have to follow a common security baseline.
ISO 27001 is an international standard (ISO literally stands for International Standards Organization) that lays out the basic requirements for a modern security practice. This standard is used in all sorts of situations to establish a common state of an information security management program (a/k/a a cybersecurity practice).
While these standards are two of the most common, there is a sea of acronyms out there representing various security standards that organizations will prove themselves against.
If you look at AWS’, Azure’s, or Google Cloud’s compliance pages, you’ll start to get an idea of the variety of compliance frameworks that are out there.
That process of proving your compliance is done via an audit. That audit (hopefully) produces an attestation of compliance with the specific framework.
What do you get out of it?
Each compliance framework is different but there is often a consequence for not being compliant with a framework that is required in your line of business.
Contracts may require compliance. Governments often required compliance in order to access resources or to enter into business agreements. Industry groups may not allow companies to participate in communal activities without being compliant.
However there are other benefits and many that directly impact the operations of your security practice.
Compliance is a forcing function for your team to shift towards provable security.
Too often, security teams simply assume that their controls and processes will avoid security issues. Assuming everything is working well is not how you have a long and successful career in cybersecurity!
If you are aiming for compliance, you need to think like a good student. You shouldn’t be cramming the night before the exam. You should be learning throughout the semester. Similarly, you should be aiming for continuous compliance.
If an audit were to happen today, could you respond to the questions asked? If so, you’re practice continuous compliance. If not, time to start.
Does compliance change in the cloud?
Compliance can be significantly easier in the cloud. The reason? The CSP is taking care of a lot of the technological components. It’s yet another advantage of the Shared Responsibility Model.
In the cloud compliance starts with making sure that the services you are building with are already complaint with the framework you’re looking to meet.
Let’s say we’re building in the AWS Cloud. We start by checking to see if the services in our architecture are in scope with our target compliance framework. Thankfully, AWS has a page dedicated to this exact task.
Now that we know the services we’re building with are in scope, we can continue our compliance efforts as usual. The only other difference is when it comes time to respond to an audit, we need to provide the compliance attestation from AWS alongside our response.
Again, there’s a handy way to accomplish this. One of my all time favourite AWS services comes to the rescue here. AWS Artifact is a “self-service portal” for the compliance documentation of AWS’ part of the Shared Responsibility Model.
The tl:dr of it? AWS Artifact is one big webpage with a bunch of links to the documentation you need for AWS service compliance reports.
Aiming for compliance
After checking that the services you’re building with are in scope for the compliance framework you are aiming to meet, it’s time to get the ball rolling.
Your next step should be to review the requirements of the compliance framework. These will be a combination of technical and process requirements.
Here’s a couple of concrete examples;
- Under requirement 6.2.3 of PCI DSS v4, for software you write or customize, you are required to conduct, “Code reviews look for both existing and emerging software vulnerabilities.”
- ISO 27001 A.12.4.4 is all about keeping your clocks in sync so your logs line up. The official wording, “Clocks in all related information management systems should be integrated into a single reference time source for an organization or safety domain”
Neither of these requirements are edge cases. Most security practices would make sure that code reaching production had some level of review to make sure that known vulnerabilities aren’t present. Similarly, any ops team worth their salt knows that clock synchronization (while borrring) is super important when you’re trying to troubleshoot anything.
This is commonplace throughout almost every compliance framework. The requirements are activities that your security practice already has in place or a plan in place to implement.
The key now is to be able to document that you are doing them.
For each new system that comes online, is setting the clock to your organization’s standard time server on the deployment checklist? Do you have an automated (or manually if you’re just starting out) process in place to periodically check that those clocks are still getting their time from the time server?
That’s compliance.
The same thing goes for the vulnerability code reviews. Do you have a tool that periodically scans your builds for vulnerabilities? And then again periodically or continuously in production? The reports that tool outputs or the datastore it maintains are part of your compliance efforts.
That data proves that you’re doing what you said you would.
Your first compliance steps in AWS
The first thing you practical step you need for continuous compliance in the AWS Cloud is actually already done for you…assuming you are using an account created in the past few years.
AWS CloudTrail is the service that logs almost all actions taken in your AWS environment. Enabled default, it’s up to you to take advantage of this automated audit log either through third party tooling, AWS services like Amazon CloudWatch or Amazon Athena, or a combination of both.
From there, you need to make sure that your security controls and processes are aligned with your desired framework. Those steps will be specific to the compliance regimen that you’re following.
Thankfully, AWS has a number of resources that will help you figure out the tactics you need to implement to meet your compliance goals.
Start with this talk from Scott Paddock, a Security Solutions Architect from AWS. “Everything You Wanted to Know about Compliance but Were Afraid to Ask”, is a talk Scott delivered at AWS re:Inforce 2019 and it is a gentle introduction to the implementation level of compliance in the AWS Cloud.
After that talk, I would recommend, “Practical Patterns for Meeting Your IT Compliance Requirements” by Kurt Gary. Kurt is a Principal Solutions Architect with AWS and focuses on financial services customers.
This talk looks at some design patterns and processes that can help reduce the effort needed to prove that you’re doing what you set out to do with your cloud builds.
From there, I would recommend diving into some AWS white papers. There are a number of specific compliance frameworks. Here’s a few of the key ones;
- HIPAA – Health Insurance Portability and Accountability Act in the US which sets out requirements when dealing with persona health information (PHI) and other medical data
- GDPR – The General Data Protection Regulation in the EU which governs the use of data about EU citizens
- PCI DSS – Payment Card Industry Data Security Standard covers payment processing systems
- ISO 27001 – The international standards organization’s framework for information security programs
What’s next?
There are plenty more resources available to help with your specific compliance needs in the AWS Cloud. Similar resources exist for Azure and Google Cloud as well.
Compliance is often an after thought for the security team. It’s also a critical business driver. We need to address that disconnect.
Remember that these compliance frameworks often outline reasonable security baselines. Achieving a compliance attestation can be a frustrating experience but if you remember that the goal should be the ability to prove continuous compliance. The challenge starts to seem a little easier.
Above all else, remember that compliance is really the practice of having the data that proves you’re doing what you said you would.
What security team wouldn’t benefit from that?
Categories
Suggested for you
An overview of Living Off the Land (LOTL) attack techniques
How do cybersecurity professionals influence industry standards? A Q&A with CIS Benchmark contributors
