Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Security IT

Information Security Fundamentally Wrong? 35

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.
This discussion has been archived. No new comments can be posted.

Information Security Fundamentally Wrong?

Comments Filter:
  • Um... (Score:3, Insightful)

    by Schraegstrichpunkt ( 931443 ) * on Monday January 23, 2006 @02:08PM (#14541723) Homepage
    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?
    • prevent breaches? (Score:2, Insightful)

      by TubeSteak ( 669689 )
      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.
      • 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.

        Sounds like drug compaines, car companies, and well, just about any profession. Even engineers make themselves needed by doing everything they're own strange way so that they can't be replaced easily.
      • 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.

        I think the biggest single testament to this statement being true is the utter lack of insurance in IT security. I've never been a fan of *ANY* type of insurance (think about it, they must be making money or they wouldn't be doing it, which means that the risk is far too low) but IT insurance is one thing that just hasn't taken off. Which means that the risk is far too h
        • Keep in mind that some of the best security minds are actually working on the other side of the fence. The guys that you hire to protect you are the ones that cannot make enough money as blackhats/criminals, or have a conscience (aka wife and kids), and couldn't possibly bring themselves to do harm.

          Yep, whether under fascism communism, or corporatism, the best and most powerful individuals in history were always undergrounders, whether mafia bosses, lone shadowy figures cloaked in fear and confusion or simp
        • IT insurance is one thing that just hasn't taken off

          That's changing fairly rapidly as the cyberinsurance offerings mature and as the actuarial metrics improve. The emergence of generally accepted standards of due care is also helping. The folks I've talked to recently in the insurance industry (at AIG and Gallagher, to name two) are selling it hand over fist.

          It's also worth noting that not all IT risk is covered by specialized insurance. A fair amount of IT-related business risk can be covered by g
      • I disagree. As long as there are nogoodniks on the internet, you will need some people trained in IT security.

        What gets me is that so many services provided by the security goons should be taken care of by good sysadmins, such as maintaining up-to-date inventories of network devices, or knowing what "normal" traffic for the network is. I rarely find this to be the case, and so security consultants get hired on to do device discovery, network mapping, patch management, and traffic analysis. There WOULD be
    • Re:Um... (Score:3, Insightful)

      by brandonY ( 575282 )
      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... (Score:5, Insightful)

        by Sique ( 173459 ) on Monday January 23, 2006 @02:33PM (#14542022) Homepage
        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.
        • Nice analysis! It's worth noting that covert channels are another apparantly-unsolvable problem. Possible covert channels have been found even in high security systems with hardware sandboxing once though to provably prevent infomation flow from a secure partition to an unsecure partition on the same machine.

          For example, a program in a secure partition can leak information to an insecure program through patterns of resource use that are detectable by traffic analysis on the insecure side. Attempting to i
        • 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.

          No. Actually, it's just much more restricted in HOW it can communicate with the outside.
        • 1. There is no way to formally prove in general that a program is logically correct . . . 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 . . . 3. There is always the problem of covert channels . . .

          Let me guess: You're a CS major, or you are repeating what you heard from a CS major?

          We're not anywhere close to approaching the theoretical lim

          • No, I am a technician without a formal education :) But I have coded in many different languages, and I found that you can create buffer overflows in about any language you want (Ever destroyed a spreadsheet by looping through cells and writing into the wrong rows?). Sometimes it's not the C equivalent, but having memory that is unaccounted for, is taken without content checking or writing data into places where it overwrites other data used by other routines is always possible. Returning data by reference
    • Re:Um... (Score:5, Interesting)

      by MadMidnightBomber ( 894759 ) on Monday January 23, 2006 @02:34PM (#14542030)

      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?

    • Part of the reason is because it's really hard, maybe even impossible, to design a completely secure system.
    • Or why all the telecoms/ISP/netblock owners inspect the report that we send to him? I'm tired of sending a lot of reports of breaking tentatives to the netblock owners and didn't get the responses (in this case don't count the automatic responses).
  • So... (Score:4, Funny)

    by Otter ( 3800 ) on Monday January 23, 2006 @02:16PM (#14541808) Journal
    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!
  • The base of the issue is that malware works on multiple levels, but the example he provides (or what he seems to be hinting at, is putting physical security issues into a report? That's great and all, but very few malware authors actually go the physical route. That is more for armed robbery or internal (disgruntled employee) type threats.

    I don't think this constitutes much change, just how things are reported, and maybe to who.
    • by Zphbeeblbrox ( 816582 ) <zaphar@gmail.com> on Monday January 23, 2006 @02:23PM (#14541907) Homepage
      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 can consider all the data in the context of the other layers you have a more complete picture of your networks status.

        You don't happen to work for Splunk, do you? ;) Sorry...when I read that all I could think of are those Splunk ads that have been plastered all over /. for the past few months.

      • 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, h
        • I've been able to implement just that using simple open-source tools, so I don't really see what the problem has been. The difficulty (aside from warehousing everything) is not really in gathering the data, but rather in what you want to get out of it, and how you analyze it...I have some automated tools I wrote myself to do simple data mining and anomaly detection on the data, but as you pointed out, for most companies the analysis side is underwhelming (top 10 lists and the like). I think there needs to
  • I don't quite understand what better proposal he has to offer.

    It looks like the solution would be to build an IDS from one piece. Taken to the logical conclusion, one would somehow have to throw all network traffic at some mainframe for analysis.

    Obviously one reason most IDSs are not built this way is that it is insane to analyze that amount of traffic. It seems more likely that one would instead try to tune the initial filtering steps to report more events to the next stage.

    Also, the non-IDS based security

"Hello again, Peabody here..." -- Mister Peabody

Working...