I recently had my eyes opened. It happens every now and then. During a conversation with my friend Seth Bromberger he introduced his Quantitative Threat Methodology. I’m hooked.
Why?
Well:
- Its simple and it works.
- Its easy to customise to an organisation’s requirements.
- Its quick to implement without requiring complex and expensive tools.
- It gives comparable and repeatable results.
But, this got me thinking about how we as professionals go about the business of risk assessment. Not the process, but the number crunching. I just carried out a small risk assessment, but the actual work of collecting and crunching the data was painful to say the least. Wouldn’t it be nice if we could just create a set of rules and point these at the data and out of the other end comes a crunched risk assessment. A programming language for risk assessment.
I tried not to lose sleep over this, and thankfully I didn’t.
My first thought on this subject was: how do these methodologies work?
Fundamentally, all risk methodologies break down the risk into core component elements. In information risk theory, for example, the three core elements are:
- Threats;
- Vulnerabilities;
- Impacts;
The risk is calculated from a combination of the three. However, some of these core elements are themselves comprised of other things. If we think about an impact, we would need to know what the impact affects. So an Impact may be composed of an asset and an impact. In fact one impact may affect multiple assets. In fact one RISK may affect multiple assets. In addition to this we have to consider the concept of asset types. Different assets of differing types, e.g:
- Information Assets (a HR Record);
- System Assets (SAP HR, comprised of many different servers);
- Software Assets (a single SAP Netweaver instance);
- Hardware Assets (Blade Server ID:XXYYZZ);
- Physical Assets (The Datacenter); and
- People Assets (SAP Engineer).
These differing asset types could be nested within one another (or dependant upon one another, depending upon your perspective), so the HR Record is stored on the SAP HR system, which uses the SAP Netweaver installed on Server XXYYZZ which is housed in the Datacenter and supported by the SAP Engineer.
A risk which affects one asset (e.g. the datacenter) affects all assets which are nested within it (or are dependant upon it). This introduces the concept of cascading risk.
The identification of cascading risks, in fact the identification of dependencies between assets, is complex. Any language which define how we calculate risk must include the ability to identify and map interdependencies between core risk elements.
When we think about these core elements we also have to consider that for most of these elements we will already have a data collection of these. For assets we will have an asset list, for vulnerabilities as list of identified vulnerabilities which affect us. We don’t want to re-invent the wheel, so it’d be nice to connect to feeds of data, rather than sucking the entire data source into the risk system, effectively duplicating the data. Actually we may have more information in our asset management database than we actually need for our risk assessment. Therefore is seems daft in include all the useless stuff. However, we may need to augment this data feed with new information which is specific to the risk assessment. If we think about an asset we may want to augment it with the value of the asset or the criticality assessment of this asset. So the system should be able to store the data specific to the risk assessment and link that back to the original data record in the feed, which means if we ever want to show information about our asset we can go and grab the data feed and add the risk assessment specific stuff.
Another aspect is that all these methodologies include specific characteristics which apply to the core elements. These can be broadly categorized by a set of ranges or a specific value. These sets are groups of values which equate to another value. Lookups, essentially. Every risk methodology has this type of set up. A collection, which we could call a “range”, and within that a variable number of elements, which we could call a “range element”. So if we are to think about a common aspect of risk assessment, like asset valuation, we could create a range called “asset value range” and this could contain a number of range elements, e.g:
- Range Element 1: $0-100 = 1;
- Range Element 2: $100-1000 = 2;
- Range Element 3: $1000-5000 = 3;
- etc….
This in turn will fulfil a characteristic of one of the core elements, which we could call “asset value”.
Characteristics are important, but they need to be collected into an organized structure. We could define the characteristics into reusable chunks. We could call these “characteristic policies”. In fact, we could define multiple policy types for a core element. The data feeds can be defined in a “data definition” policy. The calculation of the risk can be defined in a “risk calculation” policy.
