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.

Comments
How A Little Obscurity Can Bolster Security
Threaded  |  Newest First  |  Oldest First
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.
CoreyNach
50%
50%
CoreyNach,
User Rank: Apprentice
5/27/2014 | 5:59:28 PM
Re: Good examples but do they work?
I've used different server ports and server header masking a lot throughout the years. For one, I work for a company whose product does header masking... (our HTTP, SMTP, FTP, etc... proxies all strip and replace server headers to make it harder to identify the software behind them).... And I've changed ports on some of the server that I don't want public.. That said, I don't rely on port changing... usually if I really don't want public access to servers, I also control access in other ways too (require VPN, restrict to certain IPs only, etc...)
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.
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
samenk
100%
0%
samenk,
User Rank: Apprentice
4/17/2014 | 7:39:10 PM
Re: slows down an attack -- so it helps
Great article here, Corey! Security by obscurity should only be used as a method to delay and/or discourage the attackers from compromising our security; nothing more. "Security by Obscurity is no security at all." I agree, however, I do think offers some level of security and should be utilized, but should never be fully relied upon. In most cases, security engineers would utilize obscure measures as first layer(s) of security; if the attacker does uncover the inconspicuous security measure, he is sure to meet a tougher one, such as encryption, or authentication.
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.
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
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.
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
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
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... ^_^
mwalker871
50%
50%
mwalker871,
User Rank: Guru
4/17/2014 | 3:18:48 PM
Re: Security v. Obscurity
Sure, don't give anything away.
Don't pick names easy to guess or commonly used. Passwords are just the final threshold.

However, if your domain can be enumerated, the ship has sailed.

Which is more important?
gnummy
50%
50%
gnummy,
User Rank: Apprentice
4/28/2014 | 6:03:54 PM
Re: Security v. Obscurity
Great Post, well worded.  Definitely a great idea to include this along with other measures, I have seen several examples of this working well e.g. a huge zero day outbreak affects a large number of organisations except for the guy who simply changed the default service port e.t.c.
samenk
50%
50%
samenk,
User Rank: Apprentice
4/17/2014 | 7:42:55 PM
Re: How A Little Obscurity Can Bolster Security
Great article here, Corey! Security by obscurity should only be used as a method to delay and/or discourage the attackers from compromising our security; nothing more. "Security by Obscurity is no security at all." I agree, however, I do think offers some level of security and should be utilized, but should never be fully relied upon. In most cases, security engineers would utilize obscure measures as first layer(s) of security; if the attacker does uncover the inconspicuous security measure, he is sure to meet a tougher one, such as encryption, or authentication.

 
stephenq42
0%
100%
stephenq42,
User Rank: Apprentice
4/17/2014 | 9:51:42 PM
We rely on Security through Obscurity
Everyone who has a user account on any system relies on security through obscurity.

 

Consider the user ID/password combination.  One component (the ID) may or may not be obscure, but the second (the password) better be.  I  have always been amused that the very security professionals who state that we must not disclose our passwords (keep them obscure) are the ones who also say "Security by obscurity is no security."
przem
50%
50%
przem,
User Rank: Apprentice
4/18/2014 | 12:29:38 PM
Re: We rely on Security through Obscurity
You are misunderstanding the phrase. 'obscurity' in this context refers to relying on secreting the details of the security mechanism. The big difference is that if you have a reason to suspect your security arrangements,  you can change the password, and restore full security. This is not the case for a 'security by obscurity' system: once broken it stays broken.
Robert McDougal
100%
0%
Robert McDougal,
User Rank: Ninja
4/18/2014 | 5:05:46 PM
Great Article
Great points Corey!

 

I don't see anything wrong with security by obscurity when used in conjunction with a secure system.  By making your systems appear to be smaller targets you are essentially eliminating any "cybercrime of opportunity". 

To make use of a simple analogy a secure system without obscurity is akin to a car with windows rolled up and system armed complete with your wallet on the front seat.  Any passing thief can see your wallet but they also have to deal with your car windows and alarm to get to their prize.  However, if they want the wallet they will try to break in.

Conversely, a secure system with obscurity is the exact same car armed and locked tight with the wallet hidden in the glove box.  The would be thief can see a car locked up tight that "may" contain a wallet but they don't know for sure.  Therefore most thieves will keep on walking looking for a better target to capitalize upon.

