Black hawk down ... but not out

I've long been fascinated by the concept of 'resilience', and surprised that so many people evidently misunderstand and misrepresent it ... so please bear with me as I attempt to put the record straight by explaining my fascination.

Resilience is not simply: 

• Being secure
• Being strong
• Recovering effectively, efficiently or simply recovering from incidents
• Avoiding or mitigating incidents
• Any specific technical approach or system
• Any particular human response, action or intent
• A backstop or ultimate control
• Heroic acts
• A construct, something we design and build
• Something that can simply be mandated or demanded
• Specific to particular circumstances, situations or applications

It's bigger than any of those - in fact bigger than all of them, combined. Resilience is all of those, and more ...

Resilience is:

• A general concept, a philosophy, a belief
• An engineering and architectural approach

Using AI/ML to draft policy

This week, I am preparing a new template for the SecAware policy suite covering the information risks and security, privacy, compliance, assurance and governance arrangements for Artificial Intelligence or Machine Learning systems. With so much ground to cover on this complex, disruptive and rapidly-evolving technology, it is quite a challenge to figure out the key policy matters and express them succinctly in a generic form.

Just for kicks, I set out by asking GPT-4 to draft a policy but, to be frank, it was more hindrance than help. The draft was quite narrowly focused, entirely neglecting several relevant aspects that I feel are important - the information risks arising from the use of commercial AI/ML services by workers, for instance, as opposed to AI/ML systems developed in-house.

The controls it espoused were quite vague and limited in scope, but that's not uncommon in policies. It noted the need for accountability, for instance, but didn't clarify the reasons nor explain how to achieve accountability in practice. It was not pragmatic.

ISMS support tools (episode 4 of 4)

This final episode in the series about specifying and selecting ISMS support tools/systems concerns the general usability requirements typical of almost any computer system, such as:

• Intuitive, easy to use;
• Interoperable;
• Facilitates customisation where appropriate;
• Readily maintained;
• Well supported, documented etc.;

ISMS support tools (episode 3 of 4)

So far, I've waffled on about the variety of ISMS support tool types on the market, and about gross differences between ISMS user organisations in terms of industry, size etc.

Next, think about the kinds of things they might expect their ISMS support tools to do. Digging beneath the superficial "support our ISO/IEC 27001 ISMS", organizations may well expect/require the tools to help them with security controls such as:

• Access rights and permissions;
• Alerts or alarms;
• Anti-spam;
• Antivirus;
• Assorted security processes;
• Backups;

ISMS support tools (episode 2 of 4)

Previously I blogged about the bewildering variety of tools, systems and services supporting ISO/IEC 27001 Information Security Management Systems. The tools, in turn, are being used in various ways for various purposes by a bewildering range of organisations.

The ISMS specified by ISO/IEC 27001 is "intended to be applicable to all organizations, regardless of type, size or nature", a deliberately broad scope that takes in:

• Conventional commercial companies, government agencies and departments, charities and not-for-profits, conglomerates, kieretsu and groups, schools, colleges and universities ...; 
• Organisations of all sizes, micro-to-macro;

ISMS support tools (episode 1 of 4)

From time to time, members of the ISO27k Forum seek opinions about systems on which to run their ISO/IEC 27001 Information Security Management Systems, anticipating feedback or recommendations for certain products.

Unfortunately, it's not quite that simple!

For starters, the ISMS support systems come in several flavours. Our toolboxes are bulging ...

Supposedly comprehensive ISMS systems

These claim to support every conceivable aspect of information risk and security management, incident management, business continuity, compliance, governance, assurance and more. Whether that reflects a comprehensive architecture and design from the ground up, or a more limited core system on to which various adornments have been tacked over the years (sometimes including functional units from totally different systems and suppliers), is not necessarily obvious until users explore the limits and perhaps fall between the cracks.

More focused ISMS systems

Preparing managers to be ISO27001 certified

This morning, a new member of the ISO27k Forum asked us some questions about his organisation's upcoming ISO/IEC 27001 certification audit (paraphrased below). 

Since these are commonplace issues, I address them here on SecAware blog for the benefit of others in the same situation now ... or at earlier stages. Management being ready for the certification audit has implications for the way an ISO/IEC 27001 Information Security Management System was originally initiated/conceived, scoped, planned and approved, as well as how it is managed once it comes into operation.

1. Does the auditor need to talk to the CEO or would another member of Top Management such as the COO or a VP be sufficient?

