ISO/IEC TR 27008:2011 — Information technology — Security techniques — Guidelines for auditors on information security controls
This standard (actually a “technical report”) on “technical auditing” complements ISO/IEC 27007. It concentrates on auditing the information security controls - or rather the “technical controls” (as in IT security or cybersecurity controls), whereas ’27007 concentrates on auditing the management system elements of the ISMS.
This standard provides guidance for all auditors regarding “information security management systems controls” [sic] selected through a risk-based approach (e.g. as presented in a statement of applicability) for information security management. It supports the information risk management process and internal, external and third-party audits of an ISMS by explaining the relationship between the ISMS and its supporting controls. It provides guidance on how to verify the extent to which required “ISMS controls” are implemented. Furthermore, it supports any organization using ISO/IEC 27001 and ISO/IEC 27002 to satisfy assurance requirements, and as a strategic platform for information security governance.
Purpose and justification
- Is applicable to all organizations, including public and private companies, government entities and not-for-profit organizations and organizations of all sizes regardless of the extent of their reliance on information;
- Supports planning and execution of ISMS audits and the information risk management process;
- Further adds value and enhances the quality and benefit of the ISO27k standards by closing the gap between reviewing the ISMS in theory and, when needed, verifying evidence of implemented ISMS controls (e.g. in the ISO27k user organizations, assessing security elements of business processes, IT systems and IT operating environments);
- Provides guidance for auditing information security controls based on the controls guidance in ISO/IEC 27002;
- Improves ISMS audits by optimizing the relationships between the ISMS processes and required controls (e.g. mechanisms to limit the harm caused by failures in the protection of information - erroneous financial statements, incorrect documents issued by an organization and intangibles such as reputation and image of the organization and privacy, skills and experience of people);
- Supports an ISMS-based assurance and information security governance approach and audit thereof [?? That would appear to stray into the area of management systems auditing rather than information security controls or technical auditing];
- Ensures effective and efficient use of audit resources.
Whereas ISO/IEC 27007 focuses on auditing the management system elements of an ISMS as described in ISO/IEC 27001, ISO/IEC TR 27008 focuses on checking some of the information security controls themselves, such as (for example) those as described in ISO/IEC 27002 and outlined in Annex A of ISO/IEC 27001.
’27008 “focuses on reviews of information security controls, including checking of technical compliance, against an information security implementation standard, which is established by the organization. It does not intend to provide any specific guidance on compliance checking regarding measurement, risk assessment or audit of an ISMS as specified in ISO/IEC 27004, 27005 or 27007 respectively.”
Technical compliance checking/auditing is explained as a process of examining ‘technical’ security controls, interviewing those associated with the controls (managers, technicians, users etc.), and testing the controls. The methods should be familiar to experienced IT auditors.
‘Technical’ controls, while not explicitly defined in the standard, appear to be what are commonly known as IT security or cybersecurity controls, in other words a subset of the information security controls described in ISO/IEC 27001 and especially 27002.
Status of the standard
The standard was published in 2011 as ISO/IEC TR 27008:2011, a ‘Type 2 Technical Report’, rather than an International Standard (a curiosity of the ISO approach). Minor but numerous grammatical and technical errors in the standard, as well as its limited scope, may have hampered its adoption.
The standard is currently being revised to reflect the 2013 versions of ISO/IEC 27001 and 27002.
A new title is coming: “Guidelines for the assessment of information security controls.” A scope change has also been approved - essentially just a minor change of wording but it may turn out to be more profound in practice. The new version still includes the phrase “technical compliance checking of information system controls” without explaining what that means: it appears to imply that the new version will remain myopically focused on ‘technical controls’ as noted above.
A standards type change has also been approved: it will become a Technical Specification rather than a Technical Report.
The current draft has editorial/quality issues but the obsession with technology is a more fundamental concern (in my opinion as an experienced and somewhat jaundiced former IT auditor). Unless the organization understands and accepts the need to protect its valuable information against the huge variety of information risks, for business reasons, the ISMS and hence the specific technical security controls will remain largely irrelevant, and yet the draft standard does not address broader issues of that nature. For example, the suggested checks concerning backups hardly even hint at the need to first check whether the backup strategies, policies, procedures and standards are in fact adequate and suited to the business need to protect its data against loss and corruption. As to the need to secure the backups (e.g. controlling physical and logical access, protecting them against fire, flood, accidental or deliberate damage, theft etc.) which would normally flow from an understanding of the information risks, well that doesn’t even enter the picture. The draft dives right in to checking things at the detailed bottom level, almost completely ignoring the need to take in the bigger picture that determines what detailed controls are necessary and appropriate.
Another example: what if the organization’s malware controls do not, in fact, identify known malware at the organization’s network boundary, one of the tests suggested by the draft standard? What are the implications of that? What is the relevance of the failure to the business? Without the business context, it would be very difficult to assess and evaluate the failure, or to phrase the finding in terms that would make sense to management.
While this standard is not intended to be used by accredited ISMS certification bodies, some members of SC 27 are concerned about its potential impact on ISO/IEC 27001 certification audits. Certification against ISO/IEC 27001 requires certification auditors to assess the organization’s ISMS as a whole for compliance with the standard, but not necessarily to delve into the information security controls themselves. They review the management system in much the same way that ISO 9000 auditors review an organization’s management system for quality assurance. Some of us feel that this leaves an assurance gap: it is conceivable for an organization to implement an ISMS ‘on paper’ but to ignore significant elements of its security policies, standards, procedures and guidelines in practice, perhaps arbitrarily declaring a narrow ISMS scope and a minimalist Statement of Applicability, and declaring an unreasonably high risk tolerance simply to avoid making changes that any sane person would think appropriate. Others insist that certification auditors do normally substantiate the existence of information security controls as well as the management system controls, at least to some extent (how much being a moot point). While compliance activities operating within a certified ISMS should address this, competently auditing the information security controls can provide greater confidence that theory matches reality, and might boost the credibility of ISO/IEC 27001 certificates. Unfortunately, such an approach would cause practical problems for those certification bodies suffering a shortage of competent IT auditors.
The mention of ‘technical compliance auditing’ in this standard always catches my beady eye. Personally, I wish the standard did not mention the keyword ‘compliance’ at all, since it is generally misinterpreted to mean tick-and-bash audits in which the auditors’ prime objective is, in practice, to search for and report noncompliance. That’s clearly a very negative style of auditing, with a very limited purpose. It fails to take account of the limited applicability of many requirements, for instance, leaves little if any room for interpretation of the requirements in the specific situations under review, and implies that compliance per se is sufficient whereas it seldom is in practice. In summary, compliance implies a low bar. We can and should do better than that in respect of protecting information assets. Competent IT auditors can certainly achieve much more than pointing a stick at noncompliance!
Frankly, there are much better guides to IT auditing, or indeed technical compliance auditing, than the current version of ISO/IEC TR 27008, such as the IT audit FAQ, COBIT and other materials from ISACA, and various other sources. I am pleased to see ISACA’s experts wading-in to the ISO/IEC project with similar comments concerning the scope, purpose and value of IT auditing, suggesting that ‘technical compliance testing’ isn’t actually auditing at all! At the same time, some national bodies are suggesting that ‘technical compliance testing’ (whatever that actually means - and personally I’m not certain that any of us really know) is what the standard should cover, even if that means dropping all references to audit.
Personally, I would prefer to see the standard cover auditing of information security controls, that being, to my mind, the entire spectrum including technical (commonly known as ICT, IT or cybersecurity controls) and non-technical controls (e.g. procedural, personnel, procurement, incident management, incident response, compliance, awareness, enforcement, reinforcement, physical, legal, business continuity, resilience, recovery, contingency and more) apart from the management system and governance aspects. It’s about time SC 27 came off the fence and acknowledged that information security goes well beyond ICT. With a few exceptions (e.g. business continuity, cloud, physical and BYOD security), ISO/IEC 27002 does a fair job of describing the entire spectrum, and (since users could extend the scope of their audits as they see fit) would be a reasonable basis for the scope of an information security controls auditing standard. It could describe the audits, reviews and assessments that ought to be performed as an integral part of the operation of the ISMS, on a routine and ad hoc basis, for instance a rolling quarterly sequence of checks on the controls covering a different quarter each time, plus post-incident reviews and other ad hoc activities to find root causes of issues that should be addressed.