Strengthen Your Security With The Fortify 360

Source code analysis is a fundamental part of a complete application security process. It finds flaws and vulnerabilities in application code that could be exploited by attackers. A critical component of source code analysis is tracking and remediating the flaws and vulnerabilities uncovered during analysis. Fortify's 360 Server is a repository for all the results and remediation activities that accompany source code analysis. While the 360 Server doesn't perform the analysis, it does accept uploads from other Fortify products in the 360 suite that do. Organizations can also take advantage of its service-oriented architecture to integrate with third-party code analysis software.

Testing of Fortify's 360 server was performed by first generating application source code analysis reports from Fortify's SCA product. Once those were on hand, an analysis was created for the application, the results were uploaded and the reports were reviewed. Then a remediation process was started for each application that followed the real world process of the same application being remediated. Results and processes were compared to determine how well the product held up under real world conditions.

Server 360 provides an array of options once up and running. Staff can create new projects, which could be one or more applications that are being assessed; upload analysis reports from other Fortify applications as well as track and update compliance of projects. A common starting point in Server 360 is a new project. A project tracks outstanding issues and compliance with a single application or set of related applications. When creating a project, the user chooses one of two options: basic remediation or Software Security Assurance (SSA).

The basic remediation project provides trending, metrics and a way to analyze issues with the code base. You'll need Fortify's SSA Governance Module to choose the SSA project option. This module lets the user define contextual information around the application, such as the type of application, compliance requirements such as PCI or HIPPA and the type of data the application handles. Based on our testing, this module should really be core to the application as it provides a much more rounded and complete view of the application than the basic remediation option.

A new project is created with a few clicks in the web based interface and answering questions regarding the application. These questions map compliance and audit requirements to applications, allowing for easier review.

Once a project is created, staff can import analysis reports, define dependencies and review open issues. Open issue tracking is the core integration point between 360 Server and Fortify's other applications, such as their Source Code Analyzer (SCA) product. Security and compliance staff use the project area to view actual source code issues through a mock integrated development environment (IDE) to understand exactly what issues are outstanding. Reviewers can  mark issues as an exemption, a false positive, as exploitable or one of several other options.

Surprisingly, there isn't a method to mark an issue as resolved and provide supporting documentation or link to an updated analysis report. A "comments" section is available for staff members, which could be used to note that an issue has been resolved, but an explicit mechanism would be much more useful for tracking resolved issues.

Requirements are a set of items that must be completed before the stakeholder will sign off on the project and are tracked under the requirements section within the project workspace. These can range from complete source code analysis to uploading application permissions matrices. From this view, staff can review the status of requirements, sign off on work performed and add alerts so they are notified when certain events occur. 

In our testing, the requirements tab was populated based on the answers provided during the project creation. Each question or selection made by the user helps determine requirements for the project. Users have the ability to change these requirements to better suit their application or organization. Options for requirements vary. Authorized staff can sign off on the requirement once met and comment on it as well. In some cases, documentation is required. In these cases, staff can submit a document that will be associated with the particular requirement. Only a URL or Universal Naming Convention (UNC) path to the document can be submitted, so organizations must ensure documents are in a place that all users can access. This could be an issue if you need to provide external auditors access to this interface.

For those requirements that do not require a document to be uploaded, there is the ability to add supporting documents under the Artifacts tab. Artifacts are supporting documents, such as reports, that were created during application analysis, remediation or an audit. The same potential problem does not occur here, as users can upload documents or a path to the document. There is no mapping of an artifact to an issue or requirement; this could be a hurdle for organizations with a large amount of artifacts. Additionally, all artifacts must be classified using predefined list of classifications. There is no "other" or user-definable field.

Once project requirements are all signed off, a project can be considered closed. There is no formal method of closing the project, but the status of the project is automatically updated to show all requirements have been accepted. From this point on, the project can reside online to be reviewed as needed in the future. Because all activities within the project are tracked and logged, a full audit trail exists if needed in future reviews.

The main drawback in the product is a lack of flexibility for organizational processes and artifact handling. Most large organizations have their own way of doing things, and the lack of flexibility may grate on some users.

Installation of the 360 Server is straightforward. It runs as a Web application and requires an application server and database. We ran the software on the Tomcat app server and MySQL database.

The Fortify 360 Server is the next logical step for organizations that have implemented application security code review, have structured remediation processes and are looking to increase the efficiency of the process. It is particularly useful if they have other Fortify products in-house.