That is for the auditor to decide. CEOs are invariably busy people ... but the CEO's non-involvement (even before being asked!) hints at a lack of support or engagement from senior management*. If other senior managers are more willing and able to be interviewed, that should suffice, especially if they subtly or directly confirm that the CEO supports the ISMS, or if the CEO has overtly supported the ISMS (e.g. by personally endorsing or mandating the information security policy). See also Q4 below.

2. Approximately how much time is required for an audit interview?

The power of power measurement

Electrical power consumption by a computer cupboard, IT room, tech suite, data centre or facility is one of my favourite metrics for several reasons:

• It is readily measured using a wattmeter, watt-hour meter or ammeter on the main supply line/s;
  
  
• Compared to more technical metrics, power is simple to plot, report, explain and understand;
  
  
• As the installed IT equipment and usage gradually changes, so does the power consumption. It is straightforward to track and predict the overall trends without necessarily measuring and controlling every single item and change; 
  
  
• Step changes in power consumption indicate substantial changes in the IT equipment or usage. Marked decreases are welcome but quite rare (e.g. as older equipment is retired from service or replaced by more modern, energy-efficient stuff), whereas marked increases in consumption - especially if unexpected - may be cause for concern;
  
  
• The first law of thermodynamics tells us that all the input energy has to go somewhere i.e. heat which can be costly to remove, increases global warming, increases fire risks and decreases equipment lifetimes. 

In more detail, a high PRAGMATIC score (~77%) indicates that IT power consumption is a valuable metric, well worth considering:

Information risk management, a business imperative

Information risk management is a crucial business issue in the digital age. This piece describes a systematic and proactive approach to information risk management with a healthy dose of pragmatism.

It is obvious that serious incidents such as ransomware can disrupt operations, severely damaging an organisation's reputation, brands and customer trust, threatening its financial stability and longevity ... but that's not all. Even relatively minor incidents can accumulate significant costs over time, starving other important business activities of resources. Given that practically everything depends on information, the starting point is to embed information risk management fully into the organisation's business strategy and routine operations.

Most organisations have basic information security controls in place. However, a strategic approach is less common, while a truly comprehensive business-oriented approach to information risk management remains quite rare. 

Information risk management focuses on identifying, evaluating and treating risks to the organisation's valuable business information including: 

Unnecessary control example

A couple of days back, I said I'd offer an example of an 'unnecessary control' in the context of ISO/IEC 27001. So here goes.

Picking one at random, I'll lay into ISO/IEC 27001:2022 control A.5.28 "Collection of evidence". 

The control text reads "The organization shall establish and implement procedures for the identification, collection, acquisition and preservation of evidence related to information security events".

How can anyone possibly justify excluding such an eminently sensible control from their ISO27001 Information Security Management System?

Reading and interpreting that control literally, word-by-word, one could certainly argue that:

Unnecessary controls

With an ISO/IEC 27001 Information Security Management System, the choice of information security controls is almost* entirely a matter for the organisation's management, according to their assessment of the organisation's information risks. 

The overall information risk management process is straightforward:

1. Identify risks affecting the organisation's information.
   
   
2. Explore the risks, quantifying them in some way.
   
   
3. Decide what, if anything to do about the risks (avoid, mitigate, share or accept).
   
   
4. Do it!
   
   
5. Monitor for and deal with changes to the risks, their evaluation and treatment etc. 
   

Transition to ISO/IEC 27001:2022 - updated

As anticipated, the International Accreditation Forum has published updated guidance on the transition arrangements for certification of organisations against ISO/IEC 27001:2022, the new third edition of the standard released in October. There are several possibilities under various circumstances (as I understand it*) ...

1) Organisations that are already certified to ISO/IEC 27001:2013 (or to equivalent national translations of that old 2013 edition of the standard) have about three years to move to the new 2022 edition. Meanwhile, surveillance audits can use either edition of the standard, whichever the organisation chooses to use.

2) Organisations currently preparing to be certified prior to June 2023 can choose either edition:

Two ISMS case studies

While waiting impatiently for today's stormy NZ weather to subside so I can get outside and survey the damage, I spent a productive few hours writing-up a pair of recent consultancy assignments as case studies for the SecAware website.

< The first case study concerns helping a US tech support company to regain its ISO 27001 certification by rebuilding its failed ISMS.

Officially, the assignment was simply an ISMS internal audit. In practice, it involved some lightweight mentoring and support for a capable CISO.

The second case study concerns consultancy support for a 6-month ISMS implementation project for an innovative NZ agritech company >

