There are information risks associated with people joining any corporate function – information risks that deserve to be identified, assessed, evaluated and treated appropriately like any other. If your organisation currently pays little if any attention to these risks, how about developing and trialling a suitable strategy and approach for, say, the information risk and security management function, as a pilot or demonstrator for other corporate functions and rôles that place a high reliance on the personal integrity of their people?

This morning, Greg asked us on the ISO27k Forum for advice on ISO/IEC 27001:2022 security control A.5.7 Threat Intelligence. "I've read the details in ISO 27002 and understand it in theory. But what does a threat intelligence program consist of and look like when implemented? What tools would a infosec team use to collect threat intel, how would they analyze it and use it, etc? What have you seen in your own environments or those of clients?" FWIW here's my response: I agree with you Greg: the page of advice on threat intel in '27002 is all well and good, but what does this look like in practice? It's not entirely obvious. At a basic level, it starts with 'situational awareness' - someone simply watching out for potential or actual threats in the organisation's external and internal environments, spotting them, tracking them, thinking about and maybe responding to them. Threats become evident when incidents occur, of course, but also events and ne...

If, as many security professionals evidently believe, risk concerns the possibility of harm, then surely we ought to do everything possible to reduce the possibility and/or the harm caused, by strengthening and extending security or ideally avoiding it completely by simply not doing risky things - right? OK, so then why do we take risks at all ? Why do we need security to mitigate bad stuff? Security is costly and fallible, so can't we save money by totally avoiding or eliminating risk? Errrrrmmm  ... since it's philosophical phriday, this is an opportunity to explore the issue further, taking a deep dive. But, before I blabber on, dear reader, please take a moment to ponder this for yourself.  No, take several. Take as long as you can. Take the rest of the day off: it's phriday after all. Why do we take risks?  Seriously, why ?   What does it mean to 'take risk'? Grab a pencil or mouse. Jot something down. Think again.  Ponder on. Keep listing, scribbling,...

Last year in the course of collaboratively developing the Adaptive SME Security method , a friendly group of experts from the ISO27k Forum came up with the 'iterative risk assessment' approach. It is a pragmatic way to start a regular security improvement cycle - one that is realistic even for the tiniest of micro-businesses (sole proprietors). The process is a simplified version of conventional information risk management, tackling just one piece of the puzzle at a time. The bite-sized chunks can be picked up and chewed over as-and-when, and parked temporarily if (when!) something more urgent comes up. Each run through the cycle uses a single incident to exemplify and explore the associated risks in a way that any SME can manage - in fact, even larger organisations might benefit from this if their information risks aren't being managed effectively, to re-energise the process, or to share the work throughout the business. Time-boxing the cycle at (say) a month should avo...

