Utilize an active discovery tool to identify assets connected to the enterprise’s network. Configure the active discovery tool to execute daily, or more frequently. (CIS 1.3)
Use DHCP logging on all DHCP servers or Internet Protocol (IP) address management tools to update the enterprise’s asset inventory. Review and use logs to update the enterprise’s asset inventory weekly, or more frequently. (CIS 1.4)
Use a passive discovery tool to identify assets connected to the enterprise’s network. Review and use scans to update the enterprise’s asset inventory at least weekly, or more frequently. (CIS 1.5)

One of the biggest differences between CIS and other security frameworks is how concrete it is. ISO may say, “An organization should identify assets relevant in the lifecycle of information and document their importance” and let each subscribing company figure out the best way to do it. CIS tells you exactly how, almost specifically enough for an engineer to cost out and build.

For a long time, ISO, CoBIT, and ITIL has been preaching a good asset inventory (ISO 27001 8.1.1, CoBIT BAI09, and Asset Management, respectively). Many big organizations have responded with manual control: strong ITIL frameworks and change management and making everyone register their assets before they can be created. Such approaches can slow your organization down, adding friction to otherwise boring processes and generating resentment within IT for “all the red tape.” Ultimately, people figure out ways around that red tape, doing the least work possible or finding ways of creating assets without registering them. Then security or change management or Enterprise Architecture notices that the data quality is bad in the inventory or there are missing assets, and fights back with even stronger rules or more mandatory fields in the asset registration form, which annoys people even more. Often this becomes an evil cycle that builds years-long divisions, mistrust, and resentment between IT and IT governance.

CIS says that this is a crock, and tells you to junk most of this manual approach. Instead, use technical solutions that find all the IT Stuff for you, and report it back to your central inventory. They suggest three approaches, but there are bunches.  You may notice that their listed approaches are all network-based. This lines up with the overall goal of the Inventory of IT Stuff: if it’s talking to other things, the teams consuming your inventory probably want to know about it. Note: this does not totally eliminate manual work. See CIS 1.6: Standard Work for the processes you’ll still have to do.

Most of the methods listed here apply only to infrastructure you manage. If you’ve got SaaS apps and AWS buildouts, only the last two ideas in this post will help.

CIS 1.3

1.3: Utilize an active discovery tool to identify assets connected to the enterprise’s network. Configure the active discovery tool to execute daily, or more frequently.

An active scanner is the easiest to build. It pokes every IP in your network space on common ports to see what responds. This is such a simple technology that it’s effectively free: there are good open-source options, and it comes bundled with other security tools such as vulnerability scanners. The scanner will usually profile each IP based on the open ports. This is wrong about 10% of the time, especially for old AIX boxen or weird IoT gadgets. If you’re handy with linux, you can even hack one together with a cron job that runs nmap and cleans and stores the results.

An active scanner will be less useful the more segmented your network is. If you have lots of little segments dedicated to specific traffic, you’ll have to add extra rules on each of those segments to let your scanner talk into it. Keeping up with constantly changing microsegments will be a lot of work. Even worse, you provide a common point of vulnerability for your whole organization: if someone wanted to bypass all your fancy segmentation rules, they’d just need to crack your active asset scanner. No Bueno. Bottom line: if you’ve got a super-segmented network, just skip CIS 1.5.

  • Standalone: nmap
  • Bundled with network monitoring solutions: Solarwinds, Nagios, Spiceworks, etc.
  • Bundled with vuln scanners: Nexposé, Nessus, Qualys.
  • Probably a bunch of others. Seriously, this is the security equivalent of the free toy that comes in each box of cereal.

A free asset scanner in every box!

CIS 1.5

1.5: Use a passive discovery tool to identify assets connected to the enterprise’s network. Review and use scans to update the enterprise’s asset inventory at least weekly, or more frequently.

