IBM Security Resilient

How to Utilize IBM Resilient to Manage Emergency Application Security Vulnerabilities

By Cody Travis posted Wed August 08, 2018 01:10 PM

  

One of the most “thrilling” days of my career as an Application Security Specialist was the day that Heartbleed hit. Since Heartbleed was a zero-day vulnerability that affected so many systems at one time, I experienced a hectic day of writing PoC exploit scripts to verify which systems were affected, and frantically scanning our known network assets for vulnerable services. At the time, we had a policy in place for vulnerability remediation, which was largely based on severity. We were given 15 days to fix a critical vulnerability prior to escalation, highs were given 30 days, mediums were given 60 days, and so on. As a by-product of that experience, we had to implement a new policy on how to address those zero-day issues. There was obviously a criticality above and beyond what we considered critical. We began to refer to those issues as “super-critical” in nature.

Reflecting on this development gave me the idea to utilize the newly-released AppScan Issue Gateway on IBM Application Security on Cloud to monitor issues that could be considered super-critical and send them to IBM Resilient for remediation. Those super-critical vulnerabilities required an emergency process that immediately got kicked off when they were found. This process was akin to how an application development team reacted to application-breaking defects.

There are three required components to implement an emergency process for application security vulnerabilities:

Step #1: The first component is to determine which vulnerabilities trigger the process. The best way to accomplish this is to create a customized policy for IBM Application Security on Cloud. Customized policies are a great way to filter issues from scan results down to desired sets. However, the types of issues that get included in the policy are up to users. In this example, high or critical severity Open Source findings needed to be added to the policy. High-severity SQL Injection or Cross Site Scripting vulnerabilities could be added to the policy, as well.

Step #2: Now that we have a policy in place to tell us when to trigger the emergency process, we need to have a mechanism in place to monitor for them. AppScan Issue Gateway is designed to do just this. Its intended purpose is to orchestrate the delivery of remediation tickets via an automated process to defect management systems such as JIRA. While this use-case is slightly different, it will still serve our purpose. As scan results flow through the AppScan Issue Gateway, we can trigger which "Providers" process our results. A provider is simply defined as a self-contained integration. Out of the box, AppScan Issue Gateway contains a few providers (JIRA, VSTS, etc...), but one of the great things about the capability is that it is very simple to create a customized provider from scratch.

Step #3: That brings us to the last step, kicking off the emergency process. In IBM Resilient, I created a customized Incident Type for this use-case. I named it “Vulnerable Application,” and created the required rules that get fired when the incident is created. Those rules make sure the required stakeholders and tasks are created in the incident. Stakeholders that need to be included in those types of incidents include Application Security analysts and management, as well as the development team and their management. Legal and HR may need to be involved if there was evidence of a data breach. The tasks included in the process need to manage it from discovery all the way to closure. These tasks may include notification of stakeholders, discovering if the problem exists in production (if it was discovered in a pre-production environment), investigating any evidence of a breach or loss of Personally Identifiable Information (PII), testing the fix in pre-production and in actual production, and any post-mortem paperwork.

This process could be implemented outside of the AppScan Issue Gateway, by using pure API calls to both tools, but the AppScan Issue Gateway abstracts much of the process away from the caller to help simplify things.

To summarize, we need to realize that there is the concept of an application security incident. This incident requires its own remediation process and IBM Application Security on Cloud and IBM Resilient combine together to provide an effective solution for vulnerability detection and incident response.

To learn more about this project, click here.


  #Resilient #AppSec #IncidentResponse

​​​
0 comments
39 views

Permalink