June 24, 2014 By Diana Kelley 5 min read

Managing Application Vulnerabilities by Adopting an Inventory Management Approach

Application vulnerabilities represent a large and growing problem. As IBM wrote in the most recent X-Force report, “Attackers look for any path to exploit sensitive and valuable corporate data.” Even if you’re not testing your applications, you can bet that the attackers are.

Security professionals know that the best way to eliminate exposure in applications is to implement secure design processes like the IBM Secure Engineering Framework and test applications for security issues multiple times before putting them into production. If vulnerabilities are found, they need to be fixed prior to application deployment.

Unfortunately, not every company has the time and resources to perform thorough application security testing, and sometimes the need to deploy applications quickly trumps the requirement to remediate vulnerabilities. This doesn’t even take into account all the legacy applications that are already in use or zero-day vulnerabilities that are discovered after deployment. The net result is that most organizations have more applications and vulnerabilities than they can test and remediate.

This means that, for many companies, the best path is to find a way to identify and focus on the applications and exposures that put the organization at highest risk and prioritize those fixes. To get a handle on where you should deploy your valuable resources, this four-step approach will bring clarity to the process:

  1. Inventory application assets
  2. Rank assets, using a risk assessment model
  3. Test applications in order of priority
  4. Remediate vulnerabilities that are identified and fix application issues

If you’ve been in or around application security for more than a few months, these steps are probably familiar at a conceptual level, but simply knowing the right steps is very different from being able to implement them. You may even have tried to implement a program similar to the one above only to find roadblocks and resource gaps that discouraged you from moving forward.

I get it — as a former practitioner, I’ve felt the pain of knowing the right approach and being unable to implement it in practice. So rather than provide a laundry list of practices, here’s a narrative that identifies common roadblocks for the first step, Inventory, and provides suggestions for overcoming those blocks and moving forward.

Meet Chet at BigCo

Chet is a long-term security professional who started out as a firewall administrator and has spent the last few years focusing on application security. Chet joined BigCo three weeks ago with a remit from his CIO, Bernie, to “get our application security in order!” Chet has one direct report, Suzie, a dedicated application security tester who started out in QA. Chet also manages the company’s external relations with its penetration testing team that performs quarterly scans on BigCo’s network and Web applications.

Assessing BigCo’s Application Inventory

Chet knows that getting “application security in order” should begin with identifying which applications the company builds, buys and implements. During his first week on the job, he sent a request to all business unit managers and application owners requesting an application inventory list from them. He also asked his Ops team to provide a list of known applications in use at the company.

Instead of the detailed app inventories Chet was hoping for, he received very little useful information. Only a small percentage of people responded at all, and those who did had no list or only partial lists. Some of the business units and application owners even suggested that Chet’s team might have a better inventory list than they did.

Chet could aggregate the partial lists and work from there, but he knows that following such an approach won’t give him a comprehensive view of the true application picture at BigCo. If he only includes those applications in his testing plan, he could be wasting his scant resources on the wrong applications.

Finding More Reliable Inventory Sources

Since the email blast didn’t work, Chet digs a little deeper to get more focused in his approach. He determines that the procurement division handles license renewals for all the commercial software that the company buys. The mobile operations managers track approved mobile apps in the corporate app store and external penetration testers perform an application sweep during their quarterly reviews.

Since the email approach wasn’t as successful as he’d hoped, he reaches out to these newly identified resources by phone and email — and, per Suzie’s recommendation, he adds the head of QA to the list to obtain insight into applications that are just about to go into production.

This approach is much more fruitful, and Chet is able to build a much more accurate picture of the corporate application portfolio. Is it perfect? Not yet, but it’s a sight better than the one he started with. Going forward, Chet considers ways to integrate the information from those disparate sources automatically into his master application inventory, and he’ll continue to look for additional sources to increase the accuracy of the list.

“We Don’t Have the Budget”