A passive scanner costs a lot more, but compensates for some of the segmentation problems and provides much greater profiling accuracy. It connects to central network switches and listens to every conversation. Usually, this means a physical box that plugs into the SPAN port of each core switch. It then builds a big map of all the conversations in the form of a list of sources and destinations. Each source and destination is associated with historic conversations that can profile the asset. This can capture realities that an active scanner may not see:

  • If the thing is serving a lot of authentication requests and handing out KRB5 tickets in an Active Directory 2012 R2 -compliant manner, it’s pretty certain that it’s an AD controller running 2012 R2.  An Active scanner is only going to see open ports on some combination of 53, 88, 389, 135, 445, 636, 3268, 3269, and maybe some others.  Not as certain.  
  • If the thing is an SMB fileserver but has strict firewall rules to only talk to certain hosts, it may ignore the Active Scanner. The Passive scanner will notice all the SMB traffic, and successfully profile it.
  • If the thing does a massive amount of https traffic but the headers are for a variety of domains, either it’s a webserver or some kind of proxy/load balancer. In either case, the active scanner would never have known about the different apps that it hosts.

Passive scanners do not need to decrypt traffic, though some like to. Most of their logic comes from metadata, such as header information and typical initiation sequences and packet lengths for common conversations.

Passive scanners are great at discovering stuff behind NATTed segments. Because they watch the conversations, they can often determine different sources behind the NAT. However, if conversations stay inside the protected segment and never hit the core switch, the passive scanner will never know about them or the associated assets. As with the active scanner, if you have lots of microsegments, the passive scanner won’t do a good job of finding stuff in them.

  • Solarwinds, NetMRI, Gigamon, Qualys, and Nessus each have one baked into a larger solution.
  • Zeek/Corelight may be configured to provide this, but would need some development to achieve. Bonus: Zeek is free.

CIS 1.4

1.4 Use DHCP logging on all DHCP servers or Internet Protocol (IP) address management tools to update the enterprise’s asset inventory. Review and use logs to update the enterprise’s asset inventory weekly, or more frequently.

In many networks, some assets change IPs pretty regularly. If the assets in your inventory are primarily identified by IP (as they would through barebones active or passive scanners as above), you’re going to find that each of those things (IPs) regularly disappear and reappear. At worst, a windows laptop may suddenly turn into a mac, go dead for 5 months, then become a smart TV, and back again to a windows laptop. The customers of your inventory are going to hate this, because they need to know what’s going on with the true thing behind the IP. Is it truly off? Is it really on Windows XP?

CIS recommends slurping in DHCP logs to help with this problem: if DHCP servers are handing out the IPs, those logs can track changes in IP across devices to “reverse” the traveling IP problem.

DHCP is also often a first step step into a network if you aren’t using NAC. The logs provide some record of connection, but this method of discovery is less complete, harder to build, and easier for a malicious device to fool than an Active Discovery engine.

I’m unconvinced that this is a valuable and effective approach. I’d skip it because:

  1. I’ve yet to see a turnkey solution that uses DHCP logs to eliminate the travelling IP problem.
  2. When I ask likely sales reps about DHCP logs for asset discovery, I get blank looks. This tells me that almost nobody is doing this.
  3. This problem is solved much more easily via other methods (see below).
  • Rapid7 seems to have an ingestion script for noticing new assets based on DHCP logs. I don’t know how well it works, especially for solving the travelling IP problem.

If you have wisdom to impart on this control, please tell me.  

Manage by name

This isn’t so much a method of discovery as a pro tip that can make your discovery less painful. Use shortname or FQDN as the primary identifier of an asset in your Inventory of IT Stuff. This will be more useable and sensible to your customers, and avoid problems with traveling IPs, proxies, and multiple-hosts-on-a-box problems. Active Directory computer management almost forces you to do this anyway for machines under its control.

The challenge comes from convincing the network team to register DNS for all their stuff: nobody names the management port on their switches. There’s also VoIP phones, IPMI interfaces, timeclocks, smart TVs in your lobby, IP cameras, and IP sensors that have no one has named before. You’ll want to do this because it’ll make your customers more confident in your inventory if there are no direct IPs in the primary address field. You can do it. At worst, just write a random-naming script and feed it all the IPs that they tell you about then paste the results into your DNS. Address drift and oddness by generating regular reports of the names that get profile changes, and hold the device owners accountable (see CIS 1.6: Standard Work).

