My next class:
Network Monitoring and Threat Detection In-DepthSingaporeNov 18th - Nov 23rd 2024

Security Features Nobody Implements

Published: 2016-04-07. Last Updated: 2016-04-07 18:17:10 UTC
by Johannes Ullrich (Version: 1)
24 comment(s)

"Nobody" may be wording it a bit strong. But adoption of these security features is certainly not taking off. If you can think of any features I forgot, then please comment:

DNSSEC

That is probably my favorite issue. DNSSEC "fixes" on of the most important protocols. Without it, spoofing is always possible, and in some cases not even terribly hard. I think there are a number of reasons it is not implemented:

  • If you implement it, there is a good chance that you make your domain non-reachable if you mess up. 
  • Implementation is far from straight forward. In particular depositing the key signing keys with your parent zones could be easier.
  • There are few public examples one could point to recently, showing how the failure to provide DNSSEC led to a breach.

So in short: high risk low gain. Insider tip: Some registrars like make it dead simple to enable DNSSEC for zones hosted with them.

HTTPS Key Pinning

Unlike DNSSEC, key pinning is a somewhat new-ish feature, and may not even be supported by all browsers. But while I think you would be hard pressed to find a recent breach that was caused by a site supporting SSLv3 (and we all turned that off. or?), there are multiple examples where certificate authorities issued keys to the wrong party. If anything, our statistics about revoked certs sort of tell the story. But surveys find that less then 1% of sites implement key pinning. I think the issue is similar like with DNSSEC: if you mess up, you take your site down, but there is at least a low perceived risk of actually becoming a victim of a fraudulent certificate. Also, while pretty much any audit tool flags SSLv3 as a big risk, key pinning isn't considered much of a risk at this point.

first-party-only Cookie Attribute

This cookie attribute is supposed to prevent cookies from being sent if javascript is used to send a request, and the javascript wasn't loaded from the site it sends the request to. This can cause numerous issues with cross site request forging, but also helps with the BREACH attack, in particular in its newer implementations. For this one you got a decent excuse: Nobody supports it. Server side configurations do not allow you to enable this feature, and the only client that will support it right now is the yet to be released next version of Google Chrome. Also: the standard is still in draft from and hasn't been approved as an RFC yet

https://tools.ietf.org/html/draft-west-first-party-cookies-01

Outbound Firewall Rules

Ok, there are people that implement them, but I still see a lot of networks that don't. Most see a firewall still as a device that blocks inbound connections. Firewalls do that just fine, but the security improvement of inbound filtering is marginal if you only block ports that your server isn't listening on anyway. On the other hand, preventing a server from downloading a backdoor, or connecting to a command and control channel, can be huge. In reality, setting up good outbound filtering can be difficult. Web servers may need to connect to cloudbased webservices, so IPs will change. Anti-Malware tool updates are also often hosten on CDNs, making it difficult to sensibly control them.

Monitoring DNS Logs

Most people watch firewall logs very carefully. Unless you look just at your outbound logs, there is probably little "interesting stuff" that you will find in your firewall logs. Is it really important for you to know that a kid in China just ran nmap against your systems? On the other hand, DNS logs are full of interesting and actionable information, in particular if you are looking at your recursive name servers. You will find infected systems resolving C&C server host names, covert channels and all kinds of good stuff.

Digitally Signed E-Mail (just added this one later...)

"A user clicking on a link in an e-mail or opening and attachment" is probably how 80% or more of recent breach reports start. But still, I see hardly anybody digitally signing e-mail. Sure not an absolute protection, but wouldn't it help if the mail server stripped attachements from e-mails not signed?

Anything else? I considered "using an IDS properly", "not reusing passwords", as other topics to talk about.

 

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

Keywords:
24 comment(s)
My next class:
Network Monitoring and Threat Detection In-DepthSingaporeNov 18th - Nov 23rd 2024

Comments

Hi,

"Anti-Malware tool updates are also often hosted on CDNs"

Update services need to use consistent, documented DNS names. Modern UTMs allow one to create definitions using DNS lookups, but it's useless if it's not documented.

Thanks!
On the "outbound" firewall filtering side, to my surprise the default rule for outbound traffic in Microsoft Azure from the VM to the Internet is to ALLOW.
Making exfiltration easy...
I would also put HSTS in this category.
[quote]"A user clicking on a link in an e-mail or opening and attachment" is probably how 80% or more of recent breach reports start.[/quote]

If clicking said link or opening said attachment results in execution of some attacker provided binary or script: whitelisting prevents execution (on Windows; see http://www.mechbgon.com/srp/index.html or http://home.arcor.de/skanthak/SAFER.html for proven solutions).

On *x, permissions of newly created files don't allow execution in the first place; if you want to go a step further: use mount -onoexec /home
yes. HSTS certainly fits. A bit more common then key pinning, but could still be used more. Should CSP be listed too? (I am having issues with CSP myself... which is why I left it off :/)
Oh. yes! Windows Software Restriction Policy!! I guess you can tell that I am not a Windows guy :)
DNS logs...

I made sure we diligently keep DNS logs, including blocking all out bound DNS to enforce the internal DNS server

But I have never seen/found a tool that makes surveillance practical or easy.

In my mind, DNS logs is for forensic analysis, once you know what to look for... and that is usually when it's too late.

I did find an article recently about an IOC in DNS logs, and I ended up grepping each and every file...

What else is there to do ?
Change Control, Actual change control not enter a change for metrics purposes.
SELinux. The first thing I do when setting up a new Linux server is to set SELinux to permissive so that it doesn't break whatever else I was going to set up on that server. Maybe this is wrong and I just need to learn how to use it correctly, but why such a barrier? If it's adds that much complexity, I don't have much incentive to use it...
The recommendations here are pretty solid.

1) Most places don't utilize egress filtering, and that limits the detective/protective controls in which a FW/IPS could be utilized to address malicious outbound traffic. Also remember that you are going to need to turn on SSL de-inspection on your web-filter, IPS/IDS to ensure that you can peek inside SSL/TLS traffic, because the bad guys are utilizing these mechanism's to exfiltrate data, and contact C2's to download more malicious code.

2) As for DNS log monitoring, the concept is good but the devil is in the details, unless you have a known/updated listing of C2 IP's or DNS addresses monitoring the logs for these requests could be a futile and time expensive exercise. I am not saying with the right automation (Splunk, SEIM, Integration of Threat Intelligence, along with log aggregation from multiple network resources mean you wont find value in what you are looking for (known or suspected evil traffic). What is learned from these tools plus free resources like urlquery.net and others can give the Sec Ops folks a leg up on attackers.

3) Email, it seems that everyone is a bit "click-happy" these days, and sure enough malicious payloads as attachments on emails are a favorite target for nation states, spear phishing and regular phishing. Again AV or and email gateways can be bypassed, so folks its really about controlling code execution on your end-points (AKA Whitelisting), so even if your user does something stupid, your business isn't paying the price for it, and you end up learning more from the attackers than they learn from you.

4) Lastly, if you don't learn from your mistakes you are doomed to repeat them, again security operations and network security in general is alot of design/preparation and ultimately execution when the stuff hits the fan. So learn from your mistakes or what you discovered from your incident response activities and re-evaluate the controls in your business, organizations to ensure that the last successful attack against your computing infrastructure is well understood, a root cause analysis is agreed upon by the technical stake-holders and courses of action are put in place.

Edward Ziots,
CISSP, CISA, CRISC.
IT Audit Management

Diary Archives