I'm not a fan of new year's resolutions that tend (in my experience) to have limited impact and are often soon forgotten. My cynical self says the same thing applies to pledges, vows and other stated commitments, even agreements and contracts to some extent. They are more symbolic than actual control mechanisms (although I'm sure the lawyers would argue otherwise - on the clock, naturally). The focus is often on avoiding, preventing or stopping bad things, a negative emphasis although the actual language may be positive as in "I will lose weight" and "I will get fit". They can be a last resort, a sharp retrospective reminder of where we thought we were going when we are already heading off-course.

In a discussion thread on the ISO27k Forum about selecting appropriate information security controls, a member told us: "As far as software development is concerned, we really need the controls A8.25 and following". I queried that determination, guessing  their thought process may have been along these lines:  We do software development. Controls A8.25+ concern software development. Therefore, for conformity with ISO/IEC 27001, controls A8.25+ are applicable and cannot be excluded. #3 is patently a false conclusion, a logical error. The Annex A controls are  not  formally required for conformity with the standard. They are not mandatory - none of them, not one. If you believe otherwise, kindly explain which specific clause from ISO/IEC 27001 contains that explicit requirement because, despite hunting high and low over many years, and despite numerous claims from so-called experts in the field, I simply can't find it. There  is , however, a formal req...

Recovering from a ransomware incident is costlier, more complicated and much slower that people commonly assume. "Just restore the backups and you're good to go, right?". Spoiler alert: restoring networks and IT systems from backups is only a fraction of this.  Here's a reasonably complete set of ransomware recovery activities that would normally led by general business and IT managers : Wake up and smell the coffee! Deal with the unfolding crisis and a degree of confusion. Invoke the crisis management process. Settle things down. Assemble the business incident management team. Invoke the incident management process. Form the IT incident management team. Contact insurers, law enforcement and security experts for guidance.

In the past few days, I have been triggered yet again by someone fearing that ISO/IEC 27001 certification auditors may insist that various Annex A controls are applicable and must therefore be implemented for conformity. Apocryphal nightmares about auditors doing exactly that tend to stoke the fear and prolong the myth. Myth, yes, myth. I've said it before and no doubt I'll say it again: the Annex A information security controls are not formally required for conformity with the standard - none of them, not even one. If you or your auditors believe otherwise, kindly tell us which clause of the standard applies. What are the exact words leading to that conclusion? Spoiler alert: there are none. There is no such requirement. IT DOES NOT EXIST. There is , however, a conformity requirement to check through Annex A for any controls that might reduce otherwise untreated information risks, but even then there is no (repeat, no ) obligation to implement the controls as stated in A...

There is a growing appreciation, perhaps even consensus in the field that information risk management - or indeed risk management in general - is not simply a matter of predicting or controlling the future, at least not in a rational and deterministic manner. Given that the future is inherently complex and uncertain (= risky!), the best we can reasonably hope for is to reduce somewhat the number and negative impacts of disruptive events and incidents, while simultaneously hopefully increasing the chances and value of positive, beneficial outcomes. Both objectives are asymptotic: the effort and investment required to progress increase exponentially as we get ever closer to those two goals, ultimately putting them both beyond our means given finite resources (oh and one or two other things to pour our money into!). In other words, despite our best intentions, we know we are doomed to fail at some point.  Doomed I tell you. That's not merely a pessimistic outlook: I'm an optimist ...

Truly effective deception isn't even recognised as such - it passes completely unnoticed.  There is no shortage of now-recognised examples that the deceived didn't spot at the time and maybe still haven't noticed. Here's a sample: A stick insect appears to a predator to be an inedible stick, not a tasty insect Spotted from an enemy's reconnaisance biplane, an inflatable tank or field gun may appear solid, a credible threat at least While an accomplice distracts a resident by knocking at the front door on a pretext, the cunning thief slips around the back Phishers emulate the look and feel of legitimate emails, senders and websites to dupe victims into visiting and disclosing their credentials, using spurious urgency to shortcut or bypass checks, specific timing and wording, and sheer volume to exploit the offguard vulnerables

Recently I enjoyed a lecture by a bank's economist to local business leaders concerning the NZ economy. Observing the blizzard of graphs, I was struck by his short timeline , stretching to about a couple of years ahead. Now I'm sure the economist is earning his crust at the bank. Of course they need to keep on top of day-to-day and month-to-month fluctuations in the economic parameters, playing the markets. Equally, I'm sure the bank has other experts with a longer-term outlook, diligently modelling the implications of national and global issues including political, social, environmental and technological, for many years or decades ahead - for at least as long as the bank's mortgages and business loan periods anyway. Nevertheless, that prompted me to think about planning horizons in information risk and security management, within the broader context of budgeting and investment management in any commercial organisation - a pertinent topic as we plummet towards the new c...

Objectives are king. If strategy is the organisational or personal journey ahead, we must truly understand our objectives to move ahead confidently in the right direction, systematically measuring progress towards those objectives.  If the objectives are uncertain, well, any path will do, and our measures are largely pointless: we may know how far we've come and how much fuel we've consumed so far but we're not sure how much further we need to go, nor in what direction and at what speed. That's sub-optimal. So far so good. But what if the objectives are hidden, in conflict, or not what they seem? There are clearly potential problems with objective-led approaches - a little seething cluster of problems in fact.  So, then, it seems objectives have objectives. 

 

First, two definitions: " Certification " is the process of checking something against defined criteria, and if it passes (meets the criteria), issuing a certificate of compliance or conformity or assurance or whatever. Certification gives some assurance that the certified organisation or individual meets the criteria ... provided the certification body or person is competent and trustworthy, the checks were done properly, and the certificate itself is authentic. Hmmm, quite a few caveats there ... " Accreditation " is the process of confirming that whoever is checking and issuing certificates is properly qualified, competent and trusted to issue meaningful certificates by following prescribed processes. It adds credibility, meaning and value to the certification and issued certificates ... provided the accreditation body or person is competent and trustworthy, the checks were done properly, and the a...

  Risk and security professionals typically believe that a company's risk tolerance or risk appetite determines whether risks are or are not acceptable. However, they seldom define the terms which are used loosely and interchangeably in practice. So what are they? If you accept ( as I previously asserted in this place ) that risk is uncertainty, risk tolerance implies a willingness to tolerate or put up with a certain amount of uncertainty, while risk appetite suggests a desire for a certain amount of uncertainty.  OK so far, but what is ' a certain amount of uncertainty '? That seems paradoxical.