3 ms·

> As was pointed out in another comment[0], most traffic is encrypted these days. Any traffic traversing the enterprise network needs to be visible (unencrypte

by rapjr9 5y ago

> As was pointed out in another comment[0], most traffic is encrypted these days. Any traffic traversing the enterprise network needs to be visible (unencrypted) to network administrators. Defense in depth means the network administrators do not get access to everything because if -they- are compromised then everything is compromised. So you should have multiple admins with limited power over their own subnets and turning off encryption should be like getting a warrant from a judge. This helps prevents stalking also. Network administrators are a centralized primary vulnerability that needs to be mitigated.

nobody9999 5y ago
>Defense in depth means the network administrators do not get access to everything because if -they- are compromised then everything is compromised. So you should have multiple admins with limited power over their own subnets and turning off encryption should be like getting a warrant from a judge. This helps prevents stalking also. Network administrators are a centralized primary vulnerability that needs to be mitigated. A reasonable point. There certainly need to be policies and controls around who can access decrypted network traffic, as well as under what circumstances access to such traffic should be granted. However, that doesn't mean the capability to do so shouldn't be there. That said, good policies/controls can significantly mitigate the risks you addressed. Those can (and should) include separation of duties, clearly defined roles and granular access controls. What's more, you need to hire honest, decent people. Fortunately, most folks are. If one or more of your employees violates policy (and potentially the law) and exfiltrates corporate data/information, depending on severity, that employee(s) should be disciplined, fired and/or prosecuted. And "turning off encryption" isn't anything to which I described, or even alluded. Rather, I discussed using proxies to mediate connections between internal and external sides of encrypted (and unencrypted ones for that matter). connections is good security practice. >turning off encryption should be like getting a warrant from a judge. That's a ridiculous statement on its face. Organizations (and by extension, those designated by the organization to do so) have the legal right to examine all data that traverses their networks. Full stop. Edit: Correct awkward phrasing.
- rapjr9 5y ago
  >Organizations (and by extension, those designated by the organization to do so) have the legal right to examine all data that traverses their networks. Full stop. I didn't say it should require going to an actual judge, I intended to say that digging into packets should require approval and the approval should not be given easily (maybe a "break glass" system). I do think that companies legal right to view all data on the network may change in the near future, especially in the USA if it ever gets decent privacy laws, and in the UK. Businesses may also move away from it because it could be a source of liability. It's rather like the rethinking going on around collecting more data than needed from customers rather than the minimum; the extra data becomes something the police can demand, that can be subpoenaed, that the company is liable for if stolen or modified or otherwise compromised, and that the company may be required to maintain the accuracy of. It also seems like examining decrypted network traffic to manage the network would only be necessary for some types of data, not all data. There can be internal company liabilities also, if an admin has carte blanche to look at lots of data and some crucial proprietary company data is leaked to the outside, just having had the potential for access makes the admin a suspect, innocent or not. Minimizing access and limiting the types of data which can be viewed to what is necessary seems logical, again with a break glass mechanism for unusual situations. It's mainly a historical artifact that network administrators have had such power and in many cases it is way more powerful than is actually needed. Hiring honest decent people is always good, but they can be blackmailed or simply ordered by the company to do unethical things, or ordered to grant access to someone who will do unethical things.
  - nobody9999 5y ago
    My apologies. Apparently, I didn't clearly express my thoughts, as you've definitely misunderstood the processes and ideas I was attempting to describe. I'll preface my attempt to express myself more clearly by reiterating that data on or traversing company owned property must be available to the company and/or its designees, even if that data is of a personal nature, as long as the there is a legitimate business need to inspect such data. That said, I am not suggesting (nor am I sure why anyone would imagine that it's desirable or, in a large organization, even feasible) the decryption, capture and storage of every packet traversing such a network. Rather, I'm merely pointing out that the owner of private property has the right to inspect such data. Even more, in certain circumstances (I'll address those below), an organization must do so to identify potential threats/incursions/data thefts and take appropriate action to mitigate or prevent such activity. The circumstances under which this may be required include identifying potential compromise attempts (already widely done via IPS/deep packet inspection systems), malware payloads, data exfiltration and a variety of other threats. I'm not claiming (or even implying) that all traffic should be reconstructed and manually reviewed. That said, automated tools can (and should) be used to identify potential threats and network traffic tagged as such should be reviewed by the network/security personnel specifically designated and authorized to perform such activities. I'd add that usage of corporate resources should be restricted to activities specifically related to the business of the organization, on devices that are owned and managed by that organization. Other activities should be explicitly disallowed by policy and non-company owned devices should be barred from access to the internal network. Which is why I specifically highlighted the use of "guest" networks in my initial comment[0]. That network to be used by external users as well as the personal devices of internal users for non-company business. I do not advocate (unless the threat model requires it) ubuquitous surveillance of users. And all users should be informed of the policies and mechanisms in place that might trigger review of network data, as well as the potential repercussions of policy and/or legal violations. When such reviews are triggered, any data collected around such potential threats/policy violations needs to be appropriately safeguarded, not only to protect the privacy of users, but also to protect the integrity of any investigation to be performed. Again, we're talking about internal networks and systems wholly owned by the organization, and any device not in that set should be barred from connectivity to the internal network and forced to use the "guest" network. As I also mentioned in my initial post[0], external cloud-based infrastructure is not in scope here, but is also an important topic that deserves an entire discussion itself. And Internet-facing applications accessed by external parties (e.g., customers) are also not in scope here. I am specifically referring to internal corporate users on company-owned devices. As for bad actors and/or those who might "be blackmailed or simply ordered by the company to do unethical things, or ordered to grant access to someone who will do unethical things," organizational policies and the law should govern the consequences of such actions. Until we have general AI[1] that can perform such tasks, we'll just have to use humans and (with appropriate policies/controls) trust them to do their jobs. When they don't, just as it's always been, there are consequences (including discipline, termination and civil/criminal legal action) for such bad behavior. I hope I've been able to more clearly express myself this time. [0] https://news.ycombinator.com/item?id=30575249 https://news.ycombinator.com/item?id=30575249 [1] https://en.wikipedia.org/wiki/Artificial_general_intelligence https://en.wikipedia.org/wiki/Artificial_general_intelligenc... Edit: Cleaned up some prose, clarified some arguments.

