151

Provided that I have a decent level of physical security in the office, I monitor the physical addresses of devices connected to the network and only give VPN access to trusted parties, do I need to encrypt access to intranet resources over HTTP?

There is an employee complaining that he doesn't like sending his credentials in plain text over the network and that he cannot take responsibility for his network identity in such case. What are the real world chances that someone would steal his identity? I can't find any clear-cut recommendations for encryption within a corporate network.

Robert Cutajar
  • 1,461
  • 2
  • 7
  • 7
  • 104
    I believe the employee is well within his right to complain in such case. Just thought I'd add that. Also when talking about "trusted parties" who are you exactly referring to - do you have any reasons to trust them beyond the fact they told you they're trustworthy, etc? –  Jun 21 '18 at 15:52
  • 2
    If you want clear-cut recommendations, read Google's BeyondCorp paper(s). – Xander Jun 21 '18 at 19:07
  • Related: https://security.stackexchange.com/questions/152019/is-it-acceptable-for-an-internal-hr-site-to-run-over-http – Arminius Jun 21 '18 at 22:15
  • 96
    If I wanted to steal another employee’s credentials to, say, snoop through confidential company data, sabotage employees I don’t like, or cryptojack our computers in a way that someone else takes the fall, sniffing logins to an http intranet would be a good way to go about it, dontcha think? – HopelessN00b Jun 21 '18 at 22:44
  • 14
    What's your threat model? Employees attacking the company, the company attacking the employees, employees attacking each other, third parties attacking the employees, third parties attacking an employee and pivoting into an attack on the company, ...? It's hard to evaluate the cost-benefit of a security measure without knowing what you want to defend against. – Jeffrey Bosboom Jun 22 '18 at 02:38
  • 57
    I must admit the guilt of a little trolling excursion. I have spoken on behalf of the organization while I am the guy complaining. Your amazing reactions may help convince the IT department to do something :D Thanks everyone! – Robert Cutajar Jun 22 '18 at 12:13
  • 2
    I'll just leave this here https://arstechnica.com/information-technology/2013/11/googlers-say-f-you-to-nsa-company-encrypts-internal-network/ – Wayne Werner Jun 22 '18 at 15:59
  • Also, I used to work at a company where every single employee's AD login credentials were passed as basic auth unencrypted to our squid proxy. That was when I changed my work password to `Password1` – Wayne Werner Jun 22 '18 at 16:01
  • 8
    Note that for US government agencies, internal encryption of all traffic is generally mandatory, and likewise with government contractors. The highest profile breaches of the last ten years have all been insider threats. – Todd Wilcox Jun 22 '18 at 20:06
  • 3
    As an attacker you have IP-address based security (I don't care), you have MAC-address based security (I don't care). You have put glue in all the network sockets. It will slow me down, but it also tells me that you probably are relying on it (you have no other security). – ctrl-alt-delor Jun 22 '18 at 22:54
  • Relevant reading: https://www.gearbrain.com/iot-hack-on-casino-aquarium-2560513466.html – Thorbjørn Ravn Andersen Jun 23 '18 at 06:18
  • For certain information, I would be in trouble if I sent it over an unencryted connection and my boss found out. – gnasher729 Jun 24 '18 at 19:17
  • 3
    If you need a bumper sticker type slogan: "Firewalls. Crunchy on the outside, chewy on the inside." – arp Jun 25 '18 at 09:38
  • 4
    If you're trying to sell this to management, seems like you might make an analogy to locking office doors and filing cabinets in the building. I mean if they're good with unencrypted internal communications, why not unlocked doors? Plus not having to deal with pesky locks could save a lot of time! – Nat Jun 25 '18 at 17:38
  • 1
    Good news everyone, We are now running on HTTPS. – Robert Cutajar Jul 31 '20 at 09:01

12 Answers12

262

Yes encrypt, it is easy. Plus according to a 2014 Software Engineering Institute study 1 in 4 hacks was from someone inside the company with an average damage 50% higher than an external threat actor.

Link to source: https://insights.sei.cmu.edu/insider-threat/2017/01/2016-us-state-of-cybercrime-highlights.html Although this is the 2017 version.

