Slashdot Mirror

← Back to Stories (view on slashdot.org)

Information Security Fundamentally Wrong?

Posted by ScuttleMonkey on from the most-people-only-want-the-illusion-of-security dept.

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.

9 of 35 comments (clear)

  1. Um... by Schraegstrichpunkt · · Score: 3, Insightful

    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?

    --
    http://outcampaign.org/
    1. Re:Um... by brandonY · · Score: 2, Insightful

      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.

    2. Re:Um... by Sique · · Score: 4, Insightful

      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.

      --
      .sig: Sique *sigh*
    3. Re:Um... by MadMidnightBomber · · Score: 5, Interesting

      As your mother used to tell you, prevention is better than cure - remember those graphs about how much coding mistakes cost to fix at various stages of the development process? Well, it's the same for prevention, detection and response, getting increasingly expensive.

      Anyway, the article isn't loading right now, but the distinction between Information Gathering, Information Processing and Information Reporting is fundamentally artificial. They're all aspects of a single process, and yes, I used to do this for a living. Security's not hard - follow the lock-down guides for your host OSes and network devices. Run an IDS such as snort, and keep an eye on it. Keep abreast of current problems at isc.sans.org, frsirt and vendor's announcements. Make sure your users have good passwords and audit all logon failures. Tighten up your physical security and educate about social engineering. Then you at least have a good chance to keep the lid on things.

      The real problem with security is that a lot of systems are overly complex and it's impossibly to really close off every possibile avenue of attack. Management always prefers a full feature set to the fuzzy notion of security - after all, they've never had a major incident up til now, so why change?

      --
      "It doesn't cost enough, and it makes too much sense."
  2. prevent breaches? by TubeSteak · · Score: 2, Insightful
    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.
    --
    [Fuck Beta]
    o0t!
  3. So... by Otter · · Score: 3, Funny

    So, if you multiply some completely arbitrary numbers together and then multiply some wholly imaginary numbers together, the arbitrary numbers for real technology come out lower than the imaginary numbers for imaginary technology? Wow, I'm impressed!

    --
    What I'm listening to now on Pandora...
    1. Re:So... by Anonymous+Brave+Guy · · Score: 2, Funny

      I think your explanation might be a bit complex...

      --
      If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
  4. Re:I'm not certain this is a rethink, really by Zphbeeblbrox · · Score: 3, Insightful

    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.

    --
    If you see spelling or grammatical errors don't blame me. I tried to preview but IE here at work borked the CSS
  5. Re:I'm not certain this is a rethink, really by IbeUID0 · · Score: 2, Insightful

    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.