[Owasp-o2-platform] Proposed workflow for breaking and analysing FVDL Files
jsteven at cigital.com
Mon Aug 1 14:51:09 EDT 2011
HP has a few reasons for why an adopting organization would want to sign their scanning results file uploads out of a tool like SCA or Fortify360. About 10-11 months ago, I noticed in my own practice, that organizations 'raised their game' requiring not just a bake-off of two tools on a few (3-10) applications but rather wanted to roll their tools out to thousands of developers and begin on-boarding 100-300 applications/yr. until their portfolio coverage was acceptable.
If you dig into 360's marketecture you'll see they're upgrading something intended to provide results visualization/distro for a development team to a more fully-integrated "Vulnerability Lifecycle Management" tool. In this context, one wants two things:
* Results Signing - an integrity check - Has anyone in the vulnerability management workflow mucked with results?
* AuthN/AuthZ - is the person Uploading scans allowed to? Is the person requesting them authorized to see the results?
Client organizations at the high end have been asking for these VM Workflow features for some time beyond that 10-11 mo. window of which I spoke.
The thread included below refers to results signing, which 360 supports. Pulling apart an FPR reveals an audit.fvdl and an audit.fvdl.mac. I'll leave it to licensed and approved enterprising souls to understand the scheme by which the mac is created. Suffice it to say 360 Server (As of 5.11Q1) accepts and distributes, and properly renders unsigned FPRs.
If one wants work stream automation, one also needs to handle the AuthN/AuthZ scheme which in 360 is referred to as sourceanalyzer.f360AuthToken. This allows you to generate credentials for 360 interaction that 'code for' who can upload what for how long. Without revealing anything proprietary, I can tell you this upload is constructed based on:
* User Name
* Token lifetime
Other things matter when uploading a file, but readers can gather this information from publicly-available info. Note that as these solutions appear to be generalized from specific schemes crafted by HP Consulting staff for particular integrations, I expect that some of the other elements of this upload will remain volatile until more officially standardized.
While some build/QC integration for 360 is publicly available open source, much of it is not freely distributed beyond HP's 360 licensees. You don't *need* to understand this scheme to interact with 360 but you will if you want to progress beyond manual 360 upload (of unsigned results) and actually produce meaningful process integration, such as would be required for continuous integration/scanning scenarios.
As HP appears to want to control the VM workflow process, I don't hold much hope of them open sourcing these behaviors and widgets. This is unfortunate, because short of the workflow(s) we implement for clients, what organizations demand isn't well-supported by their current kit, at least not in teams larger than nine or so.
Senior Director; Advanced Technology Consulting
Key fingerprint = 4772 F7F3 1019 4668 62AD 94B0 AE7F EEF4 62D5 F908
Software Confidence. Achieved.
On Aug 1, 2011, at 11:20 AM, Dinis Cruz wrote:
> Ahh, interesting, well, I don't have a working copy of Fortify here, so its up to you guys to figure out a way around this.
> So what happens? does the Fortify Audit Workbench refuses to load a modified FVDL?
> Btw, what is Fortify's view on this? Surely there are very valid use-cases where the FVDLs need be manipulated directly (for example as part of an build script)
> On Sat, Jul 30, 2011 at 2:44 PM, Alvaro Muñoz <alvaro.picapau at gmail.com> wrote:
> The only problem I see is that the FPR file is signed so nobody modifies it
> El 30/07/2011, a las 15:39, Dinis Cruz <dinis at ddplus.net> escribió:
>> Following the multiple blog entries prosted about O2's support for Fortify's FVDL, (sent to me by an O2 user) here is a description of a use-case that O2 should support:
>> I would shoot for the ability to disposition large *.fpr/*.fvdl files.
>> Here is a typical workflow:
>> 1. Scan is run code base generating an *.fpr file
>> 2. Code Reviews receive the file but because it is too large it cannot be opened by Fortify’s tool.
>> 3. Code reviewer uses O2 to open file and disposition or suppress issues by Category (XSS, SQL Injection, Path Tampering, etc.)
>> 4. Code Reviewer then saves dispositions to *.fpr file.
>> 5. The *.fpr is saved and on subsequent scan of the same application. The new.fpr file is merged with the old.fpr file.
>> 6. The code reviewer works on the merged.fpr to disposition items.
>> 7. Wash, rinse, repeat.
>> The data needs to be stored in the *.fpr file because most code assessment processes relies on merging the old fpr with the new *.fpr/*.fvdl on subsequent rereviews.
>> Next step(s) is to write a script(s) to implement this workflow, and try to figure the best GUIs to enable it.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 2486 bytes
Desc: not available
Url : https://lists.owasp.org/pipermail/owasp-o2-platform/attachments/20110801/119fb7ee/attachment.bin
More information about the Owasp-o2-platform