“Software is eating the world.”

– Marc Andreessen (Wall Street Journal, 2011)

Application security (AppSec) is the most misunderstood and underserved security challenge facing every organization, security team, and developer. No matter your perspective, the perceived complexity and intractability of the problem space makes it the most likely to be delegated, deprioritized, or simply ignored.

Whether you’re in the process of designing and building your own software or trying to get clarity on the security of your vendor-supplied applications, approaching AppSec discussions with an intentionally proactive and practical mindset. What follows are statistics and suggestions to make this effort easier to envision, evangelize, and execute.

The Drivers of Application Security

Organizations focus on cybersecurity domains where they feel the most control. For decades, we’ve seen ongoing incremental investment in endpoint, firewalls, gateways, awareness training, identity and access management (IAM), and secure storage. All are important, and all have made security far better.

In contrast, application security suffers from more frugal treatment because secure practices and policies for applications are outside the purview and experience of most security teams and security-minded business leaders. They have little standing or expertise to address resistance from resource-strapped development teams, scheduling pressure from business units, and unmotivated vendors. Application security is left with little urgency and less focus.

Among developers, secure application development is not taught with the same consistency and priority as performance, reliability, or ease-of-use. According to one Harvard Business Review article that argues security coursework should be mandatory for computer science students, “almost 70% of development and IT professionals described their training in application security as ‘inadequate’”. Consequently, applications aren’t being built with the same level of investment in secure coding.

The result is the continuing proliferation of vulnerable software and a growing ecosystem of tools designed to identify, exploit, and co-opt those applications. Just one of these vulnerable applications, if popular enough, can wreak far more havoc than any standalone corporate compromise.

Well-publicized examples include the vulnerabilities discovered in ServiceNow and, more recently, Log4j. Once discovered, such vulnerabilities tend to persist, no matter the severity or public exposure. The average time to fix a critical or high severity vulnerability is still well over six months from time of discovery. During this period, attackers will identify, exploit, and leverage the vulnerability to either launch their campaign or create a resilient backdoor to continue their work after the vulnerability is eventually patched.

We’ve learned that:

  1. Vulnerabilities survive and even thrive in the typical development and software acquisition process.
  2. Once vulnerable applications hit the market, there is a long and painful period while organizations muster the will and the resources to correct, block, or otherwise mitigate the vulnerabilities once discovered.

The costs and challenges of poor application security impact both the software creator and the customer. Among the most vulnerable are organizations that are compelled to run older, custom, or unsupported applications. Progress requires an approach that balances the desire to improve with the reality, disruption, and cost of potential remediations.

Executing on Application Security

Here are four areas to consider as you move to improve your application security posture.

1. Create a reasonable scope

The average enterprise is managing more than 400 applications according to the Cloud Security Alliance and others. That means your new AppSec program starts with a lengthy list of potential targets. Attempting to concurrently assess and improve this inventory will quickly prove impossible; any successful assessments will identify errors and exposures for which neither time nor resources have been allocated to repair.

You’ll want to establish a meaningful set of criteria to specify your initial targets. Criteria can be risk level, support of the application owner, or public versus private exposure. Select applications that help you tell your story, whether through successful outcomes, defects detected and repaired, or costs and exploits avoided.

2. Rationalize your remediation options

Before beginning your first assessment, consider what actions you’ll take after vulnerabilities are identified, because you will find some. Best-case scenario, a willing vendor will quickly address your findings. Sadly, even that excellent level of support requires weeks or months to materialize. Plan on promptly mitigating risks with additional controls or by limiting access to the application. Notify stakeholders that rely on the application or its outputs. Recognize that some applications may be unsupported or were written by vendors or employees that are no longer around.

An application with an identified but unaddressed weakness is a liability. Avoid the temptation to point out problems without participating in a plan to address them. This single lesson is key to cultivating a positive and supportive application security program and stakeholder team.

3. Look to the future

While your existing application inventory is substantial, it’s also growing all the time. Use contract language, preferred vendors, and documented practices to ensure that identified risks don’t continue to expand. During discussions with internal teams and negotiations with vendors, clarify your need to understand and improve the security of applications you will be acquiring. These discussions are best held prior to purchase or the extension or renewal of a software contract. Application providers are most likely to react in line with your security expectations if you’ve made those expectations clear from the start.

Beyond transparency, do your due diligence on the stability and reputation of the firms with whom you interact for applications. A well-intentioned company that falls on hard times is unlikely to invest in support of a new security problem, and a product historically marred by vulnerabilities will likely continue to offend.

4. Illuminate upside for stakeholders and vendors

Your increased focus on application security is likely to make software acquisition or application development more difficult. Make time to effectively illustrate and communicate the benefits to your stakeholders accordingly. Application users can proceed with confidence, understanding that there are now fewer opportunities for malicious actors to co-opt or disrupt their services. Through negotiations, vendors acquire better relationships – even concessions – just by improving the security of the software they write. Those improvements are then available to all current and future clients.

It’s critical to tell the story of improved application security to your management team, peers, and business leaders. The negative impact of vulnerable applications is limited only by the combined transactional, reputational, and reliability risk that an exploit poses. By documenting problems fixed and vulnerabilities mitigated, there is a clear path to a safer, more predictable infrastructure.

To learn more about application security and the right strategy for your organization, contact us at [email protected], or complete the form below.

Author: Jack Danahy, Vice President of Product and Engineering

Contact Us

7 + 11 =

Pin It on Pinterest

Share This

Share This

Share this post with your friends!