If you use DHCP, you’ll also want to make sure the DNS stays accurate.  AD also does a pretty decent job of this, but if you’ve got a lot of BYOD, you may need another system to auto-name things and keep track of IP changes. Sometimes DHCP reservations can be an easy way to get this done (again, AD does it, though I’ve had bad experience with the correctness of their reverse DNS in DHCP scopes). Dynamic DNS may be a shim to help handle problematic stuff. Talk to your network team. If you are also the network team and want help to do this, I’d be [happy to talk to you](mailto:sales@simple-salt.com?subject=help me tie down wandering IPs).

  • Active Directory

Manage by NAC

Network Access Control has been the holy grail of IT Stuff Management and Network Security teams for at least 30 years. For about 25 of those years, it has been really annoying to manage, especially because when it fails everything explodes. There have been buckets of competing standards and partial implementations that go from barely-checking-the-box-but-not-gonna-actually-stop-any-badness all the way to everyone-is-super-sure-that-only-the-right-people-can-connect-but-a-network-blip-is-going-to-boot-you-for-a-week.

We will talk more about NAC strategies in CIS 13.9: NAC. For now, know that certificate-based device auth (802.1X EAP-TLS) is the way to go for almost everything.

Once it’s built, discovery is easy: you just regularly slurp out the current assets from the NAC into your Inventory of IT Stuff, probably with an API.

NAC will take some time to set up, some dedicated network people to maintain, changes to the way new stuff is provisioned, and a substantial monetary investment with the enterprise network equipment vendor of your choice. It’s not as painful as it used to be, but it’s also not for the dabbler.

serious business for sure!

  • Cisco ISE
  • Juniper Pulse
  • Aruba Clearpass
  • Forescout

Dedicated inventories

The idea of an Inventory of IT Stuff is so intuitive to most IT people that you’ll find there’s already bunches of them lying around, built for specific purposes. Active Directory has one. Vsphere has one. Avaya and Cisco and Juniper each have one. AWS and Azure have perfect inventories: that’s how they bill you. A CASB or federator will have inventories of all the SaaS instances you’ve integrated. You can suck out lists of databases/containers/instances in your farm/cluster/VPC pretty easily. Those systems already do a lot of thinking to make sure they know about all the things they manage – why duplicate that effort?

Unfortunately, most of these vendors don’t have prebuilt adapters to automatically pipe their asset lists into the major CMDB systems. This is one reason that using a data team to manage your inventory is an advantage – they already probably have people who breathe APIs and ETL who can build and maintain those flows.

  • Active Directory, Satellite
  • any cluster management (vsphere, RHEV, kubernetes, Hadoop, Sun Grid Engine, database farms, Openstack, puppet, …)
  • any decent IaaS or PaaS platform (AWS, Azure, DigitalOcean, Rackspace)
  • network flow monitors (AppDynamics, SolarWinds, Lumeta)
  • lots more…

Internet scanners

The biggest gap in all these techniques is that they discover stuff you kinda already know about - things that you host or are in a hosting instance you can look at. What about stuff hosted outside your walls, and nobody has told you about? SaaS apps and weird little websites and single-use S3 buckets and dropbox accounts that small teams in your organization used without telling you?

Some companies will help you with this problem by inventorying the entire internet and telling you the pieces that have to do with you. The most likely assets this service can find are websites.

You can also usually ask the bigger service providers for a list of all accounts registered from an email in your domain, then give someone in IT oversight of those accounts, maybe including a discovery API hook. If you’ve got centralized Accounts Payable, your procurement department may be able to tell you a list of monthly vendors that are IT-ish.

  • RiskIQ Digital Footprint
  • Cycognito (no personal experience, but someone I trust likes them)

Remember

Keep your goal in mind: create and maintain an accurate Inventory of IT Stuff to satisfy your customers.

Do not lie to yourself: it will never be perfect.

Start small and continuously improve: choose one of these methods to populate it, and start talking to your customers to learn the next best way to make it better. Most organizations should start with what’s already in an existing Dedicated Inventory and then augment to address customer needs.

keep swimming!

See other posts for detailed techniques to build and maintain an accurate and dependable Inventory of IT Stuff, including: