Skip to content ↓ | Skip to navigation ↓

Today’s post is all about Control 1 of the CSIS 20 Critical Security Controls – Inventory of Authorized and Unauthorized Devices.  Here I’ll explore the requirements I’ve parsed out of the control (I used the PDF version, but the online version is here) and offer my thoughts on what I’ve found. 

Method And Format Explanation

There is nothing particularly complicated about my method of looking for requirements.  I’ve looked through the following sections of Control 1:*

  • How to Implement, Automate, and Measure the Effectiveness of this Control
  • Procedures and Tools to Implement and Automate this Control
  • Control 1 Metric
  • Control 1 Test

The other sections didn’t contain information that felt like requirements to me, so I’ve not analyzed them here.      In all, I’ve identified 39 requirements that should be met to fully meet the intent of this Control. **  This post (and those that follow, but pertain to other CSC controls) will have three main sections:

  • Key Take Aways: If I can, I’ll boil my analysis down to the most important three to five concepts.  As  more CSC controls are covered, I expect patterns to be discovered.
  • Potential Areas Of Improvement: Where I feel there could be areas of improvement with respect to the Control, I’ll say so here.  I’ll try to keep this, again, to between three and five improvements.
  • Requirement Listing: This is a numbered list containing each requirement, its description (most often taken verbatim from the PDF document), and my notes pertaining to the requirement.
I’ll probably not repeat any of this method and format explanation again, but I will reference this post in subsequent posts.  If you have any suggestions for improvement, please let me know by commenting below or giving a shout out on Twitter (@adammontville).

Key Take Aways

  1. Don’t do it all at once.  Having an accurate inventory is undoubtedly important, but meeting the full spirit of this control is more than just standing up a process.  It involves orchestration of several business processes, and the intricacy of this orchestration is likely to increase with the size of the organization.
  2. Take these requirements to your vendors.  If your tool vendors aren’t aware of these requirements, the data integration between business processes, which likely rely upon disparate tools, will be your burden.
  3. Look for standard data formats to be supported in tools.  The tools you have today should support standard data formats.  The tools you acquire in the future, should support data formats listed here.  In particular, the Asset Identification specification, or one that is well-aligned with the model it puts forward, should be high on your list.
  4. Start Small And Basic.  This Control is process heavy and will benefit from automation, but if you move too big too fast, you’re likely to end up in the integration ring of hell.  If I had to do this, I would not start with NAC or bothering with any automation in terms of access.  Instead, I would start by getting the discovery and inventory maintenance down pat and integrating that with my incident detection and response system (in the sense that a system is people, process, and technology).

Potential Areas Of Improvement

  • Use consistent terminology consistently.  I found myself asking rather pedantic, but important, questions about the intended meaning of words.  The term “system” is a great example.  Sometimes it’s used when it really means a tool or technological component, such as an Intrusion Detection System like, Snort.  Other times, it’s used in a more comprehensive sense to encompass people, process, and technology.
  • Level Of Abstraction.  There’s one case that really stood out to me, and perhaps I’m picking a nit, but this Control really assumes an IP-based network.  Yes, an IP-based network is important to consider and likely covers 80 percent (at least) of the problem space, but some of the more critical problem domains may not use IP-based networks exclusively.  SCADA systems (about which I admittedly know little), may use different protocols and have different requirements.  It would be nice to see some level of abstraction to cover these edge cases, even if the details stick to IP networking.
  • Explain Why.  In a couple of instances recommendations are made without any real explanation as to why.  The better example is in mapping information to assets.  This will help identify “critical” assets, but why?  Presumably, it is because a priority approach can be taken to address ensuring you have inventory accuracy for the assets that store, process, and/or transmit the most critical information to your organization.
  • Dependencies.  Throughout this Control (and I don’t expect this to be any different to others we’ll explore) there are allusions to processes that must exist for the Control to be successful.  Using the information mapping example again, consider that some information classification scheme has to be determined and applied before the criticality can be understood, which is what makes mapping information to assets worth the effort.  I do not recall seeing this particular dependency mentioned, nor do I believe it’s covered elsewhere in the 20 CSCs.

