Despite the influx and rapid evolution of threats plaguing businesses today, many enterprises still rely on limited cyber resilience measures. Some embrace completely locked-down network perimeters. For others, robust endpoint controls on servers and workstations define the organization’s security posture. Some security leaders tout their users as the first line of defense when it comes to preventing incidents and breaches.

Still, it’s rare to see an organization with a strong application security program that places software front and center. Secure critical business applications are often the linchpin of enterprise data protection, yet they receive relatively little attention in terms of risk identification and mitigation — typically tacked onto other initiatives such as vulnerability and penetration testing and the software development life cycle.

Given what’s at stake, that needs to change.

What You Don’t Know Can Hurt You

The biggest application risk is software that hasn’t been properly vetted for security flaws. It seems obvious, but I’m always surprised by just how many web, mobile and even client/server application environments remain untested or otherwise vulnerable to attack.

In many cases, not even a simple network vulnerability scan has been performed, much less in-depth application vulnerability and penetration testing. Source code analysis, which can complement traditional vulnerability and penetration testing, is typically an afterthought at best.

Why Is Application Security Lacking?

In many cases, I believe IT and security teams, along with their software development and quality assurance (QA) counterparts, take application security for granted because they assume it’s just an internal application or marketing website that doesn’t process or store critical information assets. Or, they assume that common application flaws, such as cross-site scripting (XSS), unhandled exceptions and web server misconfigurations, are insignificant.

In reality, these vulnerabilities can amount to a huge gap in security. It’s all about context: I’ve seen situations where critical software flaws were right under the noses of the people in charge, but they didn’t fully understand their own software functionality or didn’t look deeply enough from multiple perspectives.

There are bigger security challenges as well, such as SQL-injection, remote file inclusion and related input validation issues — not to mention flawed login mechanisms and business logic. Even when application security is addressed, it’s often brushed over via quick vulnerability scans or limited manual analysis, which creates an unnecessary false sense of security.

Use All of Your Tools

One of the biggest problems I’ve seen in terms of software security testing is a very limited approach to the tools that are used. Namely, using one web vulnerability scanner to look for weaknesses without any detailed review using a web browser, Hyptertext Transfer Protocol (HTTP) proxy or related tools. When no vulnerabilities of significance are uncovered, security teams consider themselves secure. In reality, the testers may not have looked hard enough.

There’s also a lack of oversight in terms of application security. In some cases, IT and security team members assume that developers will know and do the right thing. Developers and QA professionals assume they’ll be able to lob their software over the fence and security teams will serve as the crutch to find everything that needs to be fixed, eventually.

Ideally, all parties involved would not only understand what’s expected in terms of the business and user functionality, but also what threats and vulnerabilities exists and where software security improvements can be made.

A similar challenge is a lack of accountability. When scoping security assessment projects and even after testing has commenced, I’m often instructed not to test various websites and applications because they’re being hosted somewhere else. The assumption is that due care is taking place, software vulnerabilities have been identified and someone is doing something about it all.

Assumed security is never real. With that kind of attitude, you won’t have a leg to stand on when an incident strikes.

Review Your Application Security Ecosystem Holistically

A substantial amount of business risk stems from poor application security. Looking at this in terms of solutions, security teams can greatly improve their application security programs simply by stepping back and looking at the bigger picture of how software development, testing and maintenance are done in the enterprise. This means asking some essential questions:

• Does everyone in the software development life cycle understand the business’s security goals? If not, it’s essential to establish a bridge of regular communication across departments and ensure that security risk management is consistent and reflects the organizational structure — and vice versa.
• Do these people have the proper application security training? Tools? If not, review your training program and tool repository. Consider hiring an outside expert to improve necessary internal skills.
• Are security standards consistent across all application platforms and business units? Again, interdepartmental communication is essential. Make sure security standards messaging is frequent and clear, and give various teams the opportunity to offer their input to keep everyone on the same page.
• What are the common software vulnerabilities that keep surfacing, and what could be done differently to mitigate those moving forward? Researching vendors who provide integrated, holistic security solutions may be a significant step in approaching patterns in security gaps.

Unless and until these areas are addressed, application vulnerabilities will continue to crop up. Software environments are just too unique and complex for one-size-fits-all solutions. There are common technical issues to address, of course, but there are also the people and business processes involved that need to be a part of the discussion.

Application security may stand on its own in your enterprise, but don’t treat it as a peripheral concern. Make it part of your ongoing and iterative security efforts at the highest levels. Bring it into the fold in terms of visibility, control and metrics. That’s the only way you’ll mitigate what’s arguably one of your greatest areas of risk.