How Secureworks observes unobservable assets across AWS Organizations

If managing the security for thousands of AWS accounts is considered a headache, securing multiple AWS Organizations is a chronic migraine. 

This step-by-step process shows how our team at Secureworks uses JupiterOne to find assets in our environment that don’t have agents, but should have agents installed, and monitor this at scale across multiple AWS Organizations.

A company may manage multiple AWS Organizations due to mergers and acquisitions, or different arms of the business may just choose to use AWS in different ways and want clear delineation and ownership. Either way, security teams are responsible for the security state of all accounts across multiple organizations.

The biggest propensity for failure is where security teams lack visibility. Endpoint agents report where they are, not where they are missing. The short life span of resources in the cloud challenges traditional means of tracking deployments and asset life cycles. And the cloud requires teams to monitor security posture at scale. Furthermore, manual tracking and laborious spreadsheet reconciliation between data exports just don’t cut it for most security teams.

Step 1: Understand your environment

First things first, quickly find the account IDs for the AWS Organizations by using this query:

FIND aws_account WITH master=true

This will return the list of account IDs for the AWS Organizations and ground yourself before you dig further into the data.

Then we use this information to find which accounts belong to each AWS Organization using this query:

FIND aws_account THAT HAS aws_account WITH accountId=12345

At this point, you will want to tag the accounts in each AWS Organization to quickly identify which scope you’re working with, whether they are pilot vs production, business unit, etc.

Determining the scope for each AWS Organization

This is the most important step to establish the baseline we monitor and track against. By understanding the business use for each AWS Organization, we can determine the configuration policy that matches the business’s appetite for risk. This is bespoke to each company and requires security teams to speak with a variety of relevant teams. These can include the engineering teams that are deploying and using these assets, compliance teams for understanding standards and controls, and often IT, which is responsible for adjusting the configuration of the assets.

Step 2: Find the lack of relationships between your assets

JupiterOne excels at showing the relationships between assets stored in disparate data sources. This is useful to us because, as mentioned earlier, endpoint agents report where the agents are installed, not where they are missing. To find which assets are missing agents, JupiterOne can return us a list of accounts to investigate by querying for AWS instances in the accounts of a particular org that do not have a relationship with the endpoint agent:

FIND aws_instance WITH accountId = (‘12345’ OR ‘23456’ OR ‘34567’ OR …) THAT !RELATES TO [_type of endpoint agent or service]

Pro-tip: Instead of using !RELATES TO, use the verb that is specific to the service to return results more efficiently.

You now have your list of “problem children” to investigate, and you can save this query as an alert to get notified when new assets surface on the list.

Rinse and repeat for other services, like vulnerability scanning or device management. Save those queries as alerts and you’re ready to accumulate the results from each of those queries into an aggregate list and make this search actionable for the teams that fix the issues.

Step 3: Report on the gap in visibility

Once you’ve saved multiple alerts listing the assets that are missing specific installations, it’s time to build the aggregate alert.

FIND Alert with alertName = (‘Alert 1’ OR ‘Alert 2’ OR …) as alerts
THAT HAS * with _type != ‘jupiterone_rule_alert’ as assets
RETURN alerts.displayName, assets.id, assets.displayName

This query is probably the most complex one in this blog, so let’s break it down.

In the first line, we’re finding all of the alerts that we created in the previous step – the “problem children” of each service – and creating an alias of alerts to help us return specific properties of those alerts.

In the second line, we’re calling back all of the assets in those alerts, filtering out the alert object ‘jupiterone_rule_alert’ from the results, and creating an alias of assets to help us return specific properties of those assets.

In the final line, we’re specifically asking to list every asset ID, name of the asset, and name of the alert in which it’s found so the team responsible for fixing the issue can immediately identify the asset and the problem.

Aggregating multiple alerts into a single “master” is helpful when you have a lot of alerts that you need to make actionable, but don’t want to configure too many webhooks or post requests. You can adjust the query to include other properties in the alert, like alert description, so the end-user of the report can understand what the problem is and which asset they need to fix.

Automation removes pain and simplifies action

Let’s recap. 

You may have the capability to protect your endpoints and run vulnerability scanners, but struggle to find the gaps in your coverage at scale. Manual reconciliation of exports from your endpoint agents and scanners with AWS reports is unmanageable across thousands of AWS accounts and multiple AWS Organizations.

JupiterOne takes a lot of the pain and suffering caused by doing this process by hand and simplifies it. We push data from disparate services into JupiterOne so we can take advantage of the relationships that exist or are missing. We now automatically distill what assets need action and send the information to the teams responsible for fixing the issues.