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!