5 best practices from the app sec front lines
Recent security reports by Verizon and Alert Logic, among others, show that attacks on web applications have increased and now account for a majority of the security incidents organizations experience.
The trend has pushed many enterprises into launching application security initiatives to prevent, detect, and fix vulnerabilities in software, beginning with the code development stage and running throughout the lifecycle of applications. More than 80% of respondents to a SANS Institute survey of 475 technology executives said their organizations have already made application security part of their risk management process.
The widening adoption of DevOps and rapid development practices has lent urgency to those efforts. These trends have also focused attention on the need for organizations to unite their security, development, and operations teams under a common application security mission.
Here are five strategies that experts say will bolster your application security program.
1. Implement a DevSecOps approach
One of the biggest mistakes enterprises make in application security is focusing solely on the development organization, said Kunal Anand, CEO of Prevoty.
Organizations are increasingly moving away from waterfall release models to rapid development cycles, where code is released on a monthly, weekly, daily, or even hourly basis.
When the emphasis is on getting code out that quickly and continuously, security may be seen as an impediment and given short shrift if you don't have the proper processes in place. So, increasingly, there's a need to bring the security, development, and operations groups together under a common DevSecOps umbrella.
A company's internal politics can create artificial silos. The result is an organization where security, development, and IT operations teams aren't talking to each other, Anand said.
"Simply put, not talking about security across important teams is a fast way to fail."
Implementing a DevSecOps approach ensures that security, development, and IT Ops teams are working toward a common security goal, said Ryan O'Leary, vice president of WhiteHat Security's threat research center and technical support.
Development wants to get code out as fast as it possibly can. Operations wants stable releases that don’t impact uptime and system stability, and security wants code that's free from vulnerabilities, he said.
"If these departments are separated, they each have separate priorities."
It is impossible to align these priorities when each group is tasked with its own mission. It is more effective to combine them, O'Leary said.
2. Get your developers up to speed on security, stat
Secure coding is not a skill many developers have because until relatively recently it wasn't even on their radar. Few developers are formally taught security principles or are held to secure coding standards.
In a survey of 397 developers and IT professionals sponsored by Veracode earlier this year, 68% said their organizations did not provide adequate application security training. Some 86% said their organizations did not spend enough on training developers to code securely.
"Many qualified developers tend to ignore 'minor'—in their perception—flaws, such as XSS [cross-site scripting] or XSRF [cross-site request forgery], putting the entire application at risk," said Ilia Kolochenko, CEO of web security firm High-Tech Bridge. "Others candidly believe that if they have a WAF [web application firewall] or RASP [runtime application self-protection], no code security is ever required."
Training developers regularly on new attack techniques and exploitation vectors is therefore essential to application security, Kolochenko said. Security and quality assurance policies need to be promulgated among the team to make development standards unambiguous and clear for everyone, he explained. Fair but strict sanctions for overt and repetitive violations can help, as can bonuses for teams with the most secure code, he said.
Consider making secure development a part of new-hire training for developers. Give people incentives to write secure code, added WhiteHat's O'Leary.
Gamification of secure coding practices, for instance, is a great way to encourage developers. Maintain some kind of a scoreboard for tracking developers to see which have the least vulnerabilities and security defects in their code.
"Developers should feel a sense of pride in writing secure applications, because it's they who can prevent bad guys from successfully attacking their site,"
3. Adopt defensive coding practices
Even without formal security training, developers can take some basic precautions to ensure that the code they are writing does not contain commonly exploited errors.
"If you are writing an application that processes untrusted input, like a web browser, it is very easy as a developer to assume that the data you are getting is well-formed and you can parse it very quickly," said Owen Garrett, head of products at NGINX.
"Defensive coding assumes that every bit of input is invalid."
With defensive coding, you distrust everything you are given. A good developer will go to great lengths to make sure that everything is in the right place when handling any input or request, he said.
Defensive coding practices can result in code getting slightly more complex, Garrett conceded. But it generally is a good practice to have code that can whitelist what you know is good instead of blacklisting what you think is bad, he said.
At its core, defensive programming is all about thinking how an attacker might leverage errors and vulnerabilities in the application and then coding the app to prevent those from occurring, O'Leary said.
"It's almost like you're getting into the mindset of an attacker, looking at the layout of the application, and making sure anything that the bad guy could do to exploit the application is prevented."
4. Test early, test often using SAST and DAST
Static and dynamic application security testing are both essential to application security. Many organizations make the mistake of assuming that they can get away with conducting either static or dynamic testing. The reality, said WhiteHat's O'Leary, is that they test the application in entirely different ways.
Static application security testing (SAST) is best employed during the development phase, as code is written. The kind of vulnerabilities that static tests reveal is usually easier to remediate and takes less time to fix that are issues unearthed later in the development lifecycle.
Dynamic application security testing (DAST) is what you do when your application is in production and already being used. The errors that show up during dynamic tests are the kinds of vulnerabilities that malicious attackers are looking for as well. So the stakes are much higher.
Using just SAST can leave your production environment pretty vulnerable, O'Leary said. "Production is really what you care the most about. It needs to be constantly tested for vulnerabilities, as the bad guys are likely not hacking your QA environment. They're going after production," he said.
But ignoring SAST entirely and focusing just on DAST is a big no-no as well, he said. Having only DAST means that you're scanning your applications late in the development cycle, where the cost of making fixes is higher.
And there's always the potential that you'll release a bunch of vulnerabilities into production because you didn't look for them in development.
"Both find completely different issues, and you really need both to secure your applications entirely."
5. Develop good processes for change and exception management
Frequent updates and feature additions are a hallmark of rapid development environments. One way to ensure that updates don't end up breaking applications and disrupting operations is to adopt a gradual rollout process, said Yoav Cohen, vice president of research and development at Imperva.
Imperva has established a change-control board comprising individuals from its operations, security, product, and development teams. The board determines the updates and features to include in the company's weekly production rollout. The updates then go through a final QA process before gradually rolling out in four stages, starting with updates to a single server and gradually ramping to servers across the organization. The approach lets users quickly isolate an issue or shut down a problematic update, Cohen explained.
Sometimes, a product or feature might need to ship to production with known vulnerabilities, with the understanding that fixes will come in future releases, said Prevoty's Anand. Having good processes for exception management is critical to ensuring that this doesn't pose a problem.
"The reality is that few teams get the opportunity to go back and fix things. New code can become legacy code in a matter of weeks.”
Organizations practicing exception management should consider tools for identifying vulnerabilities in production apps and prioritizing fixes for the ones that are being exploited, he said.
Continuous app sec
Security is no longer something that can be bolted onto an application at the end of the development cycle. The adoption of DevOps and practices such as continuous integration, continuous delivery, and continuous distribution has greatly accelerated the speed at which organizations release and update applications.
To ensure that security doesn't get left behind in this cycle, development organizations need to bake security into the development process itself rather than treat it as an afterthought. These 5 best practices are key.