SANS ISC: Security Features Nobody Implements

• SANS Site Network
  • Current Site
  • SANS Internet Storm Center
  • Other SANS Sites Help
  • Graduate Degree Programs
  • Security Training
  • Security Certification
  • Security Awareness Training
  • Penetration Testing
  • Industrial Control Systems
  • Cyber Defense Foundations
  • DFIR
  • Software Security
  • Government OnSite Training

SANS ISC InfoSec Forums

"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