by rapjr9 5y ago

nobody9999 5y ago

>Defense in depth means the network administrators do not get access to everything because if -they- are compromised then everything is compromised. So you should have multiple admins with limited power over their own subnets and turning off encryption should be like getting a warrant from a judge. This helps prevents stalking also. Network administrators are a centralized primary vulnerability that needs to be mitigated. A reasonable point. There certainly need to be policies and controls around who can access decrypted network traffic, as well as under what circumstances access to such traffic should be granted. However, that doesn't mean the capability to do so shouldn't be there. That said, good policies/controls can significantly mitigate the risks you addressed. Those can (and should) include separation of duties, clearly defined roles and granular access controls. What's more, you need to hire honest, decent people. Fortunately, most folks are. If one or more of your employees violates policy (and potentially the law) and exfiltrates corporate data/information, depending on severity, that employee(s) should be disciplined, fired and/or prosecuted. And "turning off encryption" isn't anything to which I described, or even alluded. Rather, I discussed using proxies to mediate connections between internal and external sides of encrypted (and unencrypted ones for that matter). connections is good security practice. >turning off encryption should be like getting a warrant from a judge. That's a ridiculous statement on its face. Organizations (and by extension, those designated by the organization to do so) have the legal right to examine all data that traverses their networks. Full stop. Edit: Correct awkward phrasing.

