PCI DSS

Inventory Management for Compliance

How do you do inventory for your PCI DSS compliance? Is it a spreadsheet? Or is it a database driven tool that has an API built into it, so that you can query the in-scope assets? How much importance do you place on the inventory?

One of the aspects of scope that does not get what I would call, “top billing,” is the inventory. I have written in other blog entries that organizations live and die by their inventory, and from experience, to me, that is so true.

I have seen people learn about inventories the hard way.

During one company’s first compliance assessment, a firm used a spreadsheet to track which systems were in-scope and it worked well for the initial emergency, “get this rolled out phase”, but it lost energy for longer term use because no one maintained it. Their second year, when they started looking internally at their compliance posture prior to the second annual assessment, they quickly came to the realization that what was an asset in the first year, did not reflect what was running in place eight months later. In the information age, the ability to roll out new content is paramount, and standing up new servers is easier than taking systems offline for upgrading. With the advent of cloud computing, the ability to bring up a new instance has been reduced to seconds, which has a direct impact on what is in scope and what is out of scope.

Naturally they had to pull out all the stops to get ready. They remediated the gaps and completed the assessment. Were they successful? Absolutely. Was it enjoyable? Not so much. Was it avoidable? Oh yeah. What they really needed (other than someone asking the basic question, if there was scope creep in the Cardholder Data Environment (CDE)) is an inventory tool or process integrated into their business.

The size of your CDE dictates if you need to go buy an inventory tool or if you can continue to manage using spreadsheets.

There is no heuristic on when you go from spreadsheets to an inventory tool. You will have to decide that based on your experience in your environment. That said, I would suspect companies with the designation, “Large” in their description would need a tool.

Looking at the PCI DSS, there are several requirements directly related to having an inventory.

• Requirements 12.3.3 and 12.3.4 have to do with usage policy.
• Requirement 2.4 is specifically looking for an inventory.

To be compliant, you need to show the inventory is maintained, includes a description of function/use and someone must attest that the inventory is kept up. That is pretty basic stuff, so I am going to tell you what I would like to see in the inventory as a person who came from the other side of the assessment table.

I recommend the inventory should have these columns.

Note that the function/purpose are the only fields that are required per Requirement 2.4:

1. Hostname
2. Application name
3. I/P
4. Scope
   • PCI Directly in scope (Stores/Updates/Transmits CHD)
   • PCI Connected-to (No CHD, but connected to the in-scope systems, does a security function on the network, or could affect the security of the CDE)
   • Out of scope (Optional – I will explain below)
5. Type – Something to help categorize the system
   • Stand-alone system, Hypervisor, Virtual instance
   • Cloud-small/medium/large
   • PAAS, SAAS, IAAS
6. Function – High level terms like Server, Desktop, Mobile, Firewall, Router, Switch, etc.
7. Purpose – Lower level term to describe what the system does
   • POS controller, Domain controller, A/V server, logging host, DLP server, Jump host, IDS/IPS, etc.
   • Probably Not Applicable for network devices since they are purpose-built devices and the function will describe enough detail.
8. Hardware Vendor
9. Hardware Model
10. Operating system with version and vendor
11. Location – this can be as granular as you need, a floor tile location, the name of a datacenter, a street address if at someone’s house, or maybe “remote” for mobile devices.
12. Comments – A freeform area to put additional text about the entity.

I have seen some inventories where the scope is set to yes/no, but then you need to also have some form of description of connected-to or fully in scope somewhere else in the inventory. You will also notice I put out of scope in there. That is if you want to keep one inventory and include all your systems in there. That can be helpful if you want to use the inventory for other efforts. Say if you start tracking systems for other compliance efforts, you could add to the scope column to designate those systems.

The list above is rather spreadsheet centric, but tools, like a configuration management database (CMDB), are available for this kind of tracking. There are many advantages to picking up tools, such as the ability to quickly find software products if a vulnerability is flagged in the industry or looking for end of life hardware.

Ideally, I like the idea of linking the inventory with the vulnerability scanner as that would also permit you to possibly start managing your vulnerabilities better and make building your scanning list dynamic to match your current environment.

Configuration management tools can also keep systems within specified build parameters and can make you aware when a system falls out of that configuration. The list of what you can do with these types of tools to manage your environment in endless.

If you use tools, put as much automation as you can, that can pick up new adds and changes to the environment including decommissioning.

If you opt to stay with spreadsheets, make sure you build the manual processes into your business flows to keep the inventory owner aware of changes to the environment. For instance, if you buy a new device, the inventory person needs to know. Likewise, if you decommission a device, the inventory person would want to know about that too. Moving systems in and out of scope dramatically affects the inventory; the updates need to be reflected. A good way my team managed that in the past was to sit in on the weekly change review meeting with a keen ear open for changes to the in-scope applications. Many changes were caught in that venue that dictated changes to the manual inventory we kept at the time.

_____________________

SecureTrust, a Sysnet company, leads the industry in innovation and processes for achieving and maintaining compliance and security. SecureTrust delivers world-class consulting, compliance and risk assessment services and solutions for the enterprise market as well as tailored merchant risk management programs and solutions for merchant program sponsors around the globe.

CLICK HERE to contact us for all Enterprise Compliance, Merchant Risk Management and Compliance Technology needs.

_____________________

Drew Cathey has been a member of the SecureTrust team for five years and has been in IT for 35 years. Coming from a background in telecommunications IT operations, he has held positions in engineering, project management and IT security. Drew holds degrees in biology, engineering and an MBA in Information Technology management along with PMP, CISSP, CISA and QSA certifications. He resides in St. Petersburg, FL with his two children and enjoys running, bicycling and tennis.