Pentesting policy

This morning I'm continuing to develop a generic penetration testing policy template. 

As always, it takes me more time and effort to write short, formal pieces such as a new policy than longer run-o-the-mill awareness briefings. The actual writing part is straightforward: knowing what to incorporate and what to leave out requires more thought.

A policy on pentesting presents particular challenges: I think I know what it has to say but what else should it say? How should it be said and what can be safely left unsaid?

The few published pentest policies Google has found me so far all differ in style, naturally, but also vary in purpose and content. Most are quite narrowly focused on specific aspects or types such as the vulnerability scanning performed under PCI-DSS. They have prompted me to consider aspects I might otherwise have neglected but I can improve on them by incorporating good ideas from all sources including my own experience in this area (such as it is!) and security standards into a more coherent and comprehensive whole. 

The 'background' section to the policy is important in setting the scene, explaining the rationale for the policy statements that follow. So far, the background talks about the pros and cons of pentesting - its value to the business and its limitations as an assurance technique - in about 200 carefully-chosen words. That is followed by one succinct policy axiom, supported in turn by a few more detailed policy statements expanding on and explaining the key points. Other sections such as roles and responsibilities, and cross-references to related policies complete the model.

It is tempting to concentrate purely on the technology aspects since pentesting obviously revolves around IT but the broader business and risk management aspects are equally relevant for any policy. The technical/cybersecurity controls required within pentesting only make sense in the context of administrative controls around the pentesting process, extending all the way out to the clarification of pentest objectives and parameters, selection of suitable pentesters, contracts and agreements, oversight/monitoring, scheduling, ethics, reporting and, of course, the downstream activities of systematically addressing identified vulnerabilities. Running Nessus, or whatever, is but a small cog in a larger, more complicated mechanism.

Authorization is a key control for pentesting so I'm carefully figuring out what that actually means, how it works and how to express it in terms that should work for almost any organization - which is yet another complication for me. I'm not writing a pentest policy for my own company or a specific client, but a generic or universal model - at least that's the objective. 

Actually, the primary objective is educational, raising awareness of information risk and security: the model policies we offer are merely mechanisms to set people thinking and talking. It's an added bonus if they end up with effective security policies based on ours but even if they don't, I hope they have been stimulated to review, consider and discuss their options.