For the eighth year in a row, AWS has been ranked in Gartner’s Magic Quadrant as the No. 1 IaaS provider. This is a clear indicator of the trust companies show in AWS, by migrating to AWS and adopting AWS services. Despite this, most companies, across industry segments have much to learn about AWS best practices for security.
Organizations—across industries—should start to address their security concerns, or map them, by answering the following three questions:
- Who can access my applications and when are they being accessed?
- How is it possible for us to better monitor key file changes?
- How can we ensure of being notified in time in the event of an anomalous occurrence?
This article looks at the key ways organizations can identify and meet the most common of challenges to AWS security.
Beware of Misconfigurations
It is common to see organizations give priority to putting tools and controls in place before establishing security strategy. It is far better and more practical to assess a control or tool’s ability to support your strategy than vice versa. Taking a strategy first approach also allows you to integrate security into your business functions, like operations and development team workflows. With an overarching security strategy in place you can implement security monitoring across your tools from day one. And it applies to any business process or tool.
Address Lack of Security Visibility
There are so many cloud applications that organizations use on AWS today, with so many different logins and controls, that it’s next to impossible to know for certain, and at any given time, who is accessing what or where across the organization. And whether the activity is malicious or in any way anomalous. If there is no security strategy supporting the management of these applications, the lack of visibility is more magnified.
The following best practices will help you achieve higher visibility on AWS:
a. Use a solution that can give you more information that an IDS log. It needs to show you specific events at specific times on specific servers.
b. Look beyond logs
Logs, while useful, provide a narrow view of what’s happening. Typical network-based intrusion detection (NIDS) doesn’t have the ability to flag anomalous behavior prior to to an attack. With Host-based intrusion detection (HIDS), by contrast, security is at the host-level, giving you detailed information about the attack, viz. what happened, when and where, and before/during/after an attack.
c. Safeguard yourself against insider threats
Unfortunately, attacks are sometimes internal. But there are some key indicators that the threat was internal, such as unusual network activity, unauthorized installs, abnormal login attempts or failures, or key file changes.
Complement Cloud Provider Security
AWS offers several useful security tools and configurations, like AWS CloudTrail and Amazon Cloud Watch; but, it’s important to understand where AWS’s responsibility ends and yours begins, especially when protecting data in sensitive workloads.
Even before you decide to migrate to AWS, you should ask data security questions like,
How can we ensure compliance?
How do we deal with incident response?
How do we access log data?
Identify liability—pre-emptively
In the event of a security incident, it is critical to be able to identify who is responsible, so appropriate action can be taken. While AWS, like other cloud providers are beginning to assume more security accountability, as a user, you are nevertheless responsible for stuff like access control, monitoring, and audit logging. So you know who is accessing what, how your applications and data are being monitored, and alerts handled. Companies that are proactive in defining access levels and monitoring activity will be able to pinpoint liability if or when anything goes wrong with their AWS environment.
Protect your credentials
There is a lot of sensitive data on the cloud, for instance healthcare information, credit card data, financial reports, etc. This is a huge lure for attackers. Ironically, it is not zero-day attacks that you should worry about, (though undetected vulnerabilities, are a concern) but credential theft. Credentials are literally the keys to the data, providing immediate access through just one data source. Credential theft can wipe out a business, as CodeSpaces found out. 12 hours after their AWS account was hit, CodeSpaces was already dead in the water. The company did reclaim the dashboard, but the attackers made so many fake log-in credentials that the system was systemically undermined, and had to be shut down.
There have been cases where theft of the company’s cloud service provider administrative credentials led to intrusions that go unnoticed for months, exposing reams of customer information.
You can take some steps to protect your credentials and data:
- Switch on multi factor authentication (MFA) for everything in your control
- Use continuous security monitoring to spot anomalous logins
- Use a logging service at the host level
- Rotate credentials using secrets management system, like AWS Secrets Manager or Hashicorp Vault.
Heighten security in multi-tenant environments
Multi-tenancy increases risk of data breaches. But you can protect your data from being exposes to competition by taking extra precautions—beyond the layers of protection put in place by providers like AWS. You can start by improving security in five key areas:
- System access & users
- Patching & vulnerability management
- Infrastructure control plane
- Networking
- Runtimes & services
Meet compliance regulations from the outset
While cloud providers do offer protection to ensure data privacy, such as encryption in stasis and in transit, data is not monitored continuously for behavior that could be construed as anomalous. Cloud providers just don’t cover every aspect of compliance. This means that gaps exist, but its not easy to plug the gaps and figure out where they are. Rather than revert to previous—often outdated—security protocols, you’re better off with a strong cloud managed servicer provider who can help you meet compliances, natively.
