Apparently my last post wasn’t boring enough so I was asked to write a piece on security and compliance. There are more security compliance standards out there than I can count on my fingers and toes, and boy 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 means avoiding paying the often hefty fines for non-compliance. 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.
- Putting your own mind at ease. Maybe you’re having sleepless nights worrying about your security posture 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 (like our good selves!). It’s completely 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 requirements. Keep the process light, focused on the right things and all will be good.
Do your threat modelling
Whatever size or shape of an organization you run, threat modelling is something you should definitely be doing, regardless of your compliance requirements. Threat modelling is a process of identifying security risks and their impact on your business as well as who are you protecting from and how you could be attacked. For example, if you’re running a pet dating service you probably don’t need to worry about being hacked by the NSA. 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 and of course The Scale Factory can help you threat model (excuse me as I’m hitting my career framework’s marketing quotas). There are good books written on the topic and it’s also worth watching Ben 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 can 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 a peace of mind for yourself, then CIS benchmarks are a good, non-geographically-specific, 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 (most of the time). As an added 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 (hey, we’ve gone the full circle!). 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 for that.
AWS shared responsibility model
The responsibility for security and compliance in the cloud is shared jointly 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.
The map is not the territory
It’s important to note that just because you are compliant with a security standard doesn’t mean you are actually secure. Changing one crappy 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 an antivirus on all machines, which probably doesn’t make a lot of sense on your Linux monitoring server. If anything, it opens up another attack vector (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.
Hopefully this was a useful, high level security and compliance overview that didn’t bore you to death. 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 you with threat modelling, risk analysis and security auditing of your infrastructure.