Fortify WebInspect

Automation

WebInspect automation workflows

WebInspect automation workflows use build automation tools to manage the dynamic scanning ecosystem, including QA testing and cloud deployments. 

Dynamic analysis (DAST), combined with static analysis (SAST), provides more thorough coverage, but automating dynamic is more complex. You can either build your own tech stack, or borrow a framework. This guide helps you accelerate your automation by using existing test automation scripts/frameworks that other enterprises have already created as part of their DevOps practices.

AppSec In-a-box with Custodela

Automating WebInspect into existing DevOps systems and processes allows security tests to be run simultaneously and at scale.

Watch Ken McDonald from Custodela present an AppSec In-a-box approach to automate WebInspect:

Dynamic Application Security Test Orchestration (DASTO)

Target solves Dynamic Application Security Test Orchestration (DASTO) with the WebBreaker tool on GitHub. This open-source project utilizes WebInspect to provide greater agility and flexibility to deliver improved integration into the SDLC pipeline, Git workflows, etc.

  1. WebBreaker Main Page
  2. WebBreaker on GitHub
  3. WebInspect Python API Library
  4. Fortify SSC Python API Library
Maven plugin for WebInspect automation

Maven plugin developed by Ruud Senden with Fortify for WebInspect and WebInspect Enterprise enables users to automatically build applications, deploy test instances and run integration tests. Integrate the following scenario into the CI/CD pipeline:

  1. Instantiate a WebInspect proxy
  2. Route the traffic from their integration tests through this proxy
  3. Save the proxy traffic as a workflow macro (and shut down the proxy)
  4. Configure a new scan based on this workflow macro Run this scan on either WebInspect or WebInspect Enterprise
WebInspect Automation – General workflow

WebInspect Automation – General workflow

Automation workflows use a build automation tool that manages the scanning ecosystem via the following steps:

  1. Security team sets up the security scanning steps as a “security task” that is called after a build and after app deployment, via the build automation tool.
  2. Development teams submit code changes to the build automation tool and after the set operational period, the security task is triggered after the build and app deployment is complete.
  3. On completion of the security task, the automation tool is set up to either pass or fail the build job based on the security risk defined by the security team.
  4. The security vulnerability findings are captured in Fortify Software Security Center (SSC), from where they can be optionally moved to bug repositories via the integrations available on SSC.

Basic Security Task – WebInspect

Head ?
Step 1
Health check the WebInspect sensor to ensure the scanner is available to schedule a scan.
face to face
Step 2
Call the WebInspect REST API/ or command line to initiate a scan. This involves passing the necessary URL, settings file and login information. 1. WI API reference: http://hostname:port/webinspect/swagger/ui/index#/
Certificate 1
Step 3
Polling the sensor to check the status of scan and trigger the next steps on scan completion.
Thumb up
Step 4
On scan completion, export findings as an FPR to a server containing Fortify Client and upload to SSC via the Fortify Client. 1. Fortify Client documentation found in the Fortify Software Security Center (SSC) Installation and Configuration Guide.
Basic Security Task – WebInspect Enterprise

This is simpler because WIE manages the scheduling and polling to identify availability of a sensor. WebInspect Enterprise also automatically publishes results to Fortify Software Security Center.

  1. Call the WebInspect Enterprise server API to schedule a scan with URL and settings file/template information.
Proxy and QA Automation

Proxy and QA Automation

Automation can utilize artifacts generated during QA functional tests (for example Selenium scripts to automate WI/WIE scans). The advantage of this approach is:

  1. The functional testing often involves a sequence of actions that have a business logic associated with them, whereas it is impossible to model from a blind WebInspect automatic crawl.
  2. The possibility to utilize the login sequence used during the functional testing and not create a separate WebInspect Login Macro. This involves configuring settings to exclude the login page from WI crawl or audit, and also that a logout doesn’t occur during security scan.

QA Security Task – WebInspect

Add these steps to the Basic Security Task—WebInspect:

Screen gear
Step 1 - WebInspect
Spinning up a WI proxy via REST API and replaying the captured QA artifact to generate a traffic file. The traffic file is then saved as a WebMacro.
Screen code
Step 2 - WebInspect
Using Command line/ REST API to modify default settings file. The settings file is overridden ] a Workflow macro saved from the traffic file in step 1.

QA Security Task – WebInspect Enterprise

Same additional steps as for WebInspect.

News 1
Step 1 – WebInspect Enterprise
For customers who don’t have access to WI desktop to spin up a proxy, download a license-free instance of a proxy available at the marketplace.
Doc find
Step 2 – WebInspect Enterprise
After creating a settings file, the process of initiating a scan for WIE involves additional steps. User should reference the WIE REST Create Scan Guide APR 2017.
Automation in the Cloud

Automation in the Cloud

Another use case is automation in the cloud by deploying the sensors for both WI and WIE, and dynamically scaling the sensor installation around the scale of application security testing under process.

  1. Security team accesses the scan request pipeline and determines scaling/descaling of N Sensors. Assign licenses based on this requirement.
  2. Security teams use the general workflow described in the general workflow and then loop through steps 1 and 2.

Cloud Security Task – Scaling for WebInspect sensors

Cloud secure
Step 1
A WebInspect installation MSI is stored in cloud storage and ready for deployment. [call location: cloud_memory]
face to face
Step 2
Security team calls the cloud API to create a windows instance and uses the command line of the instance (C_Instance) to do a headless installation of WebInspect sensor from location: cloud_memory.
Consolidate
Step 3
Necessary settings and macro files are deployed over the instance
Thumb up
Step 4
A scan is triggered in the command line (C_Instance) using the REST APIs of WebInspect in that instance. On scan completion, export findings as an FPR to a server containing Fortify Client and upload to SSC via the Fortify Client.

Cloud Security Task – Scaling for WebInspect Enterprise sensors

Cloud gear
Step 1
Additional steps are required to connect and configure the sensor to connect to WIE Server management layer and assign necessary permissions for access to the sensor. A WebInspect installation MSI is stored in cloud storage and ready for deployment.
Screen gear
Step 2
Security team calls the cloud API to create a windows instance and uses the command line of the instance (C_Instance) to do a headless installation of WIE sensor from location.
Screen code
Step 3
Using the command line : C_Instance, the sensor is configured to connect to WIE management server. Invoke the REST APIs of the WIE server management layer to provide permissions and security group access to the WIE sensor.
Time forward
Step 4
Once the WIE sensor installation is complete, call the WIE server API to schedule a scan with URL and settings file/template information. On scan completion, findings are automatically synched to SSC.
Disclaimer

This information is provided as part of a community effort to share approaches to automation. The information is provided as a guidance and is not an endorsement for any particular solution. There may be no Fortify QA and Support for content within this page.

release-rel-2018-9-1-hotix-1072 | Tue Sep 18 12:55:42 PDT 2018
1072
release/rel-2018-9-1-hotix-1072
Tue Sep 18 12:55:42 PDT 2018