Vulnerabilities / Threats

5/18/2015
10:15 AM
Jeff Williams
Jeff Williams
Commentary
Connect Directly
Twitter
LinkedIn
Google+
RSS
E-Mail vvv
50%
50%

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
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Joe Stanganelli
50%
50%
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.)
macker490
50%
50%
macker490,
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
50%
50%
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.
Want Your Daughter to Succeed in Cyber? Call Her John
John De Santis, CEO, HyTrust,  5/16/2018
Don't Roll the Dice When Prioritizing Vulnerability Fixes
Ericka Chickowski, Contributing Writer, Dark Reading,  5/15/2018
Why Enterprises Can't Ignore Third-Party IoT-Related Risks
Charlie Miller, Senior Vice President, The Santa Fe Group,  5/14/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: "Security through obscurity"
Current Issue
Flash Poll
[Strategic Security Report] Navigating the Threat Intelligence Maze
[Strategic Security Report] Navigating the Threat Intelligence Maze
Most enterprises are using threat intel services, but many are still figuring out how to use the data they're collecting. In this Dark Reading survey we give you a look at what they're doing today - and where they hope to go.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-11311
PUBLISHED: 2018-05-20
A hardcoded FTP username of myscada and password of Vikuk63 in 'myscadagate.exe' in mySCADA myPRO 7 allows remote attackers to access the FTP server on port 2121, and upload files or list directories, by entering these credentials.
CVE-2018-11319
PUBLISHED: 2018-05-20
Syntastic (aka vim-syntastic) through 3.9.0 does not properly handle searches for configuration files (it searches the current directory up to potentially the root). This improper handling might be exploited for arbitrary code execution via a malicious gcc plugin, if an attacker has write access to ...
CVE-2018-11242
PUBLISHED: 2018-05-20
An issue was discovered in the MakeMyTrip application 7.2.4 for Android. The databases (locally stored) are not encrypted and have cleartext that might lead to sensitive information disclosure, as demonstrated by data/com.makemytrip/databases and data/com.makemytrip/Cache SQLite database files.
CVE-2018-11315
PUBLISHED: 2018-05-20
The Local HTTP API in Radio Thermostat CT50 and CT80 1.04.84 and below products allows unauthorized access via a DNS rebinding attack. This can result in remote device temperature control, as demonstrated by a tstat t_heat request that accesses a device purchased in the Spring of 2018, and sets a ho...
CVE-2018-11239
PUBLISHED: 2018-05-19
An integer overflow in the _transfer function of a smart contract implementation for Hexagon (HXG), an Ethereum ERC20 token, allows attackers to accomplish an unauthorized increase of digital assets by providing a _to argument in conjunction with a large _value argument, as exploited in the wild in ...