The Attributer’s Blog – Traceable

Traceable is a Business Attribute from the SABSA Business Attributes Taxonomy that is well established in many disciplines but is as yet immature in the field of information security and IT security. We are all familiar with it in our daily lives too.

The Attributer has a wife who is exceptionally quick witted and who can process thoughts at a speed that leaves him (The Attributer) struggling to keep up. So fast in fact that she (The Attributer’s Wife) does not always find the time to speak what these thoughts might be, and he, being an ordinary mortal, cannot always see the connection between the new topic of conversation and the previous one, even though such a connection exists. However, the situation is mitigated by the fact that The Attributer’s Wife is also a ‘SABSA Widow’, meaning that she is accustomed to SABSA intruding a great deal into her domestic and social life, and that as a result she has been exposed to a lot of SABSA thinking and is fully conversant with the concept of ‘traceability’. Thus when he says: “I need more traceability” she immediately understands how to provide a remedy for his slow-witted brain activity. She fills in the missing links and makes it all traceable.

Consider industries beyond IT and information management. Food production has a health and safety issue associated with it. Should it become necessary to withdraw a food product because it is contaminated, all items from that production batch must be traced. The same applies to the pharmaceutical industry. Batch numbers and dates have been used for this purpose for a long time. Traceability is key to food and drug safety. The motorcar industry is similar in that safety is an issue and from time to time a particular make and model will be found to have a design fault and must be recalled for modification. This requires similar traceability – to be able to find all the cars that fall into that set. The entire mechanical and electrical engineering industry has for a long time used serial numbers to identify individual items and to be able to trace them and their whereabouts for all types of support purposes. So, we see that traceability is not a new concept and is well established as normal practice in many industries.

When we examine IT and information security practice, we find that the otherwise widespread use of traceability is not applied. There is a close parallel to be drawn between ‘safety’ and ‘security’ (in French the words are the same). So it seems strange that when we construct security solutions we do so in a way that is not directly traceable to the requirements that the business has for being ‘secured’. Looked at from the outside, the IT security controls and practices that are commonly deployed can be seen as little more that anecdotal folklore. The ‘best practice’ is to take a list of controls compiled by others and to apply these widely in the hope that this will defend the business information and IT systems from the threats that abound in our current business world. The technical and process designs are not traceable to the actual business risks and are not even seen in business terms.

The ‘carpet bombing’ approach taken by so many organisations is neither effective nor efficient. Some controls are surplus to requirements, other requirements are not adequately met by the control set, because there is no way of tracing and matching business risks with controls. One must question then how can such an approach be regarded as being ‘in control’ of the business when there is no way to demonstrate that actual business risks have been addressed.

In contrast, SABSA embeds the concept of two-way traceability. If a business identifies a risk, then it should be clear exactly how that risk is to be addressed. It should also be possible to monitor the performance of the specific controls to report back how much risk is actually being experienced and what residual risk is retained. Each control should be business-justified by forward traceability and the successful management of each business risk should be reported by backwards traceability. Controls that do not derive directly from a business requirement are not required. Acceptable risk levels are specified by the business as part of its risk appetite.

SABSA achieves traceability of controls through Business Attributes Profiling. The business requirements are distilled into individual Attributes, each of which is associated with a measurement approach and a performance target. Measurements during the operational lifecycle can be fed back and reported through a risk dashboard or scorecard. For a business that wishes to demonstrate that it is ‘in control’ how else could this be done?

The Attributer

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.