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:
- Inventory application assets
- Rank assets, using a risk assessment model
- Test applications in order of priority
- 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!