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://ift.tt/1R0TSBb. 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.
View the original content and more from this author here: http://ift.tt/1R0TQJs
from cyber security caucus http://ift.tt/1FskCXf
via IFTTT
No comments:
Post a Comment