Process control trumps document control

Departments that have an ISO 9000-type approach to quality assurance, or any other mature ‘management system’, typically have standard ways of managing documents involving things such as:

• Document lifecycles from cradle-to-grave: how does the need for a new document arise? How does that happen, in practice? Who determines and specifies the requirements or objectives etc.?
• Document ownership, accountabilities and responsibilities: who is in charge? Who has the final say? 
• Classification of documents, even if only by name [policies, procedures, guidelines etc.], with implications on authorization, use, assurance, disclosure etc.;
• Structured document review, update, authorization and release processes;
• Standard, consistent document formats and styles – preferably emphasizing readability and utility – perhaps using templates with mandatory and optional elements;
• Maintained and managed inventory of [important] documents, with some sort of overall architecture or framework – an important control, often neglected*;
• Standardized document naming and referencing, ideally with a way to identify draft, current and deprecated/retired documents i.e. versions and dates;
• Controlled release and deployment processes, including ways to ‘withdraw’ deprecated documents and other change management elements such as awareness and training for new ones;
• Assurance and compliance aspects: for processes that are or include key controls, how do you ensure that they are operating correctly and effectively?

That’s potentially a massive amount of red tape/costly overhead, hinting at a more strategic perspective: focus on key processes, making sure they are well controlled (which includes but goes beyond the documentation) while relaxing control over lesser ones, consciously allowing them to drift a little. That in turn implies a means of identifying those ‘key' processes. Particularly in the ISO27k context, the obvious mechanism to do so is risk assessment – which I’ve already hinted at in the form of document classification.

Another strategic aspect is innovation and creativity: if everything possible is tied down too tightly, there’s no wiggle room for people to explore and try out new approaches, even if those might be in the organization’s best interest. It might be worth leaving some latitude for innovative, creative approaches, or at least mechanisms to allow this under certain circumstances (e.g. studies and trials that, if successful, may lead to changes in the document-related processes). 

A simple example is the use of diagrams such as process flow charts, decision trees and mind maps to illustrate, summarise and lead people through processes, supplementing or reducing the words. Another is the use of electronic documents and displays in various formats – the electronic checklists now being used by many commercial pilots for example, plus automated process controls and electronic mimic panels in manufacturing, 'mission control', cockpits and other contexts where the information presented to the operator depends on the dynamic situation on the plant/equipment at that moment. 

* Just this morning, I was reading an insightful piece by Michael Rasmussen of 20/20 GRC about management getting into a panic when someone finally notices that they have accumulated hundreds or thousands of policies across the organization as a whole, all different types and statuses, with no central inventory and hence little to no control. It’s a mess! Think about it: even within the information risk and security areas, how many of us can say, for sure, what policies, procedures and guidelines we have in place right now, which ones are due for or undergoing review, which have/have not been officially authorized and released etc.? Expand that across HR, Finance, Ops and so on, and the scalability and control problems are obvious. “Use a Document Management System” might seem like a sensible solution, but the same issue applies: must the entire organization use the same DMS? Or if different DMSs exist, do they interoperate? How do we ensure they are internally and externally consistent?

Who's the daddy?

A deceptively simple question this morning from a client about where the information security function should sit in the organization structure set me thinking as the first coffee of the day did its magic.

My first thought is that it all depends on the organization, the existing structure and power bases, the specific interests of the individual executive managers, the strategic directions, the corporate culture, other stakeholders and most of all ‘the business’. 

So for, say, a financial services, defense, health or intellectual property company, information is such a critically important, valuable yet vulnerable corporate resource that risk and security deserves direct representation in the C-suite i.e. a Chief Information Security Officer or possibly Chief Security Officer. For other industries, it’s not so clear-cut.

I strongly favour the core term “information risk” since risk to and involving information (not just computer data!) is what drives our field. Information security (i.e. mitigating information risks using controls) is just one way to deal with information risk, and we should not neglect risk acceptance, risk sharing and risk avoidance, plus the ‘opportunity’ side of risk (deliberately taking chances where justified for business reasons), which puts a different spin on control and security. Therefore, I would argue ‘risk’ is our natural home, hence (to me) the Chief Risk Officer would be a more appropriate boss than, say, the Chief Information Officer, Chief Legal Officer or Chief Financial Officer.

A specific concern with reporting to the CLO is the tendency to emphasize compliance with legal and regulatory obligations, externally-imposed on the organization … rather than on doing what’s best for the organization and its business. Legal and regulatory compliance is a low hurdle, albeit a very solid one, painful to trip over.

