One of the challenges of CS-AWARE was to be able to represent analysis results of socio-technical system and dependency analysis, which is highly depended on the individual organization that is analysed, in a structured and machine readable form so that this information can be used to configure a CS-AWARE instance to the individual needs of an organization. In CS-AWARE this resulted in a structured format that is able to represent organizational assets, dependencies, business processes and associated information flows, information sources for continuous monitoring, and patterns that determine abnormal system behaviour. This blog post will give a quick overview of how those elements were modelled in a structured format that we call the system and dependency graph of an organization.
The first challenge was to decide the best way to base our representation on. Since no relevant protocol or format could be identified, and all internal communication in CS-AWARE is done according to the Structured Threat Information Expression (STIX™) language in its second iteration (STIX2), it seemed obvious that also the expression of the asset and dependency graph should follow this format. The problem with this idea was that STIX is designed to express cybersecurity threat information, and information about organizational structures like assets and dependencies were not part of the grammar of this language. This was a bit surprising, since organizational information like this is part of any common risk assessment process – but we had to realize that STIX was designed purely for threat exchange and not for risk assessment. Nevertheless, we decided that it is our best way forward to build upon STIX and rely on custom objects and custom parameters to express the information required for the system and dependency graph. In future we may decide to discuss with OASIS, the standardization body behind STIX, if there is an interest to extend STIX beyond the pure threat exchange purpose and be also applicable to risk modelling, which would definitely require a standardized way to express organizational information. Our modelling resulted in 3 separate custom STIX objects, a “node” object, a “logfile” object and a “pattern” object.
The “node” object, as can be seen in the snippet below, represents an organizational asset. Besides common information like node name and human readable description, the object is able to reference other node objects that are dependencies of this asset via the “source” parameter. The “x_infoflow” allows to reference if this asset plays a role in the information flow of a critical business process of the organization, which would be referenced by name. Other optional parameters that were relevant in our context were the ability to model which software and/or hardware an asset is composed of, modelled by a list of CPE (Common Platform Enumerator) identifiers, and IP/Port range relevant for the asset. The “x_categories” parameter was added to allow the definition of keywords that are relevant for the specific asset – in our use case this helped us to search for those terms in cybersecurity information related information sources like social media. Finally, the “logfile_ref” and “pattern_ref” parameters allow to reference to logfile or pattern objects relevant for an asset.
{
“type”: “node”,
“id”: “node–0b14e229-b5ff-4fef-896a-ee8891c321c7”,
“name”: “Asset 1”,
“created”: “2019-07-24T12:21:04.000Z”,
“modified”: “2019-07-24T12:21:04.000Z”,
“description”: “Asset description”,
“source”: [
“node–333d7548-b35f-4e97-8b72-3b5bc1358934”,
“node–8141673a-5cd3-417f-a36d-3fb3b7fd8393”,
“node–8e8c8ae4-59a9-4cc3-b51d-6b479143fe9e”,
“node–d7eb5902-7dc2-4a33-ac20-1639de0305f5”
],
“x_infoflow”: [
],
“x_cpe_list”: [
“cpe_<SoftwareName>:*:*:*:*:*:*:*:*:*:*:*:*:*”
],
“pattern_ref”: [
“pattern–544946f9-bf08-472d-be2e-c51593267b47”
],
“logfile_ref”: [
“x_logfile–8c207347-456c-4a6c-8bca-b340e27267d4”
],
“x_ip_range”: “0.0.0.0”,
“x_port_range”: “0000”,
“x_categories”: []
},
The logfile object, as illustrated in the code snippet below, allows to describe log files in a structured way. In addition to modelling the file name and general description, each parameter can be modelled individually and, more importantly, is assigned a unique ID for later reference. The log file object is extremely useful in the CS-AWARE context, since this very specialized knowledge about information contained in a log file, which is usually only known by a handful of individuals in an organization, can be made available to a broader audience, with concise descriptions in human readable form.
{
“type”: “x_logfile”,
“id”: “x_logfile–8c207347-456c-4a6c-8bca-b340e27267d4”,
“version”: “<xml>”,
“description”: “General description of the log file”,
“name”:”Log file name”,
“value”: “<Text>”,
“x_paramlist”: [
{
“type”: “x_parameter”,
“name”: “parameter1”,
“description”: “Parameter description.”,
“id”: “x_parameter–b2815614-f637-425c-affa-c8d0d223bd84”
},
{
“type”: “x_parameter”,
“name”: “Parameter 2”,
“description”: “Parameter description”,
“id”: “x_parameter–869177e9-29f8-49d5-a4f6-e640cd983d1e”
}
]
}
The pattern object, as shown in the code snippet below, is used to express information about suspicious behaviour patterns associated to assets, and observed in the various identified log sources. The pattern object allows to define a unique pattern ID and name, as well as a human readable description of the pattern. The “x_paramlist” allows to define one or more parameters that a pattern is composed of, with each parameter defined by a set of log files/ log file parameters to be observed, and the way they relate to each other via “x_equation”. “x_equation” can be seen as the data pre-processing for this pattern parameter, expressing the combination of log file parameter values. The resulting parameter value can be evaluated based on the “x_normal_range” and “x_max_range”, which determine if a parameter value indicates normal or suspicious behaviour.
{
“type”: “pattern”,
“id”: “pattern–544946f9-bf08-472d-be2e-c51593267b47”,
“name”: “Pattern name”,
“pattern_type”: “Behaviour monitoring”,
“created”: “2020-04-17T11:48:47.856Z”,
“modified”: “2020-04-17T11:48:47.856Z”,
“version”: “1.0”,
“description”: “Description of the pattern.”,
“x_paramlist”: [
{
“type”: “x_parameter”,
“id”: “x_parameter–b2654f51-5800-4f81-8cf2-b496edbaa513”,
“name”: “Pattern Parameter 1”,
“context”: “”,
“object_refs”: [
{
“x_logfile–8c207347-456c-4a6c-8bca-b340e27267d4”: [
“x_parameter–b2815614-f637-425c-affa-c8d0d223bd84”,
“x_parameter–869177e9-29f8-49d5-a4f6-e640cd983d1e”
]
}
],
“x_equation”: “<Text>”,
“resource_level”: “<Number>”,
“x_range_normal”: “<Text>”,
“x_max_range”: “<Text>”
}
]},
Thomas Schaberreiter
