Services
We’re doing a fair number of cloud security assessments. This post will talk a bit about what we have found and some common ideas that seem to apply across them.
When we do work with a client to help them secure their cloud environment, let’s just talk about AWS for now, the process looks something like this:
As a general rule, we’re trying to stay away from writing reports because those tend to be time consuming to write and not particularly easy to read. Instead, we deliver through JASP or GitHub issues.
In the real world, IAMIAM (Identity and Access Management) is a set of processes, policies, and technologies that enable organizations to manage and control access to their systems and data. IAM solutions help to ensure that only authorized individuals can access sensitive resources, and that access is granted on a "need-to-know" basis. is really hard. Understanding what roles and profiles exist is foundational to building out any kind of secure environment. Sadly, this is different from company to company and that makes it complicated to talk about or set baseline expectations around.
A couple of important things:
Many AWS services can easily integrate with CloudTrail. Sadly, this is often not the way people do it. Often we see theoretical integration with a SEIM via a Syslog based logging system then forwarding to the actual SEIM. That’s not bad per se, but where you can, use CloudTrail.
For example, use CloudTrail for tracking:
Many teams we have worked with were not aware of GuardDuty. While the utility may be overstated, i.e. I personally don’t buy that this is equivalent to an IDSIDS (Intrusion Detection System) is a cybersecurity technology that monitors network traffic and systems for signs of malicious activity. IDS solutions use various techniques such as signature-based detection, anomaly detection, and behavioral analysis to identify patterns of unauthorized or unusual behavior., it is a legimately useful tool for identifying strange behavior. Turn it on and you can get a feel for a baseline of certain types of events. Also, it is fairly easy to manage.
Most teams are not familiar with or running inspector either. In their defense, some can’t very easily. If they are running Docker images for example, we don’t see it being realistic to run Inspector on these.
Also, Inspector is like GuardDuty where you may or may not get everything you think you’re getting. But its support for CISCIS (Center for Internet Security) is a non-profit organization in the cybersecurity industry that provides resources, tools, and best practice guidelines to help organizations improve their cybersecurity posture. CIS benchmarks are widely used to provide guidelines for securing systems and networks. and some level of host based checking is a solid control to add to the arsenal.
We recommend using this particularly in sensitive environments (as segmented
by network or account).
Speaking of segmentation, we often don’t see proper segmentation even at a network level. The idea here is to clearly segment areas of your network so that you can define scope. The segments might correspond to business functions, application environmens, stages in a pipeline (dev / stage / prod). They might include different VPC’s for very sensitive data. One of the great things about cloud environments is
that you can just use another VPC!
Again, we also see benefits to doing this type of segmentation at the account level but at the very least we would want to see VPC level segmentation.
Beyond that, it is advisable to use a WAFA Web Application Firewall (WAF) is a type of cybersecurity technology designed to protect web applications from a variety of attacks, such as SQL injection, cross-site scripting (XSS), and other common web-based threats. A WAF sits between the web application and the internet, monitoring and analyzing incoming traffic in real-time. It can detect and block malicious traffic before it reaches the web application, providing an additional layer of defense against cyber attacks. WAFs can be implemented on-premises or through a cloud-based service and can be configured to suit the specific security needs of the web application they protect. WAF is often required by security standards such as PCI-DSS., VPC Flow Logs and Guard Duty but we often don’t see these.
Many people we talk to believe that their backups and failover are going to be automatic.
In some cases and senses that is true, but probably not in the sense they really mean. How are your S3 buckets or RDS instances really available in another availability zone or region if AWS has an issue? Are you making backups to Glacier?
AWS Config is a useful tool for tracking and optionally checking the security of certain core configurations. The cost to run the checks seems quite high in some cases, so often this is not used. Our JASP tool provides simialar types of checks for a much lower cost. Still, if your budget allows, by all means, run AWS Config with the checks enabled.
The classic AWS mistake is to put sensitive information in a public S3 bucket. I would go so far as to consider writing automated checks that will verify that your S3 buckets lookthe way you expect. We have written tests like this with Gingko and Go tools.
Many tools will report about public or otherwise misconfigured buckets. Use these, but be prepared for the cases where the buckets are intentionally public.
There is so much to learn with the cloud and with vendors like AWS releasing new security features and other services at a rapid pace, it can be overwhelming to configure your environments in a reasonable way. At the same time, engineering teams are trying to keep pace with their feature requests and deadlines. This post tried to at least mention some common issues and capture some of the easier and simpler items that can be addressed generally. Enjoy and reach out if you have questions or feedback.
