Specification

Introduction

The goal of the a9n framework is to define a standard for identifying and articulating risks to attribution in a component or system.

For a system where managing attribution is important, risks are characteristics of components whose discovery could identify the user, organisation, or activity, such as unique attributes/properties of a system. A characteristic need not necessarily explicitly link a user or account to an organisation; it could just link multiple accounts together, or even just raise enough suspicion that leads to further investigation.

Threat Categories

This framework proposes that there are three attributes of a system that must be protected to prevent digital attribution (akin to the CIA triad for information security). A fourth category, info, is reserved for issues requiring further investigation.

Explicit Attribution of Entities: Can an adversary identify who is behind the activity? This could reveal the operator or their organisation. For example, learning who the user is working or operating for by connection to owned infrastructure.
Correlation of Entities: Can an adversary connect two accounts, identities etc that are not meant to be seen as connected? For example, only 2 users connecting to the same server or service; or correlation by similarity of unusual behaviour.
Discovery of Activity: Can an adversary recognise that something unusual is happening (but not necessarily what it is), which warrants further investigation of the device or individual? For example, use of an anonymity network like Tor.
Info: Further investigation is required to validate and quantify if related risks exist. This category is informational only and not scored.

Metrics

Metrics reflect the traits of the characteristic that is potentially identifiable. They help articulate to risk owners what might be discovered and how, and therefore assist in determining the likelihood and impact of a given risk.

Threat Vector

This metric reflects the context by which identification of the characteristic is possible.

Network

Adversaries with access to the network traffic or able to initiate connections to a component.

Physical

Adversaries with physical access to a node and potentially with logical access to the data or applications.

Local

An application or process running on a device.

Involved

The known or unknown parties in an exchange that are in control of the devices which host, store or process applications, ciphertext and metadata. This category is specific to the environment, but for example would include:

For a system using an iPhone, Apple who will collect device telemetry and broker push notifications;
For a system hosting a service on AWS, Amazon who would have access to connection information and logs.

Privileges Required

This metric describes the level of privileges an adversary must possess before being able to successfully identify the characteristic. The score is greatest if no privileges are required. Guidance on how to determine the privilege score for each vector is detailed in the guidance documentation.

High: The adversary requires privileges that provide significant (e.g. administrative) control over the component allowing access to component-wide settings and files.
Low: The adversary requires privileges that provide basic user capabilities that could normally affect only settings and files owned by a user.
None: The adversary is unauthorised, and therefore does not require any access to settings or files of the component.

Complexity

This metric describes the conditions that must exist in order to identify the characteristic. Such conditions may require the collection of more information about the target, or analysis of aggregated/historical information.

High: Identification of the characteristic requires the adversary invest in some measurable amount of analysis of numerous datasets, or use/installation of additional tooling.
Low: Identification of the characteristic can be achieved in isolation without any additional tooling or information.

Impact

The Impact metric captures the effect of a successfully identified characteristic on the component.

High: The characteristic explicitly attributes the component, or indicates unusual activity beyond reasonable doubt.
Medium: The characteristic likely indicates unusual activity.
Low: The characteristic is not necessarily an indication of unusual activity, but may lead to further investigation by an adversary.

Scoring

The risk score aims to quantify the risk based on the category, impact, and simplicity to achieve. A formal scoring methodology will be defined in v2 of the specification.

Support for environmental metric scoring, where the analyst can adjust the score depending on specific characteristics of a user’s environment, will be defined in v2 of the specification.