IT systems, devices and networks can be the targets of crime as in hacking, ransomware and computer fraud. They are also tools that criminal use to research, plan and coordinate their crimes. Furthermore, criminals use technology routinely to manage and conduct their business, financial and personal affairs, just like the rest of us. Hence digital devices can contain a  wealth  of evidence concerning crimes committed and the criminals behind them. Since most IT systems and devices store security-related information digitally, digital forensics techniques are also used to investigate other kinds of incidents, figuring out exactly what happened, in what sequence, and what went wrong ... giving clues about what ought to be fixed in order to prevent them occurring again.   It’s not as simple as you might think for investigators to gain access to digital data, then analyze it for information relevant to an incident. For a start, there can be a lot of it, distributed amon...

The first task when preparing any awareness content is to determine the objectives. What are you hoping to achieve here? What is the point and purpose? What's the scope? What would success or failure even look like? There are several possible approaches.  You might for instance set out to raise security awareness 'in general', with no particular focus. That's a naive objective given the variety of things that fall within or touch on the realm of 'security'. Surely some aspects are more pertinent than others, more likely to benefit the workforce and hence the organization? Trying to raise awareness of everything all at once spreads your awareness, training and learning resources very thin, not least the attention spans of your audiences. It risks bamboozling people with far too much information to take in, perhaps confusing them and turning them off the whole subject.  It's not an effective educational strategy. We know it doesn't work and yet, strangely,...

I recommend treating any audit as a negotiation process with risks and opportunities* for both parties i.e . auditees and auditors. Here's why. In respect of ISO/IEC 27001 compliance, the certification auditors are supposed to be for mally checking that an ISMS complies with the st andard’s formal requirements, plus information security requirements that the organization determines for its own purposes**. They are not supposed to conjure-up additional requirements out of thin air, then complain about noncompliance.  However, auditors are human and make mistakes.   So auditees are fully entitled to ask auditors to identify any requirements in the standard or in their corporate requirements that they say are not being fulfilled, if necessary down to the individual clause numbers and specific words from ‘27001, their policies etc .  B y all means discuss the wording and intent/meaning of those requirements, as well as reviewing the evidence and details of the allege...

Our awareness module on digital forensics is coming along nicely. Today, in the course of researching forensics practices within organizations, I came across an interesting report from the A ssociation of C ertified F raud E xaminers . As is my wont, I started out by evaluating the validity of the survey on which it is based, and found this: "The 2018 Report to the Nations is based on the results of the 2017 Global Fraud Survey, an online survey opened to 41,573 Certified Fraud Examiners (CFEs) from July 2017 to October 2017. As part of the survey, respondents were asked to provide a narrative description of the single largest fraud case they had investigated since January 2016. Additionally, after completing the survey the first time, respondents were provided the option to submit information about a second case that they investigated. Respondents were then presented with 76 questions to answer regarding the particular details of the fraud case, including information about the pe...

ISO/IEC 27001 concerns at least* two distinct classes of risk - ISMS risks and information risks** - causing confusion. With hindsight, the ISO/IEC JTC 1 mandate to require a main-body section ambiguously titled "Risks and opportunities" in all the certifiable management system standards was partly to blame for the confusion, although the underlying issue pre-dates that decision: you could say the decision forced the U-boat to the surface. That is certainly not the only issue with '27001.   Confusion around the committee's and the standard's true intent with respect to Annex A remains to this day: some committee members, users and auditors believe Annex A is a definitive if minimalist list of infosec controls, hence the requirement to justify Annex A exclusions ... rather than justify Annex A inclusions .   It is strongly implied that Annex A is the default set.   In the absence of documented and reasonable statements to the contrary, the Annex A controls are pre...

This week, I'm thinking about management activities throughout the metrics lifecycle. Most metrics have a finite lifetime. They are conceived, used, hopefully reviewed and maybe changed, and eventually dropped or replaced by something better.  Presumably weak/bad metrics don't live as long as strong/good ones - at least that's a testable hypothesis provided we have a way to measure and compare the quality of different metrics (oh look, here's one !). Ideally every stage of a metric's existence is proactively managed i.e. : New metrics should arise through a systematic, structured process involving analysis, elaboration and creative thinking on how to satisfy a defined measurement need: that comes first. Often, though, the process is more mysterious. Someone somehow decides that a particular metric will be somewhat useful for an unstated, ill-defined and barely understood purpose; Potential metrics should be evaluated, refined, and perhaps piloted before going ahea...