Now Chet has a better set of lists, but they’re in multiple formats, and there’s no way to rank applications by risk rating without collecting them in a unified, normalized list. He creates a list of the attributes that he’ll need to determine application risk. Some examples are: Application owner, sensitivity of data stored or processed by the application, location in the corporate network or public cloud, required uptime and industry and governmental compliance mandates.

He also inventories the formats he’s received from application intelligence sources. Some of his sources supplied lists in CSV format, some included lists of applications in the body of their emails and one of them even provided Chet with database access.

To really get a handle on the application security landscape, he realizes that he’ll need a way to incorporate bug, patching, test and vulnerability tracking into his application security management system and to track library and open-source component use in composable apps.

Chet realizes that this system has a lot of moving parts and will be fairly complex to build and maintain. He conducts some research and looks at managing the portfolio in an IT Governance, Risk and Compliance (IT-GRC) console, or in an application security testing tool like AppScan 9.0.

Chet puts together a detailed RFP and receives pricing from vendors. He then presents a proposal for purchase to Bernie, the company’s CIO. Bernie reviews the proposal and says, “No way, Chet. We just don’t have the budget.”

Getting Past “No”

Chet gets discouraged and leaves the company — just kidding!

Chet asks Bernie what business justification would help to get the budget request approved. Then, Chet determines how he can create a short-term, homegrown solution by utilizing a spreadsheet or simple Web front-end to a database that will enable the program to get started and begin generating success metrics. One example: Bernie wants proof that applications are reaching production stage with fewer high-severity vulnerabilities.

Chet’s homegrown system measures vulnerability severity in applications over time and creates a historical view of vulnerabilities in production applications. Will Chet obtain the budget he needs to purchase a tool to help automate the process in a year’s time? Or budget to expand the functionality of his homegrown solution? Maybe not — but it’s much more likely now that the program is showing measurable value.

What First Steps Do You Need to Take?

We know the complex challenge of application security portfolio management can’t be solved in an article; but high-level steps have been outlined to help your organization improve its application security inventory management and overcome common impediments to success. The key take-away is that the only way to solve the problem is to begin with the very first step: Put a program in place. Next, you’ll need to demonstrate success of your program over time so you can build business case justification for increased investment.

Consult my colleague Neil Jones’ article for additional information about selecting the optimal application security and risk management solution for your organization: “Features and Functionality in the Best Application Security Solutions.”

Were these suggestions helpful? Did they get your creative juices flowing about how to address the challenge of “so many vulnerabilities, so little time?” Do you have other suggestions that you’d like to share with your peers? Let us know via Twitter!

More from Application Security

PixPirate: The Brazilian financial malware you can’t see

10 min read - Malicious software always aims to stay hidden, making itself invisible so the victims can’t detect it. The constantly mutating PixPirate malware has taken that strategy to a new extreme. PixPirate is a sophisticated financial remote access trojan (RAT) malware that heavily utilizes anti-research techniques. This malware’s infection vector is based on two malicious apps: a downloader and a droppee. Operating together, these two apps communicate with each other to execute the fraud. So far, IBM Trusteer researchers have observed this…

From federation to fabric: IAM’s evolution

15 min read - In the modern day, we’ve come to expect that our various applications can share our identity information with one another. Most of our core systems federate seamlessly and bi-directionally. This means that you can quite easily register and log in to a given service with the user account from another service or even invert that process (technically possible, not always advisable). But what is the next step in our evolution towards greater interoperability between our applications, services and systems?Identity and…

Audio-jacking: Using generative AI to distort live audio transactions

7 min read - The rise of generative AI, including text-to-image, text-to-speech and large language models (LLMs), has significantly changed our work and personal lives. While these advancements offer many benefits, they have also presented new challenges and risks. Specifically, there has been an increase in threat actors who attempt to exploit large language models to create phishing emails and use generative AI, like fake voices, to scam people. We recently published research showcasing how adversaries could hypnotize LLMs to serve nefarious purposes simply…

Topic updates

Get email updates and stay ahead of the latest threats to the security landscape, thought leadership and research.
Subscribe today