What is the Software Asset Management (SWAM) Security Capability?
The SWAM CDM Security Capability supports the ongoing assessments of a grouping of security controls that are employed to:
- Give organizations visibility into the software installed on devices/systems connected to the network by identifying all software actually present
- Address whether software products and executables are authorized on the system
- Address whether software products and executables have unsafe configurations and out-of-date patches
- Prevent or minimize compromised, vulnerable, or targeted software from being installed and/or staying deployed on the network
- Reduce number of easy-to-compromise devices due to installed software not being actively administered
- Stop or delay compromise of devices from classes of software flaws
- Stop or delay compromise of devices by restricting software installation
- Reduce amount of time that malicious or modified software is installed before detection
What security results should we be able to achieve by implementing the SWAM security capability?
SWAM makes sure that software and associated objects are identified, authorized and managed. Unidentified, unauthorized and unmanaged software is unlikely to maintain proper security updates and configurations, increasing the likelihood of successful attack and compromise. Therefore, SWAM will detect and may prevent malicious software executables from running on the system.
What types of security issues are addressed with the SWAM capability?
The SWAM security capability addresses security issues that result from unauthorized software and from malicious software. The SWAM security capability also indirectly addresses attacks based on unsafe configurations and out-of-date software patches.
Because modern software is complex and consists (typically) of thousands of files per product, it is very difficult for software managers to ensure that such software is:
- Authorized and needed
- From a trusted supply chain (as opposed to including malicious code placed there by malefactors)
- Safely configured (to reduce the attractiveness of particular targets and the likelihood of successful attacks)
- Using current patches (to reduce the attractiveness of particular targets and the likelihood of successful attacks)
As a result, attackers frequently compromise devices by finding and exploiting weaknesses. The SWAM security capability addresses attack scenarios resulting from the difficulties related to the items above, particularly the first two bullets.
The SWAM security capability indirectly supports the second two items. The quality of configuration settings (CCEs) and patching (CVEs/CWEs) for authorized software (with assigned setting/patch managers) are covered under the Configuration Setting Management (CSM) and Vulnerability Management (VUL) security capabilities, respectively. SWAM supports the CSM and VUL security capabilities by making sure we know what software is present so that it can be correctly configured and patched.
What can I do to reduce my exposure to attackes exploiting poor software management?
Once the unauthorized or poorly configured software product or executable is discovered, the removal of the risk conditions will require the following actions:
|Risk Condition||Detection Rule||Response Options|
|Blacklisted software is allowed to execute.||Software appears in the actual state inventory but is blacklisted in the desired state inventory and execution is not blocked.||- Block the software from executing
- Remove it from the actual state (uninstall)
- Un-blacklist it (this response is dangerous)
|Graylisted software is allowed to execute.||Software appears in the actual state inventory but is graylisted in the desired state inventory and execution is not blocked.||- Block the software from executing
- Remove it from the Actual State (uninstall)
- Whitelist it (this response could be dangerous)
|Unauthorized software is present.||Software appears in the actual state inventory, but not in the desired state. (Note: An organization may automatically graylist software if it installed by an approved installer to avoid this problem.)||Add the software to the desired state, and white/gray/blacklist it.|
|Non-reporting devices are present.||The hardware which has the software is in the desired or actual state inventory, but not in the software actual state with timely-enough data.||Restore reporting, or declare the device missing, uninstalled, or retired in HWAM.|
How does the SWAM security capability define a software asset?
In general, a software asset can be as small as a line of source code or as large as a software suite made up of multiple products, thousands of individual executables, and countless lines of code.
Software includes firmware, basic input/output systems (BIOS), operating systems, applications, services, and malware such as rootkits, trojans, viruses, and worms. Software assets are often described in terms of Common Platform Enumeration (CPE). CPE is a standardized method of describing and identifying classes of applications and operating systems present among an enterprise's computing assets.
In order to manage software in an efficient way, we must select the level of assets to be managed. In CDM, we focus on products and executables:
PRODUCTS: It is important to manage software products because this is the level of abstraction by which software is typically licensed, listed in registries during installation, and executed by users. By product we mean a specific combination:
- Patch Level
EXECUTABLES: To eliminate malware, it is important to focus on executable files and library modules such as dynamic linked libraries (DLLs). Malware may be introduced as a single file not associated with a product, or it may be introduced by substituting a file with malicious capability for an authorized executable within an authorized product. Linking executables to products and being able to validate that the executable present is the same one sent by the vendor are vital to identifying malware. Thus, an executable defined as "a specific file in persistent memory that can be loaded into active memory and executed by the CPU" is a software asset.
How can the SWAM security capability assessment support ongoing automated assessments as defined by NIST SP 800-137, Information Security Continuous Monitoring (ICSM) for Federal Information Systems and Organizations?
The following is an example of how the assessment for unauthorized software can be automated:
- The actual state is a list (inventory) of (as close as practical to) all products and executables in the assessment boundary. The actual state can be collected automatically using sensors deployed through-out the environment to detect devices and collect information required for comparison.
- The desired state specification is a list of all software products and executables "authorized" to be in the assessment boundary.
- Defects can be found through computing the differences between actual state and desired state. A defect is a) a software product or executable in the actual state but b) not in the desired state, and is thus "unauthorized." This can be computed by simple set difference.
What data should I collect to support the SWAM security capability?
The minimal Software Asset Management data recorded should include the following (this is a minimal list of data to be used as a starting point, there are many operational and security reasons that more data may be required):
|Software CPE (vendor, product, version, release level) or equivalent (such as SWID) for approved software||- For reporting device types
- For supply chain management
- Determining what products may apply to devices
|Management responsibility for each CPE management function||Identifying management responsibilities for ensuring that licensing, patching, and configuration standards are up-to-date. (If not specified explicitly, this is assumed to be the device manager.)|
|Time period that a software product is expected to be on the whitelist/blacklist/graylist||For identifying the life span of a particular authorized software product. (All authorized software must have a "remove by" date or review date.)|
|Digital fingerprints* of expected software executables (components, EXEs, DLLs, etc.) for the approved software products.||To identify when the executable may have changed, meaning it may no longer be "good"|
*Digital fingerprints for executables (or any file) are long numbers computed by a hashing algorithm from the contents of the file. These fingerprints make it essentially impossible to change the file contents without changing the hash. Therefore, the digital fingerprint can be used to verify that software has not been changed from one point in the supply chain to another. When fingerprints are collected closer to the origin of the supply chain, they are more authoritative and thus more likely to be useful in detecting tampering.
How do I identify managers to support the SWAM security capability?
Organizations should select a subject matter expert for the application (role or software suite) who understands the system and software dependencies, the security configurations, the patch cycle, and how to properly install the software.
There are many ways to assign management tasks:
Choice 1: Automated or Manual
In many organizations, all software is installed manually by an administrator who installs software on each local device. In other organizations, installation may be done automatically from a centralized console that uses a software installation tool to push the new software to all devices (in some scope). Both - or a combination - of these approaches are valid, but they typically change who is responsible; this change in responsibility must be reflected in the desired state data. Where an automated tool manages installation in a known scope, that scope can be used to record the automated tool's responsibility.
Choice 2: Centralized or Decentralized
Even in organizations using manual install procedures, some products (for example, database management systems) may require a central subject matter expert to perform the installation. Likewise, in patching, an organization may use automated packages to install software, executing the installation not from a central console, but from distributed locations. (This might be done to allow verification that the software install doesn't interfere with "local" software.) Clearly, if software is managed from a central console through full automation, the management will likely be centralized. The scope of responsibility can also change who is responsible for a specific function.
Choice 3: Generalist (device manager) or Specialist (e.g., subject matter expert (SME) in patching, or SME in the software product)
How can we prevent unauthorized software from getting on the network in the first place?
Removing unauthorized software or authorizing software from the graylist is something that theoretically shouldn't be necessary. But in real operational networks, it often seems inevitable and in the end is a daunting task. Still, one must ask if there are things the organization could do to reduce the rework required to find and classify newly discovered software as authorized or malicious.
The following kinds of actions can be taken to reduce the amount of unauthorized software on systems throughout your enterprise:
- Policy can state who will have elevated privileges on systems and what they can do with said privileges. System administrators often introduce unauthorized and potentially malicious software to systems because they are able to install new software on systems and use the internet with elevated accounts, or they may use poor sanitary practices with respect to removable media. Properly limiting who can hold such elevated privileges and defining authorized and unauthorized activity will greatly limit your exposure to future risk.
- Logging can track when unauthorized software is installed and by whom. Such logs can assist in determining root cause (e.g., breakdown in configuration management process, abuse of privileges). Once the person is found, letting them know what is expected can prevent creation of these risk conditions.
- A few people may need to be sanctioned. Sanction individuals who frequently install unauthorized software through the abuse of their role and privileges, and who do so after due warning.
While such actions won't eliminate all unauthorized software, these actions can lower their incidence rates, which is a positive step.
How does SWAM support other CDM security capabilities?
The SWAM security capability relies on the HWAM security capability to identify what devices exist to look for software for actual state identification and comparison to desired state specification. Furthermore, the SWAM security capability tells the CSM/VULN capabilities what software is present within the environment. The CSM and VULN security capabilities then validate that software is being properly managed (valid configurations and appropriately patched).
The SWAM security capability does not address how well software on the device is managed, but only that the software is authorized and assigned. How well the software is managed, is covered by the CSM and VULN security capabilities. However, software can only be managed if someone has been assigned the responsibility.