Again, although the centrepiece of the assignment was an ISMS management review, it involved gently mentoring and guiding the project managers (two contractors) and providing assurance for the client's senior management - plus stress-reduction when both contractors departed shortly before certification.

Why get ISO 27001 certified?

If you have designed and implemented an Information Security Management System based on ISO/IEC 27001, you should be realising a variety of business benefits through improved information risk and information security management. 

Fantastic!

The international standard specifies a framework, a rational structure with which to identify, evaluate and treat the organisation's information risks systematically. The framework is a tool that enables senior management to govern and manage the information risk and security activities in ways that align with and support the achievement of business objectives, plus obligations to or expectations of third parties.

Through strategies, policies and procedures, plus measurement and assurance processes, management has the levers to direct, organise and oversee a more efficient and effective approach to information risk and security. Information risks are systematically prioritised for treatment using suitable security controls (technological, physical, procedural and others). With appropriate controls in place, incidents grow less frequent and are identified and resolved sooner causing less disruptive and costly consequences. Appropriate security metrics, reviews and audits enable management to direct corporate resources effectively, gaining confidence in the organisation's ability to handle information risks.

2 more topic-specific information security policies

We have just completed and released another two information security policy templates through SecAware.com.

The latest additions are security policy templates on:

• APIs (Application Programming Interfaces) and microservices, used as building blocks to construct compound applications;
• DNS (Domain Name Service), used to associate domain names with Internet server IP addresses.
  
  

The full SecAware policy suite now has 83 templates:

They were all researched and written to a consistently high quality, by me. They are designed to mesh together, complementing each other. I maintain them, updating individual policies as and when required and reviewing the entire suite every year or so. 

We provide them as MS Word documents that you can easily customise. Get in touch for additional policies, procedures or guidelines, or if you need assistance to adapt them to your corporate style. 

Buy them individually for $20 or take the whole lot for $399, saving over $1200.

Book review: The Consultant's Handbook

Title: The Consultant's Handbook: How to use your expertise to deliver client success and run a profitable business

Author: Andrew Sheves

ISBN: 978-1-7345116-7-3

Price: $15 from Amazon

GH rating: 85%

Summary

Straightforward, straight-talking guidance for busy consultants looking to establish and grow their practice.  

Handling ISMS nonconformities reported by audit

A new member of the ISO27k Forum asked how long they have to resolve a minor nonconformity reported by the certification auditors.

I didn't know the answer so I looked it up in ISO/IEC 27006. Clause 9.6.3.1 says (in part):

"The time allowed to implement corrective action shall be consistent with the severity of the nonconformity and the associated information security risk." 

Significant risks should be addressed as a priority, whereas minor risks may be addressed 'in due course', perhaps as part of other planned changes or when the opportunity arises. Furthermore, complex issues are bound to take some time to resolve, whereas simple things may be resolved more or less on the spot. 

I suggested the reported nonconformity should be addressed in the normal way, using the organisation's documented ISMS processes along these lines:

Book review: The Art of Writing Technical Books

Title: The Art of Writing Technical Books

Author: Peter H. Gregory

ISBN: 978-1-957807-49-2

Price: US$15* 

GH rating: 85%

Summary

If you are thinking seriously about writing your first book, Peter's plain-talking guidance slices through the bewildering cloud of choices and issues you face.  Working with a literary agent, publisher and assorted experts is an obscure and convoluted process.  Peter explains it well.

Two dozen data centre fire controls

Fire is clearly a significant risk to any data centre given that a major incident (disaster!) is reported globally roughly every quarter year on average plus an unknown number of smaller/unreported ones. Limited public disclosure of data centre fire investigation reports makes it tough, even for experienced professionals, to assess and quantify the risk.  However, since the likely impacts and costs of such major incidents are obviously non-trivial and the number of incidents is definitely not zero, it would be negligent to ignore the risks.

Controls to avoid, mitigate or share data centre/IT facility fire risks include:

1. Governance and management arrangements taking due account of information risks including physical security aspects when designing and procuring information services such as commercial cloud services and data centre/co-location facilities - which, by the way, don't automatically reduce

Qualitative vs quantitative risk assessment

 

The risk assessment core of the risk management process involves, identifying, analysing and evaluating risks - not to understand or quantify them so much as to inform the subsequent management decisions about how to handle them.

Unless those managers who will make the decisions understand, trust, value and utlimately use the information provided by the analysts, risk assessment is a pointless, costly exercise. Providing useful information to support decisions is thus a pragmatic risk assessment objective.