Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Defence in Depth, Part 2 - Security Before Obscurity

DZone's Guide to

Defence in Depth, Part 2 - Security Before Obscurity

Think your system is safe because you've added a few layers of obscurity into it? Think again. A cybersecurity expert explains why.

· Security Zone ·
Free Resource

Discover how to provide active runtime protection for your web applications from known and unknown vulnerabilities including Remote Code Execution Attacks.

Failsafe Defaults

Software is bound to fail. Try as we might to create perfect, failure-resistant software, bugs will always exist that might cause software to fail. Notwithstanding this, it is important that this potential failure does not expose an application to a security risk.

An application should feature secure defaults, deny access to resources by default, check returned values for failure, and make sure that conditional code or filters properly handle failure.

Critically, even though some part of the application is not available, or is functioning unexpectedly, it should not be possible for an attacker to compromise the confidentiality or integrity of an application.

Security Before Obscurity

Security through obscurity refers to the use of obfuscation or randomization of a design or implementation to provide security. With this in mind, it becomes obvious that the security of a system relying solely on obscurity, rather than the implementation of sound security devices, is destined for failure.

Take, for instance, an SSH daemon configured to listen on a port other than the standard port 22. While that may deter a script-kiddie, this obscurity is going to be of little protection against a financially motivated attacker who would not only discover the SSH daemon on the unconventional port but also notice a series of known and exploitable high-severity vulnerabilities in that daemon.

While obscurity can be used as a defense in depth measure (since it would increase the efforts an attacker needs in order to break into a system), it should never replace real security controls. As such, when obscurity is implemented, it should only be used to increase the cost of attack, and it should always be assumed that a savvy attacker can identify the obscurity and overcome it.

Find out how Waratek’s award-winning application security platform can improve the security of your new and legacy applications and platforms with no false positives, code changes or slowing your application.

Topics:
security ,security best practices ,security design

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}