If a penetration test is the first time you’ve considered the security of your new IT project, you’re doing it very wrong. Much of any project’s security effort should be in the early stages, from risk assessing to agreeing with your developers, either in-house or external, just what security measures are being implemented, and validated.. Security, just like any other metric, needs to be objectified, quantified, and agreed upon before development begins. And this leads us to a very common oversight so beautifully documented in ISO27001; Security requirements in third party contracts. I would go as far to say that 80% of third party supplier contracts have no meaningful security requirements, beyond, perhaps, the typical 99.999% uptime SLA.
So, this begs the questions:
1. Before we worry about what a user can do within our shiny new web app, who’s going to define what they can’t do, or at least shouldn’t be able to do? So many software specs never consider undesirable user capability.
2. Who will ensure your web app is free of SQL injection vulnerabilities/xss/logic flaws and a myriad of other www.owasp.org goodies before the pen test? Who will check the mitigations work? The pen test is there to catch the gaps, but it isn’t cost effective or practical to rely solely on something performed so late in the project cycle. The penetration test is your last chance, but it should never be your only chance .
3. What’s the plan when your third party system management provider has a change of staff? Were you notified? Were the appropriate accounts changed?
4. Where are your data-centre backups stored, how are they encrypted, and what’s the physical risk?
5. Who will ensure that your new network infrastructure is suitably hardened before deployment, and to what standard?
The usual responses to these queries almost always includes the word assumed. That’s never a good place to be. So, let’s consider:
1. What are the security requirements of this project? What would be undesirable, and who are we formally tasking to take ownership of these requirements?
2. What do we require of our third party stakeholders, both in terms of their operational security, and project delivery?
3. Where can we stipulate all of this in writing?
When you’ve taken care of that, have a cup of coffee. You’ve not only considered one of the most overlooked risks in modern business, you’ve also aligned to ISO27001:2013 15.1.2