fortify2hdf not recognizing/converting FVDL file -- works in deprecated heimdall_tools

[jamesbeegen]

Running into an issue where using containerized saf-cli will not recognize the input fvdl file:

docker run --rm -v $(pwd):/share -t mitre/saf convert fortify2hdf -i /share/audit.fvdl -o /share/audit-hdf.json

Output

Running this conversion in the deprecated heimdall_tools in a container yields a successful conversion into HDF

docker run --rm -v $(pwd):/share -t mitre/heimdall_tools fortify_mapper -f /share/audit.fvdl -o /share/audit-hdf.json 

Why isn't the saf-cli recognizing the fvdl file, but the deprecated tools do? @corymichaelmurray

[Amndeep7]

Hi @jamesbeegen and @corymichaelmurray,

It seems like a bug might've been introduced when we did the transition from Ruby to Typescript as we moved from heimdall_tools to the SAF CLI. Thanks for bringing this to our attention. It would really help us out if you could provide a minimal sample file that is appropriately anonymized which we can use to test with.

[jamesbeegen]

Thanks for getting back to us. A sample file can be found here : Sample FVDL File

@corymichaelmurray

[Amndeep7]

Hi @jamesbeegen @corymichaelmurray, had a chance to look at this issue just now. For the exact issue you ran into, please use the latest version of the SAF CLI (1.1.14) and it should run 'successfully' in order to generate an HDF file. However, this file still has issues.

The reason as to why is that a lot of the time, like in the case of fortify, we don't have access to an official schema so we are instead forced to develop a mapper empirically based off of the samples that we can get. It seems like the schema that we were assuming does not line up to your sample file.

As an example, when we try to set the 'impact' attribute in the HDF file, we look for 'DefaultSeverity' in the FVDL file. However, that attribute does not exist in your sample. The closest attribute i can find is 'InstanceSeverity'.

082622.audit.fvdl.json.txt

This is the HDF file that gets generated at the moment - github got mad about it being json so just remove the '.txt' from the filename in order to view it as json.

[jwebb7611]

For the purposes of mapping, is it based off of the 800-53rev4 or 80053rev5?

[aaronlippold]

We use the CCI_XML file to map a lot of the things and use the 'oldest' control found so if that has been updated with the new r5 cci file then it would use the rev5. For some of the mappings we did some manual mapping that we have in spreadsheets in the codebase we we may need to update so there may be a little work there. Happy to work with everyone on it.

[ejaronne]

Currently, rev 4. https://github.com/mitre/heimdall2/blob/master/libs/hdf-converters/src/mappings/CciNistMappingData.ts is based on older CCI list from https://public.cyber.mil/stigs/cci/, which only had cci to NIST mappings for rev 4 and earlier (rev 3, 1, etc). The latest CCI list associates many existing CCIs with the (typically same) rev 5 version of the NIST control, as well as introduces brand new CCIs that are associated with rev 5. We're working on updating that list.