Welcome to the SecAware blog

I spy with my beady eye ...

13 Apr 2021

Policy development process: phase 1

On Sunday I blogged about preparing four new 'topic-specific' information security policy templates for SecAware. Today I'm writing about the process of preparing a policy template.

First of all, the fact that I have four titles means I already have a rough idea of what the policies are going to cover (yes, there's a phase zero). 'Capacity and performance management', for instance, is one requested by a customer - and fair enough. As I said on Sunday, this is a legitimate information risk and security issue with implications for confidentiality and integrity as well as the obvious availability of information. In my professional opinion, the issue is sufficiently significant to justify senior management's concern, engagement and consideration (at least). Formulating and drafting a policy is one way to crystallise the topic in a form that can be discussed by management, hopefully leading to decisions about what the organisation should do. It's a prompt to action.

At this phase in the drafting process, I am focused on explaining things to senior management in such a way that they understand the topic area, take an interest, think about it, and accept that it is worth determining rules in this area. The most direct way I know of gaining their understanding and interest is to describe the matter 'in business terms'. Why does 'capacity and performance management' matter to the business? What are the strategic and operational implications? More specifically, what are the associated information risks? What kinds of incident involving inadequate capacity and performance can adversely affect the organization?

Answering such questions is quite tough for generic policy templates lacking the specific business context of a given organisation or industry, so we encourage customers to customise the policy materials to suit their situations. For instance:

  • An IT/cloud service company would probably emphasise the need to maintain adequate IT capacity and performance for its clients and for its own business operations, elaborating on the associated IT/cyber risks.
  • A healthcare company could mention health-related risk examples where delays in furnishing critical information to the workers who need it could jeopardise treatments and critical care.
  • A small business might point out the risks to availability of its key workers, and the business implications of losing its people (and their invaluable knowledge and experience i.e. information assets) due to illness/disease, resignation or retirement. COVID is a very topical illustration.
  • An accountancy or law firm could focus on avoiding issues caused by late or incomplete information - perhaps even discussing the delicate balance between those two aspects (e.g. there are business situations where timeliness trumps accuracy, and vice versa).

The policy templates briefly discuss general risks and fundamental principles in order to orient customers in the conceptual space, stimulating them (we hope) to think of situations or scenarios that are relevant to their organisations, their businesses or industries, and hence to their management.

'Briefly' is an important point: the discussion in this blog piece is already lengthier and more involved than would be appropriate for the background or introductory section of a typical policy template. It's easy for someone as passionate and opinionated as me to waffle-on around the policy topic area, not so easy to write succinctly and remain focused ... which makes policy development a surprisingly slow, laborious and hence costly process, given that the finished article may be only 3 or 4 pages. It's not simply a matter of wordsmithing: distilling any topic down to its essentials takes research and consideration. What must be included, and what can we afford to leave out? Which specific angles will stimulate senior managers to understand and accept the premise that 'something must be done'?

OK, that's it for today. Must press on - policy templates to write! I'll expand on the next phase of the policy development process soon - namely, how we flesh out the 'something that must be done' into explicit policy statements.


11 Apr 2021

Infosec policy development

We're currently preparing some new information risk and security policies for SecAware.com.  It's hard to find gaps in the suite of ~80 policy templates already on sale (!) but we're working on these four additions:

  1. Capacity and performance management: usually, an organization's capacity for information processing is managed by specialists in IT and HR.  They help general management optimise and stay on top of information processing performance too.  If capacity is insufficient and/or performance drops, that obviously affects the availability of information ... but it can harm the quality/integrity and may lead to changes that compromise confidentiality, making this an information security issue.  The controls in this policy will include engineering, performance monitoring, analysis/projection and flexibility, with the aim of increasing the organisation's resilience. It's not quite as simple as 'moving to the cloud', although that may be part of the approach.

  2. Information transfer: disclosing/sharing information with, and obtaining information from, third party organisations and individuals is so commonplace, so routine, that we rarely even think about it.  This policy will outline the associated information risks, mitigating controls and other relevant approaches.

  3. Vulnerability disclosure: what should the organisation do if someone notifies it of vulnerabilities or other issues in its information systems, websites, apps and processes? Should there be mechanisms in place to facilitate, even encourage notification? How should issues be addressed?  How does this relate to penetration testing, incident management and assurance?  Lots of questions to get our teeth into!

  4. Clear desks and screens: this is such a basic, self-evident information security issue that it hardly seems worth formulating a policy. However, in the absence of policy and with no 'official' guidance, some workers may not appreciate the issue or may be too lazy/careless to do the right thing. These days, with so many people working from home, the management oversight and peer pressure typical in corporate office settings are weak or non-existent, so maybe it is worth strengthening the controls by reminding workers to tidy up their workplaces and log off.  It's banale, not hard! 
The next release of ISO/IEC 27002 will call these "topic-specific information security policies" focusing on particular issues and/or groups of people in some detail, whereas the organisation's "information security policy" is an overarching, general, high-level framework laying out (among other things) the fundamental principles. Our corporate information security policy template is a mature product that already includes a set of principles, so it may not need changes to comply with the updated ISO/IEC 27002 when published later this year or early next ... but we'll seize the opportunity to review it anyway. 

11 Mar 2021

NBlog Mar 11 - book review on "Cyber Strategy"



Cyber Strategy

Risk-driven Security and Resiliency

Authors: Carol A. Siegel and Mark Sweeney

Publisher: Auerbach/CRC Press

ISBN: 978-0-367-45817-1

Price: ~US$100 + shipping from Amazon



Outline

This book lays out a systematic process for developing corporate strategy in the area of cyber (meaning IT) security and resilience.  


Pros

  • An in-depth exposition on an extremely important topic
  • It emphasises risks to the business, to its information, and to its IT systems and networks, in that order
  • Systematic, well structured and well written, making it readable despite the fairly intense subject matter
  • Lots of diagrams, example reports and checklists to help put the ideas into action
  • Treating strategy development as a discrete project is an intriguing approach


Cons

  • Describes a fairly laborious, costly and inflexible approach, if taken literally and followed STEP-by-STEP
  • Implies a large corporate setting, with entire departments of professionals specializing and willing to perform or help out in various areas 
  • A little dogmatic: alternative approaches are not only possible but sufficient, appropriate or even better under various circumstances, but strategic options and choices are seldom mentioned
  • As described, the strategy planning horizon is very short
  • A defensive risk-averse strategic approach is implied, whereas more proactive, even offensive strategies can take things in a different direction: sometimes risks should not just be accepted but relished!
  • Little mention of architectural approaches e.g. business, information and IT architectures with risk and security implications and opportunities


Conclusion

Despite being described as a sequence of six STEPS (all in capitals, for some reason), there are of course way more than six activities to perform, and some are parallel or overlapping rather than sequential.

Reading, thinking about and implementing the ideas in this book should result in a soundly-constructed cyber strategy, generating far more value than the book's purchase price.  However, studying a book, even one as well-written as this one, is not sufficient to turn just anyone into a cyber strategist!  This stuff is hard.  The book makes it a little easier.

10 Jan 2021

Y2k + 20: risk, COVID and "the Internet issue"


It feels like 'just the other day' to me but do you recall "Y2k" and all that? 

Some of you reading this weren't even born back then, so here's a brief, biased and somewhat cynical recap.

For a long time prior to the year 2000, a significant number of software programmers had taken the same shortcut we all did back in "the 90s". Year values were often coded with just two decimal digits: 97, 98, 99 ... then 00, "coming ready or not!".

"Oh Oh" you could say. "OOps".

When year counters went around the clock and reset to zero, simplistic arithmetic operations (such as calculating when something last happened, or should next occur) would fail causing ... well, potentially causing issues, in some cases far more significant than others.

Failing coke can dispensers and the appropriately-named Hornby Dublo train sets we could have coped with but, trust me, you wouldn't want your heart pacemaker, new fangled fly-by-wire plane or the global air traffic control system to decide that it had to pack up instantly because it was nearly 100 years past its certified safe lifetime. Power grids, water and sewerage systems, transportation signalling, all manner of communications, financial, commercial and governmental services could all have fallen in a heap if the Y2k problems wasn't resolved in time, and this was one IT project with a hard, immutable deadline, at a time when IT project slippage was expected, almost obligatory. 

Tongue-in-cheek suggestions that we might shimmy smoothly into January 1st [19]9A were geekly-amusing but totally impracticable. 

In risk terms, the probability of Y2k incidents approached 100% certain and the personal or societal impacts could have been catastrophic under various credible scenarios - if (again) the Y2k monster wasn't slain before the new year's fireworks went off ... and, yes, those fancy public fireworks display automated ignition systems had Y2k failure modes too, along with the fire and emergency dispatch systems and vehicles. The combination of very high probability and catastrophic impact results in a risk up at the high end of a tall scale. 

So, egged-on by information security pro's and IT auditors (me, for instance), management took the risk seriously and invested significant resources into solving "the Y2k issue". 

Did you spot the subtle shift from "Y2k" to "the Y2k issue"? I'll circle back to that in just a moment. 

Individual Y2k programming updates were relatively straightforward on the whole with some interesting exceptions, mostly due to prehistoric IT systems still in use well past their best-before dates, with insurmountable hardware, software and wetware limitations. The sheer overwhelming scale of the Y2k problem was the real issue through. Simply finding all those IT systems was an enormous global challenge, let alone testing and where necessary fixing or replacing them all. The world discovered, during '98 and '99 (there I go again!) that rather few "computers" were as obvious as the beige boxes proliferating on desktops at the time, nor even the massive machines humming away in air conditioned sanctuaries known as "the mainframe". Counting the blue IBM labels was no longer considered an adequate form of computer stock-taking. Computers and chips were "everywhere", often embedded in places that were never intended or designed to be opened once sealed in place. It was almost as if they had been deliberately hidden. Conspiracy theories proliferated almost as fast as Y2k jokes. 

Flip forward 20 years and we see similar horrors unfolding today in the form of myriad IoT things and 'the cloud', so indistinct and unclear that people long since gave up trying to draw meaningful network diagrams - only now the year encoding aspect is the least of our security problems. But I digress. Back to the plot.

From what I saw, for reasons of expediency and ignorance, the general solution to "the Y2k problem" was to treat the superficial symptoms of an underlying disease that we still suffer today. We found and corrected Y2k issues in software. I believe the world as a whole missed a golden opportunity to change our software design, development, testing and maintenance processes to prevent Y2k-like issues ever arising again. Oh sure, some organizations implemented policies on date encoding, and presumably some were far-sighted enough to generalise the issue to all counters and maybe coding shortcuts etc. but, on the whole, we were far too busy baling out the hold to worry about where the ship was heading. Particularly during 99, we were in crisis mode, big time. I remember. I was there.

Instead of thinking of the Y2k work as an investment for a better future, it was treated as a necessary expense, a sunk cost. If you don't believe me, just ask to see your organisation's inventory containing pertinent details of every single IT device - the manufacturers, models, serial numbers, software and firmware revisions, latest test status, remediation/replacement plans and so on. We had all that back in 99. Oh wait, you have one? Really? So tell me, when was it last updated? How do you know, for sure, that it is reasonably comprehensive and accurate? Go ahead, show me the associated risk profiles and documented security architectures. Tell me about the IT devices used in your entire supply network, in your critical infrastructure, in everything your organisation depends upon. 

Make my day.

Even the government and defence industries would be very hard pressed to demonstrate leadership in this area.  

That's not all. Following widespread relief that January 1st 2000 had not turned out to be a cataclysmic global disaster, we slipped into a lull and all too soon "the Y2k problem" was being portrayed in the media as "the Y2k debacle". Even today, two decades on, some pundits remain adamant that the whole thing was fake news created by the IT industry to fleece customers of money.

It was a no-win situation for the IT industry: if things had gone horribly wrong, IT would definitely have copped the blame. Despite the enormous amount of hard work and expense to ensure that things did not go horribly wrong, IT still cops the blame. 

Hey, welcome to the life of every information risk and security professional! If we do our jobs well, all manner of horribly costly and disruptive incidents are prevented ... which leaves our organisations, management and society at large asking themselves "What have the infosec pros ever done for us? OK, apart from identifying, and evaluating, and treating information risks ...".

For what it's worth, I'm very happy to acknowledge the effort that went into mounting an almost unbelievably successful Y2k rescue mission - and yet, at the same time, we were saved from a disaster of our own making, a sorry tale from history that we are destined to repeat unless things change.

As I mentioned, two major areas of risk have come to the fore in the past decade, namely the information risks associated with IoT and cloud computing. They are both global in scope and potentially disastrous in nature, and worse still they are both linked through the Internet - the big daddy of all information risks facing the planet right now. 

The sheer scale of the Internet problem is the real issue. Simply finding all those Internet connections and dependencies is an enormous global challenge, let alone testing and where necessary securing or isolating them all.

You do have a comprehensive, risk-assessed, supply-chain-end-to-end inventory of all your Internet dependencies, including everyone now working from home under COVID lockdown, right? Yeah, right.

If you don't see the parallel with Y2k, then you really aren't looking ... and that's another thing: how come "the Internet issue|problem|risk|crisis ..." isn't all over the news?

Yes, obviously I appreciate that COVID19 is dominating the headlines, another global incident with massive impacts. The probability and impact of global pandemics has been increasing steadily for decades in line with the ascendance of global travel, increasing mobility and cultural blending. Although the risk was known, we failed to prevent a major incident ... and yet, strangely, the health industry isn't in the firing line, possibly because we are utterly dependent on them to dig us out of the cesspit, despite the very real personal risks they face every day. They are heroes. IT and infosec pro's aren't. I get it. Too bad.

OK, that's enough of a rant for today. I will expand on "the Internet issue|problem|risk|crisis" in a future episode. Meanwhile, I'll click the Publish button in just a moment, while it still works.

15 Nov 2020

NBlog Nov 15 - the trouble with dropping controls

I literally don’t understand a question that came up on the ISO27k Forum this week. A member asked:


‘Should a control be discontinued because a reassessment showed a lower acceptable risk score?’ 


I find it interesting to pick apart the question to explore the reasons why I don't understand it, and the implications. See what you think ... 

  • Any control may legitimately be ‘discontinued’ (removed, unimplemented, retired, replaced, modified etc.) provided that change has been duly thought-through, assessed, justified, and deemed appropriate for whatever reasons. It may be important, though, to be reasonably certain that discontinuation is, in fact, in the best interests of the organization, and that’s often hard to determine as controls can be quite complex in themselves, and are part of a highly complex ‘control environment’. A seemingly trivial, unimportant, even redundant control (such as an alert) might turn out to be critical under specific circumstances (where other alerts fail, or were accidentally disabled, or were actively and deliberately bypassed by an attacker or fraudster). So, it may be preferable to ‘suspend’ the control for a while, pending a review to determine what the effects truly are … since it is probably easier and quicker to reinstate a ‘suspended’ control if needs be, than it would have been if the control was completely removed and trashed. A dubious firewall  rule, for example, might be set to 'warn and log only', rather than simply being dropped from the ruleset, the reverse of how new firewall rules can be introduced.  On the other hand, a control that is patently failing, clearly not justifying its existence, is a strong candidate to be removed … and potentially replaced by something better (which opens a whole new topic).

  • A ‘reassessment’ might be a reassessment of the risks, the control, the control effectiveness, the business situation, the compliance obligations/expectations, the alternatives and supporting/compensating controls, or something else:  ‘reassessment’ is a very vague term.  It might mean anything on the range from ‘someone changed their mind’ to ‘a full independent investigation was launched, producing a lengthy report that formally discussed all the options including a recommendation to remove the control, which the management body duly considered and authorized, with various caveats or controls around the way it was to be done …’!

  • ‘Lower acceptable risk’ might mean ‘We reduced our risk acceptance level’ but that’s ambiguous – it could mean that you are accepting a lower level of risk than before (management is more risk-averse) or the polar opposite i.e. the level of risk that can be accepted has been reduced (management is more risk-tolerant)!  More likely, the member who posed the question simply missed a comma, intending to say ‘a lower, acceptable risk score’ suggesting that he have decided the risk does not warrant retaining the control, hence ‘discontinuation’ is an option to be considered, as already discussed. 

  • ‘Risk score’ hints at yet another potential minefield - one I've discussed repeatedly here on NBlog. How are risks being ‘scored’, exactly? How certain are you that a reduction in the score genuinely reflects a reduction in the risk? If you are totally happy with your risk evaluation and scoring process, why has this question even arisen? If you have some doubts or concerns about the process, discontinuation of a control may not be a sensible approach without additional assurance and assessment, and perhaps the ability to reinstate the control efficiently if it turns out to be needed after all.

  • More generally, removal of, or deliberate decisions not to implement, controls can be a challenging, problematic concept for risk-averse information security professionals. We are naturally biased towards risk reduction through controls. It’s an inherent part of our mind-set, a default approach.  The rest of the world does not necessarily think the same way! To ‘a level-headed business person’, controls may be perceived as costly constraints on business … which means they need to be justified, appropriate and necessary, and worth having i.e. they have a positive net value to the business (benefits less costs, ideally taking full account of ALL the benefits and ALL the costs). Ineffective controls, then, have a negative net value (no benefits, only costs) and are clearly candidates for removal … but removing controls is itself an activity that has risks, costs and benefits too.

That's a confusion of complexity and doubts arising from such a short question! Am I seriously over-thinking it? Well, yes, maybe I am. Still, it amuses me to exercise my grey matter, and I hope I've stimulated you to dig a little deeper when you see a question that furrows your brow. I've said before that some of the most insightful discussion threads on ISO27k Forum arise from seemingly naïve or trivial questions that might easily have been overlooked.


PS  Sorry for the lack of NBloggings lately - too busy with/engrossed in work, which is A Good Thing.

8 Oct 2020

NBlog Oct 8 - is Facebook an asset?

Yet another good question came up on the ISO27k Forum today*. Someone asked whether to add the company's Facebook page to their information asset register (implying that it would need to be risk-assessed and secured using the Information Security Management System processes), or whether the asset should be the Facebook account (ID and password, I guess)**.

From the marketing/corporate perspective, good customer relations are perhaps the most valuable information assets of all, along with other external relations (e.g. your suppliers, partners, prospective and former customers, regulators/authorities and owners) and internal relations (the workforce, including staff, management, contractors, consultants and temps, plus former and prospective workers). It’s tempting to think of these as just categories or faceless corporations, but in reality the interactions are between individual human beings, so social relations in general are extremely important in business. 

There are numerous mechanisms that generate, support and maintain good customer relations, Facebook for example. Likewise for other relations (e.g. ISO27k Forum!). You might think of them as simply apps or information services, often cloud based, often commercial services provided by third parties hence limiting what is on offer and your options or influence over the infosec, privacy and other requirements. 

There are also related processes and activities, some of which have infosec, privacy and other implications e.g. I have a bank pestering me right now for identification info which they need from me as part of the anti money laundering regs: it’s a pain for me and for them, but they have to comply with the laws and regs. Workforce relationship management and ‘industrial relations’ is a huge part of ‘management’, with governance, compliance and other implications and risks. Overall, relationship management is, clearly, an important part of business success, or indeed failure when things go horribly wrong (e.g. look up the Ratners jewelers fiasco in the UK, and just look around at the difficulties arising from COVID-19: our people and myriad relationships are under extreme stress this year, not just our organisations).

Summing up, I encourage everyone to think big in terms of the scope of information assets, with a strong emphasis on the information that matters most to the business, the organization, and its strategic objectives. The IT systems and services are merely business tools: what matters most is the business information generated/processed by them.

* As I've said before, it's funny how often a simple, seemingly basic or naive question on ISO27k Forum leads to something more revealing when the answers and debate start flowing: such is the power of social media! 

** My answer to the original question is "Both ... and more besides"! It was a false dichotomy.

27 Sept 2020

NBlog Sept 27 - 2021 infosec budget
























Are you responsible for your organisation's information security or cybersecurity budget? Are you busily putting the finishing touches to your 2021 budget request, still working on it, just thinking about it, or planning to do it, honestly, when you next come up for breath?

Budgeting is generally a dreaded, stressful management task. Not only do we have to figure out the figures but we typically anticipate a tough battle ahead leading (probably) to a disappointing outcome and yet more problems.

On top of that, 2020 has been an exceptional year thanks to COVID. The business and information security implications of knowledge workers suddenly working from home, en masse, are still playing out now, while the economic impacts of COVID do not bode well for any of next year's budgets except perhaps for the manufacture of vaccines, masks, gloves, sanitiser and respirators.

A substantial part of information security expenditure is (whatever we may believe as professionals) discretionary. The decision to go for ISO/IEC 27001 certification, for instance, flows largely from management's appreciation of the business value of investing in information risk and security management good practices. There may be specific drivers such as incidents, compliance pressures or demands from business owners, partners and prospective customers, but even then there are numerous options and factors to consider such as:
  • The objectives for the Information Security Management System - what it is expected to achieve;
  • How broadly or narrowly to scope the ISMS;
  • At what pace to implement the standard, and how precisely;
  • What resources to assign to the implementation, not least a suitable implementation project manager/consultant and project team;
  • Priorities for this work relative to other business activities, objectives and requirements, making adjustments as necessary (both initially and as the project proceeds when stuff comes up - as COVID did, for instance);
  • Alignment with other corporate projects and initiatives e.g. exploiting strategic opportunities to update various systems, policies and processes for security and other reasons, at the same time;
  • Change management aspects: does the organisation have the capacity and appetite first to adopt and assimilate the ISMS, and secondly to get the most out of it; 
  • Project risks e.g. the possibility that things probably will not go entirely to plan, hence the need for dynamic responses and contingency funds.
Identifying and addressing all that, and more, means a shed-load of work for management at this time of year. Not only must cunning plans be developed, they must be 'sold' to the organisation - particularly senior managers responsible for the big decisions about strategies, budgets, resourcing etc. but also the managers of other corporate departments/functions who are all, in effect, competing for slices of the same pie.

An important preliminary step, then, is to convince senior management that a 'management system' or 'governance framework' for information risk and security is more than just a matter of best practices or compliance. It gives managers the information and levers necessary to direct, guide and monitor information security, supporting and enabling the achievement of business objectives. 

With that established, it is worth exploring the additional business value of certification.  An ISO27001 compliance certificate from an accredited and respected certification body is like a stamp of approval ... but there's more to it. Consider our business case for an ISMS for strong clues about how to persuade management that implementation makes sense for the business.  Taking it all into account, the benefits are overwhelming.  You'd be nuts not to at least explore the possibility as part of your proposals for 2021.

24 Sept 2020

NBlog Sept 24 - status of ISO27001 Annex A

One of the recurrent (zombie) threads on the ISO27k Forum concerns the status of ISO/IEC 27001:2013 Annex A. Typically the zombie is prodded from its slumber by a relatively inexperienced member naively suggesting that certain security controls from Annex A are essential, implying that they are mandatory for certification.

In the course of debating and attempting to bury the zombie, some members trot out their own curious interpretations of the standard, pointing out actual and apparent discrepancies in the wording which, to them, indicate that Annex A is at least partly mandatory. I'm too polite to say they are wrong, but I believe they are misguided or mistaken - partly, it must be admitted, because the standard is ambiguously worded in some areas, hence it has to be interpreted carefully in practice.

To be clear, based on my three decades' professional experience and membership of ISO/IEC JTC 1/SC 27, my position is that none of the controls outlined in Annex A are mandatory. None at all. Zero.

This is a fundamental but complex issue to explain, so please forgive this lengthy post. In hope of decapitating the zombie, once and for all, I feel the urge to explain in detail.

To kick off, I’ll emphasise the critical distinction between two key terms:

  • Mandatory requirements are formally described in the main body of ISO/IEC 27001:2013. ALL organisations absolutely MUST do all those things and will probably need to convince the certification auditors of that in order to be certified compliant with the standard;
  • Discretionary items such as the controls summarised in Annex A are options to be considered - suggestions or recommendations, good practices you could say. Clause 6.1.3 indicates that management has much more latitude in this area provided they follow the mandatory information risk management processes from the main body, and again they may need to convince the certification auditors that they diligently followed the specified processes. Most organisations find many of the Annex A controls applicable, but seldom all of them. In the extreme, a few brave organisations choose to exclude ALL of the Annex A controls precisely as worded in the standard, instead electing to use custom controls, even if many in fact end up strangely similar to the Annex A outlines: they are merely word-smithed fine-tuned variants. 

There are touch-points between the management system (as formally specified in the main body of '27001) and the information security controls (as succinctly outlined in annex A). However, both conceptually and practically, they are distinct parts to the standard with specific implications for certification.

Here's an example. Any management system, such as an ISMS, revolves around and depends upon management information. That management information has various associated information risks and security requirements. For example, there are information risks associated with the security metrics (which are a mandatory part of the ISMS, as specified by the main body clause 9.1 “Monitoring, measurement, analysis and evaluation”) requiring risk treatments, typically through information security controls to protect that management information – controls that may be selected from Annex A, or from any other source, perhaps even created from scratch by creative thinking and innovation. 

The standard does not demand specific Annex A controls to protect the security metrics or other management information: the organisation evaluates the risks and chooses whichever controls best suit its purposes – in other words, the controls are discretionary but, for certification, the risk management process for selecting and implementing various controls must comply with the main body requirements. 

The touch point comes in clause 9.1 part (b): “The organisation shall determine … the methods for monitoring, measurement, analysis and evaluation, as applicable, to ensure valid results; NOTE The methods selected should produce comparable and reproducible results to be considered valid.” So here is a main body mandatory requirement to ensure the validity of the ISMS metrics, but notice there is no explicit requirement to use certain controls from Annex A. The organisation determines for itself how to ensure its security metrics are valid, and in practice the controls in this area vary between certified organisations. That’s fine, so long as they each followed the information risk management process defined by their ISMS, and those ISMSs in turn fulfil all the mandatory requirements of the standard.

To confuse matters a little, there are in fact some discretionary aspects to the main body of ‘27001, dotted in amongst the mandatory requirements. Clause 6.1.3 is a classic example: the organization “shall define and apply an information security risk treatment process” … but the process it describes has management selecting controls, taking account of things, determining which controls are ‘necessary’ etc. That’s a blend of mandatory and discretionary requirements. 

Another confusion is caused, unfortunately, by the use of the reserved term “shall” throughout the standard including Annex A. “Shall” normally denotes mandatory requirements in ISO-land. Personally, I think SC 27 made a mistake in changing “should” in the drafts of ‘27001 Annex A to “shall” in the published version, a change that happened quite late in the drafting process as I recall, with the publication deadline looming. On the other hand, the change was a compromise that placated those on the committee who were adamant and had been passionately arguing that some of the Annex A controls are universally required and ought to be mandatory. It also (I think) satisfied an ISO directive about the wording to be used in the management systems standards - a double whammy. 

Anyway, the upshot is that we’ve ended up with ‘a camel – a racing horse designed by committee’. This, along with the ambiguous wording of clause 6.1.3 about Annex A and even the explicit titling of Annex A as “(normative)”, are anomalies that will hopefully be resolved when ‘27001 is revised and reissued. The intended and formally specified status of Annex A remains the most contentious aspect of ‘27001 for SC 27. This is one persistent resilient awkward bugger of a zombie!

4 Sept 2020

NBlog Sept 4 - standardising ISMS data interfaces



We've been chatting on the ISO27k Forum lately about using various IT systems to support ISO27k ISMSs. This morning, in response to someone saying that a particular tool which had been recommended did not work for them, Simon Day made the point that "Each organisation trying to implement an ISMS will find it’s own way based on their requirements."

Having surveyed the market for ISMS products recently, I followed-up with my usual blurb about organisations having different information risks and business situations, hence their requirements in this area are bound to differ, and in fact vary dynamically (in part because organisations mature as they gain experience with their ISMS: their needs change). The need for flexibility is why the ISO27k standards are so vague (essentially: figure out your own requirements by identifying and evaluating your information risks using the defined governance structure - the ISMS itself), rather than explicitly demanding particular security controls (as happens with PCI-DSS). ISO27k is designed to apply to any organisation. 

That thought sparked a creative idea that I've been contemplating ever since: wouldn’t it be wonderful if there was a standard for the data formats allowing us to migrate easily between IT systems supporting ISO27k ISMSs?

I’m idly thinking about a standard file format with which to specify information risks (threats, vulnerabilities, impacts and probabilities), controls, policies, procedures, metrics, objectives etc. - maybe an XML schema with specified field names and (where applicable) enumerated lists of values.

Aside from migrating between ISMS IT support systems and services, standard data formats would facilitate data sharing between application systems, services or sub-functions (e.g. for vulnerability management, incident management and information risk management), and between departments or even organisations (e.g. insurance companies, auditors and advisors and their clients and partners).

Perhaps we should develop an outline specification and propose such a standard to ISO/IEC JTC1 SC 27. A New Work Item Proposal would need sufficient details to be clear about what is being proposed and why, expanding on the requirement. Researching the topic and generating a basic draft as a starting point would ease the process of developing an ISO27k standard, so that's something else to add to my to-do list. I wonder if there are already XML schemas in this general area?

3 Sept 2020

NBlog Sept 3 - ISO27001 rocket fuel




We're on a mission to convince every organisation that managing information risks properly is more than just a compliance imperative. It's good for business.

Is your organisation looking to raise its security game? Are managers worried about ransomware, privacy breaches and intellectual property theft, especially now with so many of us working from home? 

What about the business continuity risks as supply chains are stressed to breaking point by COVID-19? Are your suppliers cutting corners on privacy and security, hoping nobody will notice? Are desperate competitors taking advantage of the disruption to undermine your cyber-defences?

Worse still, is management blissfully unaware of the issues, with everyone heads-down, rowing hard, too busy to notice the icebergs dead ahead?

... Or is there a strong drive to secure and exploit information as an integral part of operations? Does being trusted by customers and stakeholders equate to brand value, new and repeat business, opening up strategic opportunities?

This is a great opportunity to
take the first step on your mission!

We have developed a modular approach based on ISO/IEC 27001. An Information Security Management System facilitates the management of information risks, information security controls, governance and assurance arrangements and so forth, 'systematically' i.e. in a structured and coherent way.

Despite being standards, ISO27k acknowledges that each organisation needs to adapt the ISMS according to the business situation and the associated information risks. Within the same general governance structure, the specific requirements vary markedly between organisations and industries. With that in mind, we've developed a suite of materials covering the mandatory requirements for every ISMS, plus add-ons for the discretionary parts. In truth, all of them - even the mandatory ones - are templates, designed to be customised ... and we can even help you with that if you like!

Through SecAware.com, we offer several packages:
  • ISMS Launchpad is a minimalist set of templates for the mandatory documentation that certification auditors are likely to insist upon - the ISMS scope, SOA, RTP and others.  Start here! 
  • ISMS Take-off adds a bundle of management-level documents. An ISO27k ISMS is, after all, a management system. There are template policies, procedures, job descriptions and more, designed to inform and engage management in the ISMS. If you don't yet have the go-ahead, build on the business case and strategy papers to convince the boss. 
  • ISMS Orbit, released this week, provides templates aimed at bringing your information security and related professionals/specialists rapidly up to speed with ISO27k. These are lengthier, more detailed documents on the whole, for example an 85-page FAQ about implementing the standards, and a hyperlinked glossary of over 350 pages (basically a book!). 
  • ISMS Mission bundles all of the above, saving you 30%.
Browse the SecAware website for listings of the modules and a few samples. 

I wrote all the materials hence the whole suite is consistent, reflecting my three decades in the field, using and contributing to the ISO27k standards while working/consulting for all manner of organisations around the world. I'm confident you won't find better quality templates anywhere else ... but if you do, or if you see gaps in our coverage, please let me know. This is a new product and we are already looking to enhance it, before the ink is even dry. On the horizon I see the possibility of further templates supporting the security controls in Annex A - more policies, more procedures, more metrics, awareness content, more advice and guidance ... 

Must dash, lots to do!