Despite the rapidly increasing need for cloud-native visibility into behavior and activity across AWS environments, companies are still learning about best practices for AWS security.
Amazon Web Services (AWS) is a cloud service provider that’s on almost every company’s radar today, ranking number one for the eighth year in a row as the top IaaS provider in Gartner’s Magic Quadrant. But many AWS customers today wonder what the best approach to security is and how to get there.
While the concerns and issues vary widely from company to company and industry to industry, each business must be able to answer these three key questions:
- Who has access to which applications and when?
- How can we monitor for key file changes?
- Will we be notified in a timely manner when something anomalous occurs?
But considering the growing complexities of today’s data, use cases, compliance mandates, and so on, companies often struggle to understand how they can protect and secure their data, their customers, and their very existence before moving to (or while expanding on) AWS.
We’ve spoken to many of our own Threat Stack customers as well as associates across the security industry to identify the most common challenges when it comes to AWS security, as well as some of the ways they are rising to meet them.
1. Prioritizing a Security Strategy Ahead of Controls and Tools
A big question we see bubbling up among AWS security user groups and forums (like this one on Quora) is how to approach cloud security in the first place. More specifically, do you put tools and controls in place first, or take the time to establish your security strategy? While this seems like an elementary discussion, the answer is more complicated.
Nine times out of ten, the strategy should come first, so that when assessing a control or tool, you can better determine if and how it supports your strategy. Putting the strategy first also enables you to integrate security into all business functions — especially operations and development team workflows. This can be a huge help with continuous deployment, in particular. For example, if your organization is using (or considering using) configuration management tools (e.g., Chef, Puppet, Ansible, Salt) to enable the automation of software updates and patches, having an overarching security strategy can help you implement security monitoring across these tools from day one. The same approach applies to any business process or tool you use across your organization.
If you’re looking for more advice on how to shape your organization’s security strategy, check out our top picks for cloud security blogs.
2. Overcoming the Lack of Security Visibility in the Cloud
Considering the sheer number of cloud applications that companies use on top of AWS today, and the logins and controls that vary across each of them, it’s next to impossible to know at all times who is accessing what and where across the organization (and, even more importantly, if any of the activity is malicious or anomalous). The lack of security visibility becomes seriously magnified when there’s no security strategy supporting the implementation and management of these applications.
To achieve better visibility on AWS, follow these three best practices:
1. Take an inside-out perspective
If you don’t know what’s happening on a host or workload, you need more information than an IDS log can provide. You need to know more than the fact that a certain packet went out over the wire, for example. What’s needed is a solution that shows specific events over time on specific servers, such as what we’ve built at Threat Stack.
2. Go beyond logs
While logs are essential, they often provide only a narrow view of what’s going on. In other words, it’s one thing to see who’s entering and leaving the building, and quite another to know what they are doing once they’re inside. Typical network-based intrusion detection (NIDS) doesn’t give you much to work with after a compromise, because the ability to identify behavior leading up to an attack is limited. That’s where host-based intrusion detection (HIDS) comes into play. With security embedded at the host-level, you gain knowledge of the what, when, and where, before, during, and after an attack.
3. Protect against the insider threat
If an incident occurs, it’s important to understand the bad actors — and unfortunately, sometimes they can be internal. Some key indicators that a threat came from the inside are seeing unusual network activity, unauthorized installs, abnormal login attempts or failures, or key file changes.
3. Improving Confidence in Cloud Provider Security
While AWS does offer many useful out-of-the-box security tools and configurations, such as AWS CloudTrail and Amazon Cloud Watch for logging and monitoring, it’s important to know where their responsibility ends and where yours begins — especially when it comes to protecting data within sensitive workloads.
We’re even seeing companies begin to think about the security of their data on AWS before they make the decision to migrate to AWS. It’s becoming more common for companies to talk in parallel with both AWS and cloud security providers (such as Threat Stack) to get all their questions answered up front, asking things like:
- How do we ensure compliance?
- How are we going to deal with incident response?
- How can we access log data?
These are all very pertinent questions, ones that even the largest and most well-known companies using AWS are asking. By asking questions like the ones above, as well as ones that apply to your particular use case and industry, you’ll be able to migrate onto AWS with far more confidence.
4. Defining Who is Liable
Liability is a very hot topic in cloud security. That’s because, when a security incident occurs, you need to know who is responsible so you can take appropriate action.
Today, providers like AWS are taking on a lot more collective security accountability for everything above the virtual machine layer. But users still have to take responsibility for things like access control, monitoring, and audit logging in order to determine who has access to what, how applications and data are monitored, and how alerts will be handled. By taking a proactive approach to defining access levels and monitoring activity across the network, companies can be sure that if and when something goes wrong within their AWS environment, they can pinpoint liability with laser-like precision.
5. Understanding Why Attackers are Attracted to the Cloud
Companies trust a lot of sensitive data to cloud service providers like AWS (think healthcare information, credit card data, financial reports). But that also means they become a big target for attackers. However, most security incidents actually occur because of credential theft (according to the 2018 Verizon Data Breach Investigations Report) not sophisticated zero-day attacks against cloud providers themselves.
Credentials are a goldmine for attackers for one very important reason: They are the keys to the kingdom, granting access to a vast amount of data by exploiting a single data source.
Let’s take a look at how this has happened in the recent past:
- CodeSpaces was infamously forced out of business within 12 hours after attackers compromised their entire AWS account. By the time the company reclaimed its dashboard, attackers had created alternative AWS logins, questioning the overall security of the system. This left them no choice but to shut down.
- More recently, Timehop experienced a massive breach of customer information due to a theft of the company’s cloud service provider administrative credentials. The intrusion went undetected for more than six months before it was discovered.
There are a number of ways to preemptively protect your credentials and data:
- Turn on multi factor authentication (MFA) for everything within your control.
- Monitor for anomalous logins using continuous security monitoring.
- Implement a logging service at the host level.
- Use AWS Secrets Manager or a different secrets management system, such as Hashicorp Vault, to rotate credentials.
6. Defending Against Curious Onlookers in Multi-Tenant Infrastructures
In theory, multi-tenancy leads to a higher risk of data breaches, but in practice, it really depends on how well secured your infrastructure is. Think about it this way: Is a house inherently more secure than an apartment building because it’s a smaller, less valuable target for a burglar? In theory, yes, but in practice, no. It depends entirely on how well secured the premises are.
Here’s the true risk of multi-tenancy: When untrained staff or immature processes are used to deploy and monitor virtualized systems, the company becomes vulnerable. Many companies fear that, with multi-tenancy, their data could inadvertently become exposed to competitors. And that’s not totally unreasonable. While providers like AWS are well aware of these concerns and have implemented layers of protection to ensure that you — and only you — see your own data, you can and should take a number of extra precautions on your own. We recommend benchmarking your security maturity, and making efforts to improve in five key areas:
- System access & users
- Patching & vulnerability management
- Infrastructure control plane
- Runtimes & services
7. Addressing Compliance Regulations From the Get-Go
Concerns about compliance in the cloud echo loudly from both large and small companies in regulated industries. Particularly with the recent GDPR regulations (and the hefty associated fines), AWS has introduced resources to ensure data privacy. While cloud providers like AWS do provide companies with a certain level of protection, they simply can’t cover every aspect of compliance.
AWS can (and does) offer protections such as encryption of PII, both at rest and in flight, but it doesn’t continuously monitor data for anomalous behavior, provide host-level insights that can get to the root of the problem, and so on. Yet it’s not an easy task to figure out where AWS’s compliance features end and where another solution needs to come into play to fill in the gaps. Facing a lack of time and patience to piece the puzzle together, some companies opt for the status quo by sticking with their on-premises (yet outdated) solution.
That’s too bad, because there’s no need to throw the baby out with the bathwater. Moving to the cloud is the smart choice for companies that want to stay competitive in today’s world, and there are plenty of cloud security providers like Threat Stack that can help you meet your compliance obligations.
Your AWS Mantra: Trust, But Verify
The good news is that most companies are no longer questioning whether they should move to the cloud. Instead, they’ve realized they can take advantage of the many benefits the cloud has to offer and still satisfy their security and compliance needs. AWS has proven itself to be a strong cloud partner to many of today’s biggest, fastest, and most innovative companies. You can trust them, but as with anything else, you should always verify. That’s where your responsibility as a cloud user lies. And with the seven tips outlined above, you should be well on your way to defining your security and compliance needs and figuring out how to successfully meet them in the cloud.
If you’re ready to evolve your security and operations workflows for a cloud infrastructure environment like AWS, be sure to download a copy of our free SecOps Playbook for Cloud Infrastructure.