New customer - greenfield setup
-
So the long and the short of it is - Scott is saying - no filtering is worth it, either on the employee side or the guest side.
i.e. the firewall is not a place to provide filtering (via either IP blocking or DNS website blocking) - there is not enough value if it has any cost.
Doing something simplish like Cloudflare's DNS filtering is worthwhile because there's no cost.
-
@dashrender said in New customer - greenfield setup:
So the long and the short of it is - Scott is saying - no filtering is worth it, either on the employee side or the guest side.
i.e. the firewall is not a place to provide filtering (via either IP blocking or DNS website blocking) - there is not enough value if it has any cost.
Doing something simplish like Cloudflare's DNS filtering is worthwhile because there's no cost.
Yeah, I think that something simple like CloudFlare or even PiHole (or combine the two) can have good value because the cost is low and the value is basic.
Firewalls are an inappropriate place for that kind of filtering and it makes me question the quality of a firewall that starts to act like a general purpose server platform. If they don't think that a security device should be single purpose, are they really prepared to be your security vendor?
-
@scottalanmiller said in New customer - greenfield setup:
@dashrender said in New customer - greenfield setup:
So the long and the short of it is - Scott is saying - no filtering is worth it, either on the employee side or the guest side.
i.e. the firewall is not a place to provide filtering (via either IP blocking or DNS website blocking) - there is not enough value if it has any cost.
Doing something simplish like Cloudflare's DNS filtering is worthwhile because there's no cost.
Yeah, I think that something simple like CloudFlare or even PiHole (or combine the two) can have good value because the cost is low and the value is basic.
You don't need any PiHole. You can set up DNS filtering policies on your free cloudflare account.
Just block every kind of external DNS queries in the firewall/router. Set the router to forward DNS to Cloudflare's 1.1.1.1. Cloudflare will detect your IP and filter your DNS results based on your policies.
https://developers.cloudflare.com/cloudflare-one/tutorials/secure-dns-network
I haven't played with it yet but there seems to be a lot of filtering options.
-
@pete-s said in New customer - greenfield setup:
@scottalanmiller said in New customer - greenfield setup:
@dashrender said in New customer - greenfield setup:
So the long and the short of it is - Scott is saying - no filtering is worth it, either on the employee side or the guest side.
i.e. the firewall is not a place to provide filtering (via either IP blocking or DNS website blocking) - there is not enough value if it has any cost.
Doing something simplish like Cloudflare's DNS filtering is worthwhile because there's no cost.
Yeah, I think that something simple like CloudFlare or even PiHole (or combine the two) can have good value because the cost is low and the value is basic.
You don't need any PiHole. You can set up DNS filtering policies on your free cloudflare account.
Just block every kind of external DNS queries in the firewall/router. Set the router to forward DNS to Cloudflare's 1.1.1.1. Cloudflare will detect your IP and filter your DNS results based on your policies.
https://developers.cloudflare.com/cloudflare-one/tutorials/secure-dns-network
I haven't played with it yet but there seems to be a lot of filtering options.
Custom filtering without cost? That's news to me. I've known about the 1.1.1.2/1.0.0.2 and 1.1.1.3/1.0.0.3 options of course.
-
@travisdh1 said in New customer - greenfield setup:
@pete-s said in New customer - greenfield setup:
@scottalanmiller said in New customer - greenfield setup:
@dashrender said in New customer - greenfield setup:
So the long and the short of it is - Scott is saying - no filtering is worth it, either on the employee side or the guest side.
i.e. the firewall is not a place to provide filtering (via either IP blocking or DNS website blocking) - there is not enough value if it has any cost.
Doing something simplish like Cloudflare's DNS filtering is worthwhile because there's no cost.
Yeah, I think that something simple like CloudFlare or even PiHole (or combine the two) can have good value because the cost is low and the value is basic.
You don't need any PiHole. You can set up DNS filtering policies on your free cloudflare account.
Just block every kind of external DNS queries in the firewall/router. Set the router to forward DNS to Cloudflare's 1.1.1.1. Cloudflare will detect your IP and filter your DNS results based on your policies.
https://developers.cloudflare.com/cloudflare-one/tutorials/secure-dns-network
I haven't played with it yet but there seems to be a lot of filtering options.
Custom filtering without cost? That's news to me. I've known about the 1.1.1.2/1.0.0.2 and 1.1.1.3/1.0.0.3 options of course.
Yes, they have a lot of new stuff beginning 2020. For instance a VPN solution, web application firewall etc. Some thing you need to pay for some but some that are free, depending on how many users etc.
They want to be everywhere on the edge for all traffic. Not just a DNS provider and a CDN solution.
-
@travisdh1 said in New customer - greenfield setup:
@pete-s said in New customer - greenfield setup:
@scottalanmiller said in New customer - greenfield setup:
@dashrender said in New customer - greenfield setup:
So the long and the short of it is - Scott is saying - no filtering is worth it, either on the employee side or the guest side.
i.e. the firewall is not a place to provide filtering (via either IP blocking or DNS website blocking) - there is not enough value if it has any cost.
Doing something simplish like Cloudflare's DNS filtering is worthwhile because there's no cost.
Yeah, I think that something simple like CloudFlare or even PiHole (or combine the two) can have good value because the cost is low and the value is basic.
You don't need any PiHole. You can set up DNS filtering policies on your free cloudflare account.
Just block every kind of external DNS queries in the firewall/router. Set the router to forward DNS to Cloudflare's 1.1.1.1. Cloudflare will detect your IP and filter your DNS results based on your policies.
https://developers.cloudflare.com/cloudflare-one/tutorials/secure-dns-network
I haven't played with it yet but there seems to be a lot of filtering options.
Custom filtering without cost? That's news to me. I've known about the 1.1.1.2/1.0.0.2 and 1.1.1.3/1.0.0.3 options of course.
Apparently so -
https://developers.cloudflare.com/cloudflare-one/tutorials/secure-dns-network -
@pete-s said in New customer - greenfield setup:
@travisdh1 said in New customer - greenfield setup:
@pete-s said in New customer - greenfield setup:
@scottalanmiller said in New customer - greenfield setup:
@dashrender said in New customer - greenfield setup:
So the long and the short of it is - Scott is saying - no filtering is worth it, either on the employee side or the guest side.
i.e. the firewall is not a place to provide filtering (via either IP blocking or DNS website blocking) - there is not enough value if it has any cost.
Doing something simplish like Cloudflare's DNS filtering is worthwhile because there's no cost.
Yeah, I think that something simple like CloudFlare or even PiHole (or combine the two) can have good value because the cost is low and the value is basic.
You don't need any PiHole. You can set up DNS filtering policies on your free cloudflare account.
Just block every kind of external DNS queries in the firewall/router. Set the router to forward DNS to Cloudflare's 1.1.1.1. Cloudflare will detect your IP and filter your DNS results based on your policies.
https://developers.cloudflare.com/cloudflare-one/tutorials/secure-dns-network
I haven't played with it yet but there seems to be a lot of filtering options.
Custom filtering without cost? That's news to me. I've known about the 1.1.1.2/1.0.0.2 and 1.1.1.3/1.0.0.3 options of course.
Yes, they have a lot of new stuff beginning 2020. For instance a VPN solution, web application firewall etc. Some thing you need to pay for some but some that are free, depending on how many users etc.
They want to be everywhere on the edge for all traffic. Not just a DNS provider and a CDN solution.
I use their VPN. Helps a lot down here.
-
@scottalanmiller said in New customer - greenfield setup:
@pete-s said in New customer - greenfield setup:
@travisdh1 said in New customer - greenfield setup:
@pete-s said in New customer - greenfield setup:
@scottalanmiller said in New customer - greenfield setup:
@dashrender said in New customer - greenfield setup:
So the long and the short of it is - Scott is saying - no filtering is worth it, either on the employee side or the guest side.
i.e. the firewall is not a place to provide filtering (via either IP blocking or DNS website blocking) - there is not enough value if it has any cost.
Doing something simplish like Cloudflare's DNS filtering is worthwhile because there's no cost.
Yeah, I think that something simple like CloudFlare or even PiHole (or combine the two) can have good value because the cost is low and the value is basic.
You don't need any PiHole. You can set up DNS filtering policies on your free cloudflare account.
Just block every kind of external DNS queries in the firewall/router. Set the router to forward DNS to Cloudflare's 1.1.1.1. Cloudflare will detect your IP and filter your DNS results based on your policies.
https://developers.cloudflare.com/cloudflare-one/tutorials/secure-dns-network
I haven't played with it yet but there seems to be a lot of filtering options.
Custom filtering without cost? That's news to me. I've known about the 1.1.1.2/1.0.0.2 and 1.1.1.3/1.0.0.3 options of course.
Yes, they have a lot of new stuff beginning 2020. For instance a VPN solution, web application firewall etc. Some thing you need to pay for some but some that are free, depending on how many users etc.
They want to be everywhere on the edge for all traffic. Not just a DNS provider and a CDN solution.
I use their VPN. Helps a lot down here.
helps? in what way?
do a lot of US based service block you because in SA? -
@dashrender said in New customer - greenfield setup:
@scottalanmiller said in New customer - greenfield setup:
@pete-s said in New customer - greenfield setup:
@travisdh1 said in New customer - greenfield setup:
@pete-s said in New customer - greenfield setup:
@scottalanmiller said in New customer - greenfield setup:
@dashrender said in New customer - greenfield setup:
So the long and the short of it is - Scott is saying - no filtering is worth it, either on the employee side or the guest side.
i.e. the firewall is not a place to provide filtering (via either IP blocking or DNS website blocking) - there is not enough value if it has any cost.
Doing something simplish like Cloudflare's DNS filtering is worthwhile because there's no cost.
Yeah, I think that something simple like CloudFlare or even PiHole (or combine the two) can have good value because the cost is low and the value is basic.
You don't need any PiHole. You can set up DNS filtering policies on your free cloudflare account.
Just block every kind of external DNS queries in the firewall/router. Set the router to forward DNS to Cloudflare's 1.1.1.1. Cloudflare will detect your IP and filter your DNS results based on your policies.
https://developers.cloudflare.com/cloudflare-one/tutorials/secure-dns-network
I haven't played with it yet but there seems to be a lot of filtering options.
Custom filtering without cost? That's news to me. I've known about the 1.1.1.2/1.0.0.2 and 1.1.1.3/1.0.0.3 options of course.
Yes, they have a lot of new stuff beginning 2020. For instance a VPN solution, web application firewall etc. Some thing you need to pay for some but some that are free, depending on how many users etc.
They want to be everywhere on the edge for all traffic. Not just a DNS provider and a CDN solution.
I use their VPN. Helps a lot down here.
helps? in what way?
do a lot of US based service block you because in SA?Yes, US services block non-US addresses very often, including things like the ability to pay taxes or deal with courts. But it also just smooths our services and ensures you get good DNS results.
-
@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.
-
@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.
-
If this was a medical office, as an example, imagine if a client claimed that security had been compromised. Any investigation would quickly turn up that the end to end encryption rules were violated and that the office had intentionally removed encryption and exposed the data and had an opportunity for people, anyone with access to the firewall, to extricate it outside of the known controls.
While unlikely to be the actual source of a breach, in court it would really only need to be shown that the data was voluntarily exposed and that would be enough for damage to be done. But if you did want to steal HIPAA data, this is exactly the kind of exposure point you'd hope for. Especially as a great many firewalls that offer this have backdoors or weak security that would normally border on being useless when used properly, but when configured as a trusted man in the middle means you have a way to siphon out the data without detection after the network monitoring controls are already past. Nothing on the network would be able to detect large volumes of data flowing out as it was flow out from the outside interface of the LAN only.
-
@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.
There was a big study a couple of years ago:
https://www.thesslstore.com/blog/https-interception-harming-security/Basically it's what Scott said.
-
@scottalanmiller said in New customer - greenfield setup:
@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.
Nice! I'm glad to hear you point all those things out because I've also thought similarly about deep packet inspection / MITM functionality on the firewall. It's basically breaking that secure chain of trust, like you said, and when I first learned about it, I just though it seemed a little risky or wrong or something.
And as I added more and more exceptions, I began to think, what is the point of this if I'm going to add a bunch of exceptions? Then I would just be leaving all the untrusted sites but that sort of thing should be more filtered out using web content filtering, not DPI.
Also, I'm not defending it, but when I was attempting to enable DPI-SSL on our Sonicwall, I was able to add many category-based exceptions which included banking and medical services, among others. So at least that concern is somewhat removed there, but still.
-
@dave247 said in New customer - greenfield setup:
I was able to add many category-based exceptions which included banking and medical services, among others. So at least that concern is somewhat removed there, but still.
That's good that they try. A problem with that, though, is that categories have to be maintained and trusted. So if you use Bank of America or Wells Fargo, I'm sure you are fine. But what if you use a local savings and loan or credit union or a foreign bank or do your banking through a third party site? Sure, your bank might make their list, but it might not. They make an effort, and probably a good one, but at some point it's just people making a list of sites they feel should be in a category. They don't really know. Anyone can make a fake bank website to get around that, there's no way to have enough staff to check sites. And I'm sure tons of real financial institutions get missed because no one though of checking that name.
-
@scottalanmiller said in New customer - greenfield setup:
@dave247 said in New customer - greenfield setup:
I was able to add many category-based exceptions which included banking and medical services, among others. So at least that concern is somewhat removed there, but still.
That's good that they try. A problem with that, though, is that categories have to be maintained and trusted. So if you use Bank of America or Wells Fargo, I'm sure you are fine. But what if you use a local savings and loan or credit union or a foreign bank or do your banking through a third party site? Sure, your bank might make their list, but it might not. They make an effort, and probably a good one, but at some point it's just people making a list of sites they feel should be in a category. They don't really know. Anyone can make a fake bank website to get around that, there's no way to have enough staff to check sites. And I'm sure tons of real financial institutions get missed because no one though of checking that name.
Yes, great points there. Oh hey, I was also going to ask you why you excluded Sophos from your deep packet inspection comment. I assume you will say they do it right, and if that's they case, how do they do it better / correctly?
-
@dave247 said in New customer - greenfield setup:
@scottalanmiller said in New customer - greenfield setup:
@dave247 said in New customer - greenfield setup:
I was able to add many category-based exceptions which included banking and medical services, among others. So at least that concern is somewhat removed there, but still.
That's good that they try. A problem with that, though, is that categories have to be maintained and trusted. So if you use Bank of America or Wells Fargo, I'm sure you are fine. But what if you use a local savings and loan or credit union or a foreign bank or do your banking through a third party site? Sure, your bank might make their list, but it might not. They make an effort, and probably a good one, but at some point it's just people making a list of sites they feel should be in a category. They don't really know. Anyone can make a fake bank website to get around that, there's no way to have enough staff to check sites. And I'm sure tons of real financial institutions get missed because no one though of checking that name.
Yes, great points there. Oh hey, I was also going to ask you why you excluded Sophos from your deep packet inspection comment. I assume you will say they do it right, and if that's they case, how do they do it better / correctly?
I only excluded them as not being an exhaustive list. I like them better than most vendors, but in a category of vendors I don't like much. They are like... if I was forced to do this, I'd choose them first most of the time. That doesn't mean I like it, I just dislike them less. Mostly experience, but also they offer most of their products in both crappy "on firewall" designs and "offloaded to a server" designs which is, at least, one step improved.
-
@scottalanmiller said in New customer - greenfield setup:
@dave247 said in New customer - greenfield setup:
@scottalanmiller said in New customer - greenfield setup:
@dave247 said in New customer - greenfield setup:
I was able to add many category-based exceptions which included banking and medical services, among others. So at least that concern is somewhat removed there, but still.
That's good that they try. A problem with that, though, is that categories have to be maintained and trusted. So if you use Bank of America or Wells Fargo, I'm sure you are fine. But what if you use a local savings and loan or credit union or a foreign bank or do your banking through a third party site? Sure, your bank might make their list, but it might not. They make an effort, and probably a good one, but at some point it's just people making a list of sites they feel should be in a category. They don't really know. Anyone can make a fake bank website to get around that, there's no way to have enough staff to check sites. And I'm sure tons of real financial institutions get missed because no one though of checking that name.
Yes, great points there. Oh hey, I was also going to ask you why you excluded Sophos from your deep packet inspection comment. I assume you will say they do it right, and if that's they case, how do they do it better / correctly?
I only excluded them as not being an exhaustive list. I like them better than most vendors, but in a category of vendors I don't like much. They are like... if I was forced to do this, I'd choose them first most of the time. That doesn't mean I like it, I just dislike them less. Mostly experience, but also they offer most of their products in both crappy "on firewall" designs and "offloaded to a server" designs which is, at least, one step improved.
Well - according to the above article - trusting them for SSL interception is just plain bad - just like most of the rest on that list.
-
@dashrender said in New customer - greenfield setup:
@scottalanmiller said in New customer - greenfield setup:
@dave247 said in New customer - greenfield setup:
@scottalanmiller said in New customer - greenfield setup:
@dave247 said in New customer - greenfield setup:
I was able to add many category-based exceptions which included banking and medical services, among others. So at least that concern is somewhat removed there, but still.
That's good that they try. A problem with that, though, is that categories have to be maintained and trusted. So if you use Bank of America or Wells Fargo, I'm sure you are fine. But what if you use a local savings and loan or credit union or a foreign bank or do your banking through a third party site? Sure, your bank might make their list, but it might not. They make an effort, and probably a good one, but at some point it's just people making a list of sites they feel should be in a category. They don't really know. Anyone can make a fake bank website to get around that, there's no way to have enough staff to check sites. And I'm sure tons of real financial institutions get missed because no one though of checking that name.
Yes, great points there. Oh hey, I was also going to ask you why you excluded Sophos from your deep packet inspection comment. I assume you will say they do it right, and if that's they case, how do they do it better / correctly?
I only excluded them as not being an exhaustive list. I like them better than most vendors, but in a category of vendors I don't like much. They are like... if I was forced to do this, I'd choose them first most of the time. That doesn't mean I like it, I just dislike them less. Mostly experience, but also they offer most of their products in both crappy "on firewall" designs and "offloaded to a server" designs which is, at least, one step improved.
Well - according to the above article - trusting them for SSL interception is just plain bad - just like most of the rest on that list.
Trusting anyone with doing that, to me, is a bad idea. It's both an unnecessary point of really risky trust, and it means trusting a vendor who is supposed to be a security vendor that's willing to look the other way on security concerns. Um... it's like trusting a security guard to not need a door, who literally just told you he'll happily not worry about security because it's not his problem.
-
@scottalanmiller said in New customer - greenfield setup:
@dashrender said in New customer - greenfield setup:
@scottalanmiller said in New customer - greenfield setup:
@dave247 said in New customer - greenfield setup:
@scottalanmiller said in New customer - greenfield setup:
@dave247 said in New customer - greenfield setup:
I was able to add many category-based exceptions which included banking and medical services, among others. So at least that concern is somewhat removed there, but still.
That's good that they try. A problem with that, though, is that categories have to be maintained and trusted. So if you use Bank of America or Wells Fargo, I'm sure you are fine. But what if you use a local savings and loan or credit union or a foreign bank or do your banking through a third party site? Sure, your bank might make their list, but it might not. They make an effort, and probably a good one, but at some point it's just people making a list of sites they feel should be in a category. They don't really know. Anyone can make a fake bank website to get around that, there's no way to have enough staff to check sites. And I'm sure tons of real financial institutions get missed because no one though of checking that name.
Yes, great points there. Oh hey, I was also going to ask you why you excluded Sophos from your deep packet inspection comment. I assume you will say they do it right, and if that's they case, how do they do it better / correctly?
I only excluded them as not being an exhaustive list. I like them better than most vendors, but in a category of vendors I don't like much. They are like... if I was forced to do this, I'd choose them first most of the time. That doesn't mean I like it, I just dislike them less. Mostly experience, but also they offer most of their products in both crappy "on firewall" designs and "offloaded to a server" designs which is, at least, one step improved.
Well - according to the above article - trusting them for SSL interception is just plain bad - just like most of the rest on that list.
Trusting anyone with doing that, to me, is a bad idea. It's both an unnecessary point of really risky trust, and it means trusting a vendor who is supposed to be a security vendor that's willing to look the other way on security concerns. Um... it's like trusting a security guard to not need a door, who literally just told you he'll happily not worry about security because it's not his problem.
OK I get all that - and am more aware of things than I was before this thread.
What is your defense in layer strategy for malware, etc?
I can't recall if you're a fan of web filtering or not?
You've spoken of PiHole before, though again, not sure if you're really a fan of that - or not?
What about blacklisting at the firewall level - We've discussed Ad nauseam about how poor geo blocking is (it's just so wrong, and can frequently get in the way).
Do you rely solely on the AV of the endpoint for protection of bad shit happening to endpoints?
