Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Risk

4/17/2014
07:30 AM
Connect Directly
Twitter
LinkedIn
RSS
E-Mail
100%
0%

How A Little Obscurity Can Bolster Security

Most security professionals deride the idea of "security by obscurity." Is it time to re-evaluate the conventional wisdom?

One of the first maxims I remember learning when I began my formal information security (InfoSec) training was, "Security by obscurity is no security at all." If you haven’t heard this saying before, security by obscurity refers to relying on an aspect of secrecy to protect your systems, rather than on truly secure design. Most security professionals utter the phrase with derision.

A good example of a system that relies on security by obscurity? Those fake rocks that hide house keys. It’s doubtful the average burglar will realize you’ve hidden your key in plain sight. If one does stumble (perhaps literally) upon the imitation rock, your entire security system falls apart, and the robber has the key to your kingdom.

In the security world, our distaste for security by obscurity originates from an old cryptographer’s axiom called Kerckhoff’s principle, which proposes that a cryptosystem should remain secure even if the attacker knows exactly how the system works. (We're assuming the attacker doesn’t have the “key” to the system.) There’s no doubt this axiom holds true. The best security systems are ones that attackers fully understand, but still can’t break without the proper keys or credentials. For instance, bank robbers may totally understand how a vault door works, but they can’t open one without a disproportionate amount of time, tools, and effort -- or the actual combination to the vault. That’s why most of your defenses should rely on securely engineered systems, and not on obscurity.  

However, that doesn’t mean obscurity doesn’t hold some value. In fact, I believe, as an industry, we’ve given security by obscurity too bad of a name. Combined with proven security controls, obscurity offers valuable additional protection, creates a worthy layer to a defense-in-depth strategy and can pose significant speed bumps to an attack, causing hackers to move on to softer targets. It’s kind of like that popular joke about the bear chasing a group of people. You don’t have to run faster than the bear to survive, only faster than the slowest member. A little obscurity might just give you the boost you need to “outrun” your peers’ defenses.

So let’s talk concrete examples. Here are three practices many consider security by obscurity, but I think actually could supplement your defenses:

Changing a server’s default port
Internet and network services tend to run on common, default ports. For instance, SSH is port 22, Telnet is 23, RDP is 3389, and so on. However, there is nothing stopping you from changing these default ports. If you want your SSH server to listen on port 7624, it can. This simple change will make it harder to find by automated network scans. Sure… this is security by obscurity. Smart, persistent attackers targeting your network can still use full-range port scans and fingerprinting techniques to find your SSH server. However, a huge percentage of the malicious ports scans on the Internet are targeting common server ports. So this simple obfuscation can help.

Server header masquerading
Unfortunately, servers are a little too friendly, often totally identifying themselves in their reply headers. For instance, a Web server reply contains a Server: header, where it identifies what software and version it’s running. Here’s an example: 

Server: Apache/2.2.8 (Ubuntu) PHP/5.2.4-2ubuntu5.6 with Suhosin-Patch mod_ssl/2.2.8 OpenSSL/0.9.8g

That header is gold to an attacker, who now knows exactly what software your server runs, including any additional packages. If any of that software is unpatched, the attacker might have his way in. You can change this. Many servers have configuration options that allow you to share less information about the server version. There are also network security tools that totally masquerade these server headers. A security stickler will argue that if you keep your servers patched and hardened, it won’t matter if an attacker knows what software they run. I say, patch and harden your servers, but go ahead and masquerade their headers too, making them a bit harder to enumerate.

Use non-standard naming conventions
Operating systems and servers often have default users and groups. Why not rename them? Rename the default “administrator” username to “neo,” or whatever else floats your boat. A smart attacker may still be able to discover how you renamed all the default users and groups, but any attack tools or scripts that rely on default installs will fail to operate.

I could go on with worthwhile obscurity examples, but you get the point.

By itself, security through obscurity is not good. However, obscurity can bolster your defenses when added as a complementary layer to a true security control. Remember that fake rock ? It only offers the illusion of defense, since the burglar easily has access to your key if he finds your hidden rock. Now imagine that same fake rock, but with a combination lock. Though the lock is the only true security control, coupling the lock with the hidden rock presents a very strong security solution. While I may not want to live without my lock, I also don’t see why I should leave it in plain sight.

What do you think? Does obscurity have any place as a complementary layer of your security strategy, or is it a waste of time and effort? Let us know in the comments section. 

Corey Nachreiner regularly contributes to security publications and speaks internationally at leading industry trade shows like RSA. He has written thousands of security alerts and educational articles and is the primary contributor to the WatchGuard Security Center blog, ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Oldest First  |  Newest First  |  Threaded View
Page 1 / 3   >   >>
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
User Rank: Strategist
4/17/2014 | 10:10:49 AM
Good examples but do they work?
Thanks for those simple obfuscations, Corey. Wondering if you've tried them out in practice.
gkchat
50%
50%
gkchat,
User Rank: Apprentice
4/17/2014 | 10:29:24 AM
slows down an attack -- so it helps
It seems like you are reacting to the overuse of a good idea.  The good idea is that you have to put your energy into fixing the basic security of your system and NOT rely on obscurity.  A determined bad guy will still find your changed port number, or the name of your administrator group.

In my security training, we were taught not to give away any unnessary information that tells an attacker how the system works.  That header information you mention would be a big no-no.  So are exception traces that emit to the end-user.  Error messages are there to help the user, but should avoid giving away too much system design information.  One might argue that this is also security by obscurity.  I would disagree.  A system might have many vulnerabilities that are 'unknown' until an attack is crafted that bypasses the security I've set up.  The less I tell an attacker about my system, the less likely that they can find those 'open' doors between the time an attack is discovered and the time I can patch my system.

We sometimes tend to forget that our 'bad guys' are using computers too.  They have invested in automation and the more we 'follow convention', the easier it is for them to try their 'key' in thousands of virtual doors.
David F. Carr
50%
50%
David F. Carr,
User Rank: Strategist
4/17/2014 | 10:49:36 AM
Custom platforms another example of security by obscurity
There's also some security benefit from using a custom platform, such as a homegrown content management system instead of WordPress. WordPress has the advantage of being tested constantly by those trying to break it (maliciously or not), so security flaws tend to be found and patched -- which is good as long as you can keep up with the patches. Even then, hackers know that the login url is likely to be www.somedomain.com/wp-admin/ so they can throw brute force attacks against that and other known addresses like the one for sending trackbacks. A custom system may have more latent flaws, but they won't be as widely known as with a popular open source software platform.
kobrien82
50%
50%
kobrien82,
User Rank: Apprentice
4/17/2014 | 12:55:03 PM
Know your risks first
Interesting article, Corey. Something to consider here is that there is a distinction between obscurity, where you rely upon the use of an unknown or custom system to trip up a tracker, and a defensive posture where you don't emit system details without cause.

However, it's also worth looking at what risks you're protecting against. If you're describing a strategy for protecting your servers, it makes total sense to not expose your Apache patch level; if you're looking at an infosec program for your data stored in a public cloud platform (say, Google Apps) from leak, obscurity isn't nearly as sensible a strategy. In general terms, outsider threat is defended against via (amongst other things) an approach of least information exposure; insider risk is mitigated by clarity and classification that helps avoid unintentional breach or leak. 
CNACHREINER981
50%
50%
CNACHREINER981,
User Rank: Author
4/17/2014 | 1:19:48 PM
Re: Know your risks first
That is an excellent point! When relying on someone elses' systems (the cloud) obscurity is NOT good. We need transparency in what tactics and strategies our external partners are using to protect out data...

But in that sense, the external partner becomes an extension of ourselves. I wouldn't argue we obscure things from trusted parties, only from truly untrusted attackers.

Thanks for you thoughts!

Corey
CNACHREINER981
50%
50%
CNACHREINER981,
User Rank: Author
4/17/2014 | 1:25:49 PM
Re: Custom platforms another example of security by obscurity
I absolutely agree... However, to be devils advocate to this point (and my own article), I think this will only be the case if you have security conscious and trained folks creating the custom systems. Since they are blackboxes, custom systems are more difficult for an attacker to enumerate. However, the arguement against them is sometimes the folks creating custom systems aren't necessarily the best secure coders or designers. Because of its popularity and past issues, Wordpress has had to spend time and money learning about secure design... Another example is when non-cryptologists try to roll their own encryption. It usually ends in disaster..

However, it's kind of like the hidden rock WITH the combination lock example. If you have folks who are experts at secure design, and you use them to create a custom system, you have the benefit of both layers. The secure design limits the true vulnerabilities in the system, and the fact that it's custom adds that extra layer that makes it hard (and thus less ROI for the attacker) to figure out!

Cheers,

Corey
CNACHREINER981
50%
50%
CNACHREINER981,
User Rank: Author
4/17/2014 | 1:27:16 PM
Re: slows down an attack -- so it helps
Yep... we agree. The best security is securely designed systems, but there is no point in making those systems easy to find. ^_^

 

Corey
mwalker871
50%
50%
mwalker871,
User Rank: Guru
4/17/2014 | 1:28:27 PM
Security v. Obscurity
Better to deride obscurity than end up back where we started: Obscurity is Security
David F. Carr
50%
50%
David F. Carr,
User Rank: Strategist
4/17/2014 | 1:39:22 PM
Re: Custom platforms another example of security by obscurity
One site I converted to WordPress previously ran on a CMS of sorts that you could edit by going to www.mydomain.com/data/ - no password required, pure security by obscurity. So compared with that, WordPress was certainly a huge improvement.
CNACHREINER981
50%
50%
CNACHREINER981,
User Rank: Author
4/17/2014 | 1:44:48 PM
Re: Security v. Obscurity
I can see that point. So many have relied ONLY on security by obscurity (which IS bad) for protection that it is probably good to hammer that idea out of a Infosec neophyte's head... However, I still think the more exprienced infosec folk, who realize that their primary defense needs to be true secure design, can add some obscurity to the mix too... ^_^
Page 1 / 3   >   >>
COVID-19: Latest Security News & Commentary
Dark Reading Staff 7/6/2020
Ripple20 Threatens Increasingly Connected Medical Devices
Kelly Sheridan, Staff Editor, Dark Reading,  6/30/2020
DDoS Attacks Jump 542% from Q4 2019 to Q1 2020
Dark Reading Staff 6/30/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
How Cybersecurity Incident Response Programs Work (and Why Some Don't)
This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
Flash Poll
The Threat from the Internetand What Your Organization Can Do About It
The Threat from the Internetand What Your Organization Can Do About It
This report describes some of the latest attacks and threats emanating from the Internet, as well as advice and tips on how your organization can mitigate those threats before they affect your business. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-15570
PUBLISHED: 2020-07-06
The parse_report() function in whoopsie.c in Whoopsie through 0.2.69 mishandles memory allocation failures, which allows an attacker to cause a denial of service via a malformed crash file.
CVE-2020-15569
PUBLISHED: 2020-07-06
PlayerGeneric.cpp in MilkyTracker through 1.02.00 has a use-after-free in the PlayerGeneric destructor.
CVE-2020-7690
PUBLISHED: 2020-07-06
It's possible to inject JavaScript code via the html method.
CVE-2020-7691
PUBLISHED: 2020-07-06
It's possible to use <<script>script> in order to go over the filtering regex.
CVE-2020-15562
PUBLISHED: 2020-07-06
An issue was discovered in Roundcube Webmail before 1.2.11, 1.3.x before 1.3.14, and 1.4.x before 1.4.7. It allows XSS via a crafted HTML e-mail message, as demonstrated by a JavaScript payload in the xmlns (aka XML namespace) attribute of a HEAD element when an SVG element exists.