12 January, 2016

Five Outdated Security Excuses

Five Outdated Security Excuses
Jason Gillam
Author: Jason Gillam

The Security Industry as a whole has been known to criticize businesses large and small with respect to how they manage security.   Why does it so often seem like an after-thought?  How is it that today we still frequently find that security teams are understaffed (or not at all), that business decisions involving sensitive information are made without consideration for security, and established well-known best practices (like using strong passwords) are ignored.
Hand showing 5 fingers

This myth-busting post will cover five excuses (in no particular order) for poor security that should no longer be valid:

Excuse #1: SSL is Slow

SSL was very slow and CPU intensive… over a decade ago.  It is true that there was a time when SSL handshakes were required much more frequently and the speed of the average Internet connection was much slower than it is today.  Remember when “SSL-accelerator” was a buzz word?  The performance hit from switching over to encrypted communication for virtually all connections is well worth the benefit.  Even high-volume sites that don’t necessarily host confidential information (e.g. Google’s search engine) have switched over to HTTPS for everything.

SSL should not be shunned due to performance concerns.  If your website is slow, the poor performance is most likely due to factors outside of SSL.  There are several studies available online that already prove this so I won’t go through it here.  I have had recent conversations with some folks where they make the point “but using SSL made you vulnerable to Heartbleed!”.  True, but still not a good excuse.  Once Heartbleed was announced  we had patches available in short order.  Fear of vulnerabilities in OpenSSL is not a good reason to communicate over unencrypted channels. And by the way, if by SSL you don’t really mean TLS, then it is time to update your vocabulary and probably patch a few things.

Excuse #2: Patching Might Break Stuff

True, but just because patching might break stuff doesn’t mean we should stop patching.  These days many vendors release patches on a frequent schedule and have thorough regression tests to minimize new issues from upgrading.  With all the vulnerabilities publicized over the past couple of years you would think that patching would be assumed, but unfortunately this is not the case.  And the most common line of excuses we hear from our clients is “we don’t want to risk breaking the release”.

Let’s take a step back and think about this.  If your service breaks, and you announce “service is temporarily offline because a security patch broke it”… as a consumer I will be annoyed, but much less annoyed with the outage than if you announce “your account has been compromised because we decided not to deploy a security patch”.  So when a vendor patch is announced, someone should read it, assess the risk to your services (i.e. Does it address an issue with a feature you use? What would be the impact?), and based on the level of risk decide when to schedule the patch.  But deciding not to patch anything for fear of breaking stuff is a lame excuse.

Excuse #3: We Don’t Have Funding for Security

This one of the most common excuses we in the industry hear when we perform security reviews of companies. Many smaller companies don’t even dedicate a single full-time resource to security.  It’s the one IT person who manages everything with a circuit board in it who is also responsible for security.  And many larger companies might run scans but don’t follow through and remediate issues.

In this age just about every company must dedicate some funding towards security.  If you are handling credit card or healthcare or personal data of any type you are probably required either by law or contract to test and remediate security.  This is not optional.  I heard a story over the holidays where a friend of a friend  is a small business owner and ended up with ransomware on his laptop.  This laptop contained all of his business data.  Fortunately it was recovered but this was a case of no patching, no backups, etc… There are rudimentary security precautions every business owner should invest time and a little bit of money into.  If your business is large enough that you have a network (even a small one), you should be investing in security scans and remediating issues.

Excuse #4: We Aren’t a Target

Perhaps you feel that your business is too small, or doesn’t deal with information that might be interesting to an attacker.  Perhaps you actually are not subject to PCI or HIPAA and feel that the risk of being attacked is virtually non-existent.

Not true.  If you have an Internet address then you are a target.  Plain and simple.  I have recently set up a number of honeypots for the purpose of analyzing attacks and found that every time I made them available to the Internet they were attacked within a few hours.

Yes, some companies are big obvious targets (e.g. financial, healthcare, government, etc…).  But there are organizations of criminals out there who will attack anything they can find, without any idea of what’s behind the IP address.

Excuse #5: Users Can’t Handle Complex Passwords

Many companies tend to have relatively simple password policies.  For example, it is quite common to find an 8-character limit for passwords, or to only allow certain special characters.  Sometimes the excuse for this is that it is based on some system limitation (e.g. mainframe).  This should be very rare, as there are few modern systems (even mainframes) that still limit passwords to only 8 characters.  But the other excuse we often hear is along the lines of “management doesn’t want to have to deal with passwords that are harder to remember”.

A full discussion on password complexity is a topic for another day, but for now lets just say that complexity is a factor of:

  • predictability (is it a common password found on a wordlist?)
  • character set (just alpha-numerics or can more printable characters be used?)
  • length

And perhaps surprisingly, length is usually much more of a factor than the character set.  Therefore, a 25 character fragment of lyrics to a favorite song will usually take much longer (i.e. centuries) to brute-force than “fo0B@r1!” (i.e. minutes).  My guess is that favorite lyrics (or a poem, or movie lines, or book) fragments would be at least as easy to remember as eight mangled l33t-spe4k characters for most of us.  So yes, users probably can handle complex passwords.  They just don’t really understand what makes a password complex.

Jason Gillam is a Principal Security Consultant with Secure Ideas. If you are in need of a penetration test or other security consulting services you can contact him at jgillam@secureideas.com, on Twitter @JGillam, or visit the Secure Ideas – ProfessionallyEvil site for services provided.

Join the professionally evil newsletter

Related Resources