What Security Is And What Security Is Not

In the computer security world there exists a multitude of ideologies. Even within specific areas, such as application security, or web security, there are vastly opposing views. I think these views stem from a basic issue – that ‘security’ is a loosely defined term. If a group of people can’t even agree on what makes a system secure there’s no way they can agree on what makes a system secure, they’ll just dance around vague opinions all day.

So what is security? I think it often comes down to defining it by the environment. Some people define security by the ‘threat landscape’, or, in other words they ask the question “if you ran malware on your computer, if you ran into an exploit page, would your system be compromised?” Another set of people may ask the question “are there holes in the system?”, and that simple question alone may define security for them. Others, like myself, will ask “what level of skill is required to compromise the system?”.

There is no objective answer here. I personally believe that security is defined by the level of skill required to compromise that security. I know many people who believe otherwise.

These different opinions lead to very different approaches.

For example, an approach based on the current threat landscape could be as simple as EAF. EAF is a mitigation technique implemented by EMET, and it prevents an exploit from getting shell. EAF is trivially bypassed, it takes virtually no effort, but you are unlikely to find any exploit kit in the wild choosing to bypass it – very few people have EMET installed anyways, so why would they bother?

So EAF is an effective approach when looking at it from the view of our current threat landscape – it will prevent what’s currently out in the world very effectively. Any attack spawning a shell that doesn’t take it into account will likely fail.

If you ask the question “What level of skill is required to bypass the security?” it falls flat – EAF is too easily bypassed to consider a system implementing it ‘secure’ without other considerations.

In many ways it’s a matter of practice vs theory. If you only look at works against a system in practice you’re limited – it’s easier, but you’re limited. When you expand your security to deal with what’s only ever been proven possible, you aren’t nearly as limited, but you’ve made your job (securing the system) much more difficult.

I could write a lot about this. A lot. I’m not going to, but I haven’t put anything out in a while, so I figured I’d put this out. To justify writing any more than this I’d have to start doing research and making citations and blah blah blah explaining how practice follows theory. I don’t want to do that, I have class, I’m sleepy.