Monthly Archives: September 2013

HP Fortify manual rule pack update

With the Fortify products, HP has acquired a great suite of security tools for security static code analysis (“Fortify SCA”). But HP’s security product line-up also includes other tools, for instance for runtime analysis (“Fortify Runtime”, which analyzes code while it is in production) or HP WebInspect for automated black box security testing.

The Fortify SCA products include tools like the “Audit Workbench” that are available to developers, but also server products that are more suitable for a continuous integration environment.

I discussed the Audit Workbench with a couple of developers today, and, during the walk through, came across the auto-update feature. Fortify regularly provides updates to the rule packs, and so makes new scan capabilities available to the users. The update is automated (the default is to check for updates every 15 days, see “Options” -> “Options” menu), but sometimes one wants to trigger the update manually.

It took us a couple of minutes to find it in the documentation, but a look in the bin directory of the installation quickly helped: one can either use rulepackupdate or fortifyupdate to trigger the manual update. While rulepackupdate still works in the current release, it is deprecated and replaced by the new fortifyupdate.

If you are connecting to the Internet through a proxy server: the settings for configuring the proxy hostname and port are in the “Options” -> “Options” menu, under “Server Configuration”.

Product Development Model vs Secure Software Development Lifecycle Model

The first step in any project is creating a list of requirements. In enterprise software development, this step may actually one of the most time-consuming parts. It frequently requires coordinating with several departments and stakeholders, each of them providing information about what the product should do, how it should behave, and how it should tie in with existing solutions. This may include diverse groups such as legal, marketing, engineering, and others. The result of the process is a prioritized wish-list, and most likely some sketches that show how the new product may connect to existing products.

From here on, the next steps somewhat depend on the individual organization and their development model. Although there are a variety of models, a large percentage of projects are developed using a variant of the waterfall model or some flavor of agile development models. Interestingly enough, these two models are representing the two extremes with respect to release cycle lengths. There is a lot of fuzz around how different agile is from waterfall, and sometimes people can get quite agitated around which model works better. I will skip this discussion here, and just note that each of these models has similar phases that are relevant for a secure software development process. The main difference is how the phases are executed, and how the results are used in the development process.

As an example, each project shares the initial requirements gathering phase. This phase is so universal because we always have to find out what we want to build, whether the market needs this, and how the development will be funded. In this stage, it does not matter whether the product is commercial or open source or a mix, because even a developer working in their free time will ask the question of whether implementing e.g. yet another web content management system would be worth their time.

Once an investment decision has been made, the next steps differ to a certain extent. For example, a team using a waterfall style development model will now start a very detailed analysis of the high level requirements gathered earlier, and turn them into much more detailed requirements and specifications. A team following an agile approach will start with a more preliminary design, release code early and release often, and continuously refine the product until it fulfills all of the project sponsor’s requirements. Such a release is often called a “Potentially Shippable Increment”, or PSI. And although agile seems to be so much different from the waterfall model, the agile team will perform similar steps in each PSI as waterfall team does. The difference is in the planning horizon: while the waterfall team plans for e.g. two years, an agile team may only plan for a couple of weeks. Still, the agile process requires a longer term vision to keep the project on track.

The Secure Software Development Lifecycle Process, or SSDLC process for short, should tie in seamlessly into the existing development model that a specific team choses. There are several models of SSDLC processes, but none of the better processes requires the teams to actually change how they develop their product.