We recently announced the release of an updated AWS discovery connection for our vulnerability management solutions, Nexpose and InsightVM. This new connection is more efficient and works to the user’s advantage; to do this, it leverages a different workflow than the old connection does. If you’re still using the old AWS connection (now labeled as “legacy” in product), this blog will guide you through updating to the new and improved discovery connection, so you can realize benefits like tag importing and more efficient visibility.
First, let’s look at what has changed. The legacy discovery connection polled the AWS API for asset listings every two minutes, which was a fairly resource-intensive way of watching for changes. In the new connection, we follow the AWS CloudTrail logs for changes instead. Implementing the legacy connection, you also had to have one connection for each account in each region it was used, and you needed to provide a key for an IAM User in each of these accounts unless your console was also located in AWS.
With the new connection, you can leverage AWS cross-account trust regardless of where your console resides, and you will only need a single connection for all of your accounts in all regions where they are used. Finally, assets created with the new connection are treated as live discovered assets without your having to perform a discovery scan first, so they can be tagged and organized based on the metadata imported from AWS. Note that only assessed assets count against your license usage, so these assets discovered automatically will not be increasing your license counts.
With these changes in mind, there are a few differences that will impact your implementation which you’ll need to consider. First, using CloudTrail logs, you’ll modify your existing account policy to add these permissions as per the example provided in the help pages
Note that following CloudTrail logs like this increases efficiency, but you may notice slightly more latency in identifying new or removed assets, as it can take up to 20 minutes for these logs to update.
The second change may also require a few modifications to your AWS configuration, especially if your console sits outside AWS. Previously, you were only able to use cross-account trust if your console was deployed inside AWS, which is the approach Amazon recommends, and instead you needed to create an IAM User and key for each account. With the new connection, if your console is outside AWS you can create one IAM User and key for your primary account, and then create an IAM Role in each additional account to which you will grant cross-account trust to the primary account.
Here, you’ll specify your IAM User’s access key information along with the Amazon Resource Name (ARN) for each account you’ve set up with cross-account trust—one ARN per line. You can also select all of the regions these accounts are used in, or you can select all regions so any asset from any of these accounts will show up regardless of which region they’re deployed into. If you would like to import assets from your primary account itself, you’ll also need to set up a second connection with this IAM User key information, but without the ARN, to get asset information without using cross-account trust. If your console is inside AWS, the setup is the same, except that you will not need to provide an IAM User and key for the initial account access (it will be pulled from the IAM Role assigned to your console instance instead).
The final update requires a bit more of a workflow change within Nexpose or InsightVM. Because an asset exists in these tools in the context of a site, we must have the connection creating assets into a site. You’ll first create a new site for AWS assets and send all assets from this connection into this site. If all of your assets exist in one VPC or a series of peered VPCs, you can do all of your scanning with a single engine in this site and schedule those scans within this site directly. If, however, you utilize one engine per VPC or other grouping, you will need to split these groups out for scanning. Simply leverage the VPC ID custom tags we’ve imported automatically onto all AWS imported assets to create asset groups; you’ll use these asset groups to create additional sites for scanning, setting the appropriate scan engine in each site.
Once you have made these changes, you should see assets populating into your new site within a few minutes along with any metadata tags you have chosen to import with them. You’ll be able to leverage all of your familiar asset and site level workflows on them—such as adding or removing tags, running scans, or setting up automated actions—with significantly reduced resource overhead.
Are you ready to save time on your vulnerability management processes? Try the AWS asset import capabilities within InsightVM today. Not a customer? Download a free 30-day trial of InsightVM today.