inventory is your bedrock to build everything else on top of

(This is an incomplete draft I’ve had for a while now. I don’t think I’ll ever complete it, but I didn’t want to lose it or keep it as a draft, so here it is.)

Daniel Miessler has a great article up: “If You’re Not Doing Continuous Asset Management You’re Not Doing Security.” You honestly cannot dislike that title, and the article itself is full of the points enlightened security folk should already have in their heads.

There’s a reason the top 2 controls in the CIS Top 20 Critical Security Controls are all about inventory. It drives every other thing you do in security, and without it, you’re managing by belief and never really sure if you’re being effective or not.

There are many different ways to tackle inventory, but here are some of the common ones:

  • workstation-class devices – This is usually one of the easiest to handle, since the team responsible for workstation procurement likely has an inventory of what they have in order to please customers. Being able to tap into this inventory list, or at the very least view it, is essential. For instance, how do you know you have Antivirus or endpoint protection on every workstation? You have to true that up with the inventory list. Think about the question, “How would I know something is missing security control XYZ?”
  • mobile devices (on your network and/or company-owned) –
  • servers – Typically, one team manages workstations and another team manages the servers. This team should have a handle on some beginnings of an inventory system due to licensing needs, storage/compute resource needs, and other OS-specific collections such as Active Directory or patching coverage. But the same question applies herre, “How would I know something got missed in inventory?” Or in the case of a largely Windows environment, “How do I find a new non-Windows assets that is stood up without notice?”
  • networking assets – This could include diagrams of the networks, both logical and physical when needed, for both wireless and wired networks. If the networking team manages it, it should be in this group.
  • all other network devices – This covers all the other things not nicely slotted into the above categories, like appliances or IOT. This also covers unauthorized device discovery. Essentially, if something is on the network, it needs to be found and known.
  • the cloud – The cloud is often a different beast, especially when consumed dynamically with assets coming on and off as demand moves. Worst case, you go through all other steps above over again with “cloud” in the front of it.
  • internal information systems/sites – This is about knowing the information systems that your business and users consume, which often comes in the form of internal websites, but could be other tools and systems. Largely this is defined by things that store/handle data.
  • software and applications – A huge endeavor on its own, but nonetheless important to know the software and applications in use and needed (and hopefully approved and tracked).
  • external attack surface/footprint – This is what attacks can see and will target; high risk and high priority assets and paths into the organization. This isn’t just Internet-borne, either, but could come in through other weak links such as wireless networks or VPN tunnels.
  • vendors – A good risk management program will have an inventory of all official vendors, which will fuel risk reviews and inform security of what is normal.
  • third-party services hosted elsewhere – What services does the business and its users consume that you don’t strongly control? This likely will still impact account management and permissions, data tracking, and evaluation of those services since you have some measure of intrinsic trust in them which is a potential risk for you.
  • critical business systems – This could be considered a little advanced, but it’s about knowing what’s really important to the business, which informs risk priorities, spending, and other activities like BCP/DR.
  • data/critical data – You can’t secure data if you don’t know where it is, and have some idea on what data is more important than others. Yes, this one is difficult outside of narrow compliance definitions (aka all data vs just credit card data). Honestly, this bullet item should be a top level category in itself.
  • authentication stores – This is about knowing what accounts you have, where they authenticate against (are stored), and what your users and systems actually use to do things.

There are different methods to find this out:

  • process/documenting – This is the default method shops will use to track inventory. If someone stands up a new box on the network, they update some inventory sheet or make sure they follow some checklist to include the new asset in something else (adding it to monitoring, patching, or joining a domain). This is a trust exercise, as you need to trust that every team member follows the process and every process is all-encompassing. This includes decommissioning assets as well. This should also include the assignment of ownership: who in the company is ultimately responsible for this asset?.
  • active/finding – Most of the time, security should assume the worst (trust, but verify), which would be finding assets that are weird exceptions or just get missed in the normal process. Active inventorying means looking out onto the network and scanning it, finding assets, identifying them, and pulling them back into visibility/compliance. The opposite is true as well, you want to find assets that aren’t meant to be there!
  • passive/watching – There are also passive techniques to find devices, such as watching all network traffic or alerting (and even blocking) unauthorized assets from accessing the network. This is still a fallible control, but it is part of the puzzle of knowing what is on a network.

There are a few caveats to the above. First, it’s not 100%; there may be a “bump-in-the-wire” or other passive device on the network (think a network tap just collecting data). There are also device peripherals (mice, keyboards, headsets, readers of various types…) Tackling this is a bit advanced. Second, especially with the active methods, this needs to be done continuously, or the controls need to be continuously active. If you do active scans once a day, an attacker or insider could still turn on a device, do whatever, and turn it off in time for the next scan. Handling these windows is why we practice continuous improvement and defense in depth and why we map out maturity plans.

And Miessler includes 5 questions that drive the measurement of a security teams based on how they answer them:

  1. What’s currently facing the Internet?
  2. How many total systems do you have?
  3. Where is your data?
  4. How many vendors do you have?
  5. Which vendors have what kind of your data?

Leave a Reply

Your email address will not be published. Required fields are marked *