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.

Vulnerabilities / Threats

10:15 AM
Jeff Williams
Jeff Williams
Connect Directly
E-Mail vvv

Why We Can't Afford To Give Up On Cybersecurity Defense

There is no quick fix, but organizations can massively reduce the complexity of building secure applications by empowering developers with four basic practices.

Cybersecurity is in the news all the time these days. The leading cause of these breaches is, unsurprisingly, insecure software. As Yahoo’s CISO Alex Stamos put it, “application security is eating security.” Are you surprised to know that only a mere 4% of security spending is allocated to improving in this area?

There are those who argue we should forget about cyberdefense and put all our effort into attack detection, or so-called “attack back” strategies. Nonsense. Anyone who has played even a few minutes of Plants vs. Zombies knows that you have to have a balanced approach. If your barn doors are open, your first priority is to put basic defenses in place.

Why can’t we build secure software? A better question might be why aren’t we spending all our resources getting better at writing secure code? The answer is that it’s not as easy as it seems. Many executives don’t fully understand the massive complexity of our critical software infrastructure and tend to assign blame to individuals rather than accepting that their culture doesn’t encourage security. So, many organizations go for a quick fix instead of doing the work to nurture security thinking in their culture.

Go After Attackers?
The knee-jerk reaction is to focus on the attacker. Every CEO has a press conference the day after their organization gets exploited and blames the attack on an advanced persistent threat. This PR maneuver is intended to assure the public that the organization’s defenses are sound and only a well-funded state-sponsored attack team could have exploited them successfully. Unfortunately, it’s much more likely that it was a relatively unskilled, lone attacker who will never be identified.

Sony’s breach demonstrated the inherent difficulty knowing who the cyberattackers actually are. Was it Russia? Was it China? This challenge is known as the “attribution problem” and we are nowhere close to solving it. So while cracking down on cyberattackers and even “hacking back” sound appealing in “get tough” political speeches, nothing will happen until we make progress in attribution.

Better Intrusion Detection?
Another popular way to avoid the work of actually securing things is to say we just need more effective intrusion detection and prevention. The argument is if we stop attacks from getting in, then it doesn’t matter if our code is riddled with vulnerabilities.

The problem is that detecting all but the simplest attacks requires knowledge of where the vulnerabilities are. For example, consider a URL like http://targdepot.com/store?tgt=14343. That’s what your IDS/IPS technology will see on the wire.

Is it an attack? Well it really depends on the application that’s being protected. That “tgt” parameter could reference an unauthorized account, or cause the application to crash, or delete all users, or kill the database connection pool, denying everyone access to the website. No IDS/IPS could possibly identify any of these as an attack because these tools lack sufficient context.

Blame the Developers?
Another response is to blame developers or accuse them of not caring about security. But it’s not true. Aspect Security has taught over 20,000 developers about security and the vast majority were interested, even animated, about learning how to do it right. Nevertheless, developers are busy, and expecting them to also become application security experts isn’t reasonable.

So, instead of blaming attackers and developers, let’s focus on a few things organizations can to enable developers to build secure software. It’s not a shortcut or quick fix, but we can massively reduce the complexity of building secure applications with four simple practices:

Best Practice #1: Use Standard Defenses. One way to help simplify the problem is to provide developers with standard application defenses. Many organizations have libraries, frameworks, and products that defend against one threat or another. Encryption and logging libraries are very common. Validation and encoding libraries are also fairly popular. Authentication and access control are more often provided by an external gateway.

Would it surprise you to know that many organizations still haven’t standardized their security defenses? When every application has its own custom defenses, it virtually guarantees security vulnerabilities. Building strong security defenses is difficult, and requires more stringent testing than ordinary code. Many people say, “Don’t write custom encryption.” This mandate must be extended to ALL security defenses.

Best Practice #2: Continuously Verify that Defenses Are “Correct.” Whether you write your own standard defenses, use open source implementations, or purchase products, these defenses need to be continuously verified for correctness. That means that they are properly implemented, and can’t be bypassed or tampered with. They should also be easy to understand and use properly.

Many organizations perform security testing on their applications, but don’t think to test their standard security defenses. The defenses get partially tested as part of each application, but are never subject to direct scrutiny. Given the critical nature of this code, it deserves rigorous testing.

Best Practice #3: Verify Applications Are Using Defenses Properly.  Simply having a bunch of strong defenses isn’t enough. Developers need to use these defenses properly and in all the right places. This means establishing a verification program that continuously ensures this is happening. Most application security programs try to solve the very hard problem of proving that there are no vulnerabilities in the software being produced. Verifying that the right defenses are in place and being used is easier and provides more assurance. This depends on having a great threat model so you know what defenses are supposed to be in place.

Best Practice #4: Provide Training and Support for Defenses. Lastly, you can nurture and encourage your security culture by providing training and support for your standard defenses. Training that specifically talks about your standard defenses connects security back to every developer’s job. Developers won’t spend time reinventing input validation for the 900th time, and can instead focus on their business requirements.

