Proxies in the Data Center There are a number of reasons that inline proxies are not a scalable solution for monitoring communications in enterprise environments.
-- cost -- production risk -- latency Here are some specific examples of where the use of proxies for monitoring communications is not viable: Network Security Monitoring Network security monitoring is not just monitoring traffic that results from communications with customers and partners. All it takes is for one user to click on a phishing email and there is malware inside the enterprise. Once this happens, TLS becomes the enemy, because 30% of malware is TLS encrypted, and any TLS features intended to thwart payload inspection work against the enterprise. Malware does not always phone home out to the Internet on day 1 of infection. Sometimes it does reconnaissance and lateral movement for a long time. The longer this goes on undetected, the worse the situation becomes for the enterprise. Microsegmentation is an attempt to contain this movement, but if the malware is TLS encrypted it will go right through the firewalls. The answer to this problem is ubiquitous plain-text traffic inspection. The scale at which this is needed can't be accomplished by inline solutions (proxies). Traffic inspection is needed at the Internet, the Extranet, the mainframe, the WAN, DNS servers, email servers, wireless controllers, and a host of other locations. Traffic inspection is also needed in the virtual environment, where all the virtual tools necessary don't exist yet. My Seoul presentation documented 150 physical tap points feeding network security monitoring devices - and this footprint is growing. There are too many inspection points to replace with inline solutions. You simply cannot place a proxy between every system in the enterprise. One other crucial point to this discussion is that endpoint monitoring doesn't catch everything. The strategy of "Defense in Depth" says that the more layers of security infrastructure you have, the better your chances of blocking or identifying malware. Network security monitoring is catching lots of malware missed by endpoint inspection. Threat Detection and Incident Analysis Threat detection inside the enterprise is not just receiving IDS or endpoint monitoring alerts. Threat detection analysts need to track down the source of the infection, which could be anywhere within the enterprise, and the primary tool for doing this is packet capture with a decrypted payload. Because the source of the infection could be anywhere, we need ubiquitous packet capture and ubiquitous decryption capability. Again, inline solutions don't scale to the number of monitoring points needed for this level of visibility. No only does an out-of-band solution like static DH allow many more permanent monitoring points with simple network taps, it also allows enterprises to deal with gaps in visibility. If a needed flow is missing, we can set up span or mirror sessions, capture the packets, and decrypt them after the fact. This can't be done when relying only on inline proxies. Adding a new inline proxy is a multi-month or more project. In the midst of an active attack/infiltration every minute is crucial and network re-architecture is not an option. Troubleshooting Enterprises provide services through complex, multi-layer applications and backend infrastructure. Inevitably, there are bugs in these applications and the source of the problem must be found through troubleshooting. Network troubleshooters need to inspect the packet payload in order to find transactions on the wire in environments where there is extensive NAT and extensive encryption. Both of these are very common in enterprise networks, and encryption inside the data center is becoming more ubiquitous over time. NAT, by the way, is being used in large part not for IP address exhaustion, but to allow for multiple redundant paths. Complex applications can have hundreds of application and infrastructure nodes as well as many tiers, any of which could be the cause of a slowdown or failure. Often there are no log messages on any device giving a clue as to the source of a problem. Troubleshooters need to be able to take a packet trace at any layer of the infrastructure and decrypt the trace in order to find the transaction of interest. This tracing could be between physical devices, like between a firewall and load balancer, or it could be between VMs. Tracing in the virtual space could involve tracing between VMs on different blades of the same blade chassis or between VMs on the same ESX host. Since the root cause of a problem can be anywhere in an enterprise, this translates into thousands of locations in a large enterprise where troubleshooters may need to take a trace, decrypt it, and locate a transaction. Inline proxy solutions add cost, production risk, and latency at every layer in which they are implemented. It doesn't take very many inline locations before the cost is in the millions of dollars. Because the solution is inline, lots of redundancy has to be built in, including multiple columns (doubling the cost), bypass taps for failure scenarios, and extensive procedures for troubleshooting and failover. Bypass taps and TLS decryption appliances can and do fail, and when they are inline a production outage is caused, usually in a critical part of the network and affecting multiple critical applications. Proxy solutions also add 1-3 ms of latency to every packet. This is not a big problem at one layer, but when many tiers are implemented with inlien proxy solutions the latency adds up. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
