I’m gonna guess this guy has never worked in a SOC. While I agree he has some points, from an incident investigation standpoint, TLS break and inspect can offer a significant insight into what a connection was doing before, during and after the infection. It makes root cause analysis far easier and often possible when it otherwise wouldn’t be. If you go so far as to have full packet capture along with it, you get a lot of neat abilities. For example, you can pull downloaded files straight from the stream, even if the attacker took the site down or changed it to prevent investigation. You can also use tools like Xplico to see rather exactly what the user saw. It’s certainly not a silver bullet, nothing is. But, knowing the truth on the wire can be immensely helpful.

This isn’t to say that there are not other solutions. As he brings up EDR can get you quite close to the same sort of telemetry, but it still often insufficient when trying to really find the root cause. The EDR systems I have worked with tend to record the outgoing and incoming sockets, but then fail at capturing the details of the HTTPS traffic (e.g. full query strings, parameters, etc.) These can make a huge difference between “this is obviously a false positive. Close the ticket” and “ya, might be false positive, but I can be sure. Nuke the machine from orbit.” And making that determination is often quite hard if we cannot fully follow the user’s gallivanting across the web.

The other options the author begins up have exactly zero to do with the reasons TLS break and inspect is often implemented. Anomaly detection is used for ~generating false positives~ behavioral alerting, and these alerts are often a reason for us to want break and inspect. AI sucks big o’ donkey balls in the accuracy department. And it just flat out fails at explaining “why” an alert fired. I mean hey, if you’re comfortable having your work system wiped every time the AI thinks you did something fishy, we can do that. You’re going to start to hate life really fast though, especially if you’re a developer or sysadmin. Every anomaly based detection system I’ve worked with hates devs and sysadmins. And these are usually the hardest alerts to differentiate between true and false positive.

ZTNA is a good thing, yes do this. It also has nearly zero investigatory value. Yes, it’s nice when a secretary’s system is prevented from getting to the payroll database server on port 1433. That should be the norm. But again, other than maybe generating an alert, it tells us nothing about “why” the system was doing that. Or how the system got infected in the first place (assuming it is).

All that said, yes TLS break and inspect does have trade-offs. Welcome to the world of cybersecurity. Everything you do will have trade-offs. The single point of failure and issues with common tools is one of those trade-offs, but there are also mitigations to help with them. Protecting TLS certificates is a common problem. It’s hard but not some unsolvable issue. Certificate deployment is far less of an issue than the author makes it out to be. If your network is at all well managed, you will have software deployment strategies already in place. If we can setup centralized IdM, having a trusted certificate added to the local certificate store is not a major lift. And that fixes the whole curl problem as well. The main issue I’ve seen with break and inspect is really the data storage problem. This sort of thing creates a huge amount of data. If you do full packet capture, it’s astronomical. Usually, this results in picking a fairly short window to keep the packets themselves and a slightly longer time to keep the metadata. Not great, but again, trade-offs. Cost is also a big issue. “Hey Gigamon, how much for… Holy fuck, is it even legal to use that many zeros in one invoice?”

This article demonstrates the author’s lack of understanding about the problem security is trying to solve with TLS Break and Inspect. It’s not about detection or prevention. By the time you get to looking at the break and inspect logs or packets, you already have an alert you’re working with (or doing threat hunting, which is a beast all its own). These logs are there for the investigation phase of an incident. That is the problem which needs to be solved and the only tool, which the author mentions, which gets close is EDR. But even that isn’t often enough for anything more than the most basic of incidents. Getting the truth on the wire just gives so much more detail. Granted, it’s not something organizations should take on lightly, there are trade-offs. And for some organizations, it’s quite likely that the trade-offs aren’t worth the extra investigatory ability this provides. But, fully dismissing break and inspect as a tool isn’t the right choice either.