A specific concern with reporting to the CIO is the tendency to emphasize IT, data and cyber. Those are important, of course, but there’s more to information risk. Even if IT security is locked down tight, other aspects (such as fraud and other forms of social engineering, and IPR) can still sink the business, often undermining or negating the cybersecurity controls. To me, the whole cyber movement is seriously unbalanced and misguided ... but that's just my feeling having been through the evolution from IT security to information security in the 90's and the ascendance of BS7799 then ISO27k. "Cyber" is a retrograde step ... whereas "information risk" moves things forward.

A specific concern with reporting to the CFO is the tendency to emphasize economics, or more specifically accountancy and ‘the books’. Costs and benefits which are not easily accounted for tend to be ignored. Valuing intellectual property is a particular problem here, along with the difficulties of justifying investments in risk management/reduction. As a fan of metrics, I definitely appreciate the idea of 'managing by the numbers' but that's not the same as ignoring anything without a firm dollar value.

Yet another possibility is a Chief Governance Officer – someone to take the lead on governance matters … although that function often falls to the Board of Directors and the Chairman/Chief Executive Officer (depending on structure) and collectively to the whole C-suite and so on down the management hierarchy. 

And finally, there’s the issue of other related aspects such as HR/people, health and safety, business continuity and audit. Where should they fit-in? They are also relevant to information risk and security.

At the end of the day, “C*O” is just the label on the door, a tag on the business card and an allocated parking place for the limo. What really matters is vision, leadership, competence, passion/drive and teamwork … and in that sense Information [Risk and] Security Manager - or indeed Consultant - is as good a term as any! Even a layer or two down in the hierarchy, backed with relevant security metrics and your own passion and drive, you can get plenty of stuff done through persuasion and collaboration: it’s just easier and quicker if you’re the boss, or at least have the bosses' ears.

What is the ISMS for?

Another interesting morning on the ISO27k Forum when a new member asked for help to address an ISMS internal audit finding relating to ISO/IEC 27001:2013 section 4.1: 

“The organization shall determine external and internal issues that are relevant to its purpose and that affect its ability to achieve the intended outcome(s) of its information security management system.”

To my beady eye, that succinct sentence (plus the rest of clause 4 and more besides) leads-in to a fairly diverse and creative set of activities relating to ‘establishing the context for the Information Security Management System’:

1. Who are the stakeholders with an interest in the organization’s information and hence the associated risks and opportunities? What are their 'issues' - their interests, in fact? What matters to them? What are their priorities and concerns? What business is it of theirs? [Clause 4.2]
2. Consider the organization’s purposes (business objectives/goals, strategies and other drivers and constraints) that in some way involve or drive information risk and security e.g. if “Being a trusted partner” is one of the corporate aims stated in the CEO and Board’s mission statement, that indicates a need to be a trustworthy organization, and hints at a desire to be recognized and appreciated and valued as such by business partners/outsiders. So what are the implications on how we do business, in particular how we handle information?  What should the ISMS be doing (or indeed avoiding) in support of "being a trusted partner"?
3. Consider also how information risk and security concepts can/should support and enable the business. For instance, what is management’s position on privacy – not just the obvious legal and regulatory compliance aspects but privacy, personal space, personal choice and freedoms etc. as a more general concept? What about, say, the ‘integrity’ part of the CIA triad: in what ways is integrity relevant and potentially necessary or valuable to the business? And what about information risks: how will the ISMS help manage those? What will the ISMS bring to the game that couldn't be done as well without it?
4. Elaborating on that concerning the ISMS itself, what is it expected to achieve for the organization? How will a [certified] ISMS earn its keep across all of those areas – how will it make that easier, better, cheaper etc., more than offsetting the costs involved in establishing, operating and maintaining the ISMS? What are the priorities? In hard-nosed business terms, where’s the financial value in going down the [certified] ISO27k ISMS route when there are many alternatives, some of which might not be possible or might be delayed if finite resources are allocated to the ISMS implementation? And what are the risks associated with the ISMS itself, plus the implementation project? What might derail this train?
5. With all that in mind, then, what are the key elements and factors relating to the ISMS – including things such as: its main purposes or objectives, expectations etc.; its scope [clause 4.3]; the anticipated net value (ideally with enough details behind that to measure and demonstrate the value achieved); its integration with the rest of the organization including other management systems, functions, departments, initiatives etc.; its risks; and how will all that be governed, managed, directed and controlled?

