How important is transport security really?

There seems to be a pre-occupation in the security industry about encrypting everything in transit (https/sftp/ssh etc), when the reality is there is a good argument that it is just not that important....

I remember the first time I was taught about the risks of clear text transfer. We were in a training workshop and the facilitator had a Unix machines setup where he had wireshark installed. He then asked us to telnet in and proceeded to capture our passwords. It was amazing! This was a crazy risk, we were all instantly converted, any future audits where we found Telnet and other clear text transfers would instantly get banged on the heard with our righteous hammer of audit workpaper best practice. Even to this day I still see one of the first security requirements to be written on projects be SSL/TLS and many talented pen testers will take the freebie copy paste of the no https on this page issue.

But lets look at this from that proverbial question we should always ask:

Analysing the risk

I will be the first to admit security risk assessment is hardly a mature a field, however lets break this down with what tools we have.

What are the most valuable targets:
  • Admin passwords
  • Actual sensitive info e.g. personally identifiable info, corporate strategy, mass redundancies etc - a surprising amount which is actually in emails
What are the attack trees if to actually capture or modify something in transit:

Attack trees

Fixed networks (inside corporate):
  • An attacker would have to breach physical access controls (or be a photocopy repairman) or be an insider
  • Get past an NAC (but most companies don't have this) or have a workstation
  • In packed switched networks (all modern corporations) you just don't have access to a lot of broadcast traffic
  • So you have to to get access to a router or switch, assuming you are not a network admin this means exploiting a security misconfiguration or vulnerability (fine no problems metasploit exists, most organizations suck at patching especially network devices) but lets say you listen to Cisco/Juniper etc and patch every 3 months (at least the really bad stuff) or so and you at least authenticate everything to a RAS server
  • Even if you can get access, ARP poisoning, DNS cache poisoning whatever, then you have the next problem: volume. There is a hell of a lot of data that goes access a major router or key switch. Many are gigabit enabled now and that means drinking from a firehose. Even with a legit network DLP monitor you need a high performance packet reassembler, good hardware and software and then the ability do effective pattern matching. So getting that CEO's email very tough, getting the odd password probably not so bad
  • This data is also transient - once the packets are gone they are gone (although admin logins can happen often) but there is a limited window of opportunity    
  • Alternatively you could do what I talked about earlier which is put the sniffer on the box you want to monitor, again though same problem assuming reasonable access which is a misconfig or security vulnerability, or lack of anti-malware controls. Also with the first two it is a lot more targeted attack


Public networks:
  • Seems like a lot easier target - you can no longer be comfortable about access controls of intermediate boxes or network devices
  • But lets look at something like email - most Mail Transfer Agents (MTA)'s including big ones like Google now use optimistic TLS which means the majority of your email which arguably holds a your most sensitive info is encrypted in transit without you having to do anything more?
  • Even shared MPLS networks have VLAN tagging
  • Again you have the firehose problem but a million times worse and the transient information page
  • See how many actual exploited loss incidents you find on datalossdb.org or web app sec incidents on interception of data in transit


Wireless network:
  • Corporate: WPA2 is a de-facto standard, its not perfect but you are getting encryption without doing anything more
  • Home/Starbucks etc: This is a legitimate risk in fact the best and only example that OWASP gives for no. 10 lack of transport encryption is interception on an unsecured home wireless network - hell even Google cars on streetview can do it. But even here most/all corporates that provide remote access provides a VPN so do you need anything more?

Conclusions

I'm not saying that transport encryption is not required, when it is as easy to do as TLS why not but what I am saying is that the risk is often overblown with FUD. Additional application layer encryption, email encryption, even going out of your way to use SSH (over telnet), SFTP (over ftp) or SNMP v3 (over v2) etc does it really win the risk vs reward argument?

Then consider storage encryption especially on removable media and backup tapes. Hardly anyone does this although corporates are getting better with removable media. Just have a look at the amount of real incidents on datalossdb.org on both of these vulnerabilities. Even databases and file-servers you suddenly move from from limited opportunity to virtually unlimited opportunity. From an access perspective plenty of EVERYONE / AUTHENTICATED USERS access to file-shares, plenty of select access to database tables. Storage repositories have the same problem of misconfigs and unpatched vulnerabilities but again you once you have a specific target you have a long time to wait for an opportunity.

Does the security community have their priorities the wrong way when it comes to storage and transport encryption? Something to think about....

3 comments:

  1. Enabling SSL/TLS and securing data in transit is an easy win on the part of the security team. Or an easy win for the lucky attacker for example an improperly secured wireless.But still companies chose not to do it or in most cases do not implement it correctly. Consider the number of banks that publicly failed to renew SSL certs, now think to your yourself, how many times has this happened on back-end systems?

    There is one attack vector which you have missed though. This is the malicious insider. Now I totally agree with you in that in a wired environment the practicalities of pulling off password sniffing are harder than you think. But the malicious insider can get access to the hardware, "Sumitomo Mitsui Banking Corporation" anyone?

    ReplyDelete
  2. Agree with your on SSL is is easy, it is so easy that it is almost ubiquitous and thus like WPA2 arguably reduces the need for any other transport protections on top of it, like I said a few others like sftp are more questionable from a risk perspective

    Not sure about the whole renewing of SSL certs, the cert still functions and the transport is encrypted its just not great from a phishing perspective

    I thought I did consider the insider... It depends on the motive, means and opportunity of the insider. If it is a highly disgruntled network admin - they are not going to bother sniffing the traffic, they have access to the routers, switches etc. Transport security doesn't help you here. You need things like no permanent privileged access, good monitoring, configuration compliance, change verification monitoring etc.

    Assume the Sumitomo incident is the 2005 one (http://bit.ly/zZ1nH). Here again transport encryption would not have helped, the attack was they got physical access (as cleaners), installed hardware key loggers and stole credentials, which they then used for access. Again different threat, needs different controls i.e. vetting of all staff including services such as cleaning, repairs etc, physical security monitoring, key logger detection provided by removable media control, one time passwords and 2FA for privileged accounts, thin clients for sensitive terminals with no USB/media ports, SIEM for access patterns outside of a baseline etc etc.

    ReplyDelete
  3. You are correct, whilst an invalid cert will work the whole trust element goes out the window so I see this as a failure.

    Additionally, you are correct about the Sumitomo incident, it was related to the hardware key logger however this could have easily been a software sniffer. The exfiltration and covering tracks are a lot smoother with software than with the physical hardware but both could be implemented by the insider.

    I disagree that the disgruntled network admin though. Sniffing off a mirrored port is far to easy and in the case of a SOA system provide access to other organizations through EDI.

    When considering this attack vector where is the best place to put your defenses? As you said, pretty much everywhere but enabling transport level encryption means that a failure of some of these controls would not necessarily mean compromise.

    ReplyDelete

Author

Written by