Defense in Depth in 9 Steps

Today's lame article, 9 popular IT security practices that just don't work, is a great example of someone who is paid by the word and needs to feed a family.

This is actually the article that inspired this blog.  This not because the information is horrible, although it is...  The real reason is that the author builds 9 wonderful Strawmen.  I will concede  none of these 9 technologies will give you 100% protection.  Anyone who has been in infoSec, for say 3 weeks, know that defense in depth is vital.  Controls will always fail for one reason or another.  Proper layering of controls offers very strong security.  I'd like to see MR. Grimes live in a digital world choosing not to use any of these technologies.  Based on the article, he may be mentally deficient  so I suppose he may be doing it. 

Here are his absurd contentions... and my comments.

Security fail No. 1: Your antivirus scanner won't uncover real network killers

Yes, there are new viruses every day.  However, if we pretend the number per day is fairly consistent, the total number of viruses grows rapidly.  The AV vendors get their definitions out very fast these days.  As the number total viruses grows every day, but the number of "unblocked" is fairly consistent, the AV products become more effective, by percentage, every day.  The WILL UNCOVER 1000s of "real network killers", whatever that even means.

Security fail No. 2: Your firewalls provide little protection

Yes, firewalls are VERY boring.  Yes, all the excitement and action are at the app layer now days.  However, every hosts runs a huge number of services that do not need to be customer facing.  Think remore console, like HP iLo and VNC, or management frameworks like OVO,  SCCM, and so on.  Surface area is hugely important.  Never expose surface, especially administrative surface, to an attacker.   The firewall is how you keep from exposing your systems to these "real network killers".

Security fail No. 3: Patching is no panacea

We agree!!  Woo, there are no silver bullets.  However, is he suggesting we don't patch?   The problems described are vendor problems.  We can't solve those.  There are no alternatives.  Patch your systems!

Security fail No. 4: End-user education earns an F 

We almost agree here.  The education is useless and the users should not be burdened with our concerns   However, education is part of showing due diligence.  If you are being sued due to a breach, answering to investors, etc., do you want to say you didn't even try.  IT risk is part of overall risk and this is one risk you can reduce.

Security fail No. 5: Password strength won't save you

In practice and mathematically  this is just horse shit.  I'll skip the math, we all know it.  As for stealing password via malware, etc., I sure wish I hadn't gotten rid of my AV back at point number 1.  Yes, if passwords are your only security control, you are screwed, long or short.

Security fail No. 6: Intrusion detection systems can't determine intent

This is probably the best point in the article.   While Mr. Grimes makes no recommendations, I always lean towards proactive controls over detective ones.

Security fail No. 7: PKI is broken

No, the market is broken and IT shops are broken.  The folks doing PKI at DoD, etc. seem to be doing pretty well.  This is because there is no cost pressure and a driver to sell more at less operating cost.  This problem plagues the whole security industry.  Read a few of Bruce Schneier's posts on Snake Oil. There are thousands of vendors trying to make a buck off of security while not giving a rat's ass about security.  The truth is, certs need to cost more money and there need to be consequences if your CA or enrollment API gets rolled.

Security fail No. 8: Your appliances are an attacker's dream

That's because the vendors went to the same ITT class that Mr. Grimes did.  They don't patch or run AV and their management ports are internet facing.  The appliance is designed to limit the admin's need to know technical details and keep them from breaking shit and so the vendor has another SKU to push.  As few of these "appliances" are anything more than cheap x86 hardware  what would you expect.  Whether the system is on the appliance or on your "server" if they vendor doesn't patch, you are screwed.  Blame the vendor, not the form factor.

Security fail No. 9: Sandboxes provide straight line to underlying system

I have no clue what the author was thinking here.  Yes sandboxes get exploited.  The accepted paradigm is that all code has flaws waiting to be exploited.  Yes, there have been a lot of exploits on them and there will be a lot more, but the only thing worse id not even trying to sandbox the browser   Let's make the browser spec require remote code execution via HTML...

Anything that has ever been exploited "Just Doesn't Work",  turn off your computer.

Cryptography from a 0

Today's bad security article, From 0 to cryptography, is a great example of an unqualified enthusiast with little experience or proper perspective.  This type of enthusiast can't wait to display their brilliance to those who know nothing about the topic and their ignorance to those with any small amount of industry experience.

The first hint is is that the writer decides to explain the Diffie–Hellman key exchange using colors rather than math.  He then follows with this by claiming that DH can resist a MITM attack.  WOW!!  I suspect the writer is a math enthusiast, as there is a math follow up and a heavy focus on even more math, including RSA.

Then we get gems like this:


Why it is this algorithm important? Because protocols like: SSL, TSL, SSH, PKI or IPSec, all use Diffie-Hellman.


SSL/TLS CAN leverage DH, but the most commonly negotiated cipher-suites do not.  PKI isn't even a protocol.


Then we get this flaming line of crap:

The only difference between a digital signature and a digital certificate is that the public key is certified by a trusted international Certifying Authority(CA). 

I think the author meant ", larg schmarg, harg trag cluten schnank".  At least mine makes more sense.  A digital certificate is NOTHING like a digital signature.

When talking about keys and secrets, there is never a mention of "out of band"???  How can we talk about applied cryptography with out that?

The biggest problem I see is all the math and command line examples give the impression, to the target audience, that this article is accurate or authoritative in some way.   There is some accurate data here, but one would be FAR better off by just reading the Wikipedia articles on the topics.  That is a pretty low bar.

I applaud _no for calling out this horse shit in the comments.

This article reminds me of this SMBC comic.