Will all intrusion detection become host-based once all network packets have been encrypted?
|
closed as not constructive by Iszi, Rory Alsop♦ Apr 27 '12 at 12:58
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or specific expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, see the FAQ for guidance.
|
If I understand your question correctly, then yes. If you use network-layer encryption on all traffic, for example ipsec or SSL/TLS, then any network-based IDS/IPS will have limited ability to detect application-level (or any upper layer) attacks on your hosts, because it's encapsulated/encrypted. If this is the case, then having some form of a host-based protection is your best bet. |
||||
|
|
|
No. Even if your network layer is fully encrypted and that's all working fine you still want sensors in both positions for defense in depth and alert correlation. You can and should deploy various technologies to decrypt intercepted traffic in different places in the application flows (proxies, load balancers, firewalls, SPAN/TAP ...) so your IDS shouldn't be completely blind. IDS signatures may be less useful without packet contents but can still work, and flow and statistics capture work fine with most types of encryption (though IPSec ESP would limit this). I'll agree that in a fully encrypted network you might want to shift the balance towards host-based tools but that's not the only way to read your own encrypted traffic. To answer your question you might have to redefine 'host' to include other devices where clear traffic is readable for analysis rather than just the end clients and servers. |
|||
|
|
|
I'd argue that there will be enough unencrypted traffic as well as other coverage cases for network-based IDS/IPS for some time. First, encryption is expensive, both computationally and administratively. Unless there's a good reason to encrypt all data (limited use cases), there will still remain unencrypted traffic in the mix (i.e. protocol chatter - "does it make sense to encrypt icmp packets?"). Given IDS/IPS helps monitor and apply policy to ranging from data in the packet headers (ip address, port, etc) to data in the payload, security admins will still find value in network-based IDS/IPS. Second, a defense-in-depth strategy would imply having multiple layers of defenses is an important strategy in protecting information assets. What if a host-based IDS/IPS fails? What if there is a vulnerability in the host-based IDS/IPS agent itself? Staggering security tools from the network perimeter to the host helps to reduce the risk of a single point of failure. Lastly, the IDS/IPS market will continue to evolve with the market or risk extinction. There are many vendors that have begun to prefix their firewall or IDS/IPS products with "next-gen" (i.e. next gen firewall, next gen ids/ips). Also, IDS/IPS really is a term used to describe a set of technologies and methods of implementing a technical security control. So if the market shifts, there will be vendors that find creative solutions and either re-use or create a new term to describe that market. |
|||
|
|