Compliance is a minefield. There are more security compliance standards out there than I can count on my fingers and toes, and wow some of them are dry. To spare you going through all that I will attempt a super high-level overview of what’s useful, where to start and how this all relates to operational realities. I will also touch on how cloud infrastructures can make compliance easier due to the shared responsibility model. So here we go.

Do you need to be compliant?

Step zero in navigating the security compliance minefield is to ask yourself: do I need to be compliant? There are many good reasons why you may want to look into compliance; here are a few to consider:

• Regulatory requirements. This is where non-compliance results in hefty fines and potential loss of business. Examples include: PCI DSS if you’re processing credit card payments, GDPR when storing personal data in Europe, or HIPAA when dealing with medical records in the states.
• Putting your stakeholders’ minds at ease. A lot of security revolves around trust. You may want to demonstrate to your stakeholders that you take security seriously and meet a certain standard. You may have customers trusting you with their data or investors trusting you with their cash. Being certified to a standard, such as the ISO 27001, can help you make an easier sell.
• Peace of mind. Maybe you’re having sleepless nights worrying about your security and need a structured way to review it? If you are running on AWS I would start by booking a Well-Architected review with an AWS partner. It’s free and includes a security pillar to get you started. Beyond that you may want to look at a practical security framework, such as the CIS (Center for Internet Security) benchmarks.

If your technical teams are hot on security and you have no regulatory requirements, perhaps you don’t need to worry. Do your threat modelling and create policies to suit your business. But for most businesses, and the people inside them, life is rarely so simple.

Do your threat modelling

Whatever size or shape of an organization you run, threat modelling is something you need to do, regardless of your compliance requirements. Threat modelling is the process of identifying security risks and their impact on your business as well as what you are protecting against and how you can be attacked. For example, if you’re running a pet dating service you probably don’t need to worry about being hacked by a hostile foreign government. Why would they bother? What does your pet know? However, someone spinning up an expensive bitcoin mining operation in your AWS account could be a legitimate business risk for you. So perhaps spending the time on ensuring you have MFA (multi factor authentication) enabled for your AWS users is more productive than hardening the Linux kernel on your EC2 instances? Security is always a trade off. Most businesses simply don’t have the budget to protect against all possible threats, so we need to choose. Threat modelling can help you make good choices. There are good books written on the topic and it’s also worth watching Bea Hughes’ down to earth: “How You Actually Get Hacked” talk for more inspiration and a few infosec jokes.

Do you really need to store this data?

You can’t have a data breach if you don’t have the data, it’s as simple as that. It sounds obvious but it’s amazing how rarely we ask ourselves this question, especially in the age of “big data”. You may find that you need to store surprisingly less than you thought. If you must store data, think about what you’re storing and how long are you storing it for. What are the risks of it leaking and costs of keeping it secure? Do you actually need the raw data or just the metadata? Can it be anonymised? and so on. Resist the temptation to hoard data for the sake of hoarding data. “It may come in useful later” is not a a good strategy. Say you’re running a dating website (for humans this time) and your user access logs are leaked, what’s worse: a day’s worth of data, a year’s, or five years? Did you really need to store customers’ emails and IP addresses in the logs? Maciej Ceglowski’s “Haunted by Data” keynote touches on some of those issues. His take is more from a sociological angle, but is well worth watching from a data security point of view too.

Where to start with compliance standards?

If you have a specific regulatory requirements then the standards you need to follow will largely be chosen for you. Sometimes you can wiggle out of this by using a third party service. For example, you might be able to get out of PCI DSS by using a payment processing service such as Stripe.

If what you’re aiming for is demonstrating trust to your stakeholders and peace of mind for yourself, then CIS benchmarks are a good, international standard to start with. There are benchmarks available for most things you’d care about: securing a Linux instance, network equipment, or a cloud account. They contain practical examples on how to audit and remediate issues and are fairly low on nonsense. As a bonus you can use AWS Security Hub to automatically check your infrastructure for CIS compliance, produce reports and alert on non conformance.

A step up from CIS would be ISO 27001. Again it’s an international standard but it goes beyond security controls and specifies the entire information security management system (ISMS) which includes ongoing threat modelling and risk analysis. By conforming to ISO 27001 you will automatically comply with things like GDPR or the NIS regulations in the UK. If you started with CIS (which is easier) you can map some of your existing controls to ISO 27001 . There’s a handy spreadsheet that helps with that.

AWS shared responsibility model

The responsibility for security and compliance in the cloud is shared between you and the cloud vendor. AWS are responsible for securing the cloud infrastructure: things like physical data centre security, network and the virtualisation layer. You are responsible for securing the services running on their infrastructure, like patching up the operating system on EC2 instances and ensuring security groups are configured correctly. The good news for compliance is that the AWS slice of that pie is already certified and compliant with many standards including ISO 27001. So that’s a load of stuff you don’t need to worry about. You can access AWS compliance reports through the AWS Artifact service.

The map is not the territory

It’s important to note that just because you are compliant with a security standard it doesn’t mean you are actually secure. Changing one weak password for another crappy password every 90 days will probably tick a box on a compliance check list but won’t help much in reality. Keep an eye out for things like that and don’t fall into a false sense of security.

Some compliance requirements can be a nuisance for your particular case. For example you may be required to run antivirus software on all machines, which probably doesn’t make a lot of sense on your Linux monitoring server. If anything, it could put you more at risk (anti-viruses hook up to the OS kernel and run with the highest privilege possible). Scan on demand can also have negative impact on performance. It’s worth paying attention to the exact wording of the requirements, for example PCI DSS says: “Deploy anti-virus software on all systems commonly affected by malicious software”. Since Linux is not commonly affected you can pass without it. In addition, some standards allow for exceptions if they are documented and well justified. It’s an option worth exploring before jumping through the hoops.

Wrap

I hope this was a useful high level overview. In summary the key takeaways are:

• Understand the reasons why you need to be compliant.
• Use threat modelling to workout what you business risks are.
• Think about the data your store, why you store it and for how long.
• The AWS shared responsibility model means you don’t need to worry about some aspects of compliance, such as physical security.
• Don’t fall into a false sense of security just because you ticked a few boxes on a checklist.
• Make sure you fully understand the standard you‘re aiming for and how it applies to your particular case.

If you need to hit compliance targets but aren’t sure where to start when it comes to cloud infrastructure, we’d be happy to walk you through it. We have a lot of experience in this space having worked with clients in highly regulated industries such as pharmaceuticals and finance. We can also help with the threat modelling, risk analysis, and security auditing your infrastructure needs to meet critical standards like CIS, PCI DSS, ISO 27001, NIS regulations, GxP, and HIPAA.

---

Are you ready for ISO 27001? Do you have an effective information security management system that delivers the right technical controls in your AWS environment?

Our whitepaper looks at the tasks involved and makes some recommendations. Or for a quick expert check and report of your infrastructure against the reference controls of ISO 27002, see our AWS Readiness Assessment.

Book your assessment now or book a free chat with us to discuss this further.

---

This blog is written exclusively by The Scale Factory team. We do not accept external contributions.