Requirement Listing

  1. Description: Deploy an automated asset inventory discovery tool and use it to build a preliminary asset inventory of systems connected to an organization’s public and private network(s).
    • Notes: This requirement is a one-time thing (continuous discovery is covered later in this control).  Here, the intent is clearly to establish some baseline of asset inventory for your organization.  Use NMAP, something else, any tool you can that will help you get a quick and reasonably accurate account of what’s on your network.  This requirement underscores the fact that, without an accurate and precise understanding of assets under control, the rest of what your Information Security Management System could be considered suspect.
  2. Description: Both active tools that scan through network address ranges and passive tools that identify hosts based on analyzing their traffic should be employed.
    • Notes: This requirement is more of a corollary to the first and seems to bridge between the initial effort of scanning the network and the ongoing requirement (mentioned later) to discover assets.  Here, they’re simply recognizing that more than one discovery method should be used to maximize effectiveness.
  3. Description: Deploy DHCP Server logging, and utilize a system to improve the asset inventory and help detect unknown systems through this DHCP information.
    • Notes: Following the first two requirements is a specific mention of a really great source of discovery information – DHCP.  This, of course, probably won’t help in some data center environments that don’t use DHCP, but where DHCP is leveraged, it’s a great way to passively detect new IP hosts in your enterprise.  I believe what they’re suggesting is that most enterprises have DHCP services, and most, if not all, DHCP services can be configured to generate logs, so this is an easy source of discovery information.  Use it.
  4. Description: All equipment acquisitions should automatically update the inventory system as new, approved devices are connected to the network.
    • Notes: This seems like a no brainer, except for the one pesky word ‘automatically.’  I haven’t been in ops for a while, but the last time I was there was no integration with an authoritative asset inventory and the asset acquisition process.  Perhaps things have changed, but if they have, the changes don’t seem to have made their way to the security solution space just yet.  Then, this is an area where each enterprise would be expected to come up with a solution that is unique to their needs, yet strikingly similar to the needs of many other enterprises.  It seems like an area of potential wasted effort.  Whether integration happens out of the box or is done by each enterprise, some data model representing an asset would be helpful.  In this case, because we’re dealing with ‘assets’ I’m looking at the Asset Identification specification first published by NIST as a potential solution.
  5. Description: A robust change control process can also be used to validate and approve all new devices.
    • Notes: This is a mainstay for many large enterprises, and is listed as a “quick win” in the 20 Critical Security Controls.  A ‘robust’ change control process seems like something that suits larger, more mature enterprises than it does many of the little guys.  Perhaps that in itself tells a story.  Are the 20 Critical Security Controls aligned to larger enterprises?  If so, is there a driving force behind that choice of alignment?  If not, then what are smaller guys supposed to do to arrive at ‘robust’ change management solutions – especially the start ups that have little or no time for security, much less change management?
  6. Description: Maintain an asset inventory of all systems connected to the network and the network devices themselves recording at least the network addresses, machine name(s), purpose of each system, an asset owner responsible for each device, and the department associated with each device
    • Notes: They’re overloading the term system a bit too much.  Do they mean computing devices here?  I’d like to see some alignment with the Asset Identification specification, especially after some of its shortcomings are addressed. It is unfortunate that there is not a glossary of terms listed in the 20 Critical Security Controls.  There should be at least a reference to one authoritative source, whether that be the SANS glossary, the IETF Internet Security terms (RFC 4949), or CNSSI 4009, or NIST’s version.”
  7. Description: The inventory should include every system that has an Internet Protocol (IP) address on the network, including but not limited to desktops, laptops, servers, network equipment (routers, switches, firewalls, etc.), printers, storage area networks, Voice Over-IP telephones, multi-homed addresses, virtual addresses, etc.
    • Notes: This requirement makes the assumption that the network is and IP network and, by extension, leverages TCP and/or UDP among other protocols.  While this may well be the case for the majority of organizations, other networks should be considered (perhaps as an advanced requirement).  Consider SCADA systems, for example, a railroad with electronically (and potentially remote) controlled switch and signal systems.  They probably use something more lightweight than Internet Protocol routing, and may use some point-to-point protocol.  I would still classify a rail switch as an asset, and therefore something that should be kept in the inventory – especially if it is, in some way, routable or reachable by remote means.”
  8. Description: The asset inventory created must also include data on whether the device is a portable and/or personal device.
    • Notes: This requirement is starting to get into the qualities or attributes of a given asset.  What qualifies as a ‘personal’ device?  What qualifies as a ‘portable’ device?  I think we’d all align on the obvious choices, but is the controller for a remote-controlled switch engine something that qualifies as a portable device?  Does it meet other criteria to be considered an ‘asset?’  This also begs the question (again) of what data model could be used to represent these attributes.  And, I still think the Asset Identification model is a great start.
  9. Description: Devices such as mobile phones, tablets, laptops, and other portable electronic devices that store or process data must be identified, regardless of whether or not they are attached to the organization’s network.
    • Notes: I have a small nit about this requirement in that it left out the word ‘transmit.’  Otherwise, this is a fairly straightforward requirement that is only saying that, no matter what the device or when the enterprise can actively ‘see’ it, it needs to be accounted for.  It seems reasonable to assert that such accounting must be as good as the last active contact made with the asset.  There may be some creative ways to understand the ‘last known contact’ beyond the obvious ‘connected to network’ case.  It might be reasonable to interrogate a mail server for the last time that asset retrieved mail, as one example.
  10. Description: Make sure the asset inventory database is properly protected and a copy stored in a secure location.
    • Notes: This requirement is essentially saying that the inventory database should be subject to the control framework with which this control is associated.  I’m not sure why it is required, other than, perhaps, to lend some advice to the prioritization of file protections in the enterprise.
  11. Description: In addition to an inventory of hardware, organizations should develop an inventory of information assets that identifies their critical information
    • Notes: The really important piece here is that we have the need to identify data which embodies specific information.  This data is considered an asset, and the information ought to be subject to an information management process, which should include classification.
  12. Description: Information asset inventory should map critical information to the hardware assets (including servers, workstations, and laptops) on which it is located.
    • Notes: Here is an instance where assets are considered composite in a way.  Consider that the mapping of information to hardware is an asset to asset relationship.  More accurately, we can indicate that a computing device contains data which represents information (or the information resides on a computing device).  Again, the Asset Identification specification treats assets as composites in many cases, and appears to be a suitable representation.
  13. Description: A department and individual responsible for each information asset should be identified, recorded, and tracked.
    • Notes: Here we see relationships between different types of assets: computing devices and information to humans and organizations of humans (departments).  An effective asset inventory system will be able to account for these relationships, and an effective asset management process will leverage that ability.
  14. Description: Deploy network level authentication via 802.1x to limit and control which devices can be connected to the network.
    • Notes: The only technology architecture I can think of for this requirement is that which is published by the Trusted Computing Group (and adopted by the NEA Working Group of the IETF).  As an aside, it seems that, with the exception of specifications published or directly sponsored by US Government entities, names were left out.  Here, I would say find equipment that speaks in the languages of TCG.
  15. Description: 802.1x must be tied into the inventory data to determine authorized vs. unauthorized systems.
    • Notes: The big implication here is that the Asset Inventory System needs to be integrated with the port-based NAC controls the enterprise has in place.  As far as I know, the TCG formats and protocols do not speak Asset Identification, but they may speak something else that can be mapped to the Asset Identification specification.  Additionally, it seems warranted that the access control lists managed by a TCG Policy Decision Point should be something understood by the Asset Inventory System.  This is another point of integration that would be best performed outside of enterprises, but that will likely be performed inside enterprises.
  16. Description: Deploy network access control (NAC) to monitor authorized systems so if attacks occur, the impact can be remediated by moving the untrusted system to a virtual local area network that has minimal access.
    • Notes: Here, I’m not sure why the NAC system would be doing the monitoring – other systems are better for monitoring.  Consider the Security Configuration Management (SCM will be covered in Critical Controls three and ten) profile of a given asset.  If an attack is underway (again, something the NAC won’t really be responsible for detecting), then the SCM profile may change and be assessed dynamically.  When that happens, if the profile for the target asset is unacceptable, then the NAC should be engaged.  I think that articulates the spirit of this requirement, and I believe that this requirement may end up leading NAC providers and enterprises to scope creep.
  17. Description: Create separate VLANs for BYOD (bring your own device) systems or other untrusted devices.
    • Notes: I could use a little help here, I think, because there must be some network design and implementation process that supports this requirement – I just don’t know what that process is at this point (anyone know of a good ITILv3 course or online tutorial out there?).  I’m not all that certain that VLANs are that effective against a determined adversary.  Still, it seems that having an Information Security Management System is important in this case, because the BYOD issue involves technology, process, and procedure.  It’s great to have a VLAN, but without appropriate technical and administrative measures to ensure that your people know that BYOD doesn’t mean bring your own doobie and that they shouldn’t connect BYOD devices to the wrong network, having that VLAN won’t be very effective.
  18. Description: Utilize client certificates to validate and authenticate systems prior to connecting to the private network.
    • Notes: Wow this requirement is huge.  It’s such a simple sentence, but it’s really huge.  Installing and managing a Public (to your organization) Key Infrastructure is not necessarily a piece of cake – there are a lot of gotchas here.  And, while there are certainly other important processes, I listed the Certificate Enrollment Process here because it seems the most critical overall (assuming your key generation and lifecycle are under control for your root).  All that said, some platform families make extensive use of what should be better known as application-specific PKI under the hood.  If this requirement is really driving at this, then it could be rewritten to be more specific.  If it’s really looking for organizations to stand up and manage a Certificate Authority within their organization, then this is, as I said, a huge requirement.
  19. Description: Organizations must first establish information/asset owners, deciding and documenting which organizations and individuals are responsible for each component of a business process that includes information, software, and hardware.
    • Notes: This additionally requires some level of business process maturity for the organization.  If you’re going to go around identifying information/asset owners based on some knowledge of a given business process, then that process needs to be documented or understood on some level.  The larger the organization or the more complicated their business is likely to mean the more important documented business processes are.  I’ve worked for a few different types and sizes of organziations in my career, and there has been only one that has attempted to document their business processes in a manner that would enable efficient assignment of ownership to assets: The Department of Defense.  All of the other organizations rely on a more tribal method of understanding business process and asset ownership.  There needs to be some middle ground that would make this requirement achiveable without sacrificing its intent, which is really to ensure that someone in the organization is held accountable for its assets.”
  20. Description: In particular, when organizations acquire new systems, they record the owner and features of each new asset, including its network interface media access control (MAC) address and location. This mapping of asset attributes and owner-to-MAC address can be stored in a free or commercial database management system.
    • Notes: This is a refining requirement of the first and provides insight as to what information should be collected about a given computing device when it is acquired (I’m assuming computing device because it’s difficult to find a MAC address for a human).  At first glance, the Asset Identification specification appears suitable for use here.
  21. Description: Use tools to pull information from network assets such as switches and routers regarding the machines connected to the network.
    • Notes:  What tools?  I’m assuming they’re talking about tools that speak SNMP and possibly OVAL.  Perhaps this was not intended to be a requirement, but if that’s the case it wasn’t made very clear in the 20 CSCs what was intended to be a requirement and what was not.
  22. Description: Using securely authenticated and encrypted network management protocols, tools can retrieve MAC addresses and other information from network devices that can be reconciled with the organization’s asset inventory of servers, workstations, laptops, and other devices.
    • Notes: I’m not really happy with this requirement.  I would contend that this is about reconciliation of asset attributes to account for drift.  An IP address can change over time in a DHCP environment, and when that happens a known asset might appear as an unknown asset.  Of course, if you can connect to the device securely in the first place, then it’s likely a known asset (this is really part of my issue – I think the communication security requirements are better covered elsewhere in the control framework).
  23. Description: Once MAC addresses are confirmed, switches should implement 802.1x and NAC to only allow authorized systems that are properly configured to connect to the network.
    • Notes: This is a very important requirement because it clearly indicates that MAC addresses should be, in some way, validated.  Previous requirements indicate that MAC addresses are pulled using semi-automated technical checks.  But, what does it mean to validate a MAC just before creating a whitelist of authorized systems to connect to the network?  Actually, there’s one more requirement tucked in here: “properly configured” systems.  This is clearly showing some regard for Critical Control 3, though I would argue that it’s not plausible (as the TCG discovered) to push full configuration settings over low-bandwidth 802.1x.  This leads me to believe that the 20 CSC would be better off recommending specific technologies or rewriting this and potentially other requirements to be clear about its intent.  I think it’s OK for a control framework to endorse a given technology, provided the technology is relatively open and available to most everyone (enterprises and vendors alike).
  24. Description: Effective organizations configure free or commercial network scanning tools to perform network sweeps on a regular basis, sending a variety of different packet types to identify devices connected to the network.
    • Notes: Before such scanning can take place, organizations should verify that they have adequate bandwidth for such periodic scans by consulting load history and capacities for their networks
  25. Description: In addition to active scanning tools that sweep the network, other asset identification tools passively listen on network interfaces looking for devices to announce their presence by sending traffic.
    • Notes: The term ‘system’ is overloaded here based on commonly applied terms in the industry.  In some sense, a NIDS is a piece of software, but often it is configured as parts comprising a whole, which is more correctly called a ‘system.’  Consequently, NIDS is listed both as a tool and as a technical control.
  26. Description: Such passive tools can be connected to switch span ports at critical places in the network to view all data flowing through such switches, maximizing the chance of identifying systems communicating through those switches.
    • Notes: This is really a recommendation to acquire network devices with span ports.  If I were to create a checklist for Critical Control 1, I would ensure that device acquistion with span ports was one of the items.
  27. Description: Whether physical or virtual, each machine using an IP address should be included in an organization’s asset inventory.
    • Notes: The context for this requirement is in warning about inventory churn due to appearing and disappearing assets in disconnected and/or virtual environments.  To effectively handle this churn, we might consider an additional requirement where virtual hosts are integrated with the asset inventory system.  When a guest changes state in the virtual lifecycle, the asset inventory system should know about it.  Otherwise, it’s far too easy for something to happen with no or little knowledge of the ocurrance. Audit logging can help here.
  28. Description: The system must be capable of identifying any new unauthorized devices that are connected to the network within 24 hours.
    • Notes: The overarching Asset Management Process is one that needs to include facets of asset discovery.  Without asset discovery, this requirement simply cannot be met.  At the same time, there is some requirement hidden here with respect to having a very good understanding of what new assets are “business as usual” in a virtual environment.   I cannot recall the specific use case, but do remember that configuration checks weren’t performed on a certain class of virtual guest OS because of its expected lifetime – minutes – not days, weeks, or months.  In that type of environment, your discovery mechanisms probably won’t keep up, and even if they did, how would they be able to tell good from bad?  This appears to be another call for integration of virtual host environments with the larger asset inventory system and the asset management process.
  29. Description: Alerting or sending e-mail notification to a list of enterprise administrative personnel.
    • Notes: In this context, the asset management process needs to capture asset owners so that appropriate personnel can be notified appropriately.  Again, using the model represented by the Asset Identification specification could be useful.
  30. Description: The system must automatically isolate the unauthorized system from the network within one hour of the initial alert
    • Notes: This is another call, or perhaps an underscore, for the asset management process to be integrated (at least able to communicate with) the required port-based NAC system.
  31. Description: Send a follow-up alert or e-mail notification when isolation is achieved.
    • Notes: Part of an asset management process might include assignment of owners which should include alerting contexts.  When a given system needs to generate an alert about a given computing device, for example, the asset inventory system needs to provide the information about whom to alert.  This should be brought about in the asset management process.
  32. Description: Every 24 hours after that point, the system must alert or send e-mail about the status of the system until the unauthorized system has been removed from the network.
    • Notes: This requirement is really one that could be renamed: Nag.  The system needs to nag those accountable for issues until those issues are settled.  Provided false positives are kept to a tolerable level, this is an excellent requirement to have – out of sight, out of mind, so keep the issue squarely in focus.
  33. Description: The asset inventory database and alerting system must be able to identify the location, department, and other details of where authorized and unauthorized devices are plugged into the network.
    • Notes: With automated tools, notification about an unauthorized asset connected to the network can be sent within two minutes and isolation achieved within five minutes.
  34. Description: To evaluate the implementation of Control 1 on a periodic basis, the evaluation team will connect hardened test systems to at least 10 locations on the network, including a selection of subnets associated with demilitarized zones (DMZs), workstations, and servers. Two of the systems must be included in the asset inventory database, while the other systems are not.
    • Notes: Note that testing this control addresses only the primary case of connected assets, but does not address the previously identified issue of asset churn in disconnected and/or virtual environments.  For the rest of the requirements, I’ll not comment explicitly other than to say that it’s goign to take a bit of effort to test these things, and your ops people are likely to be those who are burdened.
  35. Description: The evaluation team must then verify that the systems generate an alert or e-mail notice regarding the newly connected systems within 24 hours of the test machines being connected to the network.
    • Notes: None.
  36. Description: The evaluation team must verify that the system provides details of the location of all the test machines connected to the network.
    • Notes: None.
  37. Description: For those test machines included in the asset inventory, the team must also verify that the system provides information about the asset owner.
    • Notes: None.
  38. Description: The evaluation team must then verify that the test systems are automatically isolated from the production network within one hour of initial notification and that an e-mail or alert indicating the isolation has occurred.
    • Notes: None.
  39. Description: The team must then verify that the connected test systems are isolated from production systems by attempting to ping and use other protocols to access systems on the production network and checking that connectivity is not allowed.
    • Notes: None.

Other Controls Reviewed In This Series

Footnotes

* By the way, this is the same method I’m planning to use for evaluating the other controls, unless something changes along the way.

** I plan to reference the numbered control as “Control” with a capital ‘C’ rather than say “Control x” each time I need to reference the control I’m talking about.

Editor’s Note: This article was written by a former contributor to The State of Security who now resides with a non-profit group with an excellent reputation. We thank him for his opinions and perspective, and wish we could acknowledge him directly for his outstanding efforts on this series.