SMotW #72: % of privileged/trusted users
Security Metric of the Week #72: Proportion of highly privileged/trusted users or functions
This metric is indicative of the organization's control over access to IT systems, networks and perhaps other information assets.
The metric is measured by someone suitable (such as an IT auditor) systematically reviewing access permissions assigned to user IDs on (a suitable sample of) the organization's IT systems in order to determine the proportion that are privileged or have enhanced access rights.
The metric's PRAGMATIC ratings are not bad:
| P | R | A | G | M | A | T | I | C | Score |
| 86 | 80 | 51 | 40 | 65 | 39 | 55 | 95 | 60 | 63% |
"Not bad" however needs to be taken in context, since there is a wide choice of metrics relating to access rights/permissions. Of the 17 examples classified as "IT security metrics" in the book, ACME managers scored this one in seventh place. It has merit but is not necessarily going to be chosen for ACME's information security dashboard.
The metric could be a very granular and rich source of information provided someone has the time, energy and integrity to analyze and report the numbers. A simple illustration would be to compare the metric between business-critical and non-critical servers, or different classifications: it is not unreasonable to assume that access to highly-classified systems should be more carefully controlled than to the remainder. This is just one of many hypotheses that could be tested using metrics, an approach that auditors often use.
Putting in more effort would increase both the costs and the benefits of the metric, but perhaps to differing extents. With many metrics, there is (at least in theory) a sweet spot where the net value of the metric peaks. It's not so easy to determine that in practice, especially as metrics audiences vary in their perceptions of value (PRAGMATIC notwithstanding).
Automating the data collection, analysis and even reporting/presentation for this metric requires some investment up-front with a payoff over the medium to long term. It can be automated through remote security management software that interrogates IT systems on the network, and it's even easier if user IDs are centrally administered, provided the tools don't lie, and provided there are agents running on all applicable systems. If this metric is important to the organization, someone ought to check both provisos manually, both initially when implementing the metric and periodically thereafter in case things change.
Conversely, if the metric is not important enough to warrant those integrity checks, is it even worth reporting? This point applies to other security metrics too: since they are intended to support various strategic, management and operational decisions, missing, incomplete, out-of-date, erroneous or misleading data could have serious implications. Metrics that cannot be relied upon could literally be worse than useless, giving the impression of sound management whereas in fact the information may be invalid.
Putting in more effort would increase both the costs and the benefits of the metric, but perhaps to differing extents. With many metrics, there is (at least in theory) a sweet spot where the net value of the metric peaks. It's not so easy to determine that in practice, especially as metrics audiences vary in their perceptions of value (PRAGMATIC notwithstanding).
Automating the data collection, analysis and even reporting/presentation for this metric requires some investment up-front with a payoff over the medium to long term. It can be automated through remote security management software that interrogates IT systems on the network, and it's even easier if user IDs are centrally administered, provided the tools don't lie, and provided there are agents running on all applicable systems. If this metric is important to the organization, someone ought to check both provisos manually, both initially when implementing the metric and periodically thereafter in case things change.
Conversely, if the metric is not important enough to warrant those integrity checks, is it even worth reporting? This point applies to other security metrics too: since they are intended to support various strategic, management and operational decisions, missing, incomplete, out-of-date, erroneous or misleading data could have serious implications. Metrics that cannot be relied upon could literally be worse than useless, giving the impression of sound management whereas in fact the information may be invalid.