We have just completed an awareness module covering privacy. Despite having repeatedly covered the privacy topic, there is clearly just as much of a need for it today as ever.   One of our case studies in the module concerns a major privacy breach here in New Zealand.  ACC is the government department that administers a national insurance scheme providing medical cover for accidents and emergencies.  As such, it handles a lot of personal information including sensitive medical info.  When an ACC manager accidentally and unknowingly attached a spreadsheet containing personal details on thousands of ACC customers to an email to one of those customers, he caused an incident that rumbled along for a year, embarrassing the minister and upsetting a lot of people along the way.   Better training and awareness on privacy is one of several improvements recommendations made by the recent  official report into the debacle.    If the ACC privacy breach seems remote and obscure, the train-the-trai

Security Metric of the Week #37: proportion of software licenses purchased but not accounted for in the repository We are not entirely sure of the origin or purpose of this metric, but it's typical of the those that pop randomly out of the woodwork every so often for no obvious reason, sometimes taking on a curious aura of respectability depending on who raised or proposed them.   Unfortunately, as it stands, we lack any context or explanation for the metric.  We don't have access to whoever proposed it, we can't find their reasoning or justification, and hence we find it hard to fathom their thinking processes that presumably led them to propose it. Perhaps someone had been checking, validating or auditing software licenses and  used something along these lines as a measure in their report.  Maybe it was suggested by a colleague at an information security meeting or online forum, or proposed by a naive but well-meaning manager in such a way that it simply had to be conside

Security Metric of the Week #36: business continuity expenditure At first glance, this looks like a must-have information metric: surely expenditure on business continuity  is something that management can't possibly do without?   As far as ACME Enterprises is concerned, this metric warrants a fairly high PRAGMATIC score of 71%, making it a strong candidate for inclusion in ACME's information security measurement system. It has its drawbacks, however.  Determining BC expenditure accurately would be a serious challenge, but thankfully great precision is probably not necessary in this context: estimations and assumptions may suffice.  Still, it would be handy if the accounting systems could be persuaded to regurgitate a sufficiently credible and reliable number on demand.  Furthermore, it is not entirely obvious what management is expected to do as a result of the metric, at least not unless the business benefits of business continuity are also reported.  The net value of busines

Security Metric of the Week #35: information security compliance management maturity Compliance with information security-related laws and regulations is undoubtedly of concern for management, since non-compliance can lead to  substantial penalties both for the organization and, in some cases, for its officers personally.  Legal and regulatory compliance is generally asserted by the organization, but confirmed (and in a sense measured) by independent reviews, inspections and audits.   But important though they are, laws and regulations are just part of the compliance landscape.  Employees are also expected to comply with obligations imposed by management (in formal policies mostly) and by other third parties (in contracts mostly).  Compliance in these areas is also confirmed/measured by various reviews, inspections and audits. In order to measure the organization's compliance practices, then, we probably ought to take all these aspects into account.   P R A G M

Blogging recently about Newton's three laws of motion , we mentioned that organizations using PRAGMATIC metrics have competitive advantages over those that don't.  Today, we'll expand further on that notion. Writing in  IT Audit  back in 2003, Will Ozier discussed disparities in the way information security and other risks are measured and assessed.  Not much seems to have changed in the nine years since it was published.  Ozier suggested a "central repository of threat-experience (actuarial) data on which to base information-security risk analysis and assessment": today, privacy breaches are being collated and reported fairly systematically, thanks largely to the privacy breach disclosure laws, but those are (probably) a tiny proportion of all information security incidents - at least, in my experience things such as information loss, data corruption, IP theft and fraud are far more prevalent and can be extremely damaging.  Since these are not necessarily report

This is a busy time of year for most of us with social events at work and at home, so it seemed appropriate to deliver a module on 'social insecurity' now. The latest batch of security awareness materials primarily covers social engineering, and touches on the related information security aspects of social networking and social media.   Social engineering revolves around manipulating people to do your bidding. Social networks and social media are sources of information about targets than can be used to gain their trust and persuade or manipulate them. They are also communications vehicles through which to socially engineer others.  Social is the common factor, of course.  Humans are sociable by nature: we tend to 'belong' to various groups, and apply different standards to group members than we do to non-members.  If you think about it, s ecurity awareness and training  are  forms of social engineering.  We're actively using information to persuade people to change

Security Metric of the Week #34: organizational and technical homogeneity The degree of homogeneity (sameness) or heterogeneity (variation or variability) within the organization and its technologies affects its aggregated information security risks, in much the same way that monoculture and multiculture crops may face a differing risks from natural predators, parasites, adverse environmental conditions etc.   A particular mold that successfully attacks a certain cultivar of wheat, for example, may decimate a wheat field planted exclusively with that cultivar whereas it may not take hold, making little impact on a neighboring field planted with a mix of wheat cultivars differing in their susceptibility or resistance to the mold.  On the other hand, under ideal conditions, the monoculture crop may do exceptionally well (perhaps well enough to counteract the effects of the mold) where the mixed crop does averagely.   Homogeneity of technologies, suppliers, contracts etc . increases an o

He may not have considered this at the time, but Sir Isaac Newton's three laws of motion are applicable to security metrics ...  Law 1.  Every object in a state of uniform motion tends to remain in that state of motion unless an external force is applied to it.  An organization lacking effective metrics has no real impetus to change its approach to information security.  Management doesn't know how secure or insecure it is, nor whether security is "sufficient", and has no rational basis for allocating resources to security, nor for spending the budget on security activities that generate the most value.  Hence, they carry on doing pretty much what they've always done.  They approve the security budget on the basis of "last year's figure, plus or minus a bit".  They do security compliance activities under sufferance, and at the last possible moment.   The law of inertia is particularly obvious in the case of large bodies that continue to blunder throu