Since ISO27k is [information] risk-driven, poor quality risk management is a practical as well as a theoretical problem.  In practical terms, misunderstanding the nature of [information] risk, particularly the ‘ vulnerability ’ aspect, leads to errors and omissions in the identification, analysis and hence treatment of [information] risks. The most common issue I see is people equating ‘lack of a control’ with ‘vulnerability’. To me, the presence or absence of a control is quite distinct from the vulnerability, in that vulnerability is an inherent weakness or flaw in something e.g. an IT system, an app, a process, a relationship, contract or whatever. Even controls have vulnerabilities, yet we tend to neglect the fact that controls aren’t perfect: they can and do fail in practice, with several information risk management implications.  Think about it: when was the last time you seriously considered the possibility that a control might fail? Did you identify, evaluate and tr...

I've swapped a couple of emails this week with a colleague concerning the principles and axioms behind information risk and security, including the infamous CIA triad .  According to some, information security is all about ensuring the Confidentiality , Integrity and Availability of information ... but for others, CIA is not enough, too simplistic maybe. If we ensure the CIA of information, does that mean  it is secure? Towards the end of the last century, Donn Parker proposed a hexad , extending the CIA triad with three (or is it four?) further concepts, namely: Possession or control; Authenticity; and  Utility.  An example illustrating Donn's 'possession or control' concept/s would be a policeman seizing someone's computer device intending to search it for forensic evidence, then finding that the data are strongly encrypted. The police physically possess the data but, without the decryption key, are denied access to the information. So far, that's simply a cas...

This week I've been contemplating the right to repair movement, promoting the idea that c onsumers and third parties (such as repair shops) should not be legally denied the right to meddle with the stuff they have bought - to diagnose, repair and update it - without being forced to go back to the original manufacturer (a monopolistic constraint) or throw it away and buy a replacement (eco-unfriendly). Along similar lines, I am leaning towards the idea that products generally ought to be repairable and modifiable rather than disposable. That is, they should be designed with ‘repairability’ as a requirement, as well as safety, functionality, standards compliance, value, reliability and what have you. I appreciate that miniaturization, surface mounting, multi-layer PCBs, flow soldering and robotic parts placement make modern day electronic gizmos small and cheap as well as tough to repair, but obsolescence shouldn’t be built-in, deliberately, by default. Gizmos can still have test po...

Among other things, the awareness seminars in the SecAware awareness module on hacking make the point that black hats are cunning, competent and determined adversaries for the white hats. In risk terms, hacking-related threats, vulnerabilities and impacts are numerous and (in some cases) substantial - a distinctly challenging combination. As if that's not enough, security controls can only reduce rather than completely eliminate the risk, so despite our best efforts, there's an element of inevitability about suffering harmful hacking-related incidents. It's not a matter of 'if' but 'when'. All very depressing. However, all is not lost. For starters, mitigation is not the only viable risk treatment option: some hacking-related risks can be avoided, while insurance plus incident and business continuity management can reduce the chances of things spiraling out of control and becoming critical, in some cases literally fatal. Another approach is not just to be g...

ISO/IEC 27001:2013 section 5.2 is normally interpreted as requiring the top layer of the classical ‘policy pyramid’.   As with all the main body text in ‘27001, the wording of clause 5.2 is largely determined by: (a) ISO/IEC JTC 1 insisting on commonality between all the management systems standards, hence you’ll find much the same mandated wording in ISO 9000 and the others; and (b) the need to spell out reasonably explicit, unambiguous ‘requirements’ against which certification auditors can objectively assess conformity. Personally, when reading and interpreting clause 5.2, I have in mind something closer to “strategy” than what information security pro's  would normally call “policy” - in other words a visionary grand plan for information risk and security that aligns with, supports and enables the achievement of the organization’s overall business objectives. That business drive is crucial and yet is too often overlooked by those implementing I nformation S ecurity M ana...