A Case for Standardizing Tooling Capabilities Language
Author: Philippe Langlois
September 2019
For the defenders supporting and protecting networks, the deluge of data, alerts, best practices, notices and regulations can overwhelm even the hardiest of us. Fortunately for the defenders the tools they use have evolved in maturity, functionality and interoperability, however, understanding the specific capability of the tools and how they help you achieve certain regulations or best practices still presents a challenge. Does your vulnerability management platform, also count as your organization’s asset inventory? Does your Active Asset Inventory tool also help you create your list of active ports and services? Does your implementation of opensource tools meet the same functional capabilities of an enterprise grade tool? What additional value does [insert new marketing buzzword] provide to protecting your organization?
One way that we can attempt to address these types of questions is through the development of a standardized language to describe cybersecurity tooling capability. We have standardized languages for describing software vulnerability (CWE, CVE), standardized languages to describe platforms and software (CPE) and also some growing standardization for understanding attacker methodology and campaigns (STIX, ATT&CK). While the task may seem insurmountable: there are so many tools that address problems in unique different way. However, if the focus is not on HOW the tool functions, but on WHAT the tools does, the scope starts to narrow down drastically. With this approach we could start to whittle down the large corpus of tooling descriptions and distill them into a more manageable classes of capabilities.
One Possible Option
As part of that distillation, the key point would be finding out the “WHAT”, which is the action or activity that the tool is implementing/completing, and a good starting point is using the CIS Controls to describe the specific capability that is required for the sub-control to be implemented. While going through the process a pattern was discovered, many of the sub-controls had a relatively consistent structure, with one of a handful (approximately 12) Actions being applied to different subjects. Certainly not an extensive list or a perfect one, but intended to be a starting point.
Parse: read and interpret different files and data into an consistent format
Scan: Examine parts of something to detect specific feature
Store: Write values and data into a queriable format
Block: Prevent a specific event from occurring
Identify: Uniquely represent data points based on a specific premise or criteria
Authenticate: Verify something’s identity based on a specific criteria
Patch: To mend a weakness or vulnerability
Rate: assign a standard or value to something according to a particular scale
Verify: Demonstrate the accuracy of assumptions
Log: make a recording of specific events
Set: Turn on a setting or add a value to the system
Encrypt: convert information into a cipher to prevent unauthorized access
Below is an example of how these action terms can be used:
Scan the network for live assets,
Scan assets for deviations to baseline,
Scan assets for known malicious file hashes,
Block from the network assets w/o legitimate certificates
Block from executing unapproved applications
Block from connecting unapproved connections.
In these extremely simple examples, we’re looking at capabilities being described as the relationship between an Action (the what, in bold) and the Subject (to what, in orange). The subject allows us to understand where the action is being applied and within which context. For example are we scanning the network for live assets, or are we scanning for known out-dated software? The problem then becomes, what ultimately describes the subject. This is where there is a significant gap in my opinion. Ideally a standardized language of system subjects would allow for the capturing of relationships between subjects (a Filesystem is on a system, a network consists of different systems, applications can be distributed across different systems). The relationships would be key to understanding how specific capabilities tie back to different elements of the environment and how those protections roll up (or don’t) in the environment.
However, in the imperfect world of technology I believe we need to introduce one additional piece, the “Scope”. As much as we’d like to say that our capability would be applied universally across our environment it may only be available to certain platforms, to systems that are domain joined, or to systems that have agents installed. This scope would then help you understand the overall coverage of your organization’s security tools. For the more mathematically inclined here is a quasi-mathematical way of looking at:
Capabilities = f(Action, Subject, Scope)
By having a (this is but an option) standardized approach to describing capabilities we could theoretically make direct connections between security Tooling, security requirements and risks. This is obviously a very simple model and one that needs significant work and expertise to advance from napkin scribbles to something robust. Hopefully we can start collectively shinning a little extra light into the “fog of more” and get a better sense as to what are the capabilities that we’re looking to purchase, that we need to purchase and that we’re not currently take advantage.
