This post appears as part of a series about the foundations of the DHS CDM Program. In the first blog, we covered what the DHS CDM Program is all about, exploring its first foundational element, hardware asset management (HWAM). Today’s blog still examines the foundational principle of asset management, this time with a close look at the CDM capability specific to software asset management (SWAM).
As federal agencies adopt and mature CDM capabilities, they’re still finding challenges related to asset management (both hardware and software) and the ability to uniquely track, accurately verify, and validate data attributes associated with agency devices.
What’s CDM SWAM?
Software asset management is largely centered around increasing agencies' visibility into software assets on their networks. Once they have visibility into what software is out there, SWAM helps them understand the security considerations for the software itself, the configurations, and even users with access to it.
Between the increased visibility and understanding of security gaps, agencies should be able to proactively reduce software vulnerabilities, mitigate software misuse, and have a better understanding of the overall security of their networks.
To successfully implement SWAM security, DHS identified three critical practices for federal cybersecurity teams.
SWAM Practice 1: Software Platforms and Applications Within the Organization Are Inventoried
Federal IT spend across all agencies is estimated to reach around $90 billion in 2021. That’s a $12 billion increase over the last four years. Based on the budget number and growth alone, one can assume that agencies are buying and implementing tons of new software on top of their existing software stack. Because of this, an inventory of all of the software being used, or even unused but still on government networks, is more important than ever.
Just like HWAM, you can’t truly understand security gaps, areas where your organization is doing well, or what needs work without knowing what you have.
When compiling a software asset inventory, agencies should think about:
- Where do I find all of the information on the software assets?
- How do I compile the data? And where do I compile it?
- Is there a process in place for naming conventions and how we organize the data?
- How often do we update the inventory?
- Who owns the inventory and the responsibility to keep it up to date?
A lot of the legwork for SWAM Practice 1 revolves around establishing and implementing processes about how the software asset data will be stored, categorized, updated, and the ownership of it. Many agencies already have some form of a process around these, but they may be in silos across multiple teams or even outdated. Therefore, getting all of the stakeholders together to create more holistic inventory processes is definitely beneficial in the long term.
Aside from creating processes and policies around storing and organizing the data, the first step is simply finding all of the places where information on software assets could be stored. This may involve IT and security teams working together to aggregate databases, spreadsheets, software management platforms, etc.
The good news is that while it may be siloed, buried, outdated, or in the deep dark corners of your networks, the software asset data is out there. It may be a bit daunting to find all of the data and data sources. But once you have the data, you can then focus on how and where to store it, how to organize it, and — really — how to make sense of it all.
SWAM Practice 2: Malicious Code is Detected
Practice 2 is centered around identifying software assets that are unauthorized or unwanted on the organization’s network. This could include potentially unwanted software and applications that cause concern for IT, security, and risk teams. These applications may include software that has legitimate use, but can also be used for malicious intent.
More specifically, Practice 2 is really based around agreeing on how to determine whether a piece of software is unauthorized or unwanted, and formulating lists of known-bad or unauthorized software. It also involves creating processes for identifying these types of software and taking action when they’re identified.
A great starting point to determine what software you should allow is NIST’s guide to application whitelisting. There’s also tons of research and guidance from the private sector on examples of unwanted software that could be helpful. Some unsanctioned software examples we’ve seen across our customer base include:
- Peer-to-peer networks
- Cracking tools
- Protocol analysis tools
- Vulnerability mapping and pentest tools
- Cryptocurrency wallets and miners
- Gaming applications
- Native applications used for malicious purposes
- Remote access tools (RATs)
- Unsanctioned IT and security tools, and any unsanctioned platforms including VPN, antivirus, cloud storage, and more
SWAM Practice 3: Integrity Checking Mechanisms Are Used to Verify Software, Firmware, and Information Integrity
The goal of Practice 3 is primarily centered around the premise of integrity.
What does integrity mean exactly in regards to SWAM? It takes the practice of only allowing authorized software on the network one step further by looking at the maintenance and management of the software assets. It also verifies they’re what they say they are by analyzing the technical characteristics of the software. Plus, it helps to identify if the allowed software is installed and configured correctly to minimize security events by way of legitimate software.
This takes into account integrating things like authorization processes and software vulnerability discovery into the implementation of new and upgrades of old software. It also entails outlining the tools, processes, ownership of software integrity checks, and what happens if software fails an integrity check or if vulnerabilities or misconfigurations are found.
How Can Cybersecurity Asset Management Help With SWAM?
The biggest benefit of SWAM for federal agencies is increased visibility and agreement on and identifying unauthorized or misconfigured assets. As agencies buy more software and continue the migration to the cloud, SWAM will become increasingly important and continue as a foundational element of their overall cybersecurity strategy.
Like I mentioned earlier, the asset data is out there — the hard part is finding that data, organizing it, and making sense of it. By connecting to all of your existing security and management tools, a cybersecurity asset management platform like Axonius can easily identify all of your software assets, categorize and organize them for you, and enable you to find and take action on devices that have deviated from your security policies.
What’s more, Axonius is a DHS CDM-approved vendor for asset management.
