The bloggings will continue ...

This blog has been renamed

noreply@blogger.com (Unknown) — Sun, 13 Nov 2022 04:50:00 +0000

Wondering why things have gone so quiet lately?

The bloggings continue apace over at https://secawareblog.blogspot.com/

Unless you intended to drop out,
please update your blogrolls,
blog trackers, bookmarks or whatever.

Otherwise, goodbye
and thanks for all the fish

noreply@blogger.com (Gary) — Thu, 18 Aug 2022 04:01:00 +0000

This blog is moving to a new home.

Future blog postings will appear as if by magic at:

https://secawareblog.blogspot.com/

To continue receiving this stuff, please update
your bookmarks and blog aggregators accordingly.

Rest assured: the bloggings will
continue until morale improves.

We have migrated the content as far back as 2007
to the new URL just in case it remains of interest or
entertainment value to anyone. Paleontologists maybe.

You can browse and search for keywords
at the new URL just as here.
It's the same, only better-er.

If you've had enough already,
this is your big chance: do nothing
and this will be the last blog piece
you'll receive from me.
Chillax.
Don't even lift a finger.
The present blog URL will disappear
in a puff of logic at some point.

In the immortal words of Douglas Adams' dolphins,
so long and thanks for all the fish.

Control is ...

noreply@blogger.com (Gary) — Mon, 15 Aug 2022 02:00:00 +0000

... technical, physical, procedural, legal, social, mechanical, economic, political ...

... applied to processes, systems, machines, people, quality ...

... [a] "measure that maintains and/or modifies risk
Note 1 to entry: Controls include, but are not limited to, any
process, policy, device, practice or other conditions and/or
actions which maintain and/or modify risk.
Note 2 to entry: Controls may not always exert the
intended or assumed modifying effect.
[SOURCE: ISO 31000:2018, 3.8]

... a volume knob that goes all the way to 11

... automated, semi-automated or manual

... an illusion induced by acquiescence

... preventive, detective or corrective

... avoiding or preventing badness

... what happens in the tower

... defining and applying rules

... an action/adventure game

... an availability challenge

... an engineering solution

... local, remote or hybrid

... hitting the sweet spot

... about mitigating risk

... keeping within limits

... a means to an end

... binary or analogue

... providing direction

... setting boundaries

... negative feedback

... power superiority

... being in charge

... being resilient

... an impression

... management

... containment

... proportional

... governance

... oppression

... confidence

... an illusion

... unreliable

... constraint

... regulation

... assurance

... imperfect

... influence

... coercion

... mastery

... the key

... stability

... a belief

... a state

... power

... fragile

... costly

... a key

... finite

... rules

... key

...

The business case for security strategy and architecture

noreply@blogger.com (Gary) — Mon, 08 Aug 2022 23:20:00 +0000

The business benefits of developing an information security strategy and accompanying security architecture/design include:

Being proactive, taking the lead in this area - more puppeteer than puppet;
Designing a framework or structure to support the organisation's unique situation and needs;
Positioning and guiding the management of information risk and security within other aspect of the organisation's architecture/design e.g. its IT and information architecture (showing information flows, networked systems, databases, services etc.), complementing and supporting various other business strategies and architectures such as cloud first, artificial intelligence, IIoT, big data, new products, new markets ...);
Providing a blueprint, mapping-out and clarifying the organisational structure, governance arrangements and accountabilities for information risk and security relative to other parts of the business such as IT, physical security, Risk, legal/compliance, HR, operations, business continuity, knowledge management ...;
Defining a coherent sequence or matrix of strategic initiatives (projects, investments, business and technology changes ...) over the next N years, embedding information risk management ever deeper into the fabric of the organisation and strengthening the information security arrangements in various ways (e.g. systematically phasing-out and replacing aged/deprecated security technologies while researching, piloting and then adopting new ones such as blockchain and post-quantum crypto);
Driving the development and maturity of the information risk and security management function, covering its priorities, internal structure and external working relationships, governance etc.;
Bringing clarity and direction (focus!), reducing complexity and uncertainty associated with myriad 'other options' that are discounted or put on hold;
Seizing opportunities to align and support various departments, processes, systems, partners, projects/initiatives, budgets, plans etc., finding and exploiting points of common interest, avoiding awkward conflicts and gaps;
Identifying key objectives for information risk and security - important for ISO/IEC 27001 and security metrics;
Motivating yourself and your colleagues to think beyond the immediate task list, broadening perspectives and extending timescales.

A full-blown multi-year security strategy and architecture can work nicely, particularly in larger, more complex and mature/stable organisations whose senior management appreciates or needs the long-term grand view, the bigger picture - provided they have access to the particular expertise needed to do justice to this topic anyway. Strategy is perhaps the most difficult and risky part of information risk and security, as it is for other aspects of enterprise management.

If you're still not convinced, consider that not preparing a security strategy and some form of security architecture/design may be even riskier and costlier in the long run. Failing to plan is planning to fail. Maintaining a state of 'creative chaos' - meaning a purely reactive event-driven approach - is suboptimal. However, with no clear objectives in mind, it may seem OK to those in the thick of it, far too busy treading water to scan the horizon for land.

Can I throw you a lifeline?

Google! Study hard. There are tools and techniques to help with strategy and architecture, just as there are for information risk and security management. Seek professional help if you need it.

You might for instance start simply by (literally!) sketching out whichever areas of information risk and security management matter most to your organisation, exploring the relationships among them and the obvious links with other areas such as IT and HR. Think about the security processes/activities and systems, paying special attention to the organisation's pain points. Gradually refine and extend the rough sketch into a blueprint encompassing broader aspects such as business objectives and resources ... and pretty soon things magically emerge from the mist.

Now comes a vital step: debate it with your colleagues. Talk it through. Listen carefully to their questions, objections and concerns, pushing back a little by exploring their strategies, architectures and ideas, steadily refining yours. This is a team game. Take your time.

As the vision takes shape, raise the discussion to senior management levels ... and at that point I'll slip quietly away, job done.

Must dash: others adrift, gasping.

Risk is ...

noreply@blogger.com (Gary) — Mon, 08 Aug 2022 02:00:00 +0000

... when threat exploits vulnerability causing impact

... tough to measure, express and control

... the product of probability and impact

... the gap between theory and practice

... the root of pessimism and optimism

... the once-in-a-hundred-years event

... known and unknown unknowns

... needing seatbelts and airbags

... a hair's breadth from disaster

... the possibility of exploitation

... mitigated but not eliminated

... a factor to be borne in mind

... inevitable in the Real World

... what keeps us up at night

... not going entirely to plan

... outcome =/= prediction

... rarely good, usually bad

... rarely bad, usually good

... surprisingly complicated

... looking down the barrel

... necessary to get ahead

... expectation <> reality

... stepping into the dark

... walking the tightrope

... imperfect knowledge

... inherent uncertainty

... exciting (to a point)

... white-water rafting

... being on the brink

... throwing the dice

... adventure sports

... tricky to manage

... skipping a check

... bungee jumping

... poking the tiger

... about causation

... taking chances

... unseen danger

... chances blown

... what might be

... warning signs

... unanticipated

... best avoided

... a card game

... being brave

... de-masking

... opportunity

... lion taming

... life lessons

... hazardous

... adventure

... ambiguity

... investing

... gambling

... black ice

... no limits

... complex

... dynamic

... relative

... thrilling

... thin ice

... danger

... doubt

... luck

... fun!

... life

... ice

...

CISO workshop slides

noreply@blogger.com (Gary) — Fri, 05 Aug 2022 22:45:00 +0000

A glossy, nicely-constructed and detailed PowerPoint slide deck by Microsoft Security caught my beady this morning.

The title 'CISO Workshop: Security Program and Strategy' with 'Your Name Here' suggests it might be a template for use in a workshop/course bringing CISOs up to speed on the governance, strategic and architectural aspects of information security, but in fact given the amount of technical detail, it appears to be aimed at informing IT/technology managers about IT or cybersecurity, specifically. Maybe it is intended for newly-appointed CISOs or more junior managers who aspire to be CISOs, helping them clamber up the pyramid (slide 87 of 142):

Aside from my gripes with the example metrics (see below), the remainder of the presentation has a lot of useful information, lots of details, plenty of busy, thought-provoking diagrams and, as I said, an uncommon polish for free slide decks.

Here's a nice, fairly simple example slide that I could happily present and discuss in some depth as part of a workshop or training course:

Naturally, the slide deck emphasises Microsoft's own 'security posture', such as:

