3 ms·

> IT absolutely doesn't give a flying ** about developers. They are not paid to. Their performance is judged against how close they get to zero compliance issu

> IT absolutely doesn't give a flying ** about developers. They are not paid to. Their performance is judged against how close they get to zero compliance issues, not how close they get to zero times developers were unhappy! > I think they're preventing people from hiding their internet browsing. Without delving into the “do you have the right to privacy even on a company machine”, who would be daft enough to do something they want to hide from the company on a company machine, or the company network at all? Though there are valid useful uses of pron^H^H^H^Hicognito mode so it seems silly to ban it.

wahnfrieden 4y ago
You’re just arguing for surveillance (by capital or state) with the tired line of you should have nothing to worry about unless you deserve it which is absurd/reactionary
- dspillett 4y ago
  I'm not saying it is right for people to be monitored, but that I would never trust that I wasn't being so I'd not be daft enough to do something I don't want the company to know about using their resources. And there are perfectly valid reasons for companies to monitor traffic: data exfiltration, accidental or malicious, is a significant concern for companies that hold and process PII and for the people who have their PII held/processed by those companies. It is not as black & white as “monitoring and surveillance bad” unless you only care about your personal privacy.
  - sillystuff 4y ago
    Some of these "security" products that MiM TLS traffic allow configurations that objectively reduce your security. You can configure Palo Alto devices to accept a self-signed cert from the Internet, but present your trusted MiM cert to the on-site user. Now the user isn't aware that they are the victim of a second MiM outside the organization. The organization also exposes itself to greater liability. E.g., a rogue employee could use the trusted MiM CA cert for their own MiM e.g., capturing banking credentials of co-workers or accessing user/employee PII they would otherwise not have access to. Yes, monitoring traffic by MiM https to external sites can alert you to / possibly prevent accidental exfiltration, but it doesn't prevent intentional exfiltration. It is, however, very effective at monitoring employees. The thing it is best at, might be its true purpose in an organization.
    - slt2021 4y ago
      I am afraid you are talking about stuff you have absolutely no idea about. Palo Alto appliance should be configured with both Forward Trust and Forward Untrust CA certificates, and the issue you described will not exist. If some people misconfigure - thats their fault for not following instructions. Secondly, rogue employee doesnt have access to CA key that is stored in Palo Alto appliance. Only your firewall admin will have it, but if your main firewall admin went rogue, capturing colleagues’s data is the least of your concerns. Insider threat of that calibre is equally applicable to rogue CEO or CFO stealing all money from the bank. Or your ActiveDirectory admin getting CFO’s credentials and corporate bank credentials.
      - sillystuff 4y ago
        You seem to acknowledge that you currently can configure the device in the manner described while simultaneously being extremely aggressive. A conversation I had with PA support gives me the impression that PA didn't have 'Forward Untrust' when they first started back-dooring TLS i.e., the PA support person did not counter my point of negative security implications of their MiM back-door for invalid certificates encountered externally. This conversation was something of an on-site debate between PA reps and a few of our tech staff. PA pushing for spying on users and tech staff trying to come up with technical reasons why it was a bad idea (management already loved the idea of spying on the users, so no appeal to decency was going to work. Management arranged the debate without telling staff it would happen until the last minute while it was planned ahead with PA for weeks; IT staff at that college were good people who had a history of advocating for user privacy). Having PA MiM TLS connections is the organization back-dooring itself as well as the external sites the users connect to. This back-door is available for abuse by IT staff, management and/or an attacker(internal or external). There is a rule that seems to eventually always be proven-- if you provide infrastructure that can enable abuse, eventually it will be abused. Even if you and everyone else involved in the decision at your organization have good intentions, your future coworkers / management may not. Presumably the FBI and NSA have more thorough back ground checks of their employees than the average employer, and both have had employees abuse their access to surveillance data to e.g., stalk ex-girlfriends. And, even if the employee isn't rogue themselves, when the order comes from above, many will obey immoral/illegal orders-- e.g., Ronald Reagan, as president, had the FBI spy on his daughter's boyfriend. The safest option is to not to install the back-door in the first place. PA's ability to tie Internet activity to specific users' identities was central to their sales pitch-- our tech staff assumed this was targeted at windows shops, but we used non-MS stuff including our LDAP servers and hoped this could kill the surveillance project-- PA countered that they could, at a last resort, do things like e.g., scrape radius logs to associate identities. PA appears to be a competently run company that probably knows what messages are most effective at selling their product, and they really pushed user surveillance. Therefore, I suspect that many organizations who purchased PA products based that decision on the user surveillance capabilities (explicitly to enable abuse by management). PAs main feature seems analogous to an illegal phone wire tap, and IMO should be illegal (especially without notification to the victims-- both on-site and off-site). It is curious how corporate circumvention of encrypted communications without permission of the external site hasn't been seen as a CFAA violation while a simple 'view source' on a browser can result in SWAT pointing a gun at your child.
- Spooky23 4y ago
  You’d probably feel differently if some developer at the IRS compromised your identity because he used some compromised library to avoid internal processes. Security, public trust, etc requires controls and audit to deliver. You don’t want a startup “fake it till you make it” mentality in government or banking.
