Especially if you work in a heavily-regulated industry, you may not be the least bit surprised to discover that our latest awareness module on security compliance is weighty. Admittedly the high-res poster graphics account for much of its 100Mb but the annotated seminar presentations, briefing papers, mind maps and so forth ended up bigger than normal, even without going into detail on specific compliance requirements or resorting to the convoluted and archaic language heretofore favored by the legal profession. So what makes compliance such a bulky awareness topic? Part of the reason is of course that compliance obligations are many and varied. As a taster of the content in the module, here are 10 types of information security and privacy-related laws and regulations, taken from a list of 20 in one of the general employee awareness papers: IT and corporate governance - directors’ responsibilities to society and owners  Integrity, availability, accurate and complete reporting of f...

In the course of considering how to measure an organization's compliance with security and privacy related obligations, the PRAGMATIC method has proven itself a valuable way to structure the analysis.  Today I want to discuss how taking the PRAGMATIC approach led me to design a better compliance metric by addressing the weaknesses in one of the candidate metrics. I started by brainstorming possible ways to measure security/privacy compliance activities, focusing on the key factors or parameters that are most likely to be of interest to management for decision making purposes.  With a bit of Googling and creative thinking in odd spare moments over the course of a few days, I came up with a little collection of about 8 candidate compliance metrics: The rate of occurrence of security/privacy-related compliance incidents, possibly just a simple timeline or trend, but ideally with some analysis of  the nature and significance of the incidents; A 'compliance status' metric der...

This is one of the lowest-ranked example metrics in our collection of 150, with a pathetic PRAGMATIC score of just 9% .  What makes this one so bad? For starters, as described, it is expressed as a simple number, a count.  What are recipients of the metric expected to make of a value such as, say, 243?  Is 243 a good number or does it indicate a security issue?  What about 0 - is that good or bad?  Without additional context, the count is close to meaningless. Additional context would involve knowing things such as: The count from previous periods, giving trends (assuming a fixed period) Expected value or ranges for the count (often expressed in practice by traffic-light color coding) Verbal explanation for values that are outside the expected range Even assuming we have such contextual information, sufficient to recognize that the latest value of the metric is high enough to take it into the red zone, what are we expected to do about it? Presumably the number o...

Security Metric of the Week #11: Security budget as a proportion of IT budget or turnover Given how often this metric is mentioned, it was quite a surprise to find that it scores a measly 16% on the PRAGMATIC scale. Why is that?  What's so dreadful about this particular metric? Our prime concern stems from the validity of comparing the 'security budget' with either the 'IT budget' or 'turnover' (the quotes are justified because those are somewhat ambiguous terms that would probably have to be clarified if we were actually going to use this metric).  First of all, comparing anything to the IT budget implies that we are talking about IT or technical security, whereas professional practice has expanded into the broader church of information security.  Information security is important for anyone using and relying on information.  It could be argued that it is even more important outside of the IT department, in the rest of the business, than within it. ...

The kind of insider incidents pulled by Nick Leeson at Barings Bank and Jerome Kerviel at Societe Generale  demonstrate how much risk is associated with those in such powerful positions.  Both guys successfully bypassed sophisticated controls designed to limit their ability to take risky trading positions without proper authority, eventually causing eye-watering losses that nearly tipped over the global financial system's house of cards.   Big risk-related questions remain about this type of massive internal threat:  How many more rogue traders are still out there, doing much the same thing today?   Is it even sensible, let alone possible to draw the line between legitimate and illegitimate activities?  Given that, how can the really dangerous rogues (*) be identified from star performers? How many people in other such powerful positions are rogues (*) working for themselves rather than their employers, with dubious ethics if not outright fraudsters? ...

Security Metric of the Week #10: Number of unsecured access points As worded, this candidate metric potentially involves simply counting how many access points are unsecured.  In practice, we would have to define both "access points" and "unsecured" to avoid significant variations (errors) in the numbers depending on who was doing the counting. Depending on how broadly or narrowly it is interpreted, "access points" might mean any of the following, if not something completely different: WiFi Access Points, specifically;  Legitimate/authorized points of access into/out of the corporate network e.g. routers, modems, gateways, WiFi Access Points, Bluetooth connections  etc. ; Both legitimate/authorized and illegitimate/unauthorized points of access into/out of the corporate network - assuming we can find and identify them as such; Designated security/access control points between network segments or networks e.g. firewalls and authentication/access control g...

The following sentence is quoted directly from the top of the  first awareness leaflet I downloaded from the new website associated with a public information security awareness campaign, running in New Zealand this week: "NetSafe has heard from hundreds of people who have has their account broken into because their passwords where weak - meaning they where easily acccessed by hackers." [sic] Aside from the evident lack of competent proofreading, other concerns regarding the free security advice they are offering hardly inspire confidence in the campaign. For example, the same leaflet continues: " P ASSWORDS SHOULD BE: S TRONG: Made up of a mix of 15 letters, characters and symbols.   An example would be: Th1sI5a5tr0ngP@ssw0rd! "  Maybe the leaflet's author is not aware that: Th1sI5a5tr0ngP@ssw0rd! is not 15 characters but 22 (it should have advised " at least 15 characters", or simply said "the longer the better"). Rather than "letter...

The California State Office of Information Security and Privacy Protection publishes a fair range of awareness materials of interest to State agencies and others. Their 4-page Hostile Takeover paper gives a decent outline of multiple controls against insider threats, including the need to cater for such incidents in incident response procedures.  Good point! As with other forms of contingency planning, there are two common ways of preparing incident response procedures: Create a detailed manual explaining how to respond to a range of types of incident.  This is costly and tedious for the documentation team, since such detailed manuals are usually voluminous and complex to maintain. Keeping the manual updated, and ensuring that responders are adequately trained and aware of the latest procedures is an ongoing requirement. On the other hand, it is easier for responders to grab a manual, look up the type of incident, and follow the instructions - rather like a pilot might consul...

A recent privacy case in New Zealand raises ethical and legal concerns in relation to whether an employer can legitimately snoop on its employees using keyloggers etc . on corporate IT equipment. Although I have absolutely no knowledge of this case other than that one newspaper report (which may be accurate but is certainly not complete), and I am definitely not a lawyer, forgive me if I consider the privacy, ethics and insider threat aspects that this kind of situation raises in more general terms. From the employer's perspective, the IT equipment and network are its property, and of course it is likely that employees are using it during normal work hours when they are expected to be working for the employer. The employer would probably claim ownership of the information on its systems and network, hence using a keylogger to grab a password on an office PC and then rifling through the employee's emails could be deemed legitimate, particularly in a situation in which the emplo...