Using APIs to create a Multidomain Inventory for Asset Management

IT Organizations have to manage, secure, and get audited on their IT assets. The span of domains cover multiple different product sets with different operating systems by nature, and the teams are tasked to create a cohesive asset management framework. An example is a financial institution which is subject to the FFIEC guidance, which requires them to be able to conform to an audit structure that requires managing their assets and software.

A second example is the NIST publication 1800-5 on IT Asset management that describes a framework for managing assets in an organization. A number of organizations may adopt NIST as their security framework.

Within these frameworks, the NIST and FFIEC guidance don’t call out “Cisco Equipment” or “Microsoft software”, “Virtual machines”, or “Firewalls” in a vacuum. IT Administrators and security teams aren’t tasked with inventory and patch management of just their load balancers, servers, switches, or routers.

IT Administrators and their leadership are tasked with knowing, patching, and securing all of their IT infrastructure. From the physical to the virtual, from the endpoint to the cloud. Thus any single tool needs to be able to fit into a framework to be able to merge together different systems in a cohesive manner that is capable of managing multiple operating systems and vendor implementations.

The purpose of this blog is to show how this can be done practically using diverse Cisco hardware and software, and the framework would bolt in to any other third party and provide functional, easy to use code, that can create a single asset management table for products in the Cisco portfolio.

We do this by integrating ACI, Multiple DNAC, Meraki, Intersight, and SD-Wan platforms into a single table which can be cross referenced and then pushed, into Service Now. We do this using available DevNet sandboxes as of 11/2022. There is also a reference on how this can be reconciled and pushed into Service Now (so that the system of record can be updated following software changes, or reconciled).

This is functional code, which is easy to run against real sandbox environments, and can be validated and repurposed for your environment.

While we cannot control third party products and how they integrate, the framework would allow for other equipment which support Rest API to create a state table for inventory asset management. The framework is rather straightforward: capture the inventory from diverse systems using REST API, and normalize to a consistent list of all assets in those systems. From there, you can update Service Now or another system of record.

The problem we are trying to solve is further elaborated in NIST 1800-5, of the multiple frameworks a customer may be required to audit towards, and the fact that its not as simple as just running a single vendor’s report, when your responsible for an entire ecosystem of vendors and products.

So lets get to it!

What is created is a Google Colab notebook, which allows you to take and validate the code. This is possible because we are using cloud sandboxes hosted in DevNet and our cloud platforms. If you have never used Colab before, it is a Jupyter notebook in the sky that is as easy to run as clicking a button. It also allows me to easily share with you, so you can see for yourself how it works.

You can get a read only copy of the code here: We will walk through it below.

https://colab.research.google.com/drive/1DMfB_FfWPEIDggYawtJgmskLJmkVzqyM?usp=sharing

The first thing you want to do, is look at what it says at the top. What is shared is a read only copy, and to play with it, you want your own editable copy. So you want to save it, by going to File/Save a copy to drive.

The next thing to look at is there are sections, at a high level, its broken down into

1. Getting Meraki inventory
2. Getting SD-Wan inventory
3. Getting DNAC (and multi controller example… this multi controller could also be ACI domains, or Meraki networks)
4. Getting Intersight inventory
5. Getting ACI Inventory
6. Merging them all togther
7. Optional: Updating ServiceNow example. (note, this uses a developer instance which will be inactive by the time you read this, it is functional, get your own developer instance and use the URI at developer.servicenow.com)

Each of these sections can be ran as a group, by mousing over “7 cells hidden”, or you can expand each section and look at code, and what it is doing. You can click the run button below, OR expand the section. This shows the Meraki inventory.

We then go and get the info from SD-Wan, and Intersight, we go into all the groups and grab information and store them in tables, we have created the below tables :

• sdwan_inventory_df -> Data Frame with details from SDWAN
• meraki_inventory_df -> Data Frame with details from Meraki
• dnac_inventory_df -> Data Frame with details from DNAC
• intersight_inventory_df -> Data Frame with details from Intersight
• aci_inventory_df -> Data Frame with details from ACI

Each of these data frames include details from inventory, and we want to simplify it for the concise table. We reduce the amount of fields in each table, and rename them so they are consistent. For example, natively ACI calls hostnames in model format, as fabricNode.attributes.name. Intersight calls Hostname “HostName”. We just simplify this.

Reduce the Intersight table to just a few columns,

intersight_inventory_simple_df=intersight_inventory_df[[‘DataSource’,’SerialNumber’,’HostName’,’ModelNumber’,’Ip.Ip’,’Version’]]

Rename these columns to a consistent format:

intersight_inventory_simple_df.rename(columns={‘SerialNumber’:’Serial’,’HostName’:’Hostname’,’ModelNumber’:’Model’,’Ip.Ip’:’IP Address’,’Version’:’Version’}, inplace=True)

After concatenating all these tables, we have an inventory list with a list which we can use to audit or update our system of record.

Summary

Creating a framework in which you can bolt in and implement diverse systems is fundamental to the roles IT needs to be able to provide given the span of their remit. Cisco provides simple API frameworks for all of our product sets, from device based to controller based, from compute to switching, DC to campus. The purpose of this blog was to provide functional code to be able to be evaluated easily (using colab and devnet), taken, and modified as needed. This functional code is a stepping stone to adopting automation processes for your environment. Please reach out if there are any questions on this!

Extra Credit : Merging into ServiceNow

We do this in three phases, we get the existing inventory data from service now, we compare against our production data (basically a diff on system of record vs production), then we can update our system of record.

A use case being, after upgrading SD-Wan you will have all of your devices on a software version which may not be in service now. You can update it using this logic.

As was mentioned earlier, this code will not run when you are reading this as my developer instance goes inactive after 24 hours and is decommisioned after 2 weeks. You can get your own, and you need only change the URI and authentication headers, to make this work. You do this at developer.servicenow.com. This will provide you your URL to use, and you can either compute your authentication string using python library or glean it from Postman by putting in your authentication, then converting to python code.

We create a Diff using a SQL join,

And then we push the Diff.

Share: