Metric of the week #48: redundant controls

Security Metric of the Week #48: proportion of information security controls that are ossified

Information security risks and controls change gradually within the organization.  From time to time, new risks emerge, new controls are introduced, existing controls find new applications, old risks subside and redundant controls are retired from service - at least in theory they are.  Keeping the portfolio of controls aligned with the risks is the primary purpose of the information security function and the Information Security Management System.  This week's metric is one way to measure how well that alignment is being managed in practice. 

In immature organizations, security controls once accepted and installed seem to become permanent fixtures, integral parts of the corporate infrastructure.  Successive risk analyses lead to the introduction of yet more controls, but nobody ever quite gets around to reviewing and thinning-out the existing corpus of controls.  Gradually, controls accumulate while the business becomes ever more constrained and inefficient, carrying a costly burden of redundant, unnecessary and unsuitable controls.  

This is understandable and perhaps appropriate during the early growth phases of information security/risk management when the focus is on bringing the organization up to an acceptable baseline level of security by implementing basic controls.  After a few years, however, there is a good chance that some of the installed controls are no longer needed.  It's not unusual to find a few controls that nobody understands, needs or supports - their original purpose has long since been forgotten and may in fact no longer exist (e.g. compliance obligations that no longer apply).  Some will have been superseded by other controls, changes in the business, and changes in the risks.

The metric implies that someone has to count information security controls, and determine how many of them are ossified, redundant and no longer necessary.  Counting controls is easier said than done: for example, is every PC running the corporate antivirus software package counted separately?  Is the antivirus package a single control, since it is probably addressing several distinct malware-related risks and perhaps others such as spam?  This is something that would need to be sorted out when specifying the metric in order to ensure that successive readings were directly comparable, since this metric is about the medium to long term trend rather than point values. 

According to the management at ACME Enterprises Inc., here is the PRAGMATIC rating for this metric:

P	R	A	G	M	A	T	I	C	Score
85	88	85	80	84	75	22	62	39	69%

They are evidently most concerned about the metric's Timeliness and Cost-effectiveness.  Counting and assessing the status of controls is undoubtedly a tedious, time-consuming process: management is not sure it is worth the effort.

In discussing this metric, the ACME's Information Security Manager acknowledged that she ought to be actively looking for ossified controls.  She argued that this was an operational security management activity under her remit, and she did not require a metric, preferring instead to put her efforts into systematically addressing the ossified controls as they were identified.  On the other hand, the Chief Information Security Officer sought reassurance that the process was, in fact, operating well, and felt that the metric would be a useful way to demonstrate to more senior management that information security was playing an active part in cost containment.

As we go to press, the discussion is unresolved.  Other candidate metrics are being compared on the basis of their PRAGMATIC scores, while the ISM and CISO are exploring their requirements in more depth.  If you were advising them on their metrics, what would you suggest?