Joe M
  • 2,997
  • 1
  • 6
  • 13
  • 18
    Thank you for backing the recommendation with real world numbers. That's exactly what I needed. – Robert Cutajar Jun 22 '18 at 12:10
  • 1
    well, "~easy" in an internal network and easy on Internet (with Let's Encrypt). Beside that I fully agree and +1 for the sources. – WoJ Jun 22 '18 at 15:44
  • Besides being of practical importance, It's also solid security practice - defense in depth (without much cost). – Out of Band Jun 23 '18 at 07:58
  • Good advice. It is far to easy for an internal actor to sniff the network. – Willtech Jun 24 '18 at 09:32
  • It's easy as long as you can trust an encryption library to be implemented properly and not have any bugs. Let's not forget [the OpenSSL incident](https://en.wikipedia.org/wiki/Heartbleed). Encryption is not easy, but using a 3rd party library generally is. – Pharap Jun 24 '18 at 18:01
  • 5
    But how many of those internal "hacks" were done by MITMing an intranet http connection? Versus, say, forwarding an Excel spreadsheet from ones work address to ones gmail address? – jjanes Jun 26 '18 at 13:26
  • 1
    There are some good answers, so I won't add one, but this picture sums it up pretty well "ssl added and removed here :)" https://blog.encrypt.me/assets/img/posts/2013/11/05/nsa_slide.jpg – Jeremy French Jun 28 '18 at 08:56
  • @jjanes I think you are seriously overestimating how difficult it is to snoop traffic on an Ethernet broadcast domain. In your email example the lowest hanging fruit would be a sometimes non-encrypted SMTP connection through the LAN. Other than that the only attacks are snooping it over the internet, hacking gmail, or social engineering... – trognanders Jul 02 '18 at 19:53
110

What are the real world chances that someone would steal his identity?

Running a MITM attack on an HTTP connection when on the same LAN is basically trivial. ARP is not designed to be secure. Some high end switches provide reasonable mitigation, but it is mostly pretty weak on anything that is not fabulously expensive.

There is an employee complaining that he doesn't like sending his credentials in plain text over the network and that he cannot take responsibility for his network identity in such case.

If the guy is accountable for actions that are taken with his credentials, it is unfair to not take reasonable precautions to protect those credentials from other employees. They might be safe from external actors due to network isolation, but that is probably not what the guy is worried about...

trognanders
  • 2,925
  • 1
  • 11
  • 12
  • I don't agree: imho, running a ARP-spoofing based MITM attack on a properly secured network is not possible (or at least not "basically trivial"). – jjmontes Jun 27 '18 at 12:41
  • 4
    @jjmontes - 'properly secured' is not a phrase you can assume is applicable to most networks. – Michael Kohne Jun 27 '18 at 16:52
  • @jjmontes mind expanding ? I know very few networks where disabling ports with more than 2 or 3 mac addresses (phone, computer and maybe another device) is active, so turning a port into a copycat to get all traffic is not often a problem. – Tensibai Jun 29 '18 at 13:24
  • In more secure networks, MAC addresses, IPs, switch ports (and cabling) and ARP tables in switches and routers are static. Afaik, a user of such network could not get traffic from any other port except by physical access, and any use of an incorrect MAC will block the port and be reported (though admitedly, this is not the case in most networks). Also, this doesn't mean the OP shouldn't encrypt intranet connections. – jjmontes Jun 29 '18 at 13:45
  • 1
    @jjmontes Static ARP is only supported in managed switches, imposes rather extreme management headache, and generally is not likely to be used in this scenario. Switches from the likes of Cisco do layer 3 snooping of ARP and use *special magic* to guess when ARP replies are bogus... this is disabled by default in Cisco hardware due to _false positives_. There are things like 802.11x with one mac/port... still requires expensive switches and a radius server. In any case none of these are even remotely close to the security that HTTPS provides for almost nothing out of the box. – trognanders Jul 01 '18 at 07:49
  • @jjmontes ARP spoofing most definitely does work through switches. Most dumb switches are easily confused into delivering all traffic to a port even without ARP spoofing. – trognanders Jul 01 '18 at 07:52
41

Yes, you have to encrypt your connections. Let's take a scenario where you believe your network is physically secured (with required physical security and other required security measure) and no internet access (since you have indicated you only allow VPN access to trusted sources), but let's assume your employees take their laptop home and connecting to internet. The chances of any malware be implemented without their notice is there. And this malware may become active when it's connected to your corporate network and started sniffing traffic. This would lead to exposure of all your corporate communication including everyone's credentials.

Hence it's always recommended to encrypt sensitive traffic.

Further a study by CA (Insider Threat Report - 2018) indicates below concerns over insider threats (Reference: https://www.ca.com/content/dam/ca/us/files/ebook/insider-threat-report.pdf).

Extract from report:

  • Ninety percent of organizations feel vulnerable to insider attacks. The main enabling risk factors include too many users with excessive access privileges (37%), an increasing number of devices with access to sensitive data (36%), and the increasing complexity of information technology (35%).
  • A majority of 53% confirmed insider attacks against their organization in the previous 12 months (typically less than five attacks). Twenty-seven percent of organizations say insider attacks have become more frequent.

  • Organizations are shifting their focus on detection of insider threats (64%), followed by deterrence methods (58%) and analysis and post breach forensics (49%). The use of user behavior monitoring is accelerating; 94% of organizations deploy some method of monitoring users and 93% monitor access to sensitive data.

  • The most popular technologies to deter insider threats are Data Loss Prevention (DLP), encryption, and identity and access management solutions. To better detect active insider threats, companies deploy Intrusion Detection and Prevention (IDS), log management and SIEM platforms.

  • The vast majority (86%) of organizations already have or are building an insider threat program. Thirty-six percent have a formal program in place to respond to insider attacks, while 50% are focused on developing their program.

Possible solutions/mitigation controls for insider attacks would be: enter image description here Source: 2018 Insider Threat Report, CA Technologies

Sayan
  • 2,033
  • 1
  • 11
  • 21
29

Risk of Repudiation

In addition to all the fine answers about employees as a threat and visitors as a threat, I think you have to consider that the mere fact that the traffic is unencrypted is of itself a vulnerability even in the total absence of hackers.

You are setting yourself up for a situation where any employee who does something they are not supposed to do (by mistake or on purpose) and then is called out on it can deny that it was actually them. Normally, you the manager would just say, "we know it was you because you were logged in". In this case the accused employee can reasonably reply "the login is worthless and you know it. Anyone on the LAN could have sniffed my password and done this bad thing posing as me."

eclipz905
  • 109
  • 2
AllInOne
  • 467
  • 3
  • 6
  • Yes, but not quite. There are usually other factors that can help identifying the source of a connection: the source IP address is one example. For example, some networks link IP addresses to MAC addresses and switch ports, making very difficult or impossible for anyone to use an IP address that was not assigned to them. Besides, that argument can be used even if traffic is encrypted. – jjmontes Jun 27 '18 at 12:38
14

Some companies, especially larger ones that have been around long enough to develop bad habits, have roughly the following fallacious security model:

The network is safe as long as nobody else plugs into it and nobody inside is technologically skilled enough to abuse it.

Is this possible to protect in all cases? No, but proper physical/building access controls can help lower the risk. But what if guests are allowed in the office for meetings etc.; are there easily accessible ethernet ports in the conference rooms or easily-accessed wireless networks, or are these networks segregated from ones where credentials may be flying around?

It also depends on what you are trying to protect. Consider the worst-case scenario where someone (from inside or outside the organization) steals plaintext credentials for another user. What are they able to do; access critical infrastructure or just some low-profile development servers? If an identity is stolen, are you able to determine who is using the login?

Ideally, everyone would use encryption everywhere. But if the above threats are within your risk tolerance, then maybe it is not urgent to encrypt intranet resources. Depending on the size of the organization, there may be some overhead in deploying a CA and SSL certificates to all resources. Ask yourself what is worse: the worst case scenario or putting in the work to encrypt everything?

multithr3at3d
  • 12,355
  • 3
  • 29
  • 42
  • 1
    If an attacker is able to use credentials to "access some low-profile development servers", what's to say they can't use those same credentials to check in a change adding some kind of backdoor? – user Jun 22 '18 at 13:38
14

In 2018, the answer depends on your threat and risk analysis results. Which, of course, you have performed, identified the likely scenarios, rated them and made a business decision based on the impact and frequency, according to a proper statistical or quantitative method.

Your individual employee, however, has made his own personal risk analysis and arrived at the result that you indicated, namely:

he cannot take responsibility for his network identity in such case

And he is perfectly correct in that assessment. Even a superficial glance at the situation makes it clear that someone other than him, with minimal technical skills, could impersonate him.

To you the business risk is acceptable (obviously, I mean it's 2018, that the internal network is unencrypted is an intentional decision and not, say, a case of we've-always-done-it-like-that, right?) and you may well be right in that decision. Accepting a risk is a perfectly valid option.

To him the risk is not acceptable. Note that he does not make a business decision for the company with his statement. He makes a personal decision for himself. That is why the two risk analyses can come to different results - different context, risk appetite, impacts.

The correct answer is that you are taking the responsibility that he refuses to take. By running the network unencrypted, and accepting the risk, the company assumes the responsibility for the network identity of the users of that network, as it has decided to not protect them.

I could also be mistaken in my assumptions about your corporate risk management, in which case I recommend doing a risk analysis of this particular fact (unencrypted internal network) and threat (impersonation of users) so that you can either revise the decision of having an unencrypted network, or solidify it with results that show that securing the network would be more expensive than the expected loss.

Tom
  • 10,124
  • 18
  • 51
9

Yes, you do need to encrypt inside your "secure" corp network.

Any network penetration will lead to snooping traffic, and anything not encrypted is easy pickings for the attacker. Credentials, passwords, salary information, business plans, whatever.

For real world horror stories, just search for "lateral movement security" Hard, crunchy shell, soft chewy inside is no longer a valid security posture for any company.

While GDPR has few strict technical requirements, if you are handling Personal Information for EU citizens, a common solution to meet GDPR compliance is to show you have encryption on data-in-flight (over your network)

The reality is, your physical security aside, it's just not too difficult to get access within the network, either by physically plugging in to a port (are you monitoring your nightly cleaning staff every night? - how about visiting vendors?) or, more likely, through some form of network intrusion.

Others have cited Google's BeyondCorp paper, which is worth a read. https://cloud.google.com/beyondcorp/

Essentially, your "inside" network should not be trusted much more than the wild, nasty outside internet.

Encryption is low cost, high reward defensive stance. Why wouldn't you do it?

JesseM
  • 1,882
  • 9
  • 9
  • 1
    Definitely this; the idea of the 'secure company network' is becoming obsolete. No reason to let your guard down by assuming a network is secure; minimal extra vigilance == a lot more confidence your communications are private. – Gargravarr Jun 22 '18 at 18:19
7

Yes. You should always encrypt connections on any intranet, just as you would on the public internet.

The DNS Rebinding attack publicized yesterday allows an attacker full access to any HTTP resource on a victim's intranet, by use of a DNS rebind from an attacker controlled IP address to a corproate intranet IP (e.g. 10.0.0.22). (Scanning of an intranet IP space for HTTP services can be done with other techniques, made easier with knowledge of the user's private IP address.)

The only thing necessary for such an attack to work is to trick the victim into loading an attacker-controlled webpage (or javascript or iframe etc).

This attack is best mitigated with HTTPS, since the DNS rebind will not match the presented certificate domain. While removing default virtual hosts also appears to mitigate this particular attack, this attack just goes to show how exposing internal resources over unencrypted connections can turn into a liability with a security vulnerability somewhere else. (I'm not even talking about the slew of 802.11 wifi vulnarabilities we had late last year. Please don't expose intranet resources over wifi!)

Patrick Horn
  • 71
  • 2
7

Defense in depth

There are several good answers here, but even if you trust all your employees completely (which you most likely should not), you open the door for an external attacker and make security so much harder.

Normally an attacker first needs to somehow get into your network (this could be done in a variety of ways) and then he needs to get a login somewhere to actually access sensitive data. By providing Login-passwords unencrypted flying around everywhere you have just made the second step so much easier. Now whenever an attacker gains access to your network, he immediately has access to high level credentials.

The concept to defend in multiple layers is called defense in depth - if an attacker can compromise one layer, he still has to break additional barriers to cause harm.

So please ENCRYPT YOUR CREDENTIALS!

Falco
  • 1,493
  • 10
  • 14
  • 2
    At university, I was taught about this. Its opposite, using just the firewall and an assumption that the internal network was ring-fenced and 'secure', was dubbed the 'chocolate soft centre' approach, a term I think is accurate and I still use today. – Gargravarr Jun 22 '18 at 18:12
3

do I need to encrypt access to intranet resources over HTTP?

Yes - if people are authenticating against the service.

What are the real world chances that someone would steal his identity?

I don't know - I've never met the people who work at your office / are within the range of its Wifi network / might be able to tap your network. I don't know what you consider a "decent level of physical security". I don't know how much you trust the "trusted parties". Certainly, monitoring MAC addresses does very little to protect against network sniffing.

How much would it hurt to implement TLS?

symcbean
  • 18,278
  • 39
  • 73
  • "How much would it hurt to implement TLS?" You have to stand up a certificate authority, distribute your internal Root CA cert to all computers, operate a system to refresh certificates every time they expire, and configure every sensitive service and server to use your certs. Or maybe you could hook all the machines up to get and install certificates from Let's Encrypt!. Ultimately, it could cost quite a bit. – John Deters Jun 21 '18 at 18:53
  • Yes, it costs a HUGE amount to compete with existing commercial providers. It costs very little to set up the software (a couple of hours effort). Deploying across your estate shouldn't cost much - if you have lots of machines then you should have automated deployment tools. Revocation can be a bit tricky - but unlikely to be required on a small scale. – symcbean Jun 21 '18 at 21:02
  • 1
    @JohnDeters with some planning, it can be set up quite cheaply or even for free, and with minimal invasiveness, and rolled out incrementally. I built a self-signed CA internally, which means I can add servers as necessary, then distribute a single public key to trust (which can be revoked easily) and all my systems are then running over HTTPS. – Gargravarr Jun 22 '18 at 18:24
  • 2
    @Gargravarr, you can do this when your organization is fairly small. But the poster used the phrase "corporate network", which implies a larger number of machines. The ability to successfully manage all of them drops off as the number of machines in the network grows. The overall cost includes handling issues like certificates expiring and how many people will experience an outage when they do. Or the risk of what happens to the company when the one PKI expert leaves, and the boss tries to take over his or her duties and makes a mess of things. That is neither "cheap" nor "free". – John Deters Jun 22 '18 at 18:44
  • @JohnDeters Except there are ready solution for that. Most corporate networks use for example AD which allows pushing CA certs onto clients. I would expect it to be harder for small organizations where there are more things that are ad-hoc. – Maciej Piechotka Jun 25 '18 at 07:18
  • @MaciejPiechotka You're missing (deliberately ignoring?) the sheer complexities of scale and global redundancy etc. Nobody is saying it's impossible or even a bad idea, but what it isn't is a part time project for anyone on the Infrastructure desk. Proper, well deployed PKI at scale is something that needs proper architecture and design and a well thought out deployment. Certificates expire, intermediate CA's expire, the CRL needs distributing and so on and so forth. Pushing certs is one tiny part of spinning up a global infra. There's no "ready solution" for this at all. – Dan Jun 26 '18 at 13:20
  • If the OP is responsible for the security of a multi-national corporation which does not use encryption, then they really should be planning to setup a proper CA capability.Even if you go out and buy a corporate CA rather than using xipki, openca or similar, the costs are for the staff to operate it - but we know nothing about the scale of the operation - "corporate network" doesn't tell us whether it is 3 hosts or 3000. The "couple of hours effort" I cited above was the cost for me to setup a CA covering 80 sites and around 300 devices. – symcbean Jun 26 '18 at 14:56
1

Your employee's critique is spot on.

Think about it this way: if you trust your network to the point where encrypting credentials seems unnecessary, then why do you need credentials at all? Do you think you could replace a login form with a simple field where users could type their name?

If the answer is no, then sending credentials unencrypted is not an option either, because you don't trust your trusted parties that much after all, and a password sent over HTTP is not much of a secret.

Dmitry Grigoryev
  • 10,072
  • 1
  • 26
  • 56
-1

To quote a t-shirt: "Just do it!"

  • You are spending hours on stack exchange for a justification of not spending $7 for a cert and 20 minutes securing your server.

  • One thing you didn't think about: How does the employee know that he is entering his credential into the real website and not into a clone of the site that is running on an arduino hidden behind the copier that is ARP spoofing?

  • Does the word "compliance" mean anything? PCI/HIPAA/GDPR is going to come knocking any day. If any "admin" user logs into your website, you HAVE TO encrypt all connections or face serious trouble.
Jan Hertsens
  • 237
  • 1
  • 3