Lastly, a system which exclusively relies upon obscurity for security is a bad idea.  An analogy for this system is a car with the windows rolled down alarm off and wallet stored in the glove box.  If the opportunity to poke around is there someone will take advantage of it. 
CNACHREINER981
50%
50%
CNACHREINER981,
User Rank: Author
4/18/2014 | 5:25:38 PM
Re: Great Article
Perfect analogy, and exactly my point summed up fantastically!
theb0x
50%
50%
theb0x,
User Rank: Ninja
4/22/2014 | 12:30:54 PM
Re: How A Little Obscurity Can Bolster Security
I have always liked the old saying "A locked door keeps an honest man out."

 

 
anon9675841497
50%
50%
anon9675841497,
User Rank: Apprentice
5/24/2014 | 1:56:06 PM
Ports
Changing the default ssh port on my servers reduced the attempted logins by 90%.
xennemans
50%
50%
xennemans,
User Rank: Apprentice
8/6/2014 | 11:58:58 AM
Agree completely
Access control security and capability-based security are orthogonal.

That means they are complementary, like the yin and the yang, the masculine and the feminine.

In the same way, you would protect your systems on your network each themselves, but you also make sure no one can reach them if you don't need them to be able to be reached. Those things are also orthogonal.

In IPv6, the idea seems to be that we don't need network encapsulation anymore (NAT) because some moron says "most attacks are coming from application vulnerabilities anyway". But protecting your systems (internally) is orthogonal to not letting outside attackers in without invitations (a firewall) - you can do both at the same time, independent of one another (that's what orthogonal means).

So these are two different directions or dimensions and you can travel both whenever you like, both at the same time, only one and not the other, etcetera.

You can bolster your credentials-that-are-bound-to-one-user based model and at the same time bolster your "you are in unknown territory friend, and I have the upper hand here" model.

It is utterly foolish to suggest that a system needs to be secury only by way of its essential technical design.

A thief that knows a map of your palace will be a much harder threat than someone accidentally stumbling in.

Any thief knows this, so why don't the guards??

Technical open source systems are by definition vulnerable to mass exploits.

Obfuscated systems are, by definition, not.

At the same time, obfuscated systems are vulnerable to single-point attacks. Open source systems are not more vulnerable to those kinds of attacks, than to mass attacks.

Therefore you use both kinds of defense at the same time, and you use both of them to your maximum extent or capability.

 


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-15505
PUBLISHED: 2020-07-07
MobileIron Core and Connector before 10.3.0.4, 10.4.x before 10.4.0.4, 10.5.x before 10.5.1.1, 10.5.2.x before 10.5.2.1, and 10.6.x before 10.6.0.1, and Sentry before 9.7.3 and 9.8.x before 9.8.1, allow remote attackers to execute arbitrary code via unspecified vectors.
CVE-2020-15506
PUBLISHED: 2020-07-07
MobileIron Core and Connector before 10.3.0.4, 10.4.x before 10.4.0.4, 10.5.x before 10.5.1.1, 10.5.2.x before 10.5.2.1, and 10.6.x before 10.6.0.1 allow remote attackers to bypass authentication mechanisms via unspecified vectors.
CVE-2020-15507
PUBLISHED: 2020-07-07
MobileIron Core and Connector before 10.3.0.4, 10.4.x before 10.4.0.4, 10.5.x before 10.5.1.1, 10.5.2.x before 10.5.2.1, and 10.6.x before 10.6.0.1 allow remote attackers to read files on the system via unspecified vectors.
CVE-2020-15096
PUBLISHED: 2020-07-07
In Electron before versions 6.1.1, 7.2.4, 8.2.4, and 9.0.0-beta21, there is a context isolation bypass, meaning that code running in the main world context in the renderer can reach into the isolated Electron context and perform privileged actions. Apps using "contextIsolation" are affecte...
CVE-2020-4075
PUBLISHED: 2020-07-07
In Electron before versions 7.2.4, 8.2.4, and 9.0.0-beta21, arbitrary local file read is possible by defining unsafe window options on a child window opened via window.open. As a workaround, ensure you are calling `event.preventDefault()` on all new-window events where the `url` or `options` is not ...