That’s how I personally would read and interpret clause 4. My interpretation goes way beyond what the standard literally says and formally requires, and there are some on the ISO27k Forum who would argue (with good cause) that – as usual - I’m blabbering on, making a mountain out of a molehill and over-complicating matters (yup, guilty as charged!). The KISS approach would involve doing the least amount possible in order to convince the certification auditors that we have done what is required in the standard: I understand that perspective, and appreciate that certification and simplicity are legitimate and valuable objectives in their own right … and yet I believe we can achieve even more value from ISO27k by going beyond the minimalist formalities, designing and building an ISMS that adds even more value to the business, which in turn will help ensure its longevity and deeper integration into the organization. There's reason to my madness.

Further reinforcing the broader perspective, ISO/IEC 27003:2017 (the very useful ISMS implementation guide) has a full two pages of explanation and guidance just on section 4.1. I'm not going to lay it out here though. Go read the standard!

In practice, the outcome of those competing pressures is generally something in the middle. At the time of certification, the ISMS has to be at or above the minimum formally required in ‘27001. The question is how far above should it be? In which respects is it worth going above and beyond?

Personally, I’m keen to explore the wider business objectives and possibilities (the business risks and opportunities associated with the ISMS - the stuff that clause 6.1 should have addressed if it hadn't fallen down the information risk rabbit hole) at the outset, in order to ensure that the ISMS is designed with those longer-term goals in mind, even if in the short-term it barely does what it has to do. It's about persuading management to invest in information risk and security management because that's the route to prosperity for the organization. Scoping, directing and launching the ISMS are the critical first steps on a long journey. So let's set off on the right foot, eh? Let's at least assemble the A-team to design the edifice and construct sound foundations using building materials that won't crumble if/when we decide to add a second storey. The ISMS needs integrity too.

Corporate infosec policy

At the peak of the typical policy pyramid sits a ‘corporate information security policy’. In clause 5.2, ISO/IEC 27001 explicitly requires an information security policy specifying aspects such as demonstrable top management commitment and objectives.

The corporate information security policy template has:

• The usual boilerplate for any formal policy e.g. summary, applicability, version and date up front, plus responsibilities and references at the back;
• A short introduction, using the pyramid diagram to outline the entire information security policy structure;
• A set of seven principles (objectives) driving information risk and security e.g. “Information is a valuable business asset that must be protected against inappropriate activities or harm, yet exploited appropriately for the benefit of the organization.  This includes our own information and that made available to us or placed in our care by third parties.”

The principles fascinate me. They aren’t (yet!) stated in any of the ISO27k standards, and yet these are fundamental concepts underpinning the entire field such as 'least privilege' and 'personal accountability'. In researching and preparing our corporate infosec policy, I dug out a bunch of principles from various places and rationalized them down to the present set. I’d like to revisit that sometime, maybe even prepare a paper about the principles and then propose either a new ISO27k standard or an appendix to, say, the information security governance standard ISO/IEC 27014.

PS  At the end of 2022, I seized the opportunity to suggest incorporating a set of generic principles into ISO/IEC 27000 as part of SC 27's revision project. I have in mind developing something akin to the archetypal OECD Privacy Principles that remain fundamental to privacy laws and regulations today, decades later. Watch this space! 

Not playing by the rules

According to the BBC, British Airways has been fined £183m for last year's breach of the General Data Protection Regulation, dwarfing the previous record fines of £½m under the previous Data Protection Act.  

Ouch. Privacy compliance is now A Thing - A Very Big Scary Thing with Sharp Teeth, Claws and a Bad Attitude.

The prosecution and fine broadcasts a clear message that organizations are going to be held to account under GDPR for failing to prevent privacy breaches. I guess privacy officers, information risk and security managers, CISOs, CROs, CCOs and execs generally are now scrambling to gain assurance that their organizations are not going to end up in the same mess. And management at organizations which have suffered privacy breaches since GDPR came into effect, especially if they are currently under investigation or being prosecuted, must be quaking in their hand-made Italian leather boots. 

At 366 times the previous record, the BA fine is deliberately shocking. No wonder BA is talking about appealing the decision ... but it could have been even worse. Reportedly the fine was 1.5% of BA's global turnover, while the maximum for specific penalties under GDPR is 4%: that would have been an eye-watering £488m, or about US$600m. 

Gulp.

Airline profits are unusually volatile thanks to intense competition and factors largely outside management's control, such as fuel prices and significant incidents that affect the global travel industry. BA might conceivably need to call on its parent company or the banks for assistance to settle the bill without taking a corporate nose-dive. Even cancelling executive bonuses seems unlikely to be enough.

Having said that, any well-run organization will have identified, evaluated and treated their privacy and other information risks, including making contingency and other business continuity arrangements just in case serious incidents such as this occur. Compliance is a good reason to manage information risks professionally, on top of the many good business and social reasons for taking it seriously.

ISO27k audit planning

A thread on the ISO27k Forum about how to go about auditing an organization's Public Key Infrastructure set me thinking this morning.

The thread started with a question from PS:

"Could you please share some tips for auditing TLS/SSL arrangements within organisation?  Nessus will help us to identify weakness around configuration of crypto but if  I want to audit how sysadmins are creating self-signed certs and applying key management principles, how would I do that?"

In response, Ahmed provided some background information about PKI, followed by a fairly detailed and specific list of 15 auditable items, describing them as 'essential points':

1. Audit for Root Certificate: how its managed, should be stored over secure hardware module (HSM) FIPS 140-2, if not how its secured.
2. Assess CA Signing certificate (CA Private key) : How it is managed, secured, validity and key length.
3. Audit System documentation to audit: (mentioned above) specially key management policy and procedures.
4. Audit roles and segregation of duties
5. Audit certificate templates: Issuing compliant certificates, SSL-TLS and Digital identity if valid that your are using two certificate templates or only SSL-TLS
6. Audit for certificate (key usage) for individual certificates (Mail signing, authentication, encryption, etc.)
7. Audit access control to the CA (should be subject to dual control)
8. Audit CA Public key and intermediate certificates distribution, to assure its trusted over all systems.
9. Audit for clock sync over used system
10. audit system database security
11. audit system backup and restore (for CA server, Configurations, HSM, root certificate, database)
12. Audit for CRL publishing or cashing over systems
13. Audit validity of issued certificates and how renewals are managed, to avoid human error to forgot to renew a certificate may cause system malfunction
14. Audit the process itself for certificate issuing, renewal and revocation. (should be subject to dual control as maker checker)
15. Audit certificate formats and extensions (PKCS formats and extensions)

Those 15 items may be a useful prompt or reminder but may not be appropriate in any given situation. ‘The essential points’ for a given audit are best determined in practice by the auditor/s using risk analysis, followed by detailed planning and prioritizing the audit work given the available resources (audit timescale plus auditor man-hours and skills).

An audit must reflect the audit objectives and scope, usually determined up-front by discussion between the audit and client management when the assignment is initiated and agreed. So, for instance, if the primary objective is to audit compliance of an ISMS with ISO/IEC 27001, the PKI is probably just a small part of that. However, if the prime objective is to audit the PKI, specifically, then a list of items similar to the 15 suggested by Ahmed may flow out of the audit risk analysis – or not: it all depends on the information risks, just as the ISMS and the PKI are driven by the risks.

As a general rule, relative risks are a good basis for prioritization: in essence, the idea is to tackle the most significant risks first and deepest, leaving lower risk matters for later, shallower review. That way, if the priority stuff turns out to be more problematic or to take longer than anticipated and resources are exhausted, the assignment can end knowing that the high priority areas have been done.

With a nearly infinite amount of potential audit work for finite resources, there are things that simply can’t be done right now. So, it pays to prioritize ‘the essentials’ and de-prioritize or park the remainder for another time. Keep notes in the audit file for use in planning future audits, along with previous audit reports, fieldwork notes, an updated risk analysis and other information sources (e.g. management reviews, incident reports etc.). This is continuous improvement for auditing.

An alternative or complementary audit planning approach is to come up with a small number of 'areas of concern', then invest an appropriate amount of audit resources into each one. Determining those 'areas' again depends on circumstances: one approach to a PKI audit might distinguish technical/cybersecurity stuff from physical and procedural aspects, for instance. Another might follow the lifecycle of a digital certificate, or concentrate on the individual departments and teams associated with the PKI, or pick up on incidents and known troublespots as routes in to the analysis, or ... whatever. There's even something to be said for deliberately planning each successive audit on a different basis, in order to avoid covering the same ground from the same perspective and hence missing the same issues (blindspots).

It's always worth reserving some time to explore interesting/concerning stuff that comes up in the course of the audit. For example, if the audit fieldwork uncovers issues with, say, key-management, it mightbe worth delving more deeply into key management both to find out if there is anything substantial and reportable in that specific area, and also as a worked example for the more general aspects such as policies, procedures, technical controls or whatever.  The key-management focus may not have been apparent during the original audit planning, although sometimes there are nonspecific clues about potential problem areas that feed into the risk analysis and planning (the auditor’s nose sniffing out trouble spots!). 

This is an example of contingency management: the audit work that needs to be performed partly depends on the circumstances or situation that unfolds in the course of the assignment. It can't all be pre-plannned.

It cuts both ways too. If the initial audit work goes better than planned, that leaves more time for other, lower priority matters, and might even result in concluding the audit early with a glowing audit report. 

Yes, it does happen!  Been there, done that!