Vulnerability Management – Identification

Identifying assets for scanning is the very first and most important step. The program’s success depends on how well the organization has inventoried its assets. Usually, we use the term CMDB which could be explained as a database to store Infrastructure information and Configuration. As the organisation’s size expands, the CMBD’s complexity increases. There are 3rd Party platforms that can be leveraged to maintain the inventory, but teams develop an in-house tool in many organisations.

Ever wondered what CMDB data actually look like? Hold onto your hats because we’re about to dive into the wacky world of CMDB fields and their wild values! Get ready for a wild ride as we explore the must-have fields essential to oxygen and the good-to-have fields like sprinkles on a cupcake. But wait, there’s more! We’re not just stopping at talking about CMDB fields. Oh no, we’re taking it a step further. We will unleash the magic of Python and develop a simple yet awesome sample app that will make your head spin! Who needs a fancy CMDB when you can create your own in-house CMDB right before your eyes? Get ready to hold your sides from laughter and your breath from the excitement. This series of hands-on posts will bring you joyfully rolling on the floor as we embark on this CMDB adventure!

Asset Attributes’ Template

  • FQDN/Hostname – User-Friendly Name of the Assets or Associated Fully Qualified Domain Name
  • IP Address – IP Address associated with the asset. If there are multiple interfaces, ensure at least one has been updated.
  • Serial # – Unique Serial # of Physical Assets and the unique Object ID of the Virtual/Cloud assets.
  • Asset Class – Define the asset class, i.e. if the asset is a Desktop, Laptop, Mobile, App Server, DB Server, or Network device [ Firewall, Routers, Switches, Load Balancer etc.]
  • Asset Type – Physical, Virtual, Cloud
  • Hosting – Internet, Internal, Public Cloud etc. If the organization uses a segregated network approach, we can mention zones, usually categorized based on data sensitivity or internet exposure.
    • Continent or Org Specific Region Code, Country, Data Center or Network Zone
    • Prod, Pre-Prod/Staging, Dev, etc.
  • Business Unit Information
  • Asset State – Live/On, Terminated/Off, Decommissioned etc.
  • Operating System Information – Windows, Linux, macOS, PAN-OS, Cisco IOS version etc.
  • Support Cycle – Is the asset still in support? The expiry period could also be captured.
  • RAM, CPU & Hard Disk Information
  • Responsible Owners
    • Asset Owner – Who is the asset owner. Usually, the person/team who requested the asset becomes the owner by default unless otherwise configured.
    • Responsible for Patching – If the asset owner is not directly responsible for implementing the remediations, the contact of the person who will be informed if needed to inform about the vulnerabilities.
    • Security Point of Contact – Person/Team responsible from the security point of view.
    • Escalation Point – If needed to escalate in the absence of improvement upon alerting about the asset, the person/team should be contacted.
  • Security Attributes
    • Security Class – What will be the impact on the business if the system is compromised. Based on the impact classification, we can assign a class to the asset like Critical, High, Medium, or Low. The below parameters can also help in deciding the class.
      • Confidentiality – If compromised, can it result in an impact on Confidentiality and up to what extent?
      • Integrity – If compromised, can it result in an impact on Integrity and up to what extent?
      • Availability – If compromised, can it result in an impact on Availability and up to what extent?
  • Change Log
    • Timestamps for Created On, Last Updated etc.
    • Individual/Account, which modified the information for the asset.

Once the above template is finally prepared, we must ensure that various sources in charge of wrangling the asset inventory are seamlessly linked to this magnificent centralized tool, so it can work its magic during the scanning phase. So, what kind of sources can we expect? Let me put on my detective hat and try to round them all up 🙂
First on the list is the Client Inventory – where all the wild Desktop, Laptop, and Mobile devices roam. Don’t worry. Usually, a tried and true onboarding process is in place to capture those mischievous client devices.

Network Services – Usually, Network devices are onboarded through the Data Center process. Hence, we will need to update the data centre management process to provide a feed of inventory to the central service.

Private Cloud – Assets created and managed on private cloud instances like VMware or OpenStack. Typically these advanced platforms are already equipped with an API that can be leveraged to pull the asset information with required privileges.

Public Cloud – Assets created and managed on public cloud instances like AWS, Azure, GCP, IBM, Oracle, Ali etc. These platforms also have API endpoints, which can be leveraged to pull the asset information.

For all of the categories mentioned, we gotta make sure that each of these feeds captures info in the accepted attributes’ template format or a second process to fill in the missing attributes and ensure the CMDB is consistent.
By now, you should have a good idea of what the Identification phase involves. We’ll use a few attributes to create the target list and prioritize the remediation timeline using a few others.

“That’s all folks for this post! Brace yourselves for the oh-so-exciting ‘scanning phase,’ where we’ll magically gulp down data from mystical asset sources and meticulously craft the perfect scanning environment in our upcoming post. Prepare to be (supposedly) blown away!”

Up ↑

%d bloggers like this: