Unmasking malware in TLS connections? It can be done, say Cisco researchers A group of researchers who work for Cisco* reckons malicious traffic in TLS tunnels can be spotted and blocked – without decrypting user traffic. That's good news in the corporate setting, because today's protection relies on the controversial approach of terminating the encryption to inspect the traffic. In this paper at …
Well, that's a load of nonsense then.
Even if you can spot an outdated TLS being used by malware today, tomorrow when you spend a fortune on kit to block it, they'll just update the library - meanwhile all your old legacy software that uses TLS but not with critical data will get marked as malware and blocked.
The ciphers used in TLS are only part of the detection mechanism. The other part is analysing the network flow, which gave 90% accuracy in identifying malware families.
The kit used to block this would also be using a dynamic ruleset, so it can be updated as appropriate. I think you're being unfairly dismissive of this result.
Then what part does TLS itself actually play? Almost none.
It's like looking for a certain port-number, when what you're actually interested in is "is the same packet coming from thousands of different locations, simultaneously, in a spike, unannounced, and the follow-on transactions and replies never acted upon", etc. Not "what ciphers were enabled".
If it's practicable to infer content from the pattern of data flow, that applies to the "legitimate" communication, too. So secure encryption requires that the flow be rendered less dependent on the content (by padding it with filler data, by adding random short delays between packets or whatever), spoiling this "antimalware" method at the same time.
So, it correctly identifies the malware family in 93.2% incidents, presumably that means it misses about 1 in 15. But the big question is, how often does it mis-identify a good flow as a malware flow? Having your important communication blocked because it appears to have the same flow pattern as a malware family is... not helpful.
Where's the "shoot yourself in the foot" icon when you need it?
Remember this is first and foremost about identification - what is done as a consequence is dependent on the application - inline decryption, out of band decryption, packet capture for later analysis, alerting, blocking...
However I doubt there are enough distinct observables in the visible portion of encrypted traffic (hellos, flow frequency and length) to be able to reliably classify malicious and legitimate traffic, and then there's the consequences of malware where attackers and malicious insiders use 'legitimate' tools and services to conduct their activities. A decent infosec team needs to be able to see across all of this.
And I maintain if as a corporate user you want to maintain privacy from your employers in office hours, use your smartphone/data - you do have one don't you??
for the network layer, cisco wants to sell you a netflow solution to the enterprise malware problem - competitors sell decrypt and sandbox/DPI solutions. as per AC#1, enterprises have to protect their assets, this means employees do not have the right to privacy of their comms when on the corporate network. If you want to do something private, use your phone/tablet/whatever, on a corporate guest network if there is one, or failing that use your mobile data. For enterprise protection I would much rather have a full decrypt solution sending the data to your choice of inspection kit.
And just imagine going to your CIO with a solution design / proposal "its really cool, we can catch up to 93% of malware with this". "get out and don't come back until you are at 99% +"
AC because I do exactly this stuff for a living and thus non-attributable...
"If you want to do something private, use your phone/tablet/whatever, on a corporate guest network if there is one, or failing that use your mobile data. For enterprise protection I would much rather have a full decrypt solution sending the data to your choice of inspection kit."
A smart business would ONLY provide the one network since ANY OTHER network provides a compromise path. As for DPI, are you going to simply block anything you can't sniff (say a self-installed tunnel and certificate)?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