- ornornor 4y ago
  More like you can’t possibly expect your work machine to have any kind of privacy, being in the trade and knowing all the ways companies can (and will) use anything they managed to gather about you should they need to obliterate you. It’s simply good practice not to use your work machine for anything personal at all ever. Because depending where in the world you are, anything stored or viewed on a work machine gives your employer de facto access to it, legally speaking.
  - wahnfrieden 4y ago
    You can be careful as a worker and still be against workplace surveillance
    - ornornor 4y ago
      For sure, but let’s face it… we’re getting more surveillance and bossware at work, not less unfortunately.

wahnfrieden 4y ago

You’re just arguing for surveillance (by capital or state) with the tired line of you should have nothing to worry about unless you deserve it which is absurd/reactionary

dspillett 4y ago
I'm not saying it is right for people to be monitored, but that I would never trust that I wasn't being so I'd not be daft enough to do something I don't want the company to know about using their resources. And there are perfectly valid reasons for companies to monitor traffic: data exfiltration, accidental or malicious, is a significant concern for companies that hold and process PII and for the people who have their PII held/processed by those companies. It is not as black & white as “monitoring and surveillance bad” unless you only care about your personal privacy.
- sillystuff 4y ago
  Some of these "security" products that MiM TLS traffic allow configurations that objectively reduce your security. You can configure Palo Alto devices to accept a self-signed cert from the Internet, but present your trusted MiM cert to the on-site user. Now the user isn't aware that they are the victim of a second MiM outside the organization. The organization also exposes itself to greater liability. E.g., a rogue employee could use the trusted MiM CA cert for their own MiM e.g., capturing banking credentials of co-workers or accessing user/employee PII they would otherwise not have access to. Yes, monitoring traffic by MiM https to external sites can alert you to / possibly prevent accidental exfiltration, but it doesn't prevent intentional exfiltration. It is, however, very effective at monitoring employees. The thing it is best at, might be its true purpose in an organization.
  - slt2021 4y ago
    I am afraid you are talking about stuff you have absolutely no idea about. Palo Alto appliance should be configured with both Forward Trust and Forward Untrust CA certificates, and the issue you described will not exist. If some people misconfigure - thats their fault for not following instructions. Secondly, rogue employee doesnt have access to CA key that is stored in Palo Alto appliance. Only your firewall admin will have it, but if your main firewall admin went rogue, capturing colleagues’s data is the least of your concerns. Insider threat of that calibre is equally applicable to rogue CEO or CFO stealing all money from the bank. Or your ActiveDirectory admin getting CFO’s credentials and corporate bank credentials.
    - sillystuff 4y ago
      You seem to acknowledge that you currently can configure the device in the manner described while simultaneously being extremely aggressive. A conversation I had with PA support gives me the impression that PA didn't have 'Forward Untrust' when they first started back-dooring TLS i.e., the PA support person did not counter my point of negative security implications of their MiM back-door for invalid certificates encountered externally. This conversation was something of an on-site debate between PA reps and a few of our tech staff. PA pushing for spying on users and tech staff trying to come up with technical reasons why it was a bad idea (management already loved the idea of spying on the users, so no appeal to decency was going to work. Management arranged the debate without telling staff it would happen until the last minute while it was planned ahead with PA for weeks; IT staff at that college were good people who had a history of advocating for user privacy). Having PA MiM TLS connections is the organization back-dooring itself as well as the external sites the users connect to. This back-door is available for abuse by IT staff, management and/or an attacker(internal or external). There is a rule that seems to eventually always be proven-- if you provide infrastructure that can enable abuse, eventually it will be abused. Even if you and everyone else involved in the decision at your organization have good intentions, your future coworkers / management may not. Presumably the FBI and NSA have more thorough back ground checks of their employees than the average employer, and both have had employees abuse their access to surveillance data to e.g., stalk ex-girlfriends. And, even if the employee isn't rogue themselves, when the order comes from above, many will obey immoral/illegal orders-- e.g., Ronald Reagan, as president, had the FBI spy on his daughter's boyfriend. The safest option is to not to install the back-door in the first place. PA's ability to tie Internet activity to specific users' identities was central to their sales pitch-- our tech staff assumed this was targeted at windows shops, but we used non-MS stuff including our LDAP servers and hoped this could kill the surveillance project-- PA countered that they could, at a last resort, do things like e.g., scrape radius logs to associate identities. PA appears to be a competently run company that probably knows what messages are most effective at selling their product, and they really pushed user surveillance. Therefore, I suspect that many organizations who purchased PA products based that decision on the user surveillance capabilities (explicitly to enable abuse by management). PAs main feature seems analogous to an illegal phone wire tap, and IMO should be illegal (especially without notification to the victims-- both on-site and off-site). It is curious how corporate circumvention of encrypted communications without permission of the external site hasn't been seen as a CFAA violation while a simple 'view source' on a browser can result in SWAT pointing a gun at your child.
Spooky23 4y ago
You’d probably feel differently if some developer at the IRS compromised your identity because he used some compromised library to avoid internal processes. Security, public trust, etc requires controls and audit to deliver. You don’t want a startup “fake it till you make it” mentality in government or banking.
ornornor 4y ago
More like you can’t possibly expect your work machine to have any kind of privacy, being in the trade and knowing all the ways companies can (and will) use anything they managed to gather about you should they need to obliterate you. It’s simply good practice not to use your work machine for anything personal at all ever. Because depending where in the world you are, anything stored or viewed on a work machine gives your employer de facto access to it, legally speaking.
- wahnfrieden 4y ago
  You can be careful as a worker and still be against workplace surveillance
  - ornornor 4y ago
    For sure, but let’s face it… we’re getting more surveillance and bossware at work, not less unfortunately.