1

Is it reasonable to make mandatory that all traffic were encrypted inside an organization (in the internal network)?

Usually, in the LAN of an organization some protocols are plain text, for example, Telnet or FTP but also other like LDAP. The risk is much less inside the network but I think nowadays, with the Internet of Things, BYOD, mobility and other functionality, make encryption for communications mandatory is reasonable and acceptable, what do you think?

Please, do not answer that this depends on the risk of your organization or your policy. I'm supposing the risk is enough in all companies just thinking about malicious insiders and what I'm asking is whether this requirement shold be added to a security policy or not.

Should it depend on the segment of the internal network?

EDIT: I have discovered that there is a similar question in ServerFault: https://serverfault.com/questions/130347/encrypting-absolutely-everything-even-within-the-lan?rq=1

Community
  • 1
Eloy Roldán Paredes
  • 1,507
  • 12
  • 25

2 Answers2

4

Since this question is primarily opinion based - in my opinion :) - my answer will be primarily opinion based.

First, if there's one thing I've learned in the years I've worked in professional IT/security, it's this: It doesn't really matter if you agree or disagree with a company policy or if you think it's reasonable for them to encrypt traffic as a specific example; it's THEIR (insert company name here) company and they can enforce any policy they want so long as it doesn't break local, state, or federal law/regulation. If you don't like the policies then you have two choices: suck it up and continue to work there, or find another employer; it's really that simple.

Now on to my personal opinion of the matter. I don't think it's a question of whether it's reasonable to encrypt all traffic, even internally, but it's more of a question of why would your leadership want to do this. I work for a federal agency that has several enclaves (we'll call them islands), one of which deals with SCADA and Industrial Control Systems (ICS). These ICS enclaves/islands have way more sensitive data than the general enclave that almost all other users are on and in my opinion would be justified encrypting all traffic. This could help against potential attackers that would try sniffing the network as an example for any helpful information they could obtain. It could also help prevent a myriad of other things, but when it comes down to it there is a good business case/justification for this. The business case/justification is that if an attacker gained access to the regular non-ICS/SCADA enclave there isn't much that they could do to damage the systems out in the field controlling important infrastructure. If they, on the other hand, gained access to SCADA/ICS data from something as simple as a network protocol analyzer they'd have the keys to the kingdom and could take down some seriously critical infrastructure that would affection a lot of people. That right there is justification to be at least a little paranoid as well as more cautious and take measures such as encrypting all of the traffic internally and externally. Not all networks would have a good justification for encrypting all traffic.

To answer your specific question, I do think it should depend on the network segment as you've put it, however it may be easier operationally to encrypt all traffic rather than trying to cut out certain areas to encrypt vs leaving others unencrypted. But, without knowing your company's leadership I can't say why they'd want to do this across the board.

Brad Bouchard
  • 628
  • 1
  • 5
  • 13
  • 1
    I like your second paragraph, and fully agree. :) – Mark Buffalo Jan 21 '16 at 15:42
  • 1
    At the risk of sounding naive... Is there an argument for not implementing encryption internally? I first thought of overhead and slowing down connections but being it internal, I cant think of a scenario where a few hundred ms would hurt that much... – Purefan Jan 21 '16 at 15:55
  • 1
    @Purefan Great question. I actually have a real life scenario that I'm dealing with right now where there could be a case for not implementing encryption internally and it deals with what you've said in regard to overhead and slow connections. We use a particular vendor for email and data encryption that needs to do CRL checks on a server that is located across the country from where we are. When the CRL check happens, it's already going out several firewalls and proxies which makes it slower than we'd like it. Now add to that the use of encrypting all traffic internally and even if... – Brad Bouchard Jan 21 '16 at 16:00
  • @Purefan you did only add 200-400 ms of latency, that may just be the proverbial nail in the coffin. What I mean by that is this: We are already troubleshooting high latency with the CRL checks for our encryption vendor. The latency has a threshold where the CRL check will actually fail if it takes too long. This actually is a security risk/concern and we've narrowed down the time frame to the millisecond to know where we need to be. If we implemeneted something like the OPs question and encrypted all traffic internally and added more latency (even a few ms), we'd have failed... – Brad Bouchard Jan 21 '16 at 16:03
  • 2
    @Purefan CRL checks all of the time. In that case, it wouldn't be smart to implement a policy like the OP referenced in his question. Hopefully that made sense. – Brad Bouchard Jan 21 '16 at 16:03
  • @Purefan I have to research the case you mention "CRL checks all of the time". Could you point me in the right direction? Some site, manual, or something where I can find more information. I don't know when this can happen... – Eloy Roldán Paredes Jan 21 '16 at 17:12
  • 1
    @EloyRoldánParedes Those were my comments. CRL stands for Certificate Revocation List. In PKI it's a list of certificates that have either expired or been revoked by their particular Certificate Authority (CA). Hopefully you didn't already know that, but that was just a single example I used to make my point. Any time someone would send an encrypted email or receive one, or when someone would encrypt a file and then another would decrypt that file, the process of validating certificates would be involved which in most cases would involve checking the CRL(s). – Brad Bouchard Jan 21 '16 at 17:17
  • 1
    @BradBouchard Thank you! That's exactly what I wanted, a real life scenario where it didn't make sense to encrypt everything. – Purefan Jan 22 '16 at 14:54
2

I'll start off by saying that encrypting your internal network is normally a Good Idea. The idea we have that we can separate the "good guys" from the "bad guys" through a firewall hasn't held up to the realities of the world. For any large organization there's numerous ways inside the network, and you're simply not going to prevent attackers from getting in. The point being, you likely really shouldn't treat the internal network as inherently safe.

Policy is a completely different matter however. You sound like you're trying to reach a policy when you use the words "mandatory encryption". Personally I dislike assuming that setting policy achieves any real security goals. When setting any policy you should consider the COSTS of setting a policy. The costs of a policy can be substantial, and difficult to understand at the outset even if you do involve many stakeholders. Too often "security departments" don't even do this minimal amount of cost analysis, and don't involve other parts of a company than simply the security team.

For instance, not all products will support encryption. The words "mandatory encryption", taken at face value would exclude any products/solutions that don't support encryption. You may think this is a Good Thing, but there's many instances where security isn't required. In those cases you've eliminated a series of potential solutions merely because it doesn't meet a policy that should have never applied to it.

So you should think long and hard before setting any policy. You may wind up doing more harm than good.

Steve Sether
  • 21,480
  • 8
  • 50
  • 76
  • Excellent addition Steve. Great point about policy not achieving goals. Although I think that if done right policy does increase security posture overall, I agree that it could also have the opposite effect if done hastily. – Brad Bouchard Jan 22 '16 at 03:51
  • Can you put an example of "instances where security isn't required" and encryption may not be a Good Thing? – Eloy Roldán Paredes Jan 22 '16 at 07:25
  • @EloyRoldánParedes It's difficult to generalize, but I'd say that a wiki might be a good example. Wikis are normally writable by anyone, and contain public information. It's already publicly available, so why would you bother with encryption? – Steve Sether Jan 22 '16 at 15:45