Deepwatch and AWS Detection Engineering

As a lead detection engineer, my primary responsibilities lie in what we do with customer data once it’s brought into one of our SIEM environments. We can enhance a customer’s security coverage using the alerts and visibility that data allows us to provide.

Because of the Deepwatch platform and our close relationship with AWS, we are very experienced working on AWS-hosted Splunk deployments, as well as getting data from those AWS environments into our customers’ SIEMs. 

CloudTrail Logs

Let’s break things down into cloud configurations and service monitoring tools. Amazon has over 200 web services. From a security perspective, AWS customers are primarily interested in logging from CloudTrail. CloudTrail maintains a lot of the configuration tracking and audit logs for users accessing AWS and its APIs.

You have a few options when it comes to setting up your alerting platform for AWS activity. You can make homegrown detections in your platform, which is something that we do, offering a fair number of alerts that are based on CloudTrail logs. Those give us the most visibility into changes and configurations being made in an AWS account environment.

AWS Security Tools

In addition to CloudTrail logs, there’s also the security stack on top of that, which includes tools such as AWS Web application firewall (WAF) and AWS Virtual Private Cloud (VPC) flow logs for network monitoring. This also includes AWS security alerting from GuardDuty as well as security or system monitoring from Security Hub and Cloud Watch. 

There are a bunch of different tools you can bring in, all of which are configured in slightly different ways, but they are all ingested in a fairly similar way. As far as what this does for security practitioners, this gives us some visibility into your cloud environment, particularly around the kind of configuration changes that are being made by users with admin privileges.

There’s an inherent level of access and authentication information that you can get from these sorts of logs, enabling you to see if someone is successfully completing operations. This information is logged in our audit trails in CloudTrail. You can also identify that someone has authenticated to the service in order to make those changes.

Deepwatch can help customers tremendously in these areas by providing a sort of defense in depth. If you turn on default GuardDuty alerts and just start sending those in, you have that black box sort of coverage (and Deepwatch’s Managed Detection and Response can help make sense of those alerts). But when you work with the Deepwatch team, you can also address a very specific risk that you might be worried about with our custom detections.

Some of the native security tools like GuardDuty take in a lot of the foundational functions of the other AWS services and do some correlations and some alerting. Depending on how you have that configured, and how you’re logging, you can get a lot of information.

That gives you the opportunity to strike a sort of balance between how much you’re logging and what sort of coverage you’re seeing when you form your detection strategy. So ideally, you can start with a breadth of coverage for security use cases. Feasibly you could just start bringing in GuardDuty alerts and then you’d have the widest range of coverage from the start.

With CloudTrail and Detection Engineering resources who can create detections directly from the raw logs, you’re able to make more specialized use cases than those provided by GuardDuty based on what kinds of detections your organization wants to achieve. One of my preferred phased approaches to detections is:

1. Start bringing in GuardDuty alerts 
2. Tune those security alerts based on what you’re seeing in your account
3. Bring in CloudTrail logging
4. Create and tune custom detections around observed behaviors in CloudTrail
5. Consider integrating VPC Flow logs in your SIEM network monitoring framework

AWS Virtual Private Cloud (VPC) Flow logs can be one of the noisiest pieces of the puzzle when it comes to licensing considerations. These logs can be quite voluminous and require careful consideration when attempting to ingest. Effective monitoring of the right flows can provide a more detailed understanding of the way AWS assets are communicating with one another. This can make all of the difference when attempting to correlate activities across the cloud environment.

Detection Use Cases

You can start investigations on AWS tools, drilling down into who did what, when, where, how, and all of that information. Then you can start building your own detections as well. So if you want to, you can build something very specific where you’re looking at particular sets of assets and particular sets of actions being done. If you’re so inclined, you can ingest the logs and begin to do all of that in your SIEM as well.

There are some default GuardDuty alerts that can provide excellent coverage for things like an S3 bucket being exposed to the public, suspicious or anomalous user behaviors, and threat intelligence informed triggers for suspicious IPs and resources. GuardDuty has alerts for these things, but then if you’re ingesting CloudTrail logs, you can audit and investigate the details of those events more closely. From there, you can build out the full timeline and associate it with any information you have from various other tools in whatever SIEM you’re using, such as Splunk or Sentinel.

AWS Configurations Are Business Critical

There is also significant value in the monitoring and reporting that can be created around the logs we bring in from AWS. We see people in organizations making major AWS configuration changes that could impact the business all the time. You can have a lot of AWS instances: hosting your web applications or hosting important data. So when you see people terminate those instances or make other major configuration changes, you can track who is making those sorts of changes with your CloudTrail logs. 

From there you can build out other security use cases, monitoring whether people follow proper change management protocols. We have customers who are interested in alerting on any number of specific use cases in their AWS environments, and bringing in the right kind of data is critical to helping accomplish these goals.

Why Deepwatch?

Guard Duty, CloudTrail, the Security Hub, all of the security tools that AWS builds for their platform are excellent. So why do people choose us? It can be any number of reasons from a lack of personnel to a simple desire for a reliable source of expertise external to their organization.

While we may not know the entire scope of what your cloud environment looks like from the beginning, our detection engineers have experience deploying these AWS use cases and developing custom monitoring and playbooks for the risks that you’re most concerned about. With Deepwatch you get the security experts, your detection engineers, and a team who can help you build out whatever is needed to achieve peace-of-mind and Cyber Resilience for your organization.

↑