The idea of a configuration management database (CMDB) is that it should be able to tell you all the interesting attributes of your environment. As we noted in our earlier article, it’s not hard to imagine that just the right CMDB could be a great help in securing your systems and improving your security posture. In this article we’ll look in more detail at what a Security-Oriented CMDB (SOCMDB) should look like – and why you should care.

No one would think of trying to provide physical security for a college campus without a map of buildings – along with the details of how many doors and windows they have and where hazardous materials are stored. But when looking at security breaches, it’s obvious that many organizations don’t know what computers they have – since 30% of all intruders come in through systems which are not on the books.

Why a SOCMDB?

Guurhart does an excellent job of explaining why you want to use a SOCMDB in your environment in her excellent Peerlyst CMDB post. I’ll repeat her high-level goals here – and add two of my own.

• Prevention – reducing your attack surface. You cannot protect assets you do not know you have. Even if those assets aren’t critical, they provide a great place for attackers to hide out.
• Compliance. Once you know what you have in enough details, now you can automate compliance with best practices. Although compliance-for-compliance-sake can be wrong-headed – it is important to have security hygiene best practices – and to follow them. That’s the heart of compliance.
• Reports and Metrics. You need to know what your problem spots are and be able to track if you’re getting better. Even better – you need make pretty graphs for management that don’t want to or need to know all the gory details, they just want to know the job is getting done.
• Incident Response. When responding to an incident, immediately knowing the configuration of systems and what’s recently changed saves time when time is of the essence.
• Availability. One of the pillars of information security is availability. Since 90% of organizations aren’t monitoring everything, integrating SOCMDB discovery into the monitoring process would help everyone know what they’re not monitoring so they can improve their availability.

SOCMDB Examples

Here are a few examples of how a SOCMDB to further explain why a SOCMDB is a great idea.

• Insecure IoT devices. Perhaps you have a camera that you’re afraid might be part of a Mirai botnet. If your SOCMDB has an up-to-date list of MAC addresses in it, then you can just query your database looking for MAC addresses (and corresponding IP addresses) which have the OUI that corresponds to the devices you’re concerned about [suggested by 1337mark].
• Vulnerable Software Version (patch management). When a new vulnerability comes out, you want to be able to query the database and tell which systems have the vulnerable software installed [suggested by Gurrhart].

SOCMDB Characteristics – How

Now that we know why we want a SOCMDB – let’s see if we can see how it needs to be done to be most effective for a modern SOCMDB. To do that, let’s look at a few characteristics we’d want in such a database. Many of these also line up well with Guurhart’s criteria. Although this is no doubt incomplete, it’s a good starting place.

1. Discovery-based. When humans enter data, it’s often wrong, and soon gets out of date. Given the level of detail below, having humans provide the data is simply not possible.
2. Up-to-date – near real time. Incident response needs data which is up to date within minutes. Incident response simply cannot operate using data that’s days, weeks or months out of date.
3. Automated. The case for better automation in security is well-known. This is perfectly consistent with having the data be discovery-based and always up to date. These things are impossible without great automation.
4. Integration with compliance rules. A SOCMDB needs to have enough information to be able to support comparison against the relevant compliance rules. It needs to be able to either validate compliance rules itself, or integrate with a system which performs continuous compliance validation against applicable compliance standards. These might be based on the IT Best Practices project, external or internal standards or a combination of the above. In addition, if you find you’re out of compliance with your security requirements (as noted below), it’s best to know it before your auditor or your attacker finds out. Knowing in near-real-time that you’re out of compliance is a game-changer in terms of staying in compliance. Experience suggests that staying in compliance is hard – perhaps even harder than getting into compliance.
5. Highly extensible. The only way it can have the information necessary to support automated evaluation of arbitrary compliance rules is if it can easily be extended to discover nearly anything. As a practical matter, it should be open enough to be extensible by more sophisticated customers – not just by the vendor.
6. Highly scalable. If you have an incredibly powerful and useful system that has all the information you want – but can’t handle your scale – it’s worse than useless. In the age of cloud and warehouse-scale computing, scale is an issue for more and more companies. In practice, this likely implies a great deal of delegation and a distributed (agent-based) architecture.
7. Integration with monitoring systems. Knowing for certain that everything is monitored is critical to maximizing availability. Most companies are not monitoring everything, and could not tell you easily what things they are not monitoring.
8. Must not set off network security alarms. A security tool whose discovery sets off network security alarms has missed the boat. Discovery must be as passive as possible and not look like an attacker – while still keeping everything up to date.
9. APIs to trigger external events when things change. It’s key that a SOCMDB be able to easily integrate with other systems – and tell them when something has changed. Here are a few examples of the kinds of systems that one might want to integrate it with.
   • SIEM
   • Trouble ticketing system
   • Monitoring system
   • Alerting system
