@dave247 said in New customer - greenfield setup:
@scottalanmiller said in New customer - greenfield setup:
@dashrender said in New customer - greenfield setup:
Of course it's really only worthwhile where we can do SSL inspection (can this be down without installing certs on the clients to allow MiTM inspection?)
Nope, that's physically impossible. These types of devices I see as reckless because they are often poorly maintained, often made by questionable vendors (Sophos is fine, but many others are less respectable) and provide a single point of total egress of your data with nearly all assumed protections removed.
Hey Scott, can you elaborate a bit more on that - I'm talking about the recklessness of SSL inspection. I ask because my company has a Sonicwall NSA appliance and in the past I have attempted using the "DPI-SSL" feature (deep packet inspection) which required installing the Sonicwall cert on all systems and then the traffic would be intercepted and inspected. Despite me following their guide and applying the correct settings and site exceptions, I still had some issues and ended up scrapping the effort for now. I already know your opinion on Sonicwall but I just wanted to get more insight into the whole deep packet inspection effort.
So my issue with that is that it "breaks" the entire security chain. The idea behind the certificate system is that your traffic is encrypted end to end. By adding a man in the middle there is a time when the traffic is not encrypted, but both the browser and the server believe that it is.
If everything works as expected, this is fine because we trust the man in the middle, in this case. But that's asking a lot of "another system" to be completely trusted.
In reality neither of the end points truly trust the man in the middle. The "firewall" isn't a friend here, it's in the path because it already distrusts both end points. So trust is not really appropriately at play here.
On a technology side, this adds an extremely high profile target that is rarely secured close to as well as the server or the workstations are. Traditionally firewalls were an extra layer of security, rather than an extra layer of risk. A compromised firewall meant that you lost a layer of defense, not that the firewall represented a bypass to existing security measures as well. So this ends up being a lot like a VPN, everyone says it's for security, but as used it is nearly always a huge risk because risk is extended rather than the tool being used to lock it down more.
So both hard technical by adding a huge point of exposure and for bypassing existing controls; and soft technical by putting the most critical point of exposure where network admins tend to understand it the least and where politics tend to keep it from getting properly maintained.
Then comes liability. Legally you can use this in most circumstances. But only most. I would never use this without my legal team signing off on it. Because you are hijacking encrypted data mid-stream that is meant to be trusted you risk both political fallout (customers, vendors, etc. being angry or going public that data may have been hijacked - possibly without consent) and legal fallout (if this is discovered and HIPAA data was in flight, for example, it technically violated any end to end encryption laws or requirements.) Knowing decrypting network traffic midway carries a lot of risk and you really need to understand the legal or business risk to all of the traffic. It's not something you can just do and not worry about.
As a business owner, never ever would I take that risk. Huge risk, no real value to doing so. I'd have to be a seriously emotionally driven control freak to consider doing something like this.
Which brings the final problem with it... a tool like this would not be made by or deployed by those who value security. So if you have a vendor making these tools, or you have management demanding these tools, you have people who are prioritizing control or the emotional perception of control above business interests and security. Sure, a vendor like SonicWall is just catering to their client base. To them it is a good business decision, but that decision is to allow their customers to undermine their own security. So from a security perspective, this goes against all common sense and otherwise stated practices.
As an aside, IF something like this was ever warranted, it should never be put on the firewall but run in a VM like any other production workload. That people put it on the firewall instead shows how little security thinking is involved when these products are discussed. There are better ways to do this if someone actually intended to do it in a good way.