rapjr9 5y ago
>Organizations (and by extension, those designated by the organization to do so) have the legal right to examine all data that traverses their networks. Full stop. I didn't say it should require going to an actual judge, I intended to say that digging into packets should require approval and the approval should not be given easily (maybe a "break glass" system). I do think that companies legal right to view all data on the network may change in the near future, especially in the USA if it ever gets decent privacy laws, and in the UK. Businesses may also move away from it because it could be a source of liability. It's rather like the rethinking going on around collecting more data than needed from customers rather than the minimum; the extra data becomes something the police can demand, that can be subpoenaed, that the company is liable for if stolen or modified or otherwise compromised, and that the company may be required to maintain the accuracy of. It also seems like examining decrypted network traffic to manage the network would only be necessary for some types of data, not all data. There can be internal company liabilities also, if an admin has carte blanche to look at lots of data and some crucial proprietary company data is leaked to the outside, just having had the potential for access makes the admin a suspect, innocent or not. Minimizing access and limiting the types of data which can be viewed to what is necessary seems logical, again with a break glass mechanism for unusual situations. It's mainly a historical artifact that network administrators have had such power and in many cases it is way more powerful than is actually needed. Hiring honest decent people is always good, but they can be blackmailed or simply ordered by the company to do unethical things, or ordered to grant access to someone who will do unethical things.
- nobody9999 5y ago
  My apologies. Apparently, I didn't clearly express my thoughts, as you've definitely misunderstood the processes and ideas I was attempting to describe. I'll preface my attempt to express myself more clearly by reiterating that data on or traversing company owned property must be available to the company and/or its designees, even if that data is of a personal nature, as long as the there is a legitimate business need to inspect such data. That said, I am not suggesting (nor am I sure why anyone would imagine that it's desirable or, in a large organization, even feasible) the decryption, capture and storage of every packet traversing such a network. Rather, I'm merely pointing out that the owner of private property has the right to inspect such data. Even more, in certain circumstances (I'll address those below), an organization must do so to identify potential threats/incursions/data thefts and take appropriate action to mitigate or prevent such activity. The circumstances under which this may be required include identifying potential compromise attempts (already widely done via IPS/deep packet inspection systems), malware payloads, data exfiltration and a variety of other threats. I'm not claiming (or even implying) that all traffic should be reconstructed and manually reviewed. That said, automated tools can (and should) be used to identify potential threats and network traffic tagged as such should be reviewed by the network/security personnel specifically designated and authorized to perform such activities. I'd add that usage of corporate resources should be restricted to activities specifically related to the business of the organization, on devices that are owned and managed by that organization. Other activities should be explicitly disallowed by policy and non-company owned devices should be barred from access to the internal network. Which is why I specifically highlighted the use of "guest" networks in my initial comment[0]. That network to be used by external users as well as the personal devices of internal users for non-company business. I do not advocate (unless the threat model requires it) ubuquitous surveillance of users. And all users should be informed of the policies and mechanisms in place that might trigger review of network data, as well as the potential repercussions of policy and/or legal violations. When such reviews are triggered, any data collected around such potential threats/policy violations needs to be appropriately safeguarded, not only to protect the privacy of users, but also to protect the integrity of any investigation to be performed. Again, we're talking about internal networks and systems wholly owned by the organization, and any device not in that set should be barred from connectivity to the internal network and forced to use the "guest" network. As I also mentioned in my initial post[0], external cloud-based infrastructure is not in scope here, but is also an important topic that deserves an entire discussion itself. And Internet-facing applications accessed by external parties (e.g., customers) are also not in scope here. I am specifically referring to internal corporate users on company-owned devices. As for bad actors and/or those who might "be blackmailed or simply ordered by the company to do unethical things, or ordered to grant access to someone who will do unethical things," organizational policies and the law should govern the consequences of such actions. Until we have general AI[1] that can perform such tasks, we'll just have to use humans and (with appropriate policies/controls) trust them to do their jobs. When they don't, just as it's always been, there are consequences (including discipline, termination and civil/criminal legal action) for such bad behavior. I hope I've been able to more clearly express myself this time. [0] https://news.ycombinator.com/item?id=30575249 https://news.ycombinator.com/item?id=30575249 [1] https://en.wikipedia.org/wiki/Artificial_general_intelligence https://en.wikipedia.org/wiki/Artificial_general_intelligenc... Edit: Cleaned up some prose, clarified some arguments.