Security Metric of the Week #4: Proportion of critical controls consistent with controls policy This week's security metric example measures the proportion or percentage of critical controls that are consistant or comply with the associated policies. The metric assumes that policies are defined, at least for controls deemed "critical".  Arguably, all controls that have documented policies are critical but not necessarily so, and some critical controls may not have policies.  Examples of control policies are “access is permitted unless expressly forbidden” and “trust is transitive”.  They might also be termed, or be part of, 'control specifications'.  If such policies/specifications are not formally defined and mandated, implementation is more likely to be inconsistent and perhaps inappropriate or inadequate.  This is a relatively C ostly metric due to the need to assess the consistency or compliance of critical controls with the associated policies.  S...

"Traffic light reporting" generally implies metrics that should make sense to anyone having normal color vision, and an appreciation of the conventional sequence of colors meaning stop, ready and go.  Short of binary yes/no type metrics (such as certified compliance), metrics doesn't get much simpler than traffic-light reporting ... or does it?  According to April's eBulletin from New Zealand's Ministry of Civil Defence & Emergency Management : "The different meanings of the colours used for tsunami threat level maps in national warnings and those used for tsunami evacuation zone mapping (specifically red, orange and yellow) were identified as confusing in exercises and real events. For instance, in the threat level maps red indicated a ‘severe threat’ of 8m+ amplitude while yellow meant a ‘moderate threat’ of 3-5m. In the Tsunami Evacuation Zones Guideline the opposite applies, with the ‘red zone’ being evacuated for the lower level threat and the ‘yello...

This week's security metric is, at face value, straightforward: "simply count the number of technical/software vulnerabilities that remain unpatched." In practice, as stated, the metric is quite ambiguous.  Are we meant to be counting the number of different vulnerabilities for which patches are not yet applied, or the number of systems that remain to be patched, or both ?  If the organization is using a distributed vulnerability scanning utility that identifies missing patches, perhaps the management console gives us the metric directly as a number, or the average number of missing patches per machine. The P redictability score for this metric would be higher if it also somehow addressed unknown and hence currently unpatchable vulnerabilities, plus nontechnical vulnerabilities (e.g . physical vulnerabilities and vulnerabilities in business processes).  Software vulnerabilities are important, but the organization needs to address risks, meaning other kinds...

Security Metric of the Week #2: Coupling index Our second 'metric of the week', Coupling index , is a measure of the degree of interdependency between things such as: IT systems; Business processes; Business units, departments and teams; Organizations. Coupling has an impact on the risk of cascade failures (known colloquially as 'the domino effect').  In tightly-coupled situations, upstream issues will quickly and dramatically affect downstream elements.  In loosely-coupled situations, by contrast, there is more leeway, more 'slack' so downstream effects tend to be less evident, show up less quickly if at all, and generally have less impact on the organization. Contrast traditional mainframe-based batch-processing financial systems against real-time ERP systems, for instance: if something causes a single batch to fail on the financial system, it can generally be corrected and rerun without too much trouble, provided it still completes within the batch window...

COBIT version 5 , just released by ISACA, suggests numerous sample metrics in the Enabling Processes document - typically four or five metrics per goal of which there are 17 enterprise goals plus another 17 IT-related goals, giving approximately 150 metrics in total. For example, supporting the third financial enterprise goal "Managed busines risk (safeguarding of assets)", the following three metrics are suggested: Percent of critical business objectives and services covered by risk assessment. Ratio of significant incidents that were not identified in risk assessments vs. total incidents. Frequency of update of risk profile. The text introduces the metrics thus: "These metrics are samples, and every enterprise should carefully review the list, decide on relevant and achievable metrics for its own environment, and design its own scorecard system."  Fair enough, ISACA, but unfortunately COBIT 5 does not appear to offer any advice on how one might actually do that in...

Security Metric of the Week #1 :  Unowned information asset days We will be introducing, discussing and scoring a "Security Metric of the Week" (SMotW) through this blog for the forseeable future.  We know of literally hundreds, if not thousands of candidate metrics, including those that are proposed in various standards, books and published lists of metrics, along with a few of our own creation.  On top of that, we frequently come across novel metrics during our consulting work or simply in the stream of information that flows past every well-connected professional every day.  If you would like us to consider, score and discuss your favorite security metric, by all means email us , raise a comment on this blog, or join the Security Metametrics discussion forum . Unowned information asset days is a candidate metric concerning asset ownership, an important governance concept that underpins accountability for the adequate protection of information assets.  ...

Hello world! We have started this blog to enhance the SecurityMetametrics website and support both our book (due out in August) and the global community of professionals using, trying, or intending to use metrics to measure and improve information security. This blog, like the website and the discussion forum , is brand new and will take a while to get up to speed, but we hope it will soon start to deliver real value.  We have some great material to share with you, and definitely welcome your feedback comments and improvement suggestions.  The field of security metrics is wide open for creative, innovative approaches, academic input and practical experience.  As the field slowly matures, join us as we do our level best to nudge things along in the right direction. We'll kick off by releasing our first "security metric of the week" on Monday ...

An infosec blogger describes the fun he had using nmap to analyze typical office printers (that's an excellent Google translation of the Spanish original ).  Most printers have web configuration interfaces on the network and, thanks to having no passwords or (well known) default passwords, hackers can play pranks such as printing junk, resetting the admin pasword or changing the printer's IP address (e.g. deliberately conflicting with another device on the network).  All pretty juvenile really, little more than geek vandalism, but I guess p rinting directly to the device might conceivably be of concern if the printer is loaded with check blanks and relies on security on the print server to prevent anyone who feels like writing themselves a big fat check simply doing it.  Given that they would need access to the printer's network, knowledge of the print formatting necessary to put all those zeroes in the right place, some way of slipping past the business process controls...