10. Relationships as first-class citizens. In security, like in most of IT, what things are connected to (logically and physically) is important. Being able to represent those relationships in a rich and flexible way, and easily query about relationships is important to understanding your attack surface.
11. History of changes. When you’re performing incident analysis or investigating compliance issues – it’s important to know when critical things changed, and what they used to look like.
12. Tracking and Reporting – Being able to tell what your security posture is and track it over time. In the best case, it should offer you guidance to how best to proceed to triage your most important things first. Here are a few examples of the kinds of things you’d like to be able to know through reports:
    • What unpatched vulnerabilities you have
    • What compliance issues you have
    • Attack surface by system
13. Security Posture Score. A scoring system which took into account the severity of the problem, the nature of the system and the number of systems affected. Automatic connection to vendor patch feeds would also be useful. This could either be provided by the SOCMDB itself, or a compatible tool which was driven from its database.
14. System administrator friendly. In the end, the success or failure of any tool is significantly affected by the attitude of the administration staff. Things which make the system hard to install, configure, manage, or otherwise causes administrators headaches can cause an otherwise valuable software package to drop by the wayside. If it can also be helpful to the system administration staff, then that can work in your favor here as well.
15. Secure. The information being stored in the SOCMDB is by definition highly security sensitive. The same is true of the communication during discovery. Although the information in the SOCMDB is not directly what attackers are looking to exfiltrate, it is the buried treasure map outlining all the resources and vulnerabilities of the enterprise in great and gory detail. Once an attacker is aware you have a SOCMDB, this is exactly what they will want to get first – if they can.
16. Detailed. It’s often said that “The devil is in the details” – this is nowhere more true than in security. The list of details that are needed for a SOCMDB to be have enough information to evaluate compliance is extensive. Here are a few examples of things you’d need to know to properly secure your systems:
    • IP and MAC addresses. Need to know the IP and MAC addresses of every device active on your (server) networks.
    • Switches, routers, and other network gear – and their configuration
    • Firewalls – including their configuration.
    • Servers – system names and details as noted below
      • Full Support bare metal, VMs, clouds, and containers
      • Versions of software installed (OS packages, and language packages (Python PIP, Ruby Gems, etc).
      • Services Provided
        • What binary is providing the service?
        • What ports and IP addresses is it listening on?
        • What arguments was it invoked with?
        • What userid is it running as?
        • What are the checksums of service binaries, libraries and JARs?
        • et cetera
      • Services Used (client connections)
        • What binary is acting as client?
        • What ports and IP addresses is it connecting to?
        • What arguments was it invoked with?
        • What userid is it running as?
        • What are the checksums of client binaries, libraries and JARs?
        • et cetera
      • Database configuration
        • Schema
        • Encryption configuration
        • Storage configuration
      • Network Interface (NIC) configuration (MAC, IP addresses, VLAN configuration, etc)
      • Server Security settings
        • Firewall rules
        • Authentication rules (PAM et al)
        • Sudo configuration
        • Secure shell configuration
        • Audit subsystem configuration
        • OS settings
        • File and directory permissions
        • Boot configuration
        • et cetera

SOCMDB Questions

Although to the best of my knowledge, no product does all these things well, there are some that aim specifically at security and do many of these things well.

Here are a few questions I’d love the have the answers to?

• What are your favorite characteristics for a SOCMDB?
• What’s the biggest advantage that a SOCMDB would give you?
• What other specific real-life examples can you come up with for how an SOCMDB can help you?
• Why is having all the details correct and at your fingertips valuable to you?
• What do you want to integrate your SOCMDB with?
• What have I missed in this article?

In the exciting next article in this series, I compare the Assimilation Suite to the SOCMDB criteria described above.