“…as we know, there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns – the ones we don’t know we don’t know.” – Donald Rumsfeld
Former Secretary Rumsfeld likely doesn’t know Kubernetes from MFA, but his confusing exhortation actually demonstrates something we all know about operating in the cloud: you can’t manage something you’re not aware of. To put it more explicitly, you have to know what’s happening in your AWS cloud environment to know what’s normal versus what’s an anomaly. When there’s something amiss, that’s where you go looking to isolate and rectify the issue.
Because clouds are dynamic and operate at a blindingly fast pace you need as much insight as you can get in order to recognize where threats are, what they are, and to get some context about how they can hurt you. Once you do that, you’re on your way to knowing what’s known and having an idea that you might not know what you don’t know.
AWS S3 breaches tend to be caused by a bucket being inadvertently exposed. It’s not a factor of some complex hacking attempt, nor is it caused by intentional laziness. Rather, the fault lies in being unaware of how buckets are being used and the corresponding configurations (and changes to those configurations). What is critical to know is whether or not the configurations are adequate to maintain the type of security necessary for the data being transacted in and through that bucket.
Many will advocate for the tightest restrictions on S3 buckets. The idea, when extended to an extreme, being that if no one can access them then no data can be compromised. But that negates, in most cases, the purpose of having S3 buckets as repositories within your cloud in the first place. In fact, it negates the whole idea of even operating within the cloud. Some buckets need wide access because some level of business is being transacted in and through them. In other cases, access is restricted, but judiciously.
The important thing for cloud security managers is to have a purpose for their S3 buckets and know how they’re being used. One of the best ways of doing this is by using relevant data provided by CloudTrail logs and factoring it into the continuous monitoring of your cloud activities. CloudTrail identifies and tracks API calls being made on behalf of your AWS accounts. Logs encode the specifics of the calls being made, including important data like time of call, who made the call (even if it was done outside of your organization), the IP of where the call originated, the success of the call, errors, and pretty much all other important information.
Logs give critical data about how apps, people, and resources are behaving and interacting – they are a tableau of all the “stuff” happening in your cloud. These logs are stored and provide a level of forensic insight that users can trace to determine sources of issues.
There’s no question that CloudTrail is an important element of AWS’s inherent cloud security tools. The activity monitoring, compliance auditing, and general awareness they deliver to a user’s dashboard are insightful. But it’s also limited unless it’s included as part of a comprehensive, end-to-end approach that identifies and evaluates everything happening in your cloud. This provides the, “known knowns,” shall we say, that inform your understanding of cloud activity.
Data is more actionable and meaningful, however, when it’s paired with context. We developed Lacework’s host-based cloud monitoring solution to pair continuous monitoring with CloudTrail so that organizations can make sense of the millions (or in some cases, billions) of events captured in CloudTrail. In this way, AWS environments are able to automatically detect anomalous activity logged by CloudTrail when they happen. Whereas CloudTrail offers an incredible repository of events, Lacework then highlights those events when they happen so that issue resolution can happen before a breach can wreak havoc.
A surprising number of organizations we talk with don’t even turn on CloudTrail, however, so they miss the opportunities presented from this trove of data. We recommend a number of best practices that will help you identify issues within your AWS accounts, and that will optimize the benefits of using a host-based approach like Lacework:
- Turn on CloudTrail across your entire AWS environment: Once turned on, you’ll have CloudTrail logging for all your AWS activities, irrespective of region.
- Require MFA for S3 bucket access: Hackers have this nasty habit of deleting CloudTrail logs in order to cover their tracks. With MFA turned on for S3 bucket access, the hacker will have an additional, and complicated, hurdle to cross. MFA is simple to implement and will ultimately save you major headaches later on.
- Enable S3 bucket logging: CloudTrail uses S3 buckets to capture and store AWS events. Enabling that logging for buckets ensures you can identify and track any and all access and usage. Seeing the unauthorized access and where they’re coming from will provide a great advantage in doing forensic analysis.
- Use the least privilege for CloudTrail S3 buckets: This is all about restricting access to logs. Most people in your organization won’t need to see these logs anyway, so keeping a narrow list of admins will reduce the potential for misuse, phishing, dead account clean up, and other hacker targets that can result from widespread access.
- Encrypt logs at rest: This is a great way to maintain oversight over logs. Because users will have to decrypt CloudTrail files after they’re encrypted, it creates an additional, complex step in the process, and it demands that users who decrypt files must have permission both to decrypt and encrypt.
- Provision access with IAM policies: When you map access to groups or roles instead of specific people, you decrease the potential of unintentional access being granted. It also reduces the logistics of permission management and allows you better control over access points.
Managing security in AWS is not a set-it-and-forget-it type of proposition, but with proper management of CloudTrail, along with a host-based continuous monitoring solution, you’ll have the insight needed to be effective at combating threats. With more knowns, fewer unknowns, and knowing what you know and don’t know, you’ll be prepared to maintain your cloud environment’s security posture and keep your environment safe.