Security Engineering Process: Where Compliance Meets Programming

I recently got asked to work on a project to help finalize a Security Engineering Process for my company. I haven't delved too deeply into the goals and deliverables yet, but the project title is interesting enough to me: Security Engineering Process Assessment. This is one of the few times I'm going to argue semantics are important, so let's break this down a little.



I'm comfortable with the words "Security", "Engineering", and "Assessment", but "Process" is an interesting choice. The corporate connotation of process (at least at my company) is that you have a defined set of steps that are well documented and anyone (with a little training) can take the documentation and complete the process. For some things this is a totally reasonable idea, but is it reasonable for cyber security?

I'm going to cop out here and say, "Yes and no" with a caveat that it really depends on how you write your process.

There are some common sense security precautions you should take when designing any system such as require a user to login before they can do anything, expire sessions, use SSL by default, require passwords to be complex, etc. These fit well into a process, they can be defined and measured and are relatively straight forward.

But then there's the side of cyber security where it transitions from (don't hate my cheesiness) science to art. Because there is a level of art involved in looking at a system that is open to the internet, discerning where an attack may come from, and then finding ways to secure against that.

Here I'm thinking of things like the bad bios example or the recent Target breach that you could never hope to define process for. Anything you could define and document would fall miserably, pathetically, laughably short of protecting against an attack that can pivot within systems and compromise multiple companies, or jump air gaps and cloak itself when you are close to finding it. For defense against this kind of thing, you need artists. People who have as much creative ability as technical.

Yes, a defined process is a good idea. Most large companies will need it to show auditors and help developers who may not have a security mindset to design more secure systems. But the first step in your process should be, "Doubt the entire process" and the second step should be "Confirm doubt of entire process."