How Mature Are Your Standard Security Defenses?
Try filling out this chart for your organization. In the first column, list the exact components or modules that provide the security defense function (a few examples of common components are provided). Give yourself a check in the second column if you have evidence that each specific defense has been tested for security. The third column is if you routinely check applications for use of the standard defense. And the last column covers whether you have training and support for the defense.

If you’re not providing your developers with a complete set of defenses, it’s likely that they will be forced to create their own and will make the same mistakes that others have made before them. It’s simply unreasonable to expect your developers to create secure code without giving them the building blocks they need to succeed. Investing in a strong set of defenses will make your development teams more agile and your enterprise more secure.

A pioneer in application security, Jeff Williams is the founder and CTO of Contrast Security, a revolutionary application security product that enhances software with the power to defend itself, check itself for vulnerabilities, and join a security command and control ... View Full Bio

Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
Joe Stanganelli
Joe Stanganelli,
User Rank: Ninja
5/23/2015 | 11:38:54 PM
Low-tech security culture
To speak of training and security culture, it really touches all levels of the organization -- and information security should be top of mind even in low-tech contexts.  (After all, social engineering is the skilled hacker's top choice when it comes to finding weaknesses.  All it takes is a slip-up during a phone call.)
User Rank: Ninja
5/19/2015 | 8:18:08 AM
White List Thinking
We need a "Sea Change" to Whitelist Thinking.

it is necessary to authenticate many messages, certainly those dealing with money, -- or software.

The Essential Element to this change in thinking deals with the symmetric nature of our customary identification data.   Name, address, date of birth, Social Security Number -- even Company Letterhead Stationary -- can all be easily compromised in the digital world.   These keys -- once released in public -- are compromised forever.   In this they act like the symmetric keys used on basic encryption where the decryption key is the same as the encryption key: a shared secret.

The trouble is our traditional identification data are a shared secred -- with everyone in on it.   See KREBS essay on "Superget" -- a DarkWeb service selling these symmetric keys

this is why we need to move to the general use of PGP

PGP is based on asymmetric keys: the signing key is private and the authentication key is public.   This means you can produce an authenticated document in public -- without compromising your identity -- i.e. your private key

many detractors claim this is too complicated for ordinary people.  This is a myth that needs to be dispeled. As packaged technology it is no more difficult to use PGP than it is to use the PIN on a debit card to get cash from an ATM.   Practice using the ENIGMAIL plug-in for the Thunderbird eMail client.

There are two keys to progress in fighting hacking

1. use a secure operating system.   A secure operating system is one which will not allow itself to be compromised by the activity of an application program -- such as a web page.

2. authenticate transactions -- including software downloads, eMail, tax forms &c -- using PGP

Half-way measures have been ineffective.   It's time to recognize hacking as a problem that must be addressed in a serious manner.

BPID Security
BPID Security,
User Rank: Strategist
5/18/2015 | 8:11:52 PM
well done.
Thanks for a well considered and well written post.


As always we want easy. We don't want maintenance. We want things to work so we don't have to. So we buy cars with low maintenance and trade them out on a lease, our phones are disposable when the 32 year contract is up, and we expect internet security should work out of the box.

Jeff, it is just the way it is. Our entire modern culture is avoidance and avoiding responsibility.

Good article - excellent points, but it isn't about to change. We will continue to drive and talk on our cell phones and we will continue to ignore best practices in security and when there is a breach we will point fingers.

Thanks again. good post.
A Startup With NSA Roots Wants Silently Disarming Cyberattacks on the Wire to Become the Norm
Kelly Jackson Higgins, Executive Editor at Dark Reading,  5/11/2021
Cybersecurity: What Is Truly Essential?
Joshua Goldfarb, Director of Product Management at F5,  5/12/2021
3 Cybersecurity Myths to Bust
Etay Maor, Sr. Director Security Strategy at Cato Networks,  5/11/2021
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-05-18
In Boostnote 0.12.1, exporting to PDF contains opportunities for XSS attacks.
PUBLISHED: 2021-05-18
Mikrotik RouterOs prior to stable 6.47 suffers from a memory corruption vulnerability in the /nova/bin/bfd process. An authenticated remote attacker can cause a Denial of Service (NULL pointer dereference).
PUBLISHED: 2021-05-18
Mikrotik RouterOs stable 6.47 suffers from a memory corruption vulnerability in the /nova/bin/diskd process. An authenticated remote attacker can cause a Denial of Service due to invalid memory access.
PUBLISHED: 2021-05-18
Mikrotik RouterOs stable 6.46.3 suffers from a memory corruption vulnerability in the log process. An authenticated remote attacker can cause a Denial of Service due to improper memory access.
PUBLISHED: 2021-05-18
Mikrotik RouterOs stable 6.46.3 suffers from a memory corruption vulnerability in the mactel process. An authenticated remote attacker can cause a Denial of Service due to improper memory access.