Since I started working on Rapid7's Information Security team, I've had firsthand experience with what is arguably the hardest part of vulnerability management: Creating and updating a complete inventory of your assets and their vulnerabilities. While you'll never be able to achieve perfection in this regard, Adaptive Security in Nexpose makes it significantly easier for InfoSec teams to improve their current vulnerability management program with automation and orchestration.
For my team, Adaptive Security's “New Asset” and “Known Asset” triggers provide us new ways to get up-to-date vulnerability data about remote assets that rarely connect to our corporate networks. While experimenting with these triggers in my Adaptive Security workflows, I've come up with some optimal ways to deploy them that I figured would be worth sharing with our customers.
You might not have all of these prerequisites in place (e.g., Scan Engines dedicated for Adaptive Security scans), but hopefully being able to use some of them will put you and your team in a better position to leverage Adaptive Security's New Asset and Known Asset triggers.
Create Discovery Connections
This is necessary for Adaptive Security to use asset-based Triggers. For this blog post I'll be focusing on use cases involving DHCP Dynamic Discovery.
Enable Asset Linking
When known assets come back online after being disconnected from your corporate network for awhile, they'll likely have different IP addresses over time. Asset Linking allows you to maintain one record for an asset that has multiple IP addresses assigned to it throughout its lifecycle on your corporate network.
Create new Static Sites dedicated to Adaptive Security scans
Think about this scenario: you have multiple employees that regularly travel to remote offices. You also have Static Sites for each remote office that run on a regular schedule. If you use Adaptive Security's “Known asset” Trigger with the “add to site and scan” Action, and you use your existing Static Sites, you run the risk of cluttering your Static Sites with these traveling assets. The next time your Static Site's scan runs, it will try to scan assets that Adaptive Security added to the Static Site Asset scope. Chances are those assets aren't actually in that Site anymore, so your Engine will be wasting precious time and resources.
These dedicated Sites also give you the ability to see Adaptive Security's historical scan activity. Likewise, it provides opportunities for automatically tagging assets that Adaptive Security has scanned.
Use Scan Engines dedicated to Adaptive Security scans
This might be the hardest prerequisite to fulfill, but it helps make sure Adaptive Security doesn't overload an existing scan engine that's running a scheduled scan, thus minimizing scan failures.
Here's an example of Site Configuration details for Static Sites dedicated to Adaptive Security “Known Assets” scanning:
- Name: Austin DHCP – Known Assets (AS)
- Custom Tags: Stale
For the “Known Assets” use case, I use this to get an idea of which assets don't touch our corporate network frequently to make sure they receive patches and updated security configurations in a timely fashion from our patch management solution.
- Assets: 127.0.0.1
When defining these dedicated sites, you need to put in an IP address so the Site can be saved. Since we won't be running this site on a recurring schedule, put in a “dummy” IP. Also it's better to put in 127.0.0.1 in case you or another Nexpose admin ever “accidentally” clicks the “Scan Now” button for the site). Here's an example:
- Engines: Austin (Adaptive Security)
- Schedule: None
Since Adaptive Security will be adding assets individually to the Site configuration and then automatically initiating scans of those individual assets, we don't need the Site to ever be scanned on a schedule
And here's an example of the Automated Action details for “Known Assets” scanning:
Hopefully this helps you and your team improve your vulnerability management programs. I'm interested to see if anyone else finds this useful or has other tips to make these use cases work better, so please leave your comments and feedback below.