IT, cyber and data-centric, virtually ignoring the wider field of information risk and security management (e.g. protecting and exploiting workers' knowledge and other intangible forms of intellectual property) with limited, almost incidental reference to information risk and security management being truly driven by business objectives;
Hacking and malware i.e. deliberate, malicious and often targeted attacks, downplaying accidental threats (e.g. floods and fires) and other incidents such as human error, theft, sabotage and fraud, plus enterprise risk management as a whole (e.g. financial risk, market risk, compliance risk, strategic risk ....);
Zero-trust - whatever that means to the presenter and audience;
Cloud - meaning Azure, specifically;
DevOps and DevSecOps - whatever those terms mean ;
MS threat intelligence including artificial intelligence/machine learning rapid responses to novel malware (a cool idea, provided it works reliably).

I'm intrigued by their choice of example Security Scorecard Metrics (slide 63):

These examples supposedly focus on 'continuous improvement' (of what I'm not exactly sure), so let's take a closer look:

Business Enablement appears to refer to IT and IT security services 'enabling' the business, although 'Number of security interruptions in user workflow' implies the need to prevent security getting in the way of business, a curious take on 'enable'.
Security Posture suggests a confusing mix of application and account security metrics. I'm really not sure what 'security posture' even means in this context, and curious as to why those two aspects in particular have been selected as example metrics. Other slides in the deck appear to equate 'security posture' to vulnerability management and software/systems patching - a rather narrow/specific technical concern for metrics suggested to senior management, although arguably it is a major factor in cybersecurity - or to security strategy. Personally, I favour a much broader perspective on the organisation's overall posture (meaning its brands, corporate personality, customer perceptions ...) including security-relevant aspects (e.g. being a trusted partner). Generally, though, the risk management and security arrangements quietly support and enable the business from the inside, as it were, rather than being exposed externally - unless they fail anyway!
Security Response: the example metrics suggest the classical (outdated!) incident-response-and-recovery line i.e. dealing with business discontinuity, although thankfully later slides (#82-85) discuss resilience:
Security Improvement as a category within this set of example metrics all supposedly focused on continuous improvement, confuses me. If these metrics are about improving security, what are the others improving? The example metrics don't help clarify the intent of this category either, referring to 'modernization' and automation (possibly in the realm of security, but not stated), although '# of Lessons learned from internal/external incidents' could indicate security improvements provided they are counted rationally (e.g. is an incident relating to weak passwords counted as just one incident or one per account compromised?).

For me, continuous improvement implies three things that don't exactly sing out from the example metrics:

Clarity on the meaning of 'improve' in the present context, implying the need for management to understand what are the key parameters, as well as being able to measure and control/drive them in a positive direction.
Some version of the classic Deming-style Plan-Do-Check-Act cycle.
Process maturity, leading naturally towards maturity metrics.

So, I have concerns about the overall thrust, the categories and the individual metrics offered as examples ... which is ironic given that the very next slide hints at an altogether better approach:

How is management supposed to achieve those objectives without the corresponding metrics ... or is the previous slide intended to illustrate the selection of metrics for just one of these bullets? How would the others be measured? What's more, how were these 'key business outcomes' selected for the slide? What about all the other 'key business outcomes' - of which there are many, especially in any sizeable, mature, complex organisation. Even a tiny micro-business has to juggle numerous objectives simultaneously within its finite resources - a significant information risk right there.

All in all, though, it's well worth browsing the slides and thinking about what's included and what's missing, in your own context. In contrast to Microsoft's usual crude in-yer-face full-on marketing, it's a reasonably subtle, well-balanced, comprehensive and interesting presentation. Thank you MS for releasing it.

Fragility is ...

noreply@blogger.com (Gary) — Mon, 01 Aug 2022 02:00:00 +0000

... the arch-enemy - not the polar opposite - of resilience

... a natural consequence of complexity and dependence

... when threat meets vulnerability exceeding control

... not knowing whether, how and when it will break

... being unable/unwilling/afraid to rely on it

... untrustworthy, inadequate controls

... pushing too far, too fast, too hard

... exceeding the breaking strain

... passing the point of no return

... an engineering challenge

... inevitable at some point

... hanging on by a thread

... often revealed too late

... a propensity to failure

... being on a knife-edge

... going over the brink

... obvious in hindsight

... being a snowflake

... a smashed mirror

... beyond the pale

... a broken vase

... a cracked egg

... a step too far

... uncertainty

... snap!

...

Webserver problem problem

noreply@blogger.com (Gary) — Sun, 31 Jul 2022 19:08:00 +0000

This cold Winter's Monday morning, we woke to problems accessing our server and websites. The usual turnitoffandonagain approach let us down ... and this time so has downforeveryoneorjustme dotcom:

It's ironic that a web service purely designed to tell us if a website is working is, itself, at least partially unresponsive - a broken control. It doesn't even say what or where the problem might be, remaining stubbornly stuck at "Checking server. Please wait ..."

Ping and tracert indicate the server is still sitting pretty on its Internet perch, so my guess is something bizarre going on with the webserver, possibly an attack in progress but more likely a simple config problem somewhere along the long, long chain of links and systems between us and the server, maybe even the DNS.

This is embarrssing given my professional interests, a bad start to the week but our incident management team is on the case, tooling-up as I speak.

So what can I say? Normal service will be resumed at some point, as soon as the office thaws and we have consumed a sufficiency of coffee to figure out what's going on and either fix it or get it fixed, that is.

Meanwhile, I apologise for the inconvenience, and I'm grateful for the ability to send you this message through Blogger, a Google service that - for now at least - is still working. Good on yer, Google!

If you need to contact me urgently, try zl2ifb@gmail.com - another resilient Google service.

Half-a-dozen learning points from a '27001 certification announcement

noreply@blogger.com (Gary) — Mon, 25 Jul 2022 21:54:00 +0000

This morning I bumped into a marketing/promotional piece announcing PageProof’s certified "compliance" (conformity!) with "ISO 27001" (ISO/IEC 27001!). Naturally, they take the opportunity to mention that information security is an integral part of their products. The promo contrasts SOC2 against '27001 certification, explaining why they chose ‘27001 to gain some specific advantages such as GDPR compliance - and fair enough. In the US, compliance is A Big Thing. I get that.

It occurs to me, though, that there are other, broader advantages to ‘27001 which the promo could also have mentioned, further valuable benefits of their newly-certified ISMS.

I spot at least six general learning points here for organisations currently implementing ISO/IEC 27001:

Elaborating on the broad business benefits of ‘27001 can be a creative and valuable activity in its own right. A well-designed and effective ISMS can achieve way more than protecting the confidentiality, integrity and availability of data, or satisfying GDPR and other compliance obligations. Although PageProof hints at some, it’s unclear whether they truly appreciate its full potential but chose not to mention them in this promo.
The eventual marketing/promotional value of ‘27001 certification is worth thinking-through. From the audience's perspective i.e. the organisation’s third party stakeholders (particularly customers and prospects, plus partners, owners, regulators and other authorities), what worthwhile differences can they expect as a result of the certification? What are the main points that will truly resonate? How will successful certification be promoted, and how will it change the organisation’s ongoing marketing, promotional and advertising activities - plus its operations (in order to satisfy if not exceed the market's expectations)? Rhetorical questions such as these may be raised and discussed at any point, ideally starting early-on in the ISMS design and implementation project, and gradually refined in the run-up to certification.
Likewise, what about the internal corporate stakeholders - the managers, staff, contractors, consultants, interns etc.: how will the ISMS implementation project affect the workforce? What changes can they expect? What practical differences will the ISMS make? How can they get involved and help the process along (or at least avoid inadvertenly causing problems)? What are the key messages to be put across through internal communications at all stages of the project?
Combining points 1-3 can help clarify the objectives of the ISMS - not just the detailed information risk and security objectives but more generally the business objectives, the rationale for doing all this stuff. What are the anticipated payoffs? Which of those benefits would be in, say, the top five?
Those clear objectives, in turn, suggest some obvious metrics to drive their achievement. For example, if 'reducing compliance costs' is one of five key objectives of '27001 certification, there are various ways to measure and control those costs: what would be the ultimate compliance-cost-related metric to track, report and optimise? Congratulations: you've just identified an important security metric - a Key Performance Indicator if you prefer!
Certification marks the end of ISMS implementation and the start of routine operations. Once operational, certified and announced to the world, the ISMS should continue adding value, the very reason for its existence. Will any of the business objectives, and hence the metrics and KPIs, change markedly at that point, or will they evolve gradually through business-as-usual? Are there any implications worth taking into account in the ISMS design - for instance, ensuring that the 'security dashboard' can be updated to show new metrics or present KPIs differently? What about 'instrumenting' various security processes and systems now, generating the raw data for historical analysis even though that may not be needed until later on?

All in all, six stimulating points drawn from a quick read of a promo. Thanks for the inspiration, PageProof, and congrats on your certification.

Oh and there's a free bonus. Point 7: we can all learn stuff from those who go before us. Find out and think about other organisations' approach to information risk, security, privacy, compliance, governance, metrics, incidents, marketing, whatever. Would their strategies be applicable to our organisations? What would we do differently? Could we do even better?

POSTSCRIPT: if your organisation is so spooky or shy that it wouldn't even consider a press release or displaying its shiny new certificates on a website, you might instead think forward to how certification would be announced internally, conformed to management at least. The things that are important enough to state then are [some of] the key objectives for the ISMS, worth bearing in mind now.

If it hadn't even occurred to you to promote your eventual certification, I'd have to wonder about your management's understanding and commitment to this initiative, and question your motivation for getting into it. Why bother? What will it achieve, for the business - seriously, what? Isn't that worth celebrating, once achieved?

Resilience is ...

noreply@blogger.com (Gary) — Sun, 24 Jul 2022 20:51:00 +0000

... depending on others and being there for them when they need us most

... the rod bending alarmingly ... while landing a whopper

... an oak tree growing roots against the prevailing wind

... taking the punches, reeling but not out for the count

... demonstrating, time after time, personal integrity

... willingness to seize opportunities, taking chances

... coping with social distancing, masks and all that

... accumulating reserves for the bad times ahead

... the bloody-minded determination to press on

... disregarding trivia, focusing on what matters

... a society for whom this piece resonates

... deep resolve founded on inner strength

... knowing it'll work out alright in the end

... a word, a rich concept, a way of life

... knowing when and how to concede

... more than 'putting on a brave face'

... a prerequisite for ultimate success

... facing up to adversity: bring it on

... self-belief and trust in the team

... taking the knocks and learning

... communities pulling together

... being prepared for the worst

... standing out from the crowd

... being fit enough to survive

... pressing ahead, regardless

... standing up to be counted

... disproving the naysayers

... finding creative solutions

... having fallback options

... keeping on keeping on

... wiping away the tears

... always bouncing back

... built layer-upon-layer

... thriving on adversity

... having what it takes

... steadfast insistence

... picking your fights

... sheer doggedness

... an admirable trait

... justified optimism

... retaining options

... quiet confidence

... daring to differ

... plugging away

... core strength

... beyond hope

... getting even

... rerouting ...

... suppleness

... true grit

... faith

... us

...

I'm blogging about other infosec terms weekly:

Risk management trumps checklist security

noreply@blogger.com (Gary) — Sun, 24 Jul 2022 04:21:00 +0000

While arguably better than nothing at all, an unstructured approach to the management of information security results in organisations adopting a jumble, a mixed bag of controls with no clear focus or priorities and – often – glaring holes in the arrangements. The lack of structure indicates the absence of genuine management understanding, commitment and support that is necessary to give information risk and security due attention - and sufficient resourcing - throughout the business.

It's hard to imagine anyone considering such a crude, messy approach adequate, even those who coyly admit to using it! I'm not even sure it qualifies as 'an approach'.

Anyway, the next rung up the ladder sees the adoption of a checklist approach: essentially, someone says 'Just adopt these N controls and you'll be secure'! It may be true that some information security controls are more-or-less universal, so any organisation that does not have them all might be missing out. Maybe it is a step up from the previous approach, and yet there are significant issues with checklists that tend to be:

Basic, severely over-simplifying a complex and dynamic problem, ignoring numerous aspects while focusing attention on the N (meaning a handful);
Generic but not necessarily as universal as implied, given the wide diversity of organisations out there in terms of size, maturity, industry, culture, history, business objectives, resources and so on;
The 'lowest common denominator', setting a (very) low bar;
Sequenced linearly in a way that implies priorities for implementation and generally disregards dependencies and linkages between items on the list, yet another over-simplification;
Just someone's arbitrary selection, generally without any sound basis for selecting the listed controls and not others, other than the origantor's alleged expertise;
Tricky to interpret and apply in a given situation, given the immaturity of the organisations attracted to checklist approaches;
Not sufficient in most cases, and often biased towards particular types of control e.g. 'cyber' or 'compliance';
Unrealistic in the presumption that simply because someone recommends the N controls, managers will therefore naively accept that they are both required and valuable;
Belittling, clearly implying that they are deliberately dumbed-down because the intended audience is, well, dumb.

If N controls are inadequate or even barely sufficient, it is tempting to expand the list. N-plus control checklists suffer similar problems, plus:

The more controls that are added to the list, the less likely they are to be truly universal;
The controls tend to be grouped and structured in some fashion ... which is another ill-defined process involving arbitrary criteria and of dubious value;
The longer the list, the less attractive it becomes to those seeking easy solutions. Simply reading longer lists takes time and becomes tedious, while implementing all the controls appears increasingly arduous - especially if the recommended controls are not explained and justified properly (which would make the list even longer anyway!);
Ultimately, a long list is no better than a bit of Googling, consideration and discussion;
There is a risk that the very readers who would benefit to some extent from the approach are overwhelmed by it all and put off entirely.

At face value, ISO/IEC 27001 is an N-plus checklist, after all Annex A is an arbitrarily structured list of about 100 information security controls recommended by a committee of experts. There's more to it than that, however.

For one thing, Annex A is merely a succinct summary of the information security controls in ISO/IEC 27002. It's a simple list, yes, but one backed by roughly a page of detailed explanation behind each control, particularly in the latest, fully updated edition published a few months back.

Furthermore, the main body of ISO/IEC 27001 avoids the checklist mentality by defining the governance arrangements for managing an organisation’s information risks. It is a systematic, iterative, risk-driven approach, simple and easy to grasp. In a nutshell, there are just 4 phases:

An ISO27k ISMS enables and supports the analysis, prioritisation and changes required for any organisation to design and implement a sound, systematic approach to information risk and security management that is tailored and appropriate to its specific situation - a substantial enhancement over any crude checklist. The selection and implementation of information security controls is context-dependent in ISO27k, particularly as the standard allows organisations to choose controls from any source - including those crude checklists, and Google, and ... whatever. Any list of controls is less important than the process for identifying, evaluating and treating risks.

The risk management process at the heart of ISO/IEC 27001 is universally applicable. It's not even limited to information risks, information security, privacy and so forth.

Organisations may wish to go beyond the fairly basic risk and security management arrangements mandated in the main body of ISO/IEC 27001 … but that is not necessarily a good idea, especially at the start of their journey to maturity. ‘Keep it simple’ makes more sense as a strategy, especially in a start-up situation i.e. set out to implement just the basics, get them working properly and plan to build gradually from there, over time, making incremental improvements where justified or necessary. The ISMS itself embodies the mechanisms to capture requirements and push through improvements, systematically (see the K in the RISK mnemonic).

A reasonably mature organisation is likely to have a suite of reasonably mature management and governance arrangements already operating. A new ISO27k ISMS will be slotting in to and making use of them, requiring changes in various aspects to accommodate the structured, systematic, risk-driven ISO27k approach. The ISMS itself is likely to involve consolidating existing practices around information and cyber security management, albeit often mostly within IT but hopefully with strong lateral links to related functions such as Risk, Compliance, Procurement, HR, Operations and Facilities, perhaps even upwards to senior/Executive Management and the Board. Even here, the keep-it-simple ISMS strategy has value in terms of focusing on the essential/core processes and activities around information risk management. Anything above and beyond the core should probably be a lesser priority during the initial ISMS implementation phase, unless there are good business reasons to press ahead more urgently in other areas (e.g. compliance obligations) – in which case those pressures can help drive through the ISMS implementation.

Security in software development

noreply@blogger.com (Gary) — Fri, 22 Jul 2022 05:10:00 +0000

Prompted by some valuable customer feedback earlier this week, I've been thinking about how best to update the SecAware policy template on software/systems development. The customer is apparently seeking guidance on integrating infosec into the development process, which begs the question "Which development process?". These days, we're spoilt for choice with quite a variety of methods and approaches.

Reducing the problem to its fundamentals, there is a desire to end up with software/systems that are 'adequately secure', meaning no unacceptable information risks remain. That implies having systematically identified and evaluated the information risks at some earlier point, and treated them appropriately - but how?

The traditional waterfall development method works sequentially from business analysis and requirements definition, through design and development, to testing and release - often many months later. Systems security ought to be an integral part of the requirements up-front, and I appreciate from experience just how hard it is to retro-fit security into a waterfall project that has been runnning for more than a few days or weeks without security involvement.

A significant issue with waterfall is that things can change substantially in the course of development: the organisation hopefully ends up with the system it originally planned, but that may no longer be the system it needs. If the planned security controls turn out to be inadequate in practice, too bad: the next release or version may be months or years away, if ever (assuming the same waterfall approach is used for maintenance, which is not necessarily so*). The quality of the security specification and design (which drives the security design, development and testing) depends on the identification and evaluation of information risks in advance, predicting threats, vulnerabilities and impacts likely to be of concern at the point of delivery some time hence.

In contrast, lean, agile or rapid application development methods cycle through smaller iterations more quickly, presenting more opportunities to update security ... but also more chances to break security due to the hectic pace of change. A key problem is to keep everyone focused on security throughout the process, ensuring that whatever else is going on, sufficient attention is paid to the security aspects. Rapid decision-making is part of the challenge here. It's not just the method that needs to be agile!

DevOps and scrum approaches use feedback from users on each mini-release to inform the ongoing development. Hopefully security is part of that feedback loop so that it improves incrementally at the same time, but 'hopefully' is a massive clue: if users and managers are not sufficiently security-aware to push for improvements or resist degradation, and if the development team is busy on other aspects, security can just as readily degrade incrementally as other changes take priority.

Another issue is that security testing has to suit short process cycles, with a tendency towards quick/superficial tests and less opportunity for the thorough, in-depth testing needed to dig out troublesome little security issues lurking deep within. Personally, I would be very uncomfortable developing a cryptographic application too quickly, or for that matter anything business- or safety-critical.

So, there are some common factors there, regardless of the method:

The chosen development methods have risk and security implications;
Various dynamics are challenging, on top of the usual security concerns over complexity, and changes present both risks and opportunities;
Security is just one of several competing priorities, hence there is a need for sufficient, suitable resources to keep it moving along at the right pace;
Progress is critically reliant on the security awareness and capabilities of those involved i.e. the users, designers, developers, testers, project/team leaders and managers.

* Just one of those dynamics is that the processes may change in the course of development: a system initially developed and released through a classical waterfall project may be maintained by something resembling the rapid, iterative approaches. The cycle speed for iterations is likely to slow down as the system matures or resources are tight, or conversely speed up to react to an increased need for change from the business or technology.

So, overall, it makes sense for a software/system development security policy to cover:

An engineering mindset, prioritising the work according to the organisation's information risks ('risk-first development'?), with a willingness to settle for 'adequate' (meaning fit-for-purpose) security rather than striving in vain for perfection;
Flexibility of approach - supporting/enabling whatever processes are in use at the time, integrating security with other aspects and collaborating with colleagues where possible;
Sufficient resourcing for the information risk and security tasks, justified according to their anticipated value (with implications for metrics, monitoring and reporting);
Monitoring and dynamically responding to changes, being driven by or driving priorities according to circumstances, seizing opportunities to improve security and resisting retrograde moves in order to ratchet-up security towards adequacy.

The policy could get into general areas such as accountability (e.g. various process checkpoints with management authorisation/approval), and delve deeper into security architecture (to reduce design flaws), secure coding (to reduce bugs) and security testing (to find the remaining flaws and bugs), plus security functions (such as backups and user admin) ... but rather than bloat the SecAware policy template, we choose to leave the details to other policies and procedures. Customers are welcome to modify/supplement the template as they wish.

Whether that suits the market remains to be seen. What do you think? Do your security policies cover software/system development? If so, do they at least address the issues I've noted? If not, $20 is a wise investment ...

ISO management systems assurance

noreply@blogger.com (Gary) — Thu, 21 Jul 2022 06:19:00 +0000

In the context of the ISO management systems standards, the internal audit process and accredited certification systems as a whole, are assurance controls primarily intended to confirm that organisations' management systems conform to the explicit requirements formally expressed in the respective ISO standards.

A conformant management system, in turn, is expected to manage (design, direct, control, monitor, maintain …) something: for ISO/IEC 27001, that 'something-being-managed' is the suite of information security controls and other means of addressing the organisation’s information risks (called 'information security risks' or 'cybersecurity risks' in the standards). For ISO 9001, it is the quality assurance activities designed to ensure that the organisation's products (goods and services) are fit for purpose. For ISO 14001, it is the controls and activities necessary to minimise environmental damage.

My point is that the somethings-being-managed are conceptually distinct from the 'management systems' through which managers exert their direction and control. This is a fundamental part of the ISO management systems approach, allowing ISO to specify systems required to manage a wide variety of somethings in a similar way - a governance approach in fact.

Management system certification auditors, whose sole purpose is to audit clients' management systems' conformity with the requirements expressed in the standards, have only a passing interest in those somethings-being-managed, essentially checking that they are indeed being actively managed through the management system, thereby proving that the management system is in fact operational and not just a nice neat set of policies and procedures on paper.

Management system internal auditors, in contrast, may be given a wider brief by management which may include probing further into the somethings being managed ... but that’s down to management’s decision about the scope and purpose of the internal audits, not a formal requirement of the standards. Management may just as easily decide to have the internal auditors stick to the management system standard conformity aspects, just the same as the certification auditors.

Likewise with management reviews of the management systems: the ISO standards stop well short of specifying all the things management might conceivably want to be reviewed. Reviewing conformity with the respective ISO management systems standards is just one of several possible review objectives, alongside all the things hopefully being measured through the management system metrics.

Skyscraper of cards

noreply@blogger.com (Gary) — Mon, 18 Jul 2022 04:45:00 +0000

Having put it off for far too long, I'm belatedly trying to catch up with some standards work in the area of Root of Trust, which for me meant starting with the basics, studying simple introductory articles about RoT.

As far as I can tell so far, RoT is a concept - the logical basis, the foundation on which secure IT systems are built.

'Secure IT systems' covers a huge range. At the high end are those used for national security and defence purposes, plus safety- and business-critical systems facing enormous risks (substantial threats and impacts). At the low end are systems where the threats are mostly accidental and the impacts negligible - perhaps mildly annoying. Not being able to tell precisely how many steps you've taken today, or being unable to read this blog, is hardly going to stop the Earth spinning on its axis. In fact' mildly' may be overstating it.

'Systems' may be servers, desktops, portables and wearables, plus IoT things and all manner of embedded devices - such as the computers in any modern car or plane controlling the engine, fuel, comms, passenger entertainment, navigation and more, or the smart controller for a pacemaker

Trust me, you don't want your emotionally disturbed ex-partner gaining anonymous remote control of your brakes, altimeter or pacemaker.

In terms of the layers, we the people using IT are tottering precariously on the top of a house of cards. We interact with application software, interacting with the operating system and, via drivers and microcode, the underlying hardware. A 'secure system' is a load of software running on a bunch of hardware, where the software has been designed to distrust the users and administrators, other software and the hardware, all the way down to, typically, a Hardware Security Module, Trusted Platform Module or similar dedicated security device, subsystem or chip. Ironically in relation to RoT, distrust is the default, particularly for the lower layers unless/until they have been authenticated - but there's the rub: towards the bottom of the stack, how can low-level software be sure it is interacting with and authenticating the anticipated security hardware if all it can do is send and receive signals or messages? Likewise, how can the module be sure it is interacting with the appropriate low-level software? What prevents a naughty bit of software acting as a middleman between the two, faking the expected commands and manipulating the responses in order to subvert the authentication controls? What prevents a nerdy hacker connecting logic and scope probes to the module's ports in order to monitor and maybe inject signals - or just noise to see how well the system copes? How about a well-appointed team of crooks faking a bank ATM's crypto-module, or a cluster of spooks figuring out the nuclear missile abort codes?

Physically securing the hardware is a start, such that if someone tries to - say - open ('decapsulate') the TPM chip to analyse the silicon wafer under an electron microscope in the hope of finding some secret key coded within, the chip somehow destroys itself in the process - perhaps also the warhead for good measure.

Other hardware/electronic controls can make it virtually impossible for hardware hackers to mount side-channel attacks, painstakingly monitoring and manipulating the module's power supply and ambient temperature in an attempt to reveal its inner secrets.

Cryptography is the primary control, coupled with appropriate use of authentication and encryption processes in both hardware and software (e.g.'microcode' physically built-in to the TPM chip's crypto-processor), plus other inscrutable controls (e.g. rate-limiting brute force attacks and, ultimately again, sacrificing itself, taking its secrets with it).

Developing, producing and testing secure systems is tough, even with access to low-level debugging mechanisms such as JTAG ports and insider-knowledge about the design. There must be a temptation to install hard-coded backdoors (cheat codes), despite the possibility of 'some idiot' further down the line failing to disable them before products start shipping. There is surely a fascination with attempting to locate and open the backdoors without tripping the tripwires that spring open the trapdoors to oblivion.

OK, so now imagine all of that in relation to cloud computing, where 'the system' is not just a physical computer but a fairly loose and dynamic assembly of virtual systems running on servers who-knows-where under the control of who-know-who sharing the global Internet who-knows-how.

Having added several extra floors to our house of cards, what could possibly go wrong?

That's what ISO/IEC 27070:2021 addresses.

At least, I think so. My head hurts. I may be coming down with vertigo.

Complexity, simplified

noreply@blogger.com (Gary) — Sun, 10 Jul 2022 01:27:00 +0000

Following its exit from the EU, the UK is having to pick up on various important matters that were previously covered by EU laws and regulations. One such issue is to be addressed through a new law on online safety.

"Online safety: what's that?" I hear you ask. "Thank you for asking, lady in the blue top! I shall elaborate ... errrr ..."

'Online safety' sounds vaguely on-topic for us and our clients, so having tripped over a mention of this, I went Googling for more information.

First stop: the latest amended version of the Online Safety Bill. It is written in extreme legalese, peppered with strange terms defined in excruciating detail, and littered with internal and external cross-references, hardly any of which are hyperlinked e.g.

Having somewhat more attractive things to do on a Sunday than study the bill, a quick skim was barely enough to pick up the general thrust. It appears to relate to social media and search engines serving up distasteful, antisocial, harmful and plain dangerous content, including ("but not limited to") porn, racist, sexist and terrorist materials. Explaining that previous sentence in the formal language more becoming of law evidently takes 230 pages, of the order of 100,000 words.

Luckily for us ordinary mortals, there are also explanatory notes - a brief, high-level summary of the bill, explaining what it is all about, succinctly and yet eloquently expressed in plain English with pictures (not). The explanatory notes are a mere 126 pages long, half the length of the original with another 40-odd thousand words.

Simply explaining the explanatory notes takes half a page for starters:

So, the third bullet suggests that we read the 126 pages of notes PLUS the 230 page bill. My Sunday is definitely under threat. At this point, I'm glad I'm not an MP, nor a lawyer or judge, nor a manager of any of the organisations this bill seems likely to impact once enacted. I'm not even clear which organisations that might be. Defining the applicabilty of the law - including explicit exclusions to cater for legitmate journalism and free-speech - takes a fair proportion of those 346 pages.

Despite not clearly expressing the risk, the bill specifies mitigating controls - well, sort of. In part it specifies that OFCOM is responsible for drawing up relevant guidance that will, in turn, specify control requirements on applicable organisations (to be listed and categorised on an official register, naturally), with the backing of the law including penalties. Since drafting, promoting and enforcing the guidance is likely to be costly, the bill even allows for OFCOM to pass (some of) its costs on to the regulated organisations, who will, in turn, pass them on to users. A veritable cost-cascade.

As to the actual controls, well the bill takes a classical risk-management approach involving impact assessments and responses such as taking down unsafe content and banning users who published it. There are arrangements for users to report unsafe content to service providers, plus automated content-scanning technologies, setting the incident management process in motion.

The overall governance structure looks roughly like this:

No wonder it takes >100,000 words to specify that little lot in law ... but, hey, maybe my diagram will save a thousand, a few dozen anyway.

You're welcome.

The reason I'm blabbering on about this here is that I'm still quietly mulling-over a client's casual but insightful comment on Thursday.

"I was wondering whether [the information security policies we have been customising for them] might be a little too in depth for our little start-up."

Fair comment! Infosec is quite involved and - as you'll surely appreciate from this very blog - I tend to focus and elaborate on the complexities, writing profusely on topics that I enjoy. I find it quite hard to explain stuff simply and clearly without first delving deep, particularly if the end product doesn't suit my own reading preferences.

Looking at the policies already prepared, I had cut down our policy templates from about 3 or 4 pages each to about 2, adjusting the wording to reflect the client's business, technology and people, and removing bits that were irrelevant or unhelpful in the context of a small tech business. But, yes, I could see how they might be considered in-depth, especially since, even after combining a few, there were 19 policies in the suite covering all the topics necessary.

So, I responded to the client's point by preparing a custom set of Acceptable User Policies to supplement the more traditional topic-based policies already prepared. I set out with our AUP templates - single-sided A4 leaflets in (for me!) a succinct style - laying out the organisation's rules for acceptable and unacceptable behaviours in topic areas such as malware, cloud and IoT. The writing style is direct and action-oriented, straight down-to-business.

Modifying the AUP templates for the client involved trivial changes such as incorporating their company name in place of 'the organisation', and swapping-out the SecAware logo for theirs. A little trimming and adaptation of the bullet points to fit into half a side per topic took a bit more time but, overall, starting with our templates was much quicker and easier than designing and preparing the AUPs from scratch.

I took the opportunity to incorporate some eye-catching yet relevant images to break up the text and lead the reader from topic-to-topic in a natural flow.

I merged the AUP templates into one consolidated document for ease of use, and prepared additional AUPs on areas that weren't originally covered (security of email/electronic messaging and social media), ending up with a neat product that sums things up nicely in 11 topic areas. It can be colour printed double-sided on just 3 sheets of glossy A4 paper to circulate to everyone (including joiners), or published on the corporate network for use on regular desktop PCs, laptops or tablets.

So far, so good ... but then it occurred to me yesterday that if the AUPs are to be readily available and accessible by all, the client could do with a 'mobile' version for workers' smartphones. Figuring out the page size, margins and formatting for mobiles, and further simplifying/trimming the content to suit small, narrow smartphone screens with very limited navigation took me another hour or two, ending up with a handy little document that looks professional, is engaging and reads well, makes sense and provides useful guidance on important information security matters. Reeeeesult!

In recognition of the client's valuable suggestion that sparked this, we won't be charging them for the AUP work - it's a bonus. The client gets a nice set of policies well suited to their business and people, while we have new products gracing the virtual shelves of our online store, a win-win. Happy days.

A bargain at just $20!

Now, about that Online Safety Bill: would anyone like to commission a glossy leaflet version in plain English, complete with pretty pictures?

The discomfort zone

noreply@blogger.com (Gary) — Mon, 04 Jul 2022 23:32:00 +0000

Compliance is a concern that pops up repeatedly on the ISO27k Forum, just this morning for instance. Intrigued by ISO 27001 Annex A control A.18.1.1 "Identification of applicable legislation and contractual requirements", members generally ask what laws are relevant to the ISMS.

That's a tough one to answer for two reasons.

Firstly, I'm not a lawyer so I am unqualified and unable to offer legal advice. To be honest, I'm barely familiar with the laws and regs in the UK/EU and NZ, having lived and worked here for long enough to absorb a little knowledge. The best I can offer is a layman's perspective. I feel more confident about the underlying generic principles of risk, compliance, conformity, obligations, accountabilities, assurance and controls though, and have the breadth of work and life experience to appreciate the next point ...

Secondly, there is a huge range of laws and regs that have some relevance to information risk, security, management and the ISMS. The mind map is a brief glimpse of the landscape, as I see it ...

That's a heady mix of laws and regs that apply to the organisation, its officers and workers, its property and finances, its technologies, its contracts, agreements and relationships with employees and third parties including the authorities, owners, suppliers, partners, prospects and customers, and society at large. There are obligations relating to how it is structured, operated, governed, managed and controlled, plus all manner of internal rules voluntarily adopted by management for business reasons (some of which concern obligations under applicable laws and regs). Noncompliance and nonconformity open the can-o-worms still wider with obligations and expectations about 'awareness', 'due process', 'proof' and more, much more.

That A.18.1.1 control is - how shall I put it - idealistic:

"All relevant legislative statutory, regulatory, contractual requirements and the organization’s approach to meet these requirements shall be explicitly identified, documented and kept up to date for each information system and the organization."

All requirements?! Oh boy! Explicit! Documented! Maintained! This is bewildering, scary stuff, especially for relatively inexperienced infosec or cybersecurity professionals who seldom set foot outside of the IT domain. We're definitely in the discomfort zone here.

At the CISO, Information Security Manager or Privacy Officer level, the view is no less scary despite narrower knowledge gaps. The possibility of being held personally to account (perhaps even sacked or prosecuted!) for incidents involving noncompliance or nonconformity is both sobering and discomforting again.

The issue qualifies as a classic information risk, so an obvious risk-response is to attempt to avoid or mitigate it. Unfortunately, simply ignoring it won't make it go away, but large parts of the mind map can legitimately be handed to Other Departments or Someone Else - the Legal/Compliance team for instance (in larger organisations anyway), plus competent professionals from HR, Finance, Sales & Marketing, Operations, plus "top management". It's not really about being slopy-shouldered (honest!), so much as acknowledging that legal and regulatory compliance, particularly, deserve/require the involvement of competent specialists.

The residual risks may simply be accepted but really they ought to be explored, evaluated and reduced where cost-effective to do so. For example, misunderstandings or disagreements about precisely who is responsible for what in this domain can lead to gaps and conflicts with nasty consequences (e.g. if Everyone assumes Someone Else is dealing with, say, intellectual property) ... and that's a jolly good reason to arrange a management workshop or study to explore the entire mind map, talking it through and carving it up appropriately.

Good luck with that.

Normally, I argue against unduly narrowing the scope of the ISMS (for instance, constraining it within IT or 'cyber') but in this case, scope-narrowing is due. It makes good sense to steer well clear of the can-o-worms, well skirt around it as best we can anyway.

Fresh off the screen today, I'll soon be dropping the complete mind map one-pager into the SecAware ISMS Orbit toolkit, complementing the existing security awareness/training materials, diagrams, policies and guidance designed to make your worklife a little less fraught, more tolerable if not entirely comfortable. Meanwhile, if you ask me nicely and promise not to be scared witless, I'll share the mind map with you. It's R18 rated.

Standards development - a tough, risky business

noreply@blogger.com (Gary) — Sat, 02 Jul 2022 00:23:00 +0000

News emerged during June of likely further delays to the publication of the third edition of ISO/IEC 27001, this time due to the need to re-align the main body clauses with ISO's revised management systems template (specfically, the 2022 edition of the ISO/IEC Directives, Part 1 "Consolidated ISO Supplement — Procedure for the technical work — Procedures specific to ISO", Annex SL "Harmonized approach for management system standards").

Although we already have considerable discretion over which information security controls are being managed within our ISO/IEC 27001 Information Security Management Systems today, an unfortunate side-effect of standardisation, harmonisation, adoption, accreditation and certification is substantial inertia in the system as a whole. It’s a significant issue for our field where the threats, vulnerabilities, impacts and controls are constantly shifting and often moving rapidly ahead of us … but to be honest it’s equally problematic for other emerging and fast-moving fields. Infosec is hardly special in this regard. Just look at what's happening in microelectronics, IT, telecomms, robotics, environmental protection and globalisation generally for examples.

One possible route out of the tar-pit we've unfortunately slid into is to develop forward-thinking ‘future-proof’ standards and release them sooner, before things mature, but that’s a risky approach given uncertainties ahead. It would not be good for ill-conceived/premature standards to drive markets and users in inappropriate directions. It’s also tough for such a large, ponderous, conservative committee as ISO/IEC JTC 1/SC 27. However, the smart city privacy standard ISO/IEC TS 27570 is a shining beacon of light, with promising signs for the developing security standards on Artificial Intelligence and big data security too. I wish I could say the same of 'cyber', cloud and IoT security but (IMNSHO) the committee is struggling to keep pace with these fields, despite some fabulous inputs and proactive support from members plus the likes of the Cloud Security Alliance and NIST.

The floggings will continue until morale improves.

Another tar-pit escape plan involves speeding-up the standards development process, perhaps also the promotion, accreditation and certification processes that follow each standard's publication – but again there are risks in moving ahead too fast, compromising the quality and value of the standards, damaging ISO/IEC’s established brands.

SC 27 management appears to be working on just such an approach right now with ISO/IEC 27028, putting more time and effort into the informal drafting stages ahead of the formalities of Committee Drafts and voting. The idea is to smooth and speed up the formalities by drafting better standards in the first place, and gaining the committee’s implicit support/consensus ahead of explicit approval. Likewise with recent moves to separate subject matter expert involvement in the creative preliminary stages from national body involvement in the latter stages. We’ll see how that turns out!

Personally, I yearn for modern, collaborative, cloud-based methods, particularly for the early informal stages of each standard. I'm sure we could get a lot more done, relatively quickly and painlessly, by working together online as a group in near-realtime ahead of the necessary ISO formalities around proofreading and approval. At the very least, more productive social dialogue between the experts would help get us all to the same chapter, if not on the same page. Committee meetings, whether virtual or in person, are costly and ponderous compared to, say, Google Groups or Microsoft Teams. I see these as complementary not alternatives, not either-or but both-and.

Yet another tar-mitigation option would be for SC 27 leadership to clarify the strategy and (re)align the committee members accordingly, increasing their understanding and support for whatever it takes to optimise the processes. However, ‘leadership’, ‘strategy’, 'alignment’ and 'optimisation' are all difficult in the ISO context, given the importance of due process, ample consideration, cultural awareness, diplomacy and global consensus. Management has cats to herd, guide, persuade and convince rather than unilaterally pushing through or blocking changes (as happens occasionally). Governance is challenging at the best of times: in such a large, international, busy, largely voluntary and diverse organisation, it’s tough-as.

Looking back, despite all the challenges and all that tar, SC 27 has been remarkably successful, generating and managing a sizeable portfolio of well-respected ISO27k, privacy and other infosec standards. Sure, it could have done better in some areas, but overall the world is in better shape today than it would otherwise have been without SC 27.

Meanwhile, aside from shouting a few choice phrases from the touchline, is there anything we can do to help?

As we gain knowledge and expertise, we can give something back. Volunteer as subject matter experts, actively engaging with SC 27 through our national standards bodies to help develop better, more forward-thinking standards, for example by contributing to, reviewing and commenting on draft standards, especially in the early, more creative stages of the drafting process;
Propose, draft and offer possible new ISO27k standards, as is currently happening with, say, security control attributes and professional services;
Collaborate more, pulling together as a supportive community to develop, understand, adopt and extract value from the standards;
Think beyond mere certification. Be more creative and innovative, treating the standards as foundational platforms, suggested good practices worth considering, adapting, adopting and building upon rather than targets, hurdles or constraints on progress (as is happening right now with ISO/IEC 27001);
Be open to novel approaches, such as integrated management systems, peer-group and collaborative working, and cherry-picking whichever approaches hold the most promise for achieving our organisations' business objectives (e.g. supplementing or completely replacing the current '27001 Annex A controls with a more contemporary mix);
Be more tolerant and considerate of each other, including ISO/IEC, SC 27's management and editorial teams, the accreditation and certification bodies, auditors plus our work and professional colleagues. Remember, we're all on the same side here!

Shout, shout, let it all out

noreply@blogger.com (Gary) — Fri, 01 Jul 2022 01:00:00 +0000

Here's an insightful and enjoyable way to explore your psyche and vent a little tension at the end of a tough month, week or day.

First, find yourself a private space to watch Tears for Fears.

Now shout, shout, let it all out: what are the things you could do without?

Grab a scrap of paper and start writing down the things you could do without. You'll find yourself stimulated by your own words to think of other things, other stuff you don't want, don't like, can't stand, even hate.

Fine, scribble away.

How's it going? How do you feel now - vented? Released? Or still knotted up, twisted out of shape?

Come on, I'm talking to you, come on.

If it all gets too much, take a break. Set your list aside to ferment for a while - as long as it takes. There's no rush. You're the boss.

If you are so inclined, come back later to tidy up your list and make sense of it. How you do that is up to you. For me, it's mind-mapping, grouping things together, drawing links and doodling. I'll show you mine - well an uncontroversial snippet anyway ...

When you're ready, fully vented, destroy that bit of paper. Let it go, or maybe rip it up and start again.

What are "information assets"?

noreply@blogger.com (Gary) — Thu, 30 Jun 2022 04:35:00 +0000

Control 5.9 in ISO/IEC 27002:2022 recommends an inventory of information assets that should be “accurate, up to date, consistent and aligned with other inventories”.

Fair enough, but what are 'information assets'? What, exactly, are we supposed to be inventorying?

The standard refers repeatedly but enigmatically to "information and other associated assets" that an organisation’s Information Security Management System protects. The intended meaning of 'information asset' has been a bone of contention within ISO/IEC JTC 1/SC 27 for years, some experts and national bodies vehemently disagreeing with each other until, eventually, a fragile ceasefire was declared in order to move forward on the numerous standards projects that hinge on the term.

Currently, '27002 provides a rather broad and unhelpful definition of "asset" as "anything that has value to the organisation" - paperclips, for instance, fall within the definition. Does that mean your ISMS should protect paperclips since, arguably, they are 'associated with information', albeit very low value assets. I know this is reductio ad absurdam but it illustrates the tar pit that SC 27 found itself in.

On a more pragmatic note, I have consciously taken a wide view of information assets in preparing a checklist of information assets for SecAware. I intend to set you thinking about the potential scope, purpose and focal points of your ISMS. You may feel that certain items on the checklist are irrelevant ... or the checklist might just open your eyes to entire categories of valuable information that you hadn't even considered. Whether they end up in or out of scope of your ISMS is for you and your management colleagues to determine. I'm simply giving you food for thought.

Click the image for instant access!

Authorised exemptions

noreply@blogger.com (Gary) — Thu, 30 Jun 2022 01:02:00 +0000

Inspired by an exchange on the ISO27k Forum yesterday morning, I wrote and published a simple 2-page exemptions policy template for SecAware.

In essence, after explaining what 'exemptions' are, the policy requires that they are authorised after due consideration by management, specifically the relevant Information Owners.

Exemption decisions should also be recorded, hinting at a process and some sort of exemptions log. I'm wondering now whether to write a procedure as well, including a basic log template as a starting point. I'm also contemplating writing something on accountability and responsibility, and perhaps generic incident management and post incident review procedures to accompany the incident management policy.

Click the image for instant access!

The business context for information risk and security

noreply@blogger.com (Gary) — Mon, 27 Jun 2022 20:25:00 +0000

Although the organisational/business context is clearly relevant and important to information risk and security management, it is tricky to describe.

In my opinion, clause 4 of ISO/IEC 27001 is so succinct that it leaves readers perplexed as to what 'context' even means. It stops short of explaining how to determine and make use of various 'internal and external issues' in an Information Security Management System.

So, to help clients, I wrote and released a pragmatic 5-page management guideline on this for the SecAware ISMS toolkit, expanding on this neat little summary diagram:

With about a thousand words of explanation and pragmatic advice, the guideline has roughly ten times as many words as clauses 4.1 and 4.2 ... or twenty times if you accept that the picture is worth a thousand words. It was written independently of, and complements, ISO/IEC 27003's advice in this area.

Although I am happy with the SecAware ISMS toolkit materials as they are, I'm always looking for improvement opportunities, ways to add more value for clients. I'm currently working on, or at least thinking about:

A set of fundamental information risk and security principles;
A guideline on the Risk Treatment Plan and Statement of Applicability;
Something on security engineering, perhaps: lots of literature to study first.

The sadly neglected Risk Treatment Plan

noreply@blogger.com (Gary) — Fri, 24 Jun 2022 01:37:00 +0000

For some curious reason, the Statement of Applicability steals the limelight in the ISO27k world, despite being little more than a formality. Having recently blogged about the dreaded SoA, 'nuff said on that.

Today I'm picking up on the SoA's shy little brother, the Risk Treatment Plan. There's a lot to say and think about here, so coffee-up, settle-down, sit forward and zone-in.

ISO/IEC 27001 barely even acknowledges the RTP. Here are the first two mentions, tucked discreetly under clause 6.1.3:

Hmmm. But wait, there's more:

... and, hiding in plain view under clause 9.3 is the final, almost casual mention:

Having studied those four statements, what do you think the RTP is intended to look like? There's not exactly a lot to go on there! Even within the context of the standard, it's still somewhat unclear, verging on cryptic.

Luckily for us and the certification auditors, there's more helpful advice elsewhere.

ISO/IEC 27003 offers a page of 'guidance on formulating an information security risk treatment plan (6.1.3 e))', which I won't quote in full but summarise and critique here:

The RTP documents the outputs from '27001 clause 6.1.3 a) through c) ...

... meaning the selection of 'appropriate information security risk treatment options' and a check against Annex A to 'verify that no necessary controls have been omitted';

Even with the '27001 corrigendum, the revised wording of this clause remains problematic and contradictory, implying that Annex A is at once both a complete ('comprehensive') and an incomplete ('not exhaustive') list of possible/suggested/recommended/required controls;
Users and auditors of the standard may disagree on their interpretations of the requirement, leading to tears at bed time;
The forthcoming new edition of ISO/IEC 27001 improves but may not totally resolve the ambiguity. We'll see.

For each [identified, evaluated and] treated [information] risk, the RTP records the:

Selected treatment option(s);

Presumably meaning that the RTP should state, for every identified risk, that it is to be avoided, mitigated, shared and/or accepted;
An example in the standard mentions that a control may 'change the likelihood, or change the consequences of the risk' - as if that helps! Is that another aspect also to be recorded in the RTP or an alternative to avoid/mitigate/share/accept?;
Since risks cannot be totally eliminated in practice, some residual risk is inevitable and must be accepted - so should that be recorded against every single risk, or against a separate high-level entry for 'risks relating to the ISMS and risk management process'?

Necessary control(s);

Where both 'controls' and 'necessary' are decidedly ambiguous.
'Controls' is generally taken to mean something similar to those in '27001 Annex A - basically a set of succinct one-liners rather than detailed descriptions such as the page or so expanding on each 'control' in ISO/IEC 27002;
'Necessary' generally means something like 'relevant, appropriate and hence a valuable means to mitigate one or more unacceptable information risks' - unless a jobsworth auditor doggedly insists that every single control in Annex A (and perhaps others of his/her own invention) is 'necessary' until he/she can somehow be convinced otherwise.

Implementation status.

Yet another ambiguous phrase!
The wording implies a neat binary measure i.e. each control is either implemented or not implemented.
Things are not always so clear-cut in practice, more analogue than binary with controls being partially implemented, in the process of being implemented, in the process of being retired/removed, of uncertain status etc.
Plus there's the added question of whether even fully implemented controls are in fact effectively mitigating the risks as intended: are they in use, active, working properly, generating value for the organisation and earning their keep?
How would anyone determine that, or gain assurance?
There's a naughty little cluster of potentially nasty concerns lurking behind 'implementation status' which the standards, and the RTP, largely ignore, presumably for the sake of the poor certification auditors who are expected not just to interpret the language but use it to test for conformity.

'27003 tells us the RTP can include other useful content i.e.:

Risk owner(s);

Casually hinting at what can be a very useful governance approach and risk management mechanism - except the hint is so subtle as to be easily overlooked. ISO/IEC 27000 defines risk owner as a "person or entity with the accountability and authority to manage a risk" - one of the precious few ISO27k mentions of accountability; and

Expected residual risk after the implementation of actions.

Errrrr, how are we meant to state this in the RTP? Obviously, we expect risks to be mitigated (reduced) or stabilised by the controls, but by how much?
What if the residual risk is still unacceptable - what then?
What if the residual risk remains uncertain, just as the true implementation status is uncertain?
What if the presumption that a control is 'maintaining' the risk turns out to be unfounded?
There are fundamental problems here due to the very nature of 'risk'.

'27003 even indicates/suggests a tabular format and content of the RTP:

The word 'plan' in RTP clearly implies an intention to treat identified and evaluated information [security] risks at some future point ... but:

When? Who? How? In what manner? To what extent?
If the 'plan' is, in reality, merely a vague suggestion with no real substance to it, no resources, no schedule, no management approval etc., does it have any credibility at all?
Even if there is a budget line item, an initiative, a project, a to-do list or whatever, it is still just a plan: jam tomorrow. Free beer next week. Trust me, nirvana is just around the corner - or, as we Kiwis say, "She'll be right", sometimes followed by "Yeh, right".
Is it reasonable for the RTP to state that a significant and patently unacceptable information risk is to be accepted and not mitigated for, say, at least a year? Technically, if that's what management decides having followed the proscribed risk management process, the certification auditors' unease is not sufficient grounds for raising a nonconformity.
The ISMS management reviews, internal audits, certification and surveillance audits could usefully check progress against the RTP, hopefully generating assurance that the RTP is actually being executed and completed more or less as intended except that is presently neither suggested or required by the standards, unfortunately - an opportunity lost, I say. Yes, I appreciate it would be tricky to specify the requirements and could lead to yet more effort and expense on assurance, but the focus and pressure on putting plans into action and meeting deadlines would be worthwhile IMNSHO.

As to other standards:

The current 2018 release of ISO/IEC 27005 doesn't even mention RTP - not once! Even 'risk treatment' only appears twice, in an annex quoting from ISO 31000 (see below).
In stark contrast, the forthcoming new 2022 edition of '27005 offers a much more sensible 2½ pages of RTP advice, mostly under clause 8.6.

The purpose of formulating the RTP is 'to create plan(s) for treating specific sets of the risks that are on the list of prioritized risks'.

Hmmm, that's a bit self-referential and, anyway, what are those 'specific sets of the risks' and how are risks prioritised? Subclause 7.4.2 refers to prioritisation as 'considering assessed levels of risks' which sort of makes sense. Although I haven't spotted any mention of those 'specific sets of the risks' in '27005, ISO/IEC 27007 talks of mitigating some risks with sets of related controls: maybe that's a clue - or is that a separate concern?

The RTP is 'a plan to modify risk such that it meets the organization's risk acceptance criteria'.

Fair enough, although the standard doesn't actually explain how those risk acceptance criteria might be determined/specified by the organisation.

The implementation guidance under '27005:2022 subclause 8.6.1 will include this gem:

Nicely put! 'Design plan' hints at the organisation having developed an information risk and security architecture. Good move, although personally as a fan of security engineering I'd have preferred an explicit mention and further guidance on that.

The expansive German infosec standard IT-Grundschutz talks of the RTP in terms of a project plan.
ISO 31000 describes risk treatment in clause 6.5 as involving 'an iterative process of:

Formulating and selecting risk treatment options;
Planning and implementing risk treatment;
Assessing the effectiveness of that treatment;
Deciding whether the remaining risk is acceptable;
If not acceptable, taking further treatment.'

Such iterations have implications for the RTP. For one thing, it should be seen as a dynamic, flexible, living plan showing a bunch of things currently in progress as well as those yet to start and perhaps those already completed. After due analysis and consideration, information risk and security-relevant changes (such as novel threats or attack modes, newly-disclosed vulnerabilities and new legal, regulatory or contractual obligations) may well require updates to the RTP (e.g. adjusting the relative priorities, resourcing and deadlines for planned activities). Any reviews or audits, therefore, should not expect or require the RTP to be static or complete. Some latitude is appropriate. Loose ends are likely to be dangling.
Potentially every treatment for every identified information risk needs to be formulated, selected, planned, (approved, funded and) implemented, assessed (somehow) for 'effectiveness', and evaluated, then sent back around the loop if the residual risk is unacceptable. For just about any organisation, that's an enormous amount of planning and work if done thoroughly ... which, arguably, is appropriate given that, in theory, even small gaps or weaknesses in our information security arrangements render us liable to incidents. In practice, however, it is unreasonable to expect such a thorough, detailed approach. Most managers would consider it red tape, not cost-effective and hence inappropriate and unjustified. A more realistic business-like approach involves prioritising the more significant risks with higher probabilities and/or impacts for detailed analysis and explicit treatment, while tackling lesser risks by other means such as generic/baseline security controls plus incident management and business continuity arrangements to cope with any incidents that do occur if and when residual risks materialise.

Section 6.5.1 of '31000 offers further useful guidance on the RTP:

That's a lot more detail than most RTP's I've seen or written so far, more akin to a project or program plan - suggesting that organisations could simply use their usual project/programme management methods rather than an RTP, at least for the initial ISMS implementation phase.
Once the ISMS is operational, I'm not convinced something called an RTP would add value to the routine, iterative information risk management activities aside from satisfying the requirement of the standard and the conformity assessment criteria. So, as far as I'm concerned, feel free to stamp "RTP" on whatever risk management documents you currently use!
That still leaves open the possibility of developing an RTP of the other kind mentioned in the forthcoming fourth edition of '27005, namely a 'design plan' or security architecture. Now that's an intriguing thought ...

OK, that's enough for today. I'm done. Topic discussed. Grey matter stimulated. Axes ground and honed to a razor's edge. Time to get outside and enjoy the first matariki public holiday here in NZ. Mind you, I'm tempted to prepare a guideline about the SoA and RTP, supporting the existing templates and elaborating on the security architecture, for the SecAware ISMS toolkits - maybe next week.

Infosec principles (Hinson tips)

noreply@blogger.com (Gary) — Tue, 21 Jun 2022 21:36:00 +0000

Thinking about the principles underpinning information risk and security, here's a tidy little stack of 44 "Hinson tips" - one-liners to set the old brain cells working this chilly mid-Winter morning:

Address information confidentiality, integrity and availability, broadly
Address internal and external threats, both deliberate and accidental/natural
Celebrate security wins: they are rare and valuable
Complete security is unattainable, an oxymoron
Complexity is the arch-enemy of security: the devil's in the details
Consider all stakeholders - users, administrators, maintainers and attackers
Consider threats, vulnerabilities and impacts
Controls modify or maintain risk
Defence-in-depth layers complementary controls of different types
Don't trust anything untrustworthy
Ensure business continuity through resilience, recovery and contingency
Even barely sufficient security is a business-enabler
Excessive security is a business-impediment, more likely to be bypassed
Exploiting information can be a good or a bad thing, depending on context
Failure is a possibility, so fail-safe means fail-secure
Focus on significant risks and the associated key controls
General-purpose controls such as oversight and awareness bolster the rest
Given practical limits to attainable security, residual risks are inevitable
Good security isn't costly: it's valuable, good for business
Identify, evaluate and treat risks systematically
Information content is a valuable yet vulnerable asset
Lack of control is neither threat nor vulnerability
Offensive security is a viable approach, within reason
People can be our greatest threats and our most valuable allies
Reducing exposure reduces risk
Residual (e.g. accepted, shared or unidentified) risks are still risks
Risk management is inherently risky, prone to failure
Risk-aligned planning gives diminishing returns
Risks combine the probability of occurrence with consequences of incidents
Risk mitigation is not risk elimination
Security and risk are dynamic, so proactively maintain and improve security
Security and risk are inherently linked
Security can be an illusion
Security is a process, an outcome and a state of mind
Security maturity is the result of learning and improving
Security must be cost-effective to add value and so justify its existence
Stakeholder understanding and support is vital for long-term success
Systematically engineer security - build it up from solid foundations
Threats are anything, anyone or any situation with the potential to cause harm
Transparency and openness increase assurance, confidence and trust
Trust depends on supporting controls such as assurance
Unlike responsibility, accountability cannot be delegated or denied
Unmaintained, unloved, unused controls are unreliable, subject to entropy and decay
Vulnerabilities are inherent weaknesses

Mostly they concern information risk and security in the general corporate/organisational context as opposed to being personal, national or cyber/IT-specific.

Some of them are quite similar or clearly related and could be combined - and I just know there are others worth adding to the list.

Some are phrased as guidance, others as concepts or definitions.

Some are trite, overladen, provocative comments that could usefully be expanded-on for clarity and depth of meaning, perhaps with explanation, corollaries and illustrative examples.

All of them can be challenged with counter-examples and viable/credible alternatives. I'm sure they could all be improved upon!

My little list is deliberately pragmatic and realistic rather than academic or theoretical. The sequence could be improved upon, although I'm not sure what kind of conceptual structure would make most sense: more coffee required!

In due course I'd like to contribute to the ISO/IEC 27000 revision project which intends to introduce a new clause around 'security principles'. Maybe some version of these would help? Maybe not.

WANTED: a set of infosec principles we can all agree on

noreply@blogger.com (Gary) — Mon, 20 Jun 2022 23:28:00 +0000

The SecAware corporate information security policy template incorporates a set of generic principles for information risk and security such as "Our Information Security Management System conforms to generally accepted good security practices as described in the ISO/IEC 27000-series information security standards." and "Information is a valuable business asset that must be protected against inappropriate activities or harm, yet exploited appropriately for the benefit of the organization."

Despite being reasonably happy with the 7 principles I selected, I would prefer to base the policy on a generally-accepted set of infosec principles, akin to the OECD Privacy Principles first published with remarkable foresight way back in 1980.

There are in fact several different sets of principles Out There, often incomplete and imprecisely stated. Different authors take different perspectives, emphasizing different aspects, and the contexts and purposes also differ.

It will be an 'interesting' challenge for ISO/IEC JTC 1/SC 27 to tease out, elaborate on, fine-tune and hopefully reach consensus on a reasonably succinct, coherent, comprehensive set of generally-applicable 'concepts and principles' for the next edition of ISO/IEC 27000.

I just hope the learned committee doesn't end up specifying a racehorse looking something like this ...

The Matrix, policy edition

noreply@blogger.com (Gary) — Sat, 18 Jun 2022 21:54:00 +0000

Inspired by an insightful comment on LinkeDin from an SC 27 colleague on the other side of the world (thanks Lars!), I spent most of last week updating the SecAware security policy templates and ISO27k ISMS materials.

The main change was to distinguish conformity from compliance - two similar terms that I admit I had been using loosely and often incorrectly for far too long. As I now understand them:

Compliance refers to fulfilling binding (mandatory) legal, regulatory and contractual obligations;
Conformity concerns fulfilling optional (discretionary) requirements in standards, agreements, codes of ethics etc.

It's a fine distinction with implications for the associated information risks, given differing impacts:

Noncompliance may lead to legal enforcement action (fines/penalties), other costly sanctions (such as more intrusive monitoring by the authorities and perhaps revocation of operating licenses) and business issues (such as reputational damage and brand devaluation, plus the costs of defending legal action).
The consequences of nonconformity may be trivial or nothing at all if nobody even cares, but can also involve business issues such as inefficiencies, excess costs and so on, particularly if customers, business partners, the authorities or other stakeholders are seriously concerned at management's apparent disregard for good security practices.

Certification of an organisation's ISMS, then, demonstrates its conformity with, not compliance to, ISO/IEC 27001 - well in most cases anyway, where management voluntarily chooses to adopt and conform to the standard. If they are obliged by some mandatory, legally-binding requirement (an applicable law or regulation, or perhaps terms in a formal contract with a supplier or customer, perhaps due to a law or regulation that pplies to them), I guess they must comply.

Putting that another way, nonconformity is an option. Noncompliance isn't.

Anyway, having adjusted the terminology and tweaked the SecAware materials, I took the opportunity to prepare two new 'bulk deal' packages - a comprehensive suite of information security policy templates, and a full set of ISO27k ISMS materials. I'm hoping to persuade customers to ~~spend~~ invest a little more for greater returns.

The SecAware policies, for instance, are explicitly designed to work best as a whole, an integrated and coherent suite as opposed to an eclectic collection of policies on various discrete topics. In recent years, I have developed a spreadsheet to track the mesh of relationships between policies:

Yellow blobs on the matrix indicate touch-points between policies, issues of common concern. For example, blobs in the access control policy column mean the policy is related in some way to policies on business relationships, clear desk and screen, cryptography, database security and so on.

If, say, a organisation has an access control policy but currently lacks a policy on the information risk and security aspects of business relationships (e.g. with its Internet and cloud service providers), that may represent a gap in its policy framework unless the access control policy happens to cover business relationship security as well. Likewise with all the other related aspects. While technically it would be possible for the access control policy to cover the lot, in practice that would be 'suboptimal', resulting in an unfocused, unweildy, convoluted and confusing policy, especially if each policy went into detail on related topics.

[Trust me, I know. BTDT. Years back I developed an 'Information security policy manual' as a single document. It was a headache to maintain and being about 150 pages, a nightmare to read and understand. The 'policy suite' approach with a collection of topic-specific policies works better for me and our clients.]

The relationships are bidirectional, by the way: access control is relevant to business relationship security, and vice versa. That markedly simplifies the matrix since blobs to the right of the black diagonal would be a mirror image of those to the left.

The matrix is a surprisingly useful policy management tool, a simple, visual way to maintain the complex relationships between policies in the suite. A few days ago, for instance, I added entries for three new policies on responsible disclosure, threat intelligence and data masking/redaction. Updating the matrix involves determining, for each policy, which related areas are significant enough to merit blobs. It's worth checking that the linked policies don't both cover the same issues, at least not in any detail and especially not in conflicting terms - although, having personally written and regularly maintained these policies for decades, I already have a pretty good idea about what the related policies do and don't say. It's getting harder, though, as the suite approaches 80 topic-specific policies (!) plus 8 Acceptable Use Policies and an overarching Corporate Information Security Policy and, frankly, I'm getting on a bit.

The security architectural objective is to ensure that all relevant policy matters are covered clearly and unambiguously, leaving no significant gaps or overlaps. The policies need to interlock, supporting each other and strengthening the entire control construct. That's important from a governance perspective since policies are a primary mechanism for exerting management direction and control over the organisation.

So, there you have it, a Hinson tip for managing a complex mesh of information security or indeed other policies, something worth contemplating at least. I commend it to the house.