Let’s Put “The App” Back in AppSec


Posted on by WhiteHat Security

By Setu Kulkarni, Vice President of Product Management, WhiteHat Security

The shift to software solutions delivered in the cloud continues to fuel the now “digital” economy. With this shifting landscape, application security has risen to the top of most organizations’ concern list, and for good reason: applications accessed over the web are very easy targets for cyber attackers.

Your approach to AppSec needs to be broadened from a narrow focus on vulnerabilities to securing the end-to-end application development process. This means reexamining the way we budget for AppSec. It also means incenting developers to write secure code.

We know from interviewing CISOs that up to 70% of XSS vulnerabilities in production can be avoided by catching XSS during development. Think about how that can affect your approach to AppSec, which until today has mainly been focused on compliance and mitigation plans. Also consider the fact that securing your SDLC will likely change the way you budget for security in profound ways.

The recent Delta Air Lines outage got me thinking about how important applications have become to business. With “the interconnectedness of things,” applications need to be able to withstand all of the threats that can potentially bring them down. 

Excerpt from Wall Street Journal, August 8, 2016:

“A power outage at Delta Air Lines Inc.grounded thousands of passengers world-wide during the height of the summer travel season, wreaking havoc on the carrier’s reservations system. The technical problems likely will cost Delta millions of dollars in lost revenue and damage its hard-won reputation as the most reliable of the major U.S.-based international carriers.”

An electrical outage can be fixed fairly quickly but in this case, one or more critical systems crashed and couldn’t be brought back up, bringing Delta’s business to its knees. 

As noted by airline experts, cyber attacks (or hackers) could have easily done the same thing, and we hear of these attacks in the news all the time. In the Delta example, an electrical outage was the culprit that disrupted the company’s business—but this kind of threat looms every day that businesses allow their critical business applications to operate with no security checks and measures in place.

So how do we make our applications safe? 

It’s probably time to frame our response to this question somewhat differently. Once an afterthought in software design, security is becoming an increasingly important concern as applications become more frequently accessible over networks and are, as a result, vulnerable to a wider set of vulnerabilities. Yet so much of our AppSec efforts are currently being spent testing application security at the end of the SDLC instead of embedding it into the end-to-end software development process. Just like automotive manufacturers need to “build security” into their cars, software developers need to “build security” into their code.

Just how safe can applications be in today’s interconnected world?

Because of the ever-changing threat landscape, it’s the rare application that can be made absolutely bulletproof. But what you can do is make your applications highly resistant to current and emerging security threats. This starts with your DevOps teams, who need to be trained on security principles, best practices, and writing secure code to address the top security vulnerabilities that end up manifesting themselves in production. Once trained, you need to incentivize your developers so that writing secure code is a regular part of their planning and coding processes. Security measures built into applications minimize the likelihood that unauthorized code will be able to manipulate applications to access, steal, modify, or delete sensitive data. 

How do we reframe our approach to AppSec?

Remember that it is much better to build security into your applications today than to try to fix problems and mitigate damage after the fact. With that in mind, here is an attempt at reframing the approach to AppSec:

  1. It starts with proper budgeting. Putting the “app” back in AppSec really means thinking about security throughout the application development lifecycle. Here are a few recommendations:
  • Budget for scanning both executing and executable code (static and dynamic scanning) throughout your SDLC (not just in pre-production or production). Budgeting for this approach will give you the confidence of having the most secure applications with the lowest overall investment.
  • Take a risk-based approach to focus on the most critical apps based on business criticality and risk.
  • Finally, create a strong link between product teams and security teams so that security is a top priority for both in terms of budgets, resources, employee development, etc.

Here’s the bottom line: 

Don’t just be a firefighter when it comes to application security. Finding vulnerabilities is only a small part of AppSec; remediating/fixing problems is a bigger part; and prevention is the most important of all, as this is where you are going to get the biggest bang for your buck.

Take a more proactive approach to AppSec by building security into your applications rather than reacting to problems after they occur. Some applications are more critical than others, and some are at higher risk of a security breach. Figuring this out will help you prioritize scarce budgets and resources. Wherever applications fall on this scale, we all depend on them to do what we need to do, all day every day. And when they aren’t secure, brands can be damaged and costs can run into the millions or even billions of dollars. There is a lot at stake.

Contributors

application security DevSecOps

Blogs posted to the RSAConference.com website are intended for educational purposes only and do not replace independent professional judgment. Statements of fact and opinions expressed are those of the blog author individually and, unless expressly stated to the contrary, are not the opinion or position of RSA Conference™, or any other co-sponsors. RSA Conference does not endorse or approve, and assumes no responsibility for, the content, accuracy or completeness of the information presented in this blog.


Share With Your Community

Related Blogs