Faddom Raises $12M for Our Agentless IT Infrastructure Mapping Platform
Search
Close this search box.

How Common Platform Enumeration Puts You in Control of IT Security

Read Time: 6 minutes

IT departments are overrun with increasing numbers of assets—both on-premises and in the cloud, where environments and instances can proliferate with a snap of a finger. To keep assets in line, IT teams are bringing in more security tools, each with its own language. 

Yet many of these systems don’t share data easily, making it hard to keep track, for example, of which operating systems and software versions are in use where. On top of this, each department might have its own naming conventions for assets and vulnerabilities, leading to confusion and wasted time. With asset information isolated in different systems, and assets cataloged differently by different departments, it’s hard to get a comprehensive view of the entire IT environment. 

For instance, a hospital IT department might use one system to track hardware assets and another to manage software licenses. When the security team receives an alert about a vulnerability, it must identify which devices are using the applicable version of the targeted software or operating system. To do this, they must search through these separate systems manually, wasting hours of work. And in the meantime, the vulnerability remains unresolved, leaving the hospital’s data at risk.

Unfortunately, this situation is very common. IT teams waste precious hours deciphering data, duplicating effort, and reacting slowly to security threats. Better information flow and clear communication are crucial ways to make IT and security operations more efficient.

Standardizing asset names can streamline workflows and free up security teams. A standardized naming scheme must provide a unique identifier for all IT assets: software, hardware, and operating systems.

To accomplish this goal, several structured naming schemes are available: software identification (SWID) tags, package URL (PURL), and by far the most common, Common Platform Enumeration (CPE).

In this post, we will explore how the CPE naming standard works, the cybersecurity benefits of adopting CPE, and one essential best practice to help organizations start leveraging the benefits CPE offers.

CPE Structure and Components

All of the naming conventions available today, such as SWID, PURL, and CPE, use a structured, machine-readable format, similar to a web address. 

The basic idea behind this format is to let users drill down quickly to identify the exact hardware, software, or operating system in use. This is somewhat like listing a used vehicle for sale by make, model, and year, but for digital assets in which version number can change far more frequently than once a year.

The structure of CPE includes details like vendor, product name, version, and operating system. Together, this structure is known as a well-formed CPE name (WFN), with all the pieces fitting together to complete the puzzle of the organization’s digital landscape.

This is the basic structure of a CPE WFN:

cpe:/{part}:{vendor}:{product}:{version}:{update}:{architecture}:{language}:{modifier}

  • part: Defines the type of system detected and can have one of the following values:
    • a – for Application
    • h – for Hardware
    • o – for Operating System
  • vendor: The software developer responsible for the product
  • product: Name of the product
  • version: Version number of the product
  • update: Update/revision of the product
  • edition: Edition of the product
  • language: Language of the product (used only if different language versions are available)

Several other fields aren’t commonly used: sw_edition, target_sw, target_hw, and other. These are usually left blank with a * symbol in the relevant location. As a result, most CPE WFNs have a lot of * symbols.

Here are a few examples of WFNs within CPE. Note that all CPE WFNs begin with “cpe:” followed by the CPE version number, e.g., “cpe:2.3:” This has been omitted from the following examples.

Well-Formed Name (WFN)PartVendorProductVersionUpdate
a:apache:log4j:2.0:-:*:*:*:*:*:*aapachelog4j2.0
a:microsoft:internet_explorer:8.0.6001:beta:*:*:*:*:*:*amicrosoftinternet_explorer8.0.6001beta
o:redhat:enterprise_linux:4:update4oredhatenterprise_linux4update4
h:intel:3450_chipset:-:*:*:*:*:*:*:*hintel3450_chipset

CPE in Cybersecurity and IT Management

Understanding how CPE works is essential for IT security management. That’s because, in general, a security vulnerability is problematic only for certain versions. 

By correlating the CPE information with the Common Vulnerabilities and Exposures (CVE) system, the global vulnerability database maintained by NIST, organizations receive valuable information to help them mitigate or remediate vulnerabilities in their environment.

For example, it’s not enough to know that CVE-2023-36397 is a critical vulnerability (with a CVSS score of 9.8) in the Microsoft Windows Pragmatic General Multicast (PGM) system. 

Having to mitigate or patch every single Windows system within a given organization would be far too much work for the IT team. Yet without CPE, that’s exactly what would need to happen. Fortunately, CPE information is included in each CVE, providing essential data on which systems are affected by any given vulnerability, broken down by vendor, product, and version number.

In the example above, for instance, the CVE entry for CVE-2023-36397 lists all specific updates of Windows 10, Windows 11, and Windows Server that are affected by this vulnerability. One of the many vulnerable operating systems is listed as 

cpe:2.3:o:microsoft:windows_11_23h2:*:*:*:*:*:*:arm64:*

Well-Formed Name (WFN)PartVendorProductVersiontarget_hw
o:microsoft:windows_11_23h2:*:*:*:*:*:*:arm64:*omicrosoftwindows_11_23h2*arm64

Note that in this case, no version is listed because “23h2” is already part of the product string.

In this way, the CPE provides a unique fingerprint, helping security tools and databases understand an organization’s systems quickly and efficiently to determine which assets need attention when a new vulnerability comes to light.

By correlating vulnerabilities by CVE with affected assets by CPE, organizations can:

  • Track vulnerabilities: Identify outdated software and patch it before hackers can exploit it. 
  • Streamline compliance: Meet security regulations and reporting requirements more easily.
  • Automate tasks: Manage complex IT environments with tools that understand CPE language.

This last point is perhaps the greatest benefit of CPE. When used with automated platforms, CPE data enables automated inventory generation for a total picture of the IT infrastructure, simplifying asset management. It also enables pinpoint identification of vulnerable hardware and software and prioritized remediation. Finally, it allows companies to take a proactive approach to threat mitigation, leveraging real-time threat intelligence to preemptively block known vulnerabilities before they can exploit the network.

Further analysis and analytics on CPE data can also help eliminate silos; optimize big-picture processes; assess vendor security track records based on CPE data (guiding procurement and partnership choices); analyze historical trends to anticipate threats; improve compliance with regulations and internal policies for simplified auditing and reporting; and allocate security resources more efficiently, with greater focus on higher-risk devices and vulnerabilities.

Challenges and Limitations of CPE

Obviously, no system is perfect, and CPE faces some challenges. The vector structure can be daunting for beginners; not all vendors or products have valid CPEs, and in the quickly evolving software landscape, keeping up with new software and updates can be a constant struggle. (This is where automation can also play a useful role.) As with any IT transformation, rolling out CPE across an organization can be a complex project that must be undertaken carefully over multiple stages:

Groundwork

Before undertaking any change, IT must perform an inventory of all assets, network mapping. The IT team will also need to determine which CPE data sources will be used, along with the data format selection. The organization will also need to choose which tools it will use to catalog and track its assets by CPE data.

Initial Deployment

A pilot deployment is probably the best way to begin. At this stage, IT will ingest asset data for initial pilot departments and begin configuring security tools to work with the CPE data.

Rollout at Scale

Once the pilot has been tested successfully, the IT team will begin a phased expansion to all departments. At this point, they can also begin setting up automation for common tasks in related security tools—and reaping the benefits described above of standardizing IT asset names.

Ongoing Monitoring

IT personnel will need to assess performance and success metrics in all relevant areas, such as security, while also taking steps towards continuous improvement.

Making the Leap, Avoiding the Pitfalls

faddom ui

As discussed above, making the leap to CPE can fuel a wide range of associated improvements for IT departments and security teams. But the transition to tracking products and devices using CPE can be challenging.

To make the leap simpler and ensure that no assets fall through the cracks, organizations should begin the transition process with application dependency mapping (ADM). ADM tools build a comprehensive map of applications and their connections, providing crucial visibility before beginning the CPE rollout.

Faddom is a fast, effective way to get started with ADM. With no agents or configuration changes required, Faddom gets to work mapping the entire network—even the most complex dependencies—in under an hour.

In addition to having the world’s fastest and most secure and affordable application dependency mapping platform, Faddom has also released a new cybersecurity module that comes with cutting-edge vulnerability detection, severity scoring, actionable insights – and a lot more. All without using any agents!

To start a free trial today, just fill out the form in the sidebar!

Map All Your Servers, Applications, and Dependencies in 60 Minutes

Document your IT infrastructure
both on premises and in the cloud.

No agents. No open firewalls. Can work offline.

FREE for 14 days. No credit card needed.

Share this article

Map Your Infrastructure Now

Simulate and plan ahead. Leave firewalls alone. See a current blueprint of your topology.

Try Faddom Now!

Map all your on-prem servers and cloud instances, applications, and dependencies
in under 60 minutes.

Get a 14-day FREE trial license.
No credit card required.

Try Faddom Now!

Map all your servers, applications, and dependencies both on premises and in the cloud in as little as one hour.

Get a FREE, immediate 14-day trial license
without talking to a salesperson.
No credit card required.
Support is always just a Faddom away.

Faddom LTD Company
Reg No. (VAT No.) 516514072
8 Hataas St., Ramat-Gan, Israel 5251248
finance@faddom.com 
USA +1-339-229-8228
IL/Fax +972-077-4330450

Bank Account Details

Bank Leumi Le-Israel B.M Account # 50004 Branch# 864
Routing No.: IL010864
In: BANK LEUMI LE-ISRAEL B.M.
Branch: LEUMITECH BUSINESS CENTER864
Address: HAMENOFIM 15, HERTSLIYA
SWIFT: LUMIILITXXX
IBAN: IL050108640000000050004

Total Amount:

Price

Please send the signed proposal/purchase order to: finance@faddom.com

Contact our Team

Get a customized proposal today!