Identify>Asset Management>ID.AM-2 Software Platforms and Applications Within the Organization are Inventoried
Every new piece of software introduces a possible vulnerability.
Software platforms and apps within the organization are inventoried: Defined
Inventory…software? Maybe they want you to inventory ghosts or imaginary friends while you’re at it. We get it. It is one thing to inventory physical objects, e.g., staplers on the third floor; it is another thing to inventory something that can literally be replicated to near infinity almost instantaneously. Cybersecurity can be a lot of fun.
Unlike ID.AM-1, where you might struggle with whether to include a virtual router (or similar) in physical inventory, you’ll probably struggle with over-inclusion because it is common to emulate hardware in software. But to do the opposite, i.e., emulate software in hardware, is quite rare.
But that’s our mission with this activity, and for a bunch of good reasons: namely, that most of our vulnerabilities are simply a function of the number and types of software that we are running. So if we want to keep things safe, we have to be able to trace a threat to a vulnerability (usually tied to a given software), and from there to the machines that are running the software. It is a high bar, because there are at least a couple of ways to parse the requirement.
Software is weird.
The first way to meet the requirement is to embrace the idea that software can be copied over and over again, and leverage it by avoiding the absurdity of it. That means that you’d produce a “master list” of all applications that are in use in the organization. In this case, you’d have a list that might include one application per row, without respect to where the software might be running. Obviously, this is the low-effort/low-reward strategy: low-effort because creating a static list of the software products you use is much less arduous than other approaches, low reward because much of the benefit of having a software inventory is that a master list might help you to find out if you have a vulnerability. But it won’t necessarily tell you where that vulnerability (in terms of platform or machine) might be.
The second approach is to embrace the fact that life is complex and keep an inventory, not just of the software products that your organization uses, but also a list of the machines that are running it. As you might imagine, this is geometrically more complicated, but also might give you a much better chance of staying secure. When a vulnerability is found in a software, and you have a list of what is running on each machine, you can respond precisely, and much more quickly. This is the preferred method in regulated (e.g., finance, government, etc.) environments. Just like its physical cousin, ID.AM-1, this is a foundational control. So, if you are struggling with budgeting your effort, you might want to put more of it on this control rather than others because you’re leveraging your investment in it through to many others.
The risk of undetected software is huge. With either approach, consider the platforms involved. Corporate PC platforms are the most amenable to controlling and monitoring. Personally owned mobile devices are probably the least. In between these two extremes are cloud platforms which expose a subset of the inherent security features available to you or your administrative staff and can be something of a wildcard.
The devil is in the details.
There is a lot more complexity here than you might imagine. Consider the humble browser. Once an afterthought, downloaded when buying a new laptop, now it’s a platform in its own right, able to install and run all manner of plugins, extensions, and themes. And you probably don’t know what they are, especially when you realize that capturing that information requires an understanding of each browser, and the nuances of that browser’s interaction with its host.
In addition, it can pay to know more about the software that you have installed rather than less. Knowing the existence of a software is a start, but knowing the version and where it is running is better. Even knowing when a software was upgraded can be useful because it can tell you how long a machine was (in)vulnerable which will make for easier containment in the case of an incident.
Secret software is always safe and fun.
One of the sticky situations that come up in this area revolves around SaaS solutions. SaaS is obviously software, but it is debatable whether it should be included in the inventory. In general, the more that an SaaS solution acts like a vendor relationship, the more likely it is that it should be excluded. The opposite also applies.
For example, shipping companies are offering sophisticated options bundled in their services. They might offer portals that calculate sales tax and offer shipping cost optimization services or packaging selection. The portal might interface to a local hardware postal printer that outputs stickers with barcodes which are then attached to outbound shipments. At this stage, it might not make sense to include the shipping portal in the software inventory.
But what happens if we add API integration from your ERM to the shipping company’s system? What if your SOC controls are tied into revenue calculations that are derived from the shipping vendor data? Are your payment systems integrated too?
At some point, it becomes clear that the shipping vendor isn’t just supplying shipping services. They are a software provider too. Where the line is precisely found is almost impossible to locate. But you probably have a dozen of these stealthy software packages that should be considered for your software inventory.
ID.AM-2: In the news
Software Inventories serve as the base that other controls are built on. While critical to keeping an environment secure, it can also mean that it is difficult to pinpoint the cause of an incident as being localized to this control. One way to spot these incidents is to find incidents that have elements similar to this control.
One element relates to complex platform interactions. This control is supposed to smooth out the complexity between disparate platforms, whether they be PC, SaaS, or mobile. Applications that operate on multiple platforms likely cause (or are victims of) software inventory control failures. LastPass’s recent breach (involving login credentials, ugh) comes to mind. LastPass operates on just about every platform, including within browsers.
A similar element relates to “Shadow-IT.” The defining feature of these projects is that they evade corporate and IT governance to achieve business objectives. Whenever a business unit subscribes to a platform, there’s a risk that it is not recorded in the inventory, thus preventing an effective response to an incident. The Pennsylvania Department of Health got firsthand experience when they used Google platforms to store COVID-19 exposure data and exposed it to the broader world in a fit of institutional initiative.
My software inventories failed: What am I going to see?
The fundamental failure associated with inventories is completeness. This means that the inventory record is missing a piece of software that is currently running in the business somewhere. The challenge with completeness risks is that there is always a strong presumption that there is some degree of missed software, especially in light of the complexities that were outlined above. Perfection is just about impossible here, but there are a few things that you can watch out for that might imply a software inventory problem.
I can’t patch efficiently.
Nobody (just about!) is running their own lab to stream homegrown patches. We are all relying on vendors to provide fixes for software that has been cracked. Our reliance isn’t the only weakness in our armor though.
Finding the vulnerability and receiving the patch is one thing. Distributing it is another. The first challenge is making sure that every machine that needs a patch gets one. The second challenge is ensuring that all patches are packaged to minimize the disruption caused by having your IT department seize control of every vulnerable machine at the same time and without regard to the associated risks.
A tight software inventory better ensures success under both scenarios. An accurate software inventory can direct attention to every machine that needs it. A complete software inventory can give you a picture of all the software currently running on the estate and let you figure out when and how much patching you should enable during any given patching window.
Is that lady running KaZaA?
When people are running unauthorized software, it is almost always a signal that something is amiss. Your information security group will always be a little behind the times when it comes to the latest and greatest software packages for every niche and role. So, there’ll always be an argument for allowing employees broad authority to buy, download, and install whatever software will help them get the job done.
But it often spirals out of control. A lax attitude can open the door to every software, including malware, adware, and otherwise-nefarious programs. In these environments, you’re almost guaranteed to see something weird, just by shoulder surfing down a row of cubicles. Each one of those applications is an attack surface.
Even if your organization isn’t so laissez-faire, consider the long-tail (and superficially more benign) version of this problem. If your organization has one hundred specialist employees, each using a distinct (and appropriate) niche software to perform their role, how many of those tools are being run through a patch management process? How many can you even afford to run through a patch management process? The answer is less than 100%, and one of the iron rules of InfoSec is that all incidents start with one breach.
The guy doing our software license audit drove away in a Lambo.
For the most part, the days of software license audits are gone. It used to be common for businesses to pirate much of their software. It wasn’t even necessarily too controversial. In the fulness of time, and especially with the rise of the subscription model, that has waned, but it still happens. There are even law firms specializing in software license defense, which is amazing.
The way to measure your risk here is via a two-pronged approach: (1) figure out how much software you bought, and (2) figure out how much software you have. If generating either of those quantities is difficult, or if you’re seeing a huge gap between one or the other, then you’ve detected a risk, not just in your licensing, but also in your software inventory.
My software inventory is stellar: What does it look like?
As mentioned above, there’ll always be a little ambiguity as to the completeness of your software inventory. Accuracy (the idea that a given inventory records stands for what is installed) will also be a regular battle. But patching, fresh software inventory information, and a solid grasp of software costs will all help to give you some confidence about the quality of your software inventory.
Patch Tuesday took 12 minutes.
Patch Tuesday (as many know) is the date that Microsoft, the dominant OS vendor in the enterprise market, publishes patches. On that day, millions of individual machines around the globe are set to update in real time. Most organizations don’t do it exactly that way but are still quite busy during Patch Tuesday.
For enterprise IT, Patch Tuesday is a time to receive and assess patches for suitability of implementation. And if you don’t know what platforms you are running, it is a mess. But the ability to take in many new patches and simulate their application to a fixed number of system images to test them—and do it quickly—is a vote of confidence.
It implies that your IT Department has a correct picture of what is in the estate. It should also give you a sense that they are likely to understand the mechanics of getting the patches out to everybody promptly (or at least have a pretty good shot at it) since they know what is running. A consistently quick turnaround on patch assessment means that there are automated tools gathering information on the environment.
Near-real-time updates to the software inventory.
Software is a squiggly thing. It can be infinitely replicated. Updates can come from a bunch of sources and tempos. Manually tracking them is impossible.
We’ve avoided this topic a bit, but it really pays to get some sort of software—let’s call it software software—to track the software. Though the tone is a bit tongue in cheek, this isn’t an exotic idea. These tools are often packaged with features that also track hardware inventory.
They are usually implemented as a cross-platform agent that can be installed on Windows, Linux, SaaS platforms, and mobile devices. They track changes and relay them back to a central server. This type of system is something of a filter criteria that will separate mature IT departments from developing ones. But if you can tell that a software inventory item was recently updated (or at least checked for updates) then you are doing great here.
Autodesk just wrote us a check because we had more licenses than we needed.
We must use an analogy here, because license audits aren’t easily relatable for many of us. But tax audits are, and some people can walk into an IRS audit and feel no fear. These Apex taxpayers have their papers together; they know the law, and so feel ready for any question that gets thrown their way. It is a powerful position to be in and there’s a lesson to be learned there.
A good software inventory will tell you the software that is running on every machine. It’ll have information as to when it was installed and/or removed. You’ll know the history of versions streamed to a given machine. It’ll be like having your papers together.
The only missing ingredient might be an understanding of the terms of your licenses, i.e., whether you bought a software on a per-seat/per-user/per-machine basis, whether your company is entitled to upgrades—and the license duration is also a common term that you might want to take the time to understand. But make no mistake, a smooth software license audit is a great indicator that you’ve got a strong software inventory control in place.
Remediating or implementing a software asset inventory process.
A pattern tends to appear when it comes to standing up processes. The first step is usually to authorize. The second is to initialize. The last step is to operate. For this control, we recommend that you seek lasting authority for the process via your governance function, buckle up for a tough first run at the inventory, and use software tools to efficiently stay current.
Keeping governance in the loop.
Governance is supposed to be the glue that keeps everything going, period after period. We can’t emphasize enough the importance of maintaining the staying power on this control. The records in a software inventory become geometrically more valuable when they are current, as well as when you can use them to discern changes over time.
The only way to achieve this is by making sure that you have a mature process that can run efficiently to gather data about the software that is being run on your systems and that your company has the wherewithal to store the data consistently and over time. That means that the operation of the control must be protected from the vacillations of human resource and financial constraints.
The short way of saying this is that your company can’t take a quarter off from doing software inventory because they have run out of money or because an IT manager has secured a three percent raise working somewhere else. The best way to do this is to weld the operation of software inventory (and many other controls, frankly) into policy. This protects the control from being viewed as optional.
Designing the inventory compilation process.
Getting the first inventory compilation is the hardest part. Generally, you’ll be starting from scratch, or will have to use a very shallow first baseline. You’ll be touching many systems for the first time, reaching out to teams to ask about systems they’re running, and reconciling other data sources into your compilation.
Avoid making a lot of promises around when or how long it’ll take. You don’t have any control over platforms that were deployed in the past and nobody should be able to hold you accountable for the inevitable discoveries that are made along the way. The length of the first compilation will be unknown; it won’t be infinite either.
So engineer a way to show progress. List the data sources that you’re using to build your first baseline and keep track of how they are ingested, and any discrepancies that are resolved. The process gets easier over time as you compile good data and remove inaccuracies.
Building the inventory update process.
At some point it’ll become plain that software tools are needed to do the job efficiently. Most solutions on the market run the same way. Every machine runs a client that reports back to a central server. Therein lies a challenge.
How do you stream a software to every machine, given that you’re still trying to get a picture of what’s out there? There isn’t a ready answer to the question. Some of the gaps can be detected via network scanning/enumeration tools. But the best that you can do is to manage it.
The best way to do that is to think of the environment as a lake with a river flowing into it. The first compilation is working to measure the lake at a specific point in time. Hopefully you’ll be compiling deployed machines faster than new ones come online. So, at some point, you’ll need to shift your focus away from logging and detecting existing machines and toward installing the agent software on new machines. When that happens, make friends with IT Support and Procurement. You’ll need their help.
Configuring the software agents might require some finesse, so be careful here. On the one hand, you want the most current data that you can reasonably get. On the other hand, frequent and large updates are stressful on machines and networks alike. Be prepared for intermittent switch/router failures before you’ve tuned it.
Software inventory: other sources of authority.
COBIT5 BAI09.01, BAI09.02, BAI09.05
ISO27001:2013 A.8.1.1, A.8.1.2, A.12.5.1
NIST 800-53 Rev 4: CM-8 and PM-5
Chatting About Software Inventory.
Check out our LinkedIn page.
