How to manage application security risks and shortcomings

Application security is arguably the most critical part of an overall security program.

Software is where business transactions happen. It's where sensitive information is captured, processed and stored. It's where a large -- arguably the largest -- number of security threats and flaws exist to create the perfect risk scenarios for criminals.

Still, organizations struggle to find -- and fix -- the big application security risks. This includes things such as SQL injection at the application layer for web and mobile applications, missing patches that facilitate remote access at the server layer, and even default or weak passwords at the database layer.

However, we can't blame the flaws or the hackers for what's happening, as it goes much deeper. First off, there's a serious lack of proper application testing. The three main areas of concern are as follows:

• no security testing at all -- including critical applications, this is the most common issue due in large part to assumptions that someone else is taking care of things;
• basic vulnerability scans that don't properly address the application layer; and
• not looking at source code -- an exercise that often reveals flaws that won't turn up with traditional vulnerability and penetration testing.

Secondly, there's often a lack of communication between developers and quality assurance (QA) analysts, security teams and management in general. The main gaps that I see are as follows:

• Assumptions are made: This can involve security standards, threat modeling and overall policy enforcement during the software development lifecycle and well into the application implementation phase.
• Bystander apathy: Not unlike the assumption above that a third-party vendor or cloud service provider is doing the proper testing, in many cases, developers and QA professionals assume that any security flaws will be uncovered downstream from their duties, such as once their code goes into production. At that point, it may be too late to find and fix the flaws.
• Misguided priorities: For example, when technical staff ask for the proper resources to do their security due diligence and they're shot down by management. However, if an independent outside party, such as a security auditor or customer performing its own testing on your environment, mentions anything in their report, it suddenly grabs the attention of management. Executives want to know why these issues weren't uncovered previously without seeing the bigger picture of their actions getting in the way.

Finally, I have found that many developers, QA analysts and security teams lack insight into the software security best practices and frameworks made available to us, such as the OWASP Top 10, the Common Weakness Enumeration and ISO 27034. Or they're unable to take the time to integrate such standards and practices into their application security program because of the time-to-market demands of other parts of the business.

Further compounding this, many of the very people in charge of application security that I speak with have never taken a course on the subject. That said, it's so easy to get caught up seeking out the best standards and having others tell you what you should be doing that you can overlook the gaping flaws right under your nose. Be careful, think for yourself and use common sense.

That said, it's so easy to get caught up seeking out the best standards and having others tell you what you should be doing that you can overlook the gaping flaws right under your nose.

In the end, application security risks can be lessened via three methods.

• Know your environment: Everything from critical applications to low-risk applications, and all the information and processes they tie into, both internally and externally. Overlooking attack surfaces is one of the most dangerous oversights of security management. The golden rule of security always has been and always will be that you cannot secure what you don't acknowledge.
• Understand your application security risks: The technical vulnerabilities, process gaps and policy opportunities across the spectrum of threats your systems face. Getting others involved here to help determine priorities is key, as keeping risk analysis within IT circles works well until it doesn't. Once an incident or breach occurs and executive management and lawyers get involved, it's too late. Why not involve them from the get-go?
• Do something about it: Manage urgent issues on your most important systems first and, eventually, manage the issues on all the systems that are accessible via web, mobile or source code. No matter how much I analyze such situations, I can't come up with a single excuse for not doing something about known flaws that can create tangible business risks.
  Fingers can be pointed at management for not providing enough resources or IT/security teams for not having enough time -- or discipline -- to get things done. In the end, no one wants to hear it. Cut the nonsense. Stop having meetings that spawn more meetings and, thus, giving people an excuse to kick the application security can down the road. Do what needs to be done and do it now.

Whether it's in the early design or development phases, production phases, or ongoing maintenance of legacy applications, you have to develop some structure around your application security program with all the right people to help eliminate application security risks. Nothing more, nothing less.

Be it a stand-alone program or part of your overall information security efforts, if you treat application security as the critical business function that it is, you'll get good results. If you don't, well, it'll be more of the same over and over again.