We sometimes mention historical incidents in the awareness materials but this is the first time we have gone into any depth on the history of information security.  May’s brand new awareness module plucks interesting stories and anecdotes from the annals of history to set people thinking, drawing out the information security aspects that remain relevant today. Our timeline stretches from pre-history to the future.  Novel security technologies and techniques developed in wartime include both offensive weapons and defensive measures.  The use of information as a weapon is a theme throughout history, hence information security is far older than any of us. This is not a history lesson as such - we have been very selective about the issues we have covered, with the aim of finding items of interest and relevance to employees in general, management and tecchies. We prepared the awareness materials to satisfy the following learning objectives: Inform employees generally about the...

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.  ...