Starting today, all customers who sign up for RunReveal will instantly get alerted by email of the top 5 security critical events that happen in their AWS accounts.

Your security team needs monitoring. But setting up alerting infrastructure, building out your alerts, maintaining them, and risking being buried in false positives and noise is a lot to ask.

We've been there… What we've learned is that your first five alerts shouldn't be the most advanced alerts to detect zero days. They need to support your overall security objectives of helping the company meet its goals securely, and watching for regressions in your posture.

What this boils down to is two key groups of things you should be monitoring:

• The effectiveness of already existing security controls.
• The highest impact changes being made.

We worked with our amazing friends at Cloud Security Partners to put together an alert that does this to help our customers start monitoring as soon as they ingest their Cloudtrail logs.

The Top 5

Like many top lists, there were some snubs and honorable mentions in this list. We optimized for low false positive rate, and high criticality, but you'll see that there's room for you to customize this list based on your own business' workload.

Root Account Usage

The root account has full permissions to create new accounts, delete accounts, alter billing information, spin down your entire infrastructure, and some other special privileges. It's exceptionally rare that the root account should be used at all. If the root account does get used your security team should at least be aware of it.

This is a foundational best practices in AWS where usage of your root account might also indicate that IAM Roles, temporary credentials, and least privileged access policies are not being used. Doing IAM well is work that never ends, but the first step on that road is not using your root user account (and enabling two factor auth on it).

Disabling Security Controls

There's a few security controls that every AWS account should have enabled and they should never be disabled. Should they become disabled you could be at greater risk, have degraded monitoring, or fall out of compliance with your auditors.

We look for any of the following being disabled:

• Cloudtrail Disabled
• GuardDuty Disabled
• MFA Disabled
• Security Hub Disabled

This is the basic set of foundational security controls that you want enabled, and they should never be disabled without you becoming aware of it.

AWS Key Creation and Deletion

IAM User Keys being exposed is one of the biggest causes of breaches over the past decade. They don't expire, oftentimes have too many privileges, and are easy to recognize in the wild due to their distinctive prefix AKIA. AWS keys are catnip for hackers.

The usage of keys should be rare, and limited to situations where something external of AWS needs to access your AWS account directly. Most vendors that integrate with your AWS account will do-so using IAM Roles these days, and ideally your employees are using IAM Roles too when logging instead of each having an individual IAM user with keys. Some companies have opted to get rid of keys all-together! At RunReveal we have exactly 1 IAM User, our GrafanaCloud instance which scrapes metrics from the AWS API.

Regardless of where you are on your IAM journey, all security practitioners benefit from being aware of new keys being created, and many organizations have strict policies around when and how a key may be created and used.

Creation or Deletion of Storage Buckets

Many of the biggest breaches from the past decade ended up being caused by unauthorized access to data within an S3 bucket. But what does monitoring for the creation of a bucket do?

New buckets by themselves aren't a risk, but when a bucket is created it's likely something that the security team should want to understand the usage of. Will the bucket be used to store cat pictures that are public, or social security numbers that must be kept private? Is there a better way to accomplish the business requirements, without the use of storing sensitive information in a bucket? This alert facilitates those conversations which are critical to building a healthy culture of security.

As your security organization matures you may also mature this detection to require bucket operations are managed through terraform, pulumi, or similar.

Modification of Policies or Permissions

AWS has policies on nearly ever feature. Which policies exactly are we checking? We choose to monitor:

• IAM Policies or User Permissions changes.
• Security group changes
• Bucket policy changes
• KMS Policies
• IAM Trusted Entities Changes

Why these? These were the policy changes we felt had the most opportunity to compromise your security boundaries. Any policy within IAM can have an outsized impact depending on the role or user the policy is attached to. KMS and Bucket policies can be the last line of defense protecting information that is stored within a bucket.

How does the alerting work?

In RunReveal, there are a few foundational concepts to understand to grok how we implemented the top 5 AWS alerts feature.

• Sources — Places we read data from and store in our database.
• Scheduled Queries — Queries against our database we run on a timer.
• Notifications — Where we forward alerts when a scheduled query returns 1 or more rows.

When a new user joins RunReveal we create a notification for them using their email address. If we're going to send a customer alerts, we need somewhere to send them and email is a natural fit.

Next, we can make a scheduled query to detect those conditions within RunReveal by querying the cloudtrail_logs table. Each log source has it's own separate table with the fields that are specific to that log source, and the same data is available in the runreveal_logs table, which is a table of all log sources in a unified format.

In this case, the cloudtrail_logs format is most appropriate to query

SELECT * FROM cloudtrail_logs WHERE
(
  (userIdentity.type='Root' and userAgent!='AWS Internal') OR
  (eventName in (
    'CreateBucket',
    'DeleteBucket')) OR
  (eventName in (
    'UpdateAccessKey',
    'CreateAccessKey',
    'DeleteAccessKey')) OR
  (eventName in (
    'DeleteTrail',
    'UpdateTrail',
    'StopMonitoringMembers',
    'DeleteDetector',
    'DisableSecurityHub',
    'DeactivateMFADevice',
    'DeleteVirtualMFADevice')) OR
  (eventName in 
    ('AuthorizeSecurityGroupIngress',
     'PutKeyPolicy',
     'PutBucketPolicy',
     'UpdateAssumeRolePolicy',
     'AttachUserPolicy',
     'PutRolePolicy',
     'PutGroupPolicy')
   )
)
AND receivedAt >= now() - INTERVAL 15 MINUTE;

We create this scheduled query in each customer's account when they sign up, and it runs every 15 minutes. Customers who never log anything will have their queries run against the database, but just never return any results.

Once a user creates a source and starts ingesting Cloudtrail logs, logs that are returned  will automatically be forwarded directly to your email!

What's next?

We're working on adding more queries that you can use off the shelf and get instant value from. We'll be adding them here: https://runreveal.com/queries. We want you to be able to discover helpful queries that you can run against your logs, and easily run them on a schedule.

We're continuing to add more sources we read data from, and have a lot of exciting announcements lined up over the coming weeks. If you're interested in what we're doing get in contact or reach out to schedule a demo!