3 ms·

> Before, I was trying to figure out how mac's would ever be used anywhere near something classified or secret for a company. Relying on a personal firewall on

> Before, I was trying to figure out how mac's would ever be used anywhere near something classified or secret for a company. Relying on a personal firewall on the device itself seems ill-fated. Maybe it could be considered an additional layer of security, but I've yet to work at a place where a personal firewall is part of the security concept, no matter which OS. It's either firewalls at the gateway, maybe additional ones for certain departments, or mandatory proxy servers if you're stuck in the 90s.

Spearchucker 6y ago
Defense in depth suggests using controls to protect each individual resource. This includes individual apps, individual servers and individual user devices. A firewall is a single control, but never the only control. This from experience working with... government things.
g_p 6y ago
An application firewall on the device serves a different purpose to that running off-device, namely the ability to filter traffic based on the origin (or destination) application. Clearly if your kernel or userspace are compromised that's not much use, and that's where external controls kick in. You can't determine (absent some custom network and protocols) which piece of software was responsible for a given packet once you leave the device though, so that's the (current) best place to do that - if you want to impose policies controlling the hosts and protocols an application can use, you will want to implement this on-device, then firewall for the superset of all of those at the network level. In essence it's about raising the number of independent failures required to result in a compromise. If you imagine the application firewall on the device has its policies managed rather than selected by the user, it starts to make more sense.
- iforgotpassword 6y ago
  To fight apps phoning home, I agree. But even the tweet linked in OP refers to a tweet that shows how to abuse the now removed whitelisting by piggybacking your traffic through one of those whitelisted apps. On a locked down system like Android or iOS this isn't that trivial, but in a classic desktop OS use case it's easy to abuse another app to exfiltrate data. > In essence it's about raising the number of independent failures required to result in a compromise. Sure, it doesn't hurt, minus maybe the case that a vulnerability in that firewall itself is used. > If you imagine the application firewall on the device has its policies managed rather than selected by the user, it starts to make more sense. That's a requirement I guess. You don't want accountants and HR people handling popups by a firewall app. :-)
AmericanChopper 6y ago
I mostly agree with your assessment of their usefulness, but any organisation that handles credit cards likely has to use personal firewalls. Requirement 1.4 of the DSS: > Install personal firewall software or equivalent functionality on any portable computing devices (including company and/or employee-owned) that connect to the Internet when outside the network (for example, laptops used by employees), and which are also used to access the CDE. The most common place this would come up would be with SREs/Devs that have access to prod (and thus the "Cardholder Data Environment") from their laptops. It can also apply to business users that have access to certain admin dashboards in some organisations.

Spearchucker 6y ago

Defense in depth suggests using controls to protect each individual resource. This includes individual apps, individual servers and individual user devices. A firewall is a single control, but never the only control. This from experience working with... government things.

g_p 6y ago

An application firewall on the device serves a different purpose to that running off-device, namely the ability to filter traffic based on the origin (or destination) application. Clearly if your kernel or userspace are compromised that's not much use, and that's where external controls kick in. You can't determine (absent some custom network and protocols) which piece of software was responsible for a given packet once you leave the device though, so that's the (current) best place to do that - if you want to impose policies controlling the hosts and protocols an application can use, you will want to implement this on-device, then firewall for the superset of all of those at the network level. In essence it's about raising the number of independent failures required to result in a compromise. If you imagine the application firewall on the device has its policies managed rather than selected by the user, it starts to make more sense.

iforgotpassword 6y ago
To fight apps phoning home, I agree. But even the tweet linked in OP refers to a tweet that shows how to abuse the now removed whitelisting by piggybacking your traffic through one of those whitelisted apps. On a locked down system like Android or iOS this isn't that trivial, but in a classic desktop OS use case it's easy to abuse another app to exfiltrate data. > In essence it's about raising the number of independent failures required to result in a compromise. Sure, it doesn't hurt, minus maybe the case that a vulnerability in that firewall itself is used. > If you imagine the application firewall on the device has its policies managed rather than selected by the user, it starts to make more sense. That's a requirement I guess. You don't want accountants and HR people handling popups by a firewall app. :-)

AmericanChopper 6y ago

I mostly agree with your assessment of their usefulness, but any organisation that handles credit cards likely has to use personal firewalls. Requirement 1.4 of the DSS: > Install personal firewall software or equivalent functionality on any portable computing devices (including company and/or employee-owned) that connect to the Internet when outside the network (for example, laptops used by employees), and which are also used to access the CDE. The most common place this would come up would be with SREs/Devs that have access to prod (and thus the "Cardholder Data Environment") from their laptops. It can also apply to business users that have access to certain admin dashboards in some organisations.