Prompted by a thread on the ISO27k Forum, I've been contemplating the categorisation planning process I mentioned in yesterday's blog.
Patrick says:
"There are 70 questions that can be asked to determine whether an enterprise has most defensive principles covered and has taken steps to reduce risk (and entropy) associated with cybersecurity. If you can answer “Yes” to the following 70 questions, then you have significantly reduced your cybersecurity risk. Even so, risk still exists, and entropy must be continuously monitored and mitigated. There is no specific number of layers that can remove all risk, just as there is nothing in the physical universe that does not experience entropy."
"If your organization has customers that ask you to complete questionnaires before engagement, track those against logos added or better revenue brought in. You’re now tracking your return on investment and a key risk of if your security is not good enough, those are the businesses you loose.Do the same with each customer that asks for your ISO certification or SOC 2 report.You have an excellent metric that allows you to track that return on investment and shows security as a revenue generating part of the organization.My organization’s last quarter internal company meeting had the Senior Revenue officer publicly acknowledge and thank InfoSec for our role in landing their biggest customer.It doesn’t get much better than that."
My next book will be a 'hyper-glossary' of terms relating to information security, including closely related aspects such as information risk management, governance, compliance ... and more ... and there's the rub: I'm struggling to catch up/keep up with developments in the field, not least because of the rate at which novel concepts are introduced and new terms are coined.
Here's an example of a definition originally added a couple of years ago and most recently amended today:
There I've defined "Deep fake", one of several terms washed up in the AI tsunami. The underlined terms are hyperlinked to their definitions ... and so on forming an extensive web within the document.
'Bias' is generally considered a negative human trait with both practical and ethical implications. Paradoxically, however, that negativism can itself be considered a form of bias. Bias can - sometimes - be positive, beneficial, even necessary, and is to some extent an inevitable consequence of our biology.
In Darwinian terms, 'cognitive bias' comprises a fairly diverse set of behavioural traits that have evolved over the millennia, such as:
The fact that these traits exist today strongly suggests that they confer evolutionary advantages. Biases evidently have their biological utility and value, helping biased individuals survive, prosper and procreate somewhat more efficiently than the unbiased.
I repeat, bias (imbalance) is natural.
Among all the other bad news in the excellent Cy-Xplorer 2023 report from Orange Cyberdefense, this nugget of threat intelligence poked me in the eye:
I've become increasingly concerned about the information risks relating to professional services in recent years. They seem obvious targets for malicious cyber attacks, given:
The second edition of ISO/IEC 27032 "Cybersecurity - Guidelines for Internet security" has just been published.
The introduction to the new edition commences:
"The focus of this document is to address Internet security issues and provide guidance for addressing common Internet security threats, such as:— social engineering attacks;— zero-day attacks;— privacy attacks;— hacking; and— the proliferation of malicious software (malware), spyware and other potentially unwanted software."
JC's repeated assertions that 'cybersecurity is not purely technical' caught my beady eye: the 'cyber' bit clearly suggests that it is 100% purely tech ... but those of us who have swallowed the ISO27k pill recognise that information security requires more than just securing the bits-n-bytes. This is yet another example of the confusing use of language - specifically 'cyber'. Many professionals immersed in the field take 'cyber' implicitly to include technology plus other aspects but the general perception Out There is very strongly and perhaps exclusively technical.
For the majority, cybersecurity equates to IT security or, more specifically still, it refers to hacker attacks and malware infections via the Internet. For that reason, the recently revised and reissued standard ISO/IEC 27032, formerly on 'cybersecurity', was re-titled to clarify that it covers Internet security, specifically - an important part of the information security landscape and cyber area, but not the whole thing. It falls short on intellectual property protection, for instance, plus insider threats and plan ol' fashioned accidents that cause a significant number of incidents, despite not being 'attacks'.
"advice on where (in cases of an ISO audit) and how (in cases of an Internal audit) our ISMS could/should be improved, but I need that advice to be meaningful, grounded, and delivered in a way that has the best probability it will be absorbed by the business. In other words, I would like this process to offer real value to the business, besides just being seen as a transactional, bureaucratic overhead."
... which seems entirely appropriate and ethical to me. Nicely put!
Fuelled by two strong coffees, I've been mulling over a further response from my pal Chris Hall - an experienced and respected auditor and consultant who expressed the opinion that the role of a certification auditor is:
"... simply to assess whether the organisation conforms to the requirements of clauses 4 to 10 of ISO27001. That is all. And to report on it, pointing out where the ISMS does not conform ..."
I see things a little differently and (as usual!) more complex/nuanced in practice than Chris indicates.
ISO/IEC 27001 is a succinct, formally-worded standard for two key reasons:
There are many things the standard does not specify at all, or at least not in detail, for example here is clause 6.3 (new to ISO/IEC 27001:2022):
6.3 Planning of changes
When the organization determines the need for changes to the information security management system, the changes shall be carried out in a planned manner.
That's it, the entire specified requirement consists of a 3-word heading and a single 24-word sentence.
Oh boy.
Let's explore that one example in more detail - a deep dive into interpreting the precise language of the standard [dons lawyer's flash suit and all-knowing smirk] ...
On LinkeDin this morning, Morten Ingvard asked:
"As part of updating and reshaping some parts of our information security management system (ISMS), I'm not convinced that the new categorization of controls in ISO/IEC 27002:2022 (Organizational, people, physical and technical), is the best suit for our organization to rationally identify relevant controls for their work. I understand there is an increased focus on the use of attribution - so controls can be selected based on different perspectives, but I want to have a "default view" that the organization can read and understand, and currently, I'm strongly considering sticking with a categorization structure looking more like the older 2013-version in ISO/IEC 27001."
Here's my response to Morten:
"The categories are primarily a convenient way to sequence the controls in the standard. It was the 'default view' selected by ISO/IEC JTC1/SC27.
"The CIS Critical Security Controls® (CIS Controls®) started as a simple grassroots activity to identify the most common and important real-world cyber-attacks that affect enterprises every day, translate that knowledge and experience into positive, constructive action for defenders, and then share that information with a wider audience. The original goals were modest—to help people and enterprises focus their attention and get started on the most important steps to defend themselves from the attacks that really mattered."
[CIS Critical Security Controls v8]
Finding weaknesses/concerns and improvement opportunities in the organisation's information risk, security and related arrangements is a valid and potentially valuable outcome of an ISO/IEC 27001 certification audit. Arguably, however, that is what the management reviews and internal audits are supposed to achieve.
Certification auditing is primarily intended to provide assurance for the organisation and third parties that the organisation has correctly interpreted and implemented the standard, a specific key objective.
"I intend to provide the information, tools/techniques and impetus to:
- Change the way you think about information risk;
- Help you make better management decisions – ‘better’ in the specific sense of ‘more appropriate for your organisation, more likely to achieve the associated objectives’;
- Motivate you to do things more rationally, sensibly, effectively and efficiently, making best use of the available resources, not least your own cognitive abilities and valuable time;
- Encourage you to think about what is going on around you in risk management terms, in particular spotting creative opportunities as well as risks, seeing ‘security’ and ‘controls’ as just one way to tackle the myriad situations before you."
Towards the end of last year, I wrote a series of blog entries expanding on 20 terms of art, mostly for fun, partly for education, and partly as an exercise in creative thinking ... and today I'm doing it again.
As a recap, here are the original 20:
Today, I'm nose-to-the-grindstone, writing my book on information risk management, doing my best to 'tell a good story'. I'm trying to make sense of the jumble of concepts and thoughts in my head, hopefully expressing things clearly enough for readers to understand and be inspired to think and do things differently. It's hard work!
Just because the book is non-fiction doesn't stop it being creative, so I've returned to the listing technique I used last year, elaborating on it a little. The revised process is:
I've been thinking about the 'treatment' phase of risk management lately. These are the four conventional and generally-accepted ways of treating (addressing) identified risks:
Over the past decade or so, 'supplier questionnaires' have become A Big Thing in the business world.
Organizations have long appreciated that there are risks associated with doing business (well, fancy that!) and most quite reasonably wish to mitigate those risks, particularly in business-to-business relationships. Increasingly that involves checking out prospective suppliers' information security and privacy arrangements* as part of the supplier evaluation, selection and contracting process. A common approach is to ask prospective and current suppliers to complete security/privacy questionnaires. Being self-assertions by organizations with an obvious interest in securing the business, the assurance value of questionnaires is limited although it may be reinforced by suitable legal wording in the contracts and agreements arising: essentially, the suppliers formally confirm that their questionnaire responses are accurate, complete and valid, and/or formally accept their security and privacy obligations going forward.
That's all very well from the customer perspective, but what about the prospective suppliers? Aside from the administrative overhead of answering numerous and often lengthy questionnaires, there's the issue of being pressured into disclosing sensitive and valuable information. Remember, this step is often before contracting or building mutual trust through productive working relationships.
* By the same token, if an organization intends to disclose or share sensitive or valuable information with its partners, customers or the authorities, it ought to be every bit as concerned about the recipients' information security and privacy arrangements before proceeding.
Lately, I've read a couple of articles complaining that metrics are driving things inappropriately, either stating or implying that metrics should be abandoned.
It's pretty obvious (if you think about it) that measuring the wrong things is - at best - a pointless waste of effort, and potentially harmful if it leads things in the wrong directions, taking attention from the things that truly matter.
Likewise, measuring the right things in the wrong way leads to disappointment and frustration.
However, neither of those issues is a valid argument to stop measuring. They are good reasons to measure the right things competently, easier said than done maybe but surely better than the alternative.
I've already mentioned which are the right things to measure: the Things That Truly Matter. Of course that is context-dependent, and changes over time ... so one approach is to consider the organisation's long-term (strategic), mid-term (tactical) and short-term (operational) objectives. For bonus points, recognise that those are linked, not independent variables: operating activities support the achievement of tactical goals and strategic objectives.
Measuring things competently implies using the appropriate measurement approaches to gather, analyse, report, and most of all use metrics sensibly. A useful approach here is to work backwards along that sequence: how and what the metrics will ultimately be used for determines what needs to be reported (along with how, by whom, when and in what format), indicating the need for suitable statistics and commentary, hence a reasonable specific demand for raw data on the subject matter.
OK, I'll leave it there for today. There's a chainsaw with my name on it, and a couple of trees in the wrong places.
In the management context, measuring requires that we consider aspects such as:
“Electrical and electronic equipment contains a complex mix of materials, components and substances, many which can be poisonous, carcinogenic or toxic in particulate or dust form. Destruction and disposal of WEEE [Waste from Electrical and Electronic Equipment] needs to be managed carefully to avoid the potential of serious health risk or environmental hazard.”
This pragmatic guideline explores the information risks associated with AI/ML, from the perspective of an organisation whose workers are using ChatGPT (as an example).
Having identified ~26 threats, ~6 vulnerabilities and dozens of possible impactful incident scenarios, I came up with ~20 information security controls capable of mitigating many of the risks.
See what you make of it. Feedback welcome. What have I missed? What controls would you suggest?
When, for instance, a real-world client reads a human expert advisor's report or consultant's recommendation, they are generally:
Forumites duly offered advice and agendas. So far so good!
However, I made the point that ISO/IEC 27001 does not require/insist that management reviews take the form of periodic management meetings, specifically, although that is the usual approach in practice.
Personally, since they are both forms of assurance, I advise clients to plan and conduct their ISMS management reviews and ISMS internal audits similarly, with one critical and non-negotiable difference: auditors must be independent of the ISMS, whereas management reviews can be conducted by those directly involved in designing, operating or managing the ISMS. This is not merely a compliance matter or protectionist barrier: auditor independence brings a fresh perspective and valuable insight that insiders simply cannot match.
In my considered opinion, independence and formality follow a continuum through these activities:
One straw-man argument is that 'managing by the numbers' can imply a myopic focus on commonplace business metrics such as stock price or annual profit, both of which can be manipulated to some extent by managers even at the expense of long term resilience and commercial success, let alone other business objectives. Despite Taylor's outmoded 'scientific management' experiments having been debunked a century ago, some LinkeDinners in the thread evidently still believe that science (in the form of numeric data) and management are poles apart.
I beg to differ. That's so last century!
Management is complex, dynamic and nuanced, hence I accept that simplistic or crude metrics can't possibly address the entire practice. For example, speed is obviously a key metric for a racing car: however, going fast is just one part of racing, even on the drag strip. Staying on-track with both vehicle and driver holding together for the duration of a meet are also important for the team manager, the whole team in fact. An exploding drag car might conceivably project sufficient material across the line to qualify in record time, but there would be nothing left to compete in the final!
I've long been fascinated by the concept of 'resilience', and surprised that so many people evidently misunderstand and misrepresent it ... so please bear with me as I attempt to put the record straight by explaining my fascination.
Resilience is not simply:
