Security testing data is “the unsung hero” of securing application development. It’s the backbone of application development quality, compliance and risk management, and rests on the three fundamental pillars of security:
- Confidentiality (the data is protected from unauthorized access)
- Integrity (the data can’t be/hasn’t been tampered with)
- Availability (the data is consistently available to support your business).
When you set out to design an application, you want to make sure it behaves as intended. In other words, that it does what you want, when it’s supposed to, and that it does so consistently.
Application security is, in a way, the antithesis of this. It’s designing, building and testing applications to ensure that your application doesn’t do anything you don’t want it to do, such as crashing repeatedly or, worse, giving up information. Simply put, it’s the “it shouldn’t do anything else” part of your application.
Both application vulnerabilities and security are deeply entrenched into AppDev.
Security vulnerabilities are functions of the application’s design — either you used a library in building the application that was insecure, or you coded an application that was in some way insecure, or you have fundamental architectural security flaws.
The same principle holds with the latter, application security, in that it’s central to the design process. You have to design the app securely, build it securely and test it to verify that you did everything right. This is where penetration testing comes into play. It’s never the answer to application security, but rather the verification of a program.
Ultimately, there’s no magic pill and doing one without the other can leave you exposed.
Overcoming the obstacles
In a world where time is money, convincing people that application security is important is not always easy. The rush to get an application to market can trump the need to integrate security into the development process. Not only are you up against getting people to commit to doing it, but there’s also the matter of understanding how to do it and training your developers to do it well.
So how does a CISO shift the mindset from “security is security’s job and security’s alone” to it being a corporate responsibility? It comes down to executive sponsorship – the decision-makers have to decide that it matters.
The first step is educating the senior staff on the nature of the data you store, how you’re using it and the risk that entails. From there, it’s much easier to sell appropriate defenses. You must be able to say we have this data, here’s how we use it and here’s how we should defend it, and, just as importantly, here’s what can happen if we don’t.
Picking the right partner
When selecting an AppSec partner, look for a company that regards the application development cycle holistically from design to production to retirement.
Secondly, ask if they are committed to working in alignment with your security goals as they relate to those affecting the company at a macro level. Application security is a risk, but businesses face many other risks and they need to be balanced.
Finally, your partner should be focused on the ability to measure success. Is the program successful and are the apps becoming more secure? If the company’s not showing you how to measure it, then you’re not going to be able manage it and it’s probably going to fail.
Just do it
The good news is that when it comes to application security, it’s not brain surgery. The technology is not really that complex. In fact, it’s fairly predictable. You don’t even need to come up with anything new — OWASP, for instance, has some excellent resources.
The challenge lies in doing application security well over a large organization. With 10 developers, it’s pretty straightforward, but with a 1,000 it gets complicated. Being consistent (remember those three pillars from earlier) makes it hard and the larger an enterprise is, the harder it is to achieve. In the end, it comes down to making the choice to do it and then actually doing it, and doing it well.