10 Commandments Of Application Security

While application security cascades into just about every facet of IT security today, many enterprises have a difficult time implementing sustainable application security programs that offer measurable benefits to the business. A general disconnect between security goals and the profit motives of development teams can cause insurmountable conflict between infosec teams and developers, with line of business leaders all too ready to side with money-making dev teams nine times out of 10.

Which is why so much of application security comes down to not just bolting on security technology and checking off OWASP Top 10 items. Many of the secrets to success involve smart politics, education and delegation among developer ranks, and championing of improved business processes without causing a disruption to the everyday workflow.

1. Thou Shall Execute App Security At The Speed Of Business
There's nothing worse for application security than the hubris shown when an expert tells developers or line of business leaders to completely re-engineer their processes for the sake of security, says Bill Pennington, chief strategy officer of WhiteHat Security.

"You have to know what the pace and cadence is from your business and then make the security solutions fit that," he says. "Otherwise you're not really going to get anything implemented at all."

He tells a story of a client who was once approached by a security consultant who told developers and business leaders that they'd need to completely penetration test all code before it went live, a process that would add five days to the process every time code was to be pushed live. The head line of business leader told the executive, "We ship code every Wednesday" and the consultant told him that the business couldn't do that anymore.

"And he said, 'No. We ship code every Wednesday,'" Pennington says. "You have to fit into the way your company or your customers do business."

One of the best ways to start empathizing is to get a better grasp of how the developers work before making prescriptive decrees, says Chris Eng, vice president of research for Veracode.

"Learn how the development team works so you can help without being overly disruptive," he says. "For example, if they use agile scrum, learn how that methodology works and where it makes the most sense to insert security."

2. Thou Shall Not Architect Security
It may make a nice sound bite in meetings to advocate for securely architecting applications, but John Jacott of Coverity advocates deconstructing that mentality a bit.

"Most of the apps I've seen are rarely 'architected.' They're grown via agile or waterfall development methods," says Jacott, director of security solutions for his firm. "What you need to do is show developers early and often the consequences of poor security and let them start thinking about it."

Jacott says that most security architects are ineffectual because they micromanage.

"They do not deputize their constituents, empowering them to create more secure applications on their own," he says.

[Are your backup databases putting your organization at risk? See Backup Databases: The Data Security Achilles Heel.]

Eng agrees that grooming and educating security champions on development teams will reap big ROI down the road.

"It is the only way that security expertise will scale in a large organization," he says. "Find a tech lead or architect level and train them to spot common attack patterns and coding mistakes."

3. Thou Shall Evolve Your Testing Methodologies
Application testing is the bedrock upon which solid application security practices are built upon. If the methodologies your testing are built around are shaky, the whole structure will wobble.

"Stay up to date with the latest taxonomies because they tend to reflect what's most important in the threat space," Eng says. "For example, if your penetration testing checklist was designed around the 2007 OWASP Top Ten list, you should probably update it."

Eng suggests three big activities up-to-date enterprises should organize their testing practices around. First and foremost, start by creating an application inventory and ranking those by business criticality to measure risks during the testing practices. Next, organizations should perform static analysis on all medium and high risk applications in development, with priority placed on remediation of medium and high impact vulnerabilities before those applications go into production. Finally, enterprises should employ discovery mechanisms to find all web applications on the perimeter and perform pre-authentication dynamic scanning, again remediating medium and high impact vulnerabilities found in the process.

4. Thou Shall Not Surprise Dev Teams
Nobody likes surprises, especially not developers who have to unexpectedly put the brakes on pushing something live due to security tests they never knew were required, Jacott says.

"Every control, like this security test, should be well publicized, sponsored by the highest CXO type and be well understood and accepted," he says. "If you don't have acceptance, it's your fault; you're not using their language. Surprise testing is just punitive."

If surprises are catching development teams off guard, at least put them to good use for championing more sustainable secure development practices earlier in the process. In other words, help security and development teams learn from their mistakes going forward.

"In my personal opinion, when that happens, that actually can be a very powerful tool within the organization to say, we would like to implement security testing earlier or in different ways to weave security in the very beginning that will prevent us from having these big surprise gotchas," says Diana Kelley, application security strategist for IBM. "If we get good at it and we keep doing it over time, we're going to get less surprises in preproduction approval testing. And, we have the possibility of getting apps out there that are much more robust."

5. Thou Shall Test Apps In Production
Application security testing shouldn't stop in QA, says Pennington, who says there are three big reasons why organizations should be regularly testing apps that are in production. First of all, there are many more legacy applications already unleashed on environments long before application security hit the scene. Second, applications often look very different in production than they looked in QA.

"We service about 13,000 websites today and 10 percent of them are QA/production paired," he says. "We have yet to find matching vulnerabilities in both of those."

But more importantly, the third factor is that the knowledge of how to exploit and find vulnerabilities changes over time.

"If I scan a code base in QA today, I only know as much as I know today," he says. "A week later, someone comes out with some craziness and now we have a new way to exploit SQL injections that we didn't know about before."

6. Thou Shall Not Let Frameworks Replace Common Sense
Frameworks are an extremely valuable tool for developers and even have some valuable tools for helping to improve application security. But just as with any tool there are pitfalls, says Ken Pickering, development manager of security intelligence for Core Security.

"It's great that people are using frameworks, which provide a number of security precautions for you and can protect you from injection attacks and stuff like that," he says. "But most people don't update their frameworks as much as they update their applications. These large frameworks also have defects associated with them."

Often, frameworks can also lend themselves to big backdoors due to user permission issues.

"A lot of people will write REST APIs or integration points into their databases and I find that half the time, they're wide open," Pickering says. "For all the effort people put into their UI inputs, forcing everything to their SPRING data layer, they'll bolt on some REST framework because its easier to give access and all data tends to bypass a lot of the user permissioning. It's kind of a back door in a lot of situations."

7. Thou Shall Put Vulnerabilities In Proper Context
When testing inevitably reveals vulnerabilities, security professionals do themselves no favors if they press for remediation with the same urgency for every bug.

"Don't assume all vulnerabilities of a certain type are equivalent," Eng warns. "Don't view security in a vacuum; rather, evaluate vulnerabilities in the proper context. There are many shades of grey in determining the importance of a finding. Don't raise red flags out of habit."

Security professionals should be acting as advisers, not as authoritarian overseers mandating action. That means first providing objective information about extant vulnerabilities and documentation about the severity and impact of an exploit, he says.

"Let the business owner make the call – and be held accountable if they choose to overrule the security advice," Eng says.

8. Thou Shall Not Give Developers Rampant Access To Live Customer Data
Strong access control principles aren't just something that developers should try to code into their applications. They're also something they need to live by and work with in the development environment, Pickering says.

"Its a thorny problem because its a business problem but it has technical impact," says Pickering, who warns that allowing developers to access live customer data during development opens enterprises to a whole spate of risks." There's always been this big disconnect between the content creators and the infrastructure people so keeping access rights up to date and managing accurately has always been kind of a hard problem."

9. Thou Shall Use A WAF With A Plan
Web application firewalls have often garnered a bad reputation in the app security world as an ineffective Bandaid to poor coding practices, but Pennington says that he's come to see WAFs as invaluable tools if they're used strategically.

"I don't treat them as some magical box I plug in and it solves my problems; I treat them as a dumb enforcement point," he says.

So, for example, if an organization has shipped code and it is in production but it discovers a SQL injection vulnerability missed during testing, asking developers to drop everything to fix that problem is impractical.

"You interrupt their business, you interrupt their workflow, and then they miss shipping that next million, billion-dollar feature and they blame you," he says "If you have a Web app firewall, you can put a rule in place to block that SQL injection attack, mitigate it and say 'Developers, please fix this the next time you guys release code, within the next month or two.'"

10. Thou Shall Not Blame The Developers
It can be really easy for security teams to approach developers and "call their baby ugly," says Jacott. But that's not the way to get application security done.

"A lot of security guys love to blame developers and say they're stupid, don't know what they're doing," Pennington says. "You have to work with them in the spirit of cooperation. It's how do you reach that goal in the larger context of business and shipping code on time. "

The more chances you have to gain political capital and developer friends along the way, the greater chances you'll succeed, says Jacott, who spent plenty of time in the antagonistic role before learning how much easier it is to play ball by developer's rules.

"Now I mean to roll up my sleeves and not be outside, but one of them: people integral to their team, with technology integral to their process and a solution to their problems, instead of a problem in their solution," he says.

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.