SMotW #24: security traceability
Security Metric of the Week #24: Traceability of information security policies, control objectives, standards & procedures
This metric is based on the fundamental premise that all information security controls should be derived from and support control objectives, those being explicit business requirements for security. Controls that cannot be traced to specific, documented requirements may not be justified, and may in fact be redundant and counterproductive: alternatively, the requirements may be valid but unstated, indicating a likely gap in the organization's policies etc.
The metric implies that there should be a way of tracing, referencing or linking controls with the corresponding security requirements, in both directions: it should be possible for management to determine which control/s satisfy a given control objective, and which control objective/s are satisfied by a given control. There are various ways of achieving this in practice, such as a 2-dimensional table with control objectives along one axis and controls along the other. The body of the table can simply contain ticks for the relevant intersections, or more detailed information concerning the implementation status of the controls. In theory, every row in the table should contain at least one entry in the body, and so should every column: many will have more than one since there is a many-to-many relationship between control objectives and controls.
Turning now to the PRAGMATIC score:
P | R | A | G | M | A | T | I | C | Score |
85 | 89 | 88 | 90 | 91 | 87 | 65 | 84 | 85 | 85% |
That's a good score, let down just a bit on Timeliness since it will take a while to draw up the table and elaborate all the linkages to start with, and then to re-check them every time the metric is reported. Furthermore, making changes in response to the metric will inevitably be a slow process, resulting in a substantial lag between measuring, reporting and responding to the metric.
By the way, a similar many-to-many relationship exists between control objectives and risks. Conceptually, this adds a third dimension to the table, allowing us to trace information security risks to the corresponding control objectives and on to the related controls (or vice-versa). Such multi-dimensional relationships are quite easily represented in a database but are harder to track, manage and measure manually.