Information Security Fundamentally Wrong?

Joep Gommers writes to share his look at why the current approach to information risk mitigation is fundamentally wrong. Detection of an intrusion (incident), consists of three stages. Information Gathering, Information Processing and Information Reporting. If we look at the way we currently put these three stages together we see that efficiency, and therefore the percentage of possible accomplished risk mitigation, is poor. He claims that if every step taken in order to detect an incident is at 50% efficient, we will end up with thousands of dollars in firewalls, ids, event correlators, and outsourced security processes and very little progress in security. The article is noted as a draft, but still some interesting food for thought.

Comments

Um...

[Schraegstrichpunkt]

Um... If we're going to redesign everything anyway, in order to support logging and analyzing every event, why don't we just design security into the system this time, and actually *prevent* security breaches?

Re:Um...

[brandonY]

You cannot build a completely safe and accessible system. There's always a legitimate way in, and someone always has a chance to find that way by brute force, blind luck, or social engineering. The goal of information security is twofold:
1.) Make it not worth the effort. If it takes on average 10000 years, it's not worth it.
2.) Make sure you know that your system has been breached.

Re:Um...

[Sique]

It goes just more in depth than this:

1. There is no way to formally prove in general that a program is logically correct. You can prove it formally for single programs, but then you don't have the formal proof, that your proof is formally correct (there are not only bugs in programs, there are also bugs in theorems about programs).

2. A programming environment is either primitive-recursive (and thus very simple and doesn't offer too much for programming) or it is Turing complete and thus capable (in theory) to host every conceivable program. There has been no solution yet for a set of possible programs, which is really smaller than the set of Turing computable programs and still really larger than the set of primitive-recursive programs. It's either Scylla or Charybdis.

3. There is always the problem of covert channels. As long as different entities share the same ressources, they can also communicate to each other. And communication means influence, and influence means not predicted situations which are not tested for (again there is the exception for a primitive subset of programs).

4. The solution to 3. is sandboxing: Creating a closed environment with non-shared ressources. Problem: You can't use it for much, because it is per definitionem not able to communicate to the outside.

5. The same arguments are also telling us that DRM doesn't work. DRM requires problems 1 to 4 to be solved.

prevent breaches?

[TubeSteak]

why don't we just design security into the system this time, and actually *prevent* security breaches?

If we did something silly like that, then what would happen to security consultants?

On the one hand, they want you to be secure. On the other hand, they don't want you to be so secure that you no longer need their services.

Some people have a vested interest in maintaining the 'insecure' status quo.

Re:I'm not certain this is a rethink, really

[Zphbeeblbrox]

You obviously didn't read it carefully enough. The issue he addresses is that currently all the data from each layer is considered out of context. This makes certain types of attacks more difficult to identify. If you can consider all the data in the context of the other layers you have a more complete picture of your networks status. Most solutions right now though don't offer that kind of functionality. I think he's on to something.

Re:I'm not certain this is a rethink, really

[IbeUID0]

Not being able to read the (slashdotted?) article, it sounds like he's calling for companies to buy and install the latest series of security gizmos - the Security Event/Information Manager (SEM/SIM). This is truly the greatest generation of toys - it slices/dices/makes Julianne fries!

The goal of these devices is to take the data from the varying sources - syslogs, firewall logs, IDS/IPS entries, and so on and correlate it in an automated fashion. The challenge with these solutions is that it's, well, hard to do right. How long did it take us to get a decent IPS device? If you count the Checkpoint/Realsecure connections (where Realsecure could modify Checkpoint rules), it was about 4 years between that and a functional IPS that organizations could effectively trust. The S(E/I)M is a pretty big step beyond that. That's why managed security providers are in business, and even their correlation engines aren't that advanced. It's a great idea, and would be great to see, but I'm not convinced the complexity issues can truly be overcome. Can we really take in all the data from our servers, switches, routers, firewalls, IDS/IPS, workstations, network managment systems, application logs, LDAP/AD logs, email systems, etc. etc. and create a cohesive top-down view? I'd love it, but I wouldn't want to try to write it.

It reminds me a bit of ERP systems - great tools that managed everything and are amazingly expensive to purchase, customize, and use. Then again, if the security market goes that way, we'll have job security just installing the buggers.