IDS mailing list archives
Re: IPS, alternative solutions
From: Maarten Van Horenbeeck <maarten () daemon be>
Date: Wed, 22 Sep 2004 08:38:58 +0000 (GMT)
Daniel, I have the impression that some of the alternatives to IPS you mentioned are actually part of the IPS technology arena. A strict definition of what intrusion prevention systems comprise does not exist, and as such the name in itself also applies to e.g. firewalls. There is a large market theatre in which different types of IPS technologies are currently being deployed, with varying degrees of succes. Parts of the market have matured (network firewall solutions), while some are still considered "difficult" implementations (in-line protocol decoding and blocking/active response --which most people consider IPS). Some of the well known alternatives: - Intrusion Detection with human response In large networks, an often deployed technology at this time is implementation of intrusion detection technology (both host- and network based) in combination with 24hr response. Events are flagged by security engineers in real time, tickets are created and followed up as soon as possible by the necessary incident response personnel. Detection of events, in such case, is often outsourced to a service provider, so that the organization can focus on responding to the threats reported. This is a very effective framework due to the fact that it can be used to trigger on both known (network IDS), and unknown (network anomaly detection, host IDS) attacks. Physical security principles dictate that not all attacks can be prevented in each specific situation. What is important, is that we detect when an attack takes place, and have the necessary capability to respond and eliminate the threat at hand. This is the main reason that even though bank doors have advanced locks, they still have systems which detect when the door opens outside of business hours. - Host based exploit prevention (e.g. address space randomization, non-executable pages) While the thought given to designing these solutions is often intense, they still tend to be easy to implement -- provided only a limited number of applications needs to be supported on them. Due to the fact that most of them change the reference monitor used to screen events, they do tend to decrease overall performance of a system. Logging is often non-existant or difficult to centralize, and most of the software solutions in this field have had a troubled youth (the initial version of stack protection on Windows 2003 was defeated fairly quickly, as well as many others). This type of software is usually very helpful in stopping stock exploits, but may not be as secure against an attacker with enough resources. - Application Firewalls (e.g. DMZ/Shield, Interdo, Appshield) One of my personal preferences. While I must admit that I work for a company which develops one of these solutions, application level filters have always been an effective method to scrub inbound traffic. When correctly configured, these tools can truly limit traffic for backend servers to those sessions which do not contain malicious content, or at least malicious content which will not affect those servers. Main issue here is that configuration requires in-depth knowledge of the protocols affected. When knowledge is lacking in this perspective, configuration will be less than ideal. As such, this type of technology should inherently be deployed in combination with a professional audit of the policies. For most protocols and applications, these solutions are scalable, as they can be combined with other load balancing solutions (e.g. content switches for HTTP, round-robin DNS for SMTP). - Host based Firewalls As most operating systems have built in packet filtering tools, these should actually be part of hardening methodologies for servers. However, they do not block any application level attacks, and deployment for client machines could prove difficult. Centralized policy management is a requirement, but not always feasible due to different LAN locations and differing connection patterns between hosts. This type of protection tends to scale really well on well-structured networks. Networks with large amounts of legacy operating systems are not commonly considered suitable implementation beds without some prior review and rationalization. There is no one solution which meets all needs, and depending on the assets you are trying to protect, any or none of the above combinations may be sufficient. I do believe it is at all times important to make sure that each of the prevention, detection and response bases are covered. In order to protect our infrastructure, we initially need to prevent people from getting in (using IPS: firewalls for network border controls, application firewalls for application level screening). We also need to identify people who are trying to get in (usually solved with a combination of host- and network IDS). Last, but not least, we need to respond to any incidents which may still occur (incident response). IPS has its place in the incident lifecycle, but it should not be seen as a one-size-fits-all solution, if your assets are truly important to you. To compare this to physical security: We need a good lock on our car to keep thieves out. We also need an alarm to tell us somebody is trying to get in, and we do pay taxes to have police available who can catch the car thieves and prevent similar thefts from occuring in the future (deterrence). Cheers, Maarten -- Maarten Van Horenbeeck, GCIA <maarten () daemon be> http://www.daemon.be/maarten -------------------------------------------------------------------------- Test Your IDS Is your IDS deployed correctly? Find out quickly and easily by testing it with real-world attacks from CORE IMPACT. Go to http://www.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708 to learn more. --------------------------------------------------------------------------
Current thread:
- RE: IPS, alternative solutions, (continued)
- RE: IPS, alternative solutions Cure, Samuel J (Sep 21)
- Re: IPS, alternative solutions Jason (Sep 22)
- Re: IPS, alternative solutions Mike Frantzen (Sep 22)
- Re: IPS, alternative solutions Devdas Bhagat (Sep 27)
- Re: IPS, alternative solutions Thomas Ptacek (Sep 29)
- Re: IPS, alternative solutions Kyle Maxwell (Sep 23)
- Message not available
- Re: IPS, alternative solutions Jason (Sep 26)
- Re: IPS, alternative solutions p z (Sep 27)
- Re: IPS, alternative solutions Jason (Sep 30)
- Re: IPS, alternative solutions Jason (Sep 22)
- RE: IPS, alternative solutions Stuart Staniford (Sep 29)
- RE: IPS, alternative solutions Cure, Samuel J (Sep 21)