In the dying days of August, just as we were busily finishing-off September's awareness module on application security, what should pop on to my screen but a new survey from Ponemon Institute on that very topic.  With some trepidation, I opened the report to see how its findings compared to our own research ... and was relieved to see that we had picked up on all seven of Ponemon's key issues, plus a few more due to our slightly wider scope.   Does your security awareness and training program cover the information security aspects of application development, acquisition, management and use?  Does it even mention mobile apps, BYOD and cloud computing?  Go ahead, dust it off and take a look.  Does it talk to business and project managers, IT pros and employees in general about relevant security aspects that matter to them, in terms that make sense and resonate?  Does it successfully prompt a productive dialogue between executives and practitioners concerning...

A multi-part blog piece by Brad Bemis suggesting the use of a simplified/standardized risk analysis process for the purposes of PCI-DSS led me to look into a quick/rough-cut information security risk assessment method   based around just ten yes/no questions, that Brad recommends. The method's inventor, Ben Sapiro, calls it " Binary Risk Analysis " [ BRA ] to emphasize those yes/no choices, implying a degree of simplicity and objectivity to the method (although some have questioned that : forcing users to choose in this manner merely causes them to collapse or shoe-horn each of their subjective opinions into one of two boxes, which  does not make them any less subjective, and if anything makes them more constrained). The ten questions in BRA lead the user through the process of evaluating the frequency and severity (albeit called "threat likelihood" and "threat impact"), key factors that are commonly used to evaluate risks. It occurred to me that it w...

Security Metric of the Week #70: delay between incident occurrence and detection While some information security incidents are immediately obvious, others take a while to come to light ... and an unknown number are never discovered. Compare, say, a major storm that knocks out the computer suite against an APT (Advanced Persistent Threat) incident.   During the initial period between occurrence and detection, and subsequently between detection and resolution, incidents are probably impacting the organization. Measuring how long it takes to identify incidents that have occurred therefore sounds like it might be a useful way of assessing and if necessary improving the efficiency of incident detection to reduce the time lag.   When ACME's managers scratched beneath the surface of this candidate security metric, thinking more deeply about it as they worked methodically through the PRAGMATIC analysis, it turned out to be not quite so promising as some initially thought: P R ...

Information Security Metric of the Week #69: proportion of information security incidents for which root causes have been diagnosed and addressed 'Learning the lessons' from information security incidents is the important final phase of the incident management lifecycle that also involves preventing, detecting, containing and resolving incidents.  Its importance is obvious when you think about it: " Progress, far from consisting in change, depends on retentiveness. When change is absolute there remains no being to improve and no direction is set for possible improvement: and when experience is not retained, as among savages, infancy is perpetual.  Those who cannot remember the past are condemned to repeat it." George Santayana This week's example metric picks up on three crucial aspects: Root causes must be determined.  Addressing the evident, immediate or proximal causes of incidents is generally a superficial and unsatisfactory approach since problems upstream ...

A news item about an NZ car park card payment system being infected with the Conficker worm, and potentially compromising customers' credit cards, is a classic example of the potential fallout from an incident that probably would not have occurred if the company concerned had been proactively tracking the appropriate information security metrics. According to Stuff.co.nz's article " Car park hack puts credit cards at risk ": "Hundreds of parking machines used by thousands of motorists a week may be infected with a virus allowing hackers to harvest credit card numbers.  A compromised machine in Wilson Parking's Alexandra St car park in Hamilton prompted security experts to warn motorists to check their credit card statements if they've recently used a machine at one of the company's 276 car parks across the country.  But Wilson Parking says there is no problem with the system.  The Hamilton machine was displaying an error message on Monday and Tuesday ...

At long last: a glimmer of hope on the ISO27k metrics front!   ISO/IEC JTC1/SC27 respondents to a questionnaire circulated by the editors responsible for revising ISO/IEC 27004:2009 acknowledge that the current published standard is wordy, academic, perhaps even unworkable, which is probably why it has achieved such a low uptake, despite the obvious need for measurements as part of an Information Security Management System.  No surprise there.  However, there are encouraging signs that the editors and project team are prepared to consider a markedly different approach, although there is some concern that the new version ought to be backward compatible with the old (one might ask “Why?” given that it is hardly being used!).  I hope publication of the current version of 27004 has not, in fact, set the field back which was the fear expressed to SC27 in the formal comments accompanying NZ’s vote against publishing the standard. Given that the editors feel “ISM...

Have you read PRAGMATIC Security Metrics yet?  What did you make of it? Does it make good sense?  Is it understandable?  Are the tips and suggestions helpful?  Is it interesting, well written, approachable, stimulating?  Is it a worthwhile addition to your bookshelf, a valuable contribution to the field - something you are already using in earnest, or that you definitely intend to put to good use?  A book you are happy to recommend to your colleagues - your peers and managers - and to the likes of (ISC)2, ISACA and SANS perhaps?    - OR -  Have you skimmed it in the bookshop or website and put it straight back on the (virtual) shelf?  Is it gibberish?  Did you buy it but wish you'd not wasted your money on it?  Is it a pathetic attempt, not a patch on the other excellent security metrics books and standards out there?  Does the casual writing style annoy you, and the footnotes distract you?  Is the PRAGMATIC approa...

While catching up with a backlog of ISO27k emails from SC27 to update www.ISO27001security.com , our ISO27k information site, a new project has me very confused.  Given the new standard's working title "T he Use and Application of ISO/IEC 27001 for Sector/Service-Specific Third-Party Accredited Certifications", w hat do you think  ISO/IEC 27009   will cover?  Few of the originally-envisaged “sector-specific” variants of ISO/IEC 27001 or 27002 have surfaced since those standards, like BS 7799 that spawned them, are deliberately broad in scope and very generally applicable.  At present, we have sector-specific ISMS variants for the telecomms, finance and healthcare industries (ISO/IEC 27011, ISO/IEC TR 27015 and ISO 27799 respectively), with something for the energy industry under development (ISO/IEC TR 27019). Rather than working on a standard for 'use and application' of sector-specific ISMS standards (whatever that means), and given that the core philoso...

Security Metric of the Week #68: business continuity plan maintenance status Business continuity plans that are out of date may be a liability rather than an asset.  Whereas ostensibly it may appear that the organization is ready to cope with business interruption, in fact the plans may be unworkable in practice due to substantial changes in the business and/or the technology and/or the people since they were written or last updated.   Furthermore, valid questions about the suitability of the continuity plans at the time they were originally prepared or updated are still more important if the organization is failing to maintain the plans. Did the inevitable assumptions and constraints involved in their preparation invalidate them?  Did they pass their tests with flying colors?  Were they ever adequately tested in fact?  Could they be trusted to work properly?  If they are not being properly maintained (which could be taken to imply their being systematical...