Design – Security involvement in design and audit stage
Designed to fail
Security audits are a fantastic way to improve the security of your network. A good auditor can highlight critical flaws in your design and configuration before they are launched into the big bad world. However I think there is a massive issue with security audits; they are designed to fail.
Most security audits happen in the final stages of the design and release cycle. To be fair, there is no real benefit in performing the audit until the network configuration and integration is complete. The issue I see is that the tests performed by the security auditors are known in advance, but not revealed until the end of the project lifecycle. Finding serious network security flaws so close to launch can be really expensive.
A test is a requirement in disguise
How would you react if, just prior to launch I told you that the project was blocked because you hadn’t met a key requirement? Well, you’d ask me to show you where this requirement was documented. If the requirement wasn’t documented, we would talk about this ‘new’ requirement rather than a talking about how a requirement wasn’t addressed by your ‘poor design’.
The security auditor has a range of tests that they execute prior to green-lighting a network as ‘secure’. I would contend that any ‘test’ which could prevent you launching a project is actually a ‘requirement in disguise’. So why do we allow an auditor to give you the ‘requirements’ at the same time as the test results? Seems silly to me. Why not just ask for the security auditors test plan as an input to your project?
If you don’t ask, you don’t get
Why would an auditor refuse to give up their test plan? When an security auditor finds serious flaws in your design they look like wunderkinds, and you look like a chump. It works in reverse too. I met an auditor recently who was quite disappointed to find only minor security issues when he carried out a recent audit. When you measure success like this the performance of network design engineer and security auditor will be a zero-sum game. The more bugs and flaws an auditor finds, they more competent the auditor appears to be. It will take a strong project manager or a business-minded security team to force the auditor to reveal their test plan.
Network security design – best practice
You don’t get off the hook as a network engineer though. Of course you should do your best to preempt the audit and incorporate best practices You should design the most secure network possible given your design constraints. There will always be flawed networking stacks and bugs that cannot be factored into a design. However, if there’s going to be a pen-test you should demand their test plan early and built it into your design as a requirement. If you fail, you fail. Ensure the project manager records this as a project risk, and move on.
Sherpa Summary
- Security audits are a great idea, but almost always discover issues too late in the project.
- The earlier a bug or design flaw is caught, the less expensive it is.
- External security companies prove their value by finding vulnerabilities.
- Network design engineers need to push for the audit test plan.
- Translate these tests into design requirements and address into the network design and testing phases of the workflow.
2 thoughts on “Design – Security involvement in design and audit stage”
Security audit is there to verify that your network design is compliant with the security policy (or industry standards).. It is a comparison to something else (e.g. set of requirements).
So actually you should read the security policy and use that as a source of requirements for your design..
Having a test-plan only helps you defeat that specific security man, who is not tailoring his testing for each network design and applies same set of tests to soho network or critical infrastructure operations network…
Therefore I would advise you to reconsider last 2 points in your summary.
Hey Lubo,
Thanks for the comment. The main issue I have seen is that the network engineer never sees those security requirements or that the security policy is so loosely defined that it cannot be translated into set of design requirements.
If you have actionable network security design guidelines, then by all means skip the last two points.
Just to be clear, I think a security audit is extremely valuable. However the learnings from each audit never make it back into the network security design documents. If this was done on a widespread basis, there would be less security failures happening so late in the design/release cycle.