SCAP 2.0, The Time Is Now

By Curtis Dukes, Executive VP and GM – CIS Security Best Practices

Admonitions to try harder and spend more on cybersecurity will not prevent more attacks like the Equifax breach. We hear repeatedly “if they had only patched” that an attack would have been prevented. Yes, organizations need to do better, especially ones with lots of resources that are entrusted with large amounts of sensitive information.

It’s clear that the cost and timeliness of patching and other compliance activities need to decrease significantly for all organizations. Achieving this goal will require an increased level of cooperation between developers, platform owners, and security administrators.

We hope this post persuades members of this security community to consider adoption of the security standards in version 2 of NIST’s Security Content and Automation Protocol (SCAP). The standards in SCAP 2.0 can help achieve true security automation and improved security business practices by integrating support of these specifications into products and by normalizing data formats.

We use patching to make the case for the specifications.

Four major obstacles cause enterprises to delay or fail to patch. What is not discussed enough is how all four of these problems are at root caused by flawed security business practices.

1. Multitudes of articles tout security “automation” but they do not examine the cost or scalability of activities such as creating an accurate and up to date software inventory.
2. Installed software has third-party components (TPCs) that were not tracked and reported by the developer. Software development methodologies call out the need for better reporting of TPCs but there is no consensus data format for reporting their presence.
3. Organizations invest heavily into new software development efforts without adequate planning for the security tails such as migrating away from unsupported platforms. Software is no longer maintainable because source code no longer exists, or the original programming team has dispersed.
4. Software requires significant regression testing because it plays a critical business function. The longer the test period, the greater the time period afforded an attacker to penetrate a system and steal information. Software Level Agreements (SLAs) exist for availability of a service but few exist that promise reliability if the software or platform is patched.

Adoption of software identity (SWID) tags in ISO 27001 and recast as part of SCAP 2.0 could provide the starting point for addressing these problems.

Software inventory

If a developer creates a SWID tag whenever software is developed or updated and if the installer deposits the tag on the platform, then an IETF standard Network Endpoint Assessment (NEA) client on the endpoint can detect the new SWID tag and forward it to a software inventory server.

Adherence to the specifications allow the update to happen without the need for reformatting.  A vulnerability announcement such as a CVE can include affected SWID tags and an organization can quickly determine from its software inventory which endpoints must be isolated, monitored, or patched.

Third Party Components

The SWID tag provides an authoritative identifier for each version of the software as provided by the developer. That developer can take responsibility for tracking all TPCs associated with their software. This includes developers that provide custom software for the organization.

Life Cycle Tails

The SWID tag is the identifier that can track software throughout its entire life cycle. Each software application deployed by an organization requires life cycle management. It is the responsibility of management to factor in the costs of future updates and to ensure that critical business functions can be migrated to new platforms as old ones are retired. There is a story that needs to be told for every entry in your software inventory.

Security Software Level Agreements

A Security Software Level Agreement (SSLA) between the developer and organization could be the thread that connects the business decision to buy software to the ability to deploy and manage that software securely and responsibly over time. If a flaw is discovered in software, the developer has the responsibility to perform regression testing to ensure compatibility with old versions of the product. The developer should also test that patch on a platform configured securely with security settings such as the CIS Benchmarks. That SSLA could also include a commitment to develop the software according to an industry standard for the platform such as the ones provided by SAFECode, OWASP, or BSIMM. Adherence to one of these methodologies should reduce the number of vulnerabilities and result in software that is less brittle and quicker to deploy.

We will talk more about SSLAs in our next blog post. In the meantime, we hope you will start learning about all the advantages of SCAP 2.0 by reading the NIST whitepapers.