No correlation is interesting too. Part 2: SCA customization: Custom Source rules

As discussed in part 1 of this blog post WI misconfiguration can lead to no correlation. Now, we show how SCA misconfiguration can also lead to no correlation.

For a particular application, WI was showing issues in the category "Privacy Violation: Credit Card Number Disclosed" and "Privacy Violation: Social Security Number Disclosure". While the SSN issues correlated nicely with SCA issues, the CCN issues did not. In fact, SCA wasn't finding a single issue in the CCN Disclosed category in the first place, so no wonder there was no correlation.

The underlying problem was fairly obvious too. By default the HP Fortify SCA rules keep track of CCN and SSN when they are stored in variables which are unambiguous. For example, the SSN in this application was stored in a field called "ssn" which was tracked by default. However, the CCN was stored in a field "ccNum" which is not one of the field or variable names which we track by default. To resolve this, a characterization rule can be written to keep track of these custom field and variable names. An example of such rule is:

            <CharacterizationRule formatVersion="3.7" language="dotnet">
                <RuleID>SAMPLE_RULE_ADDING_PRIVATE_FLAG_001</RuleID>
                <StructuralMatch><![CDATA[
                    FieldAccess fa: fa.field.name matches "ccNum" and
                    not fa in [AssignmentStatement: lhs.location is [Location l: l.transitiveBase === fa.transitiveBase]]
                    ]]></StructuralMatch>
                <Definition><![CDATA[
                    TaintSource(fa, {+PRIVATE})
                    ]]></Definition>
            </CharacterizationRule>

When the field in the class is retrieved through a getter, a even more trivial rule can be written (more trivial, because click through the wizards and the rule will be written for you):

            <DataflowSourceRule formatVersion="3.2" language="dotnet">
                <RuleID>SAMPLE_RULE_ADDING_PRIVATE_FLAG_002</RuleID>
                <TaintFlags>+PRIVATE</TaintFlags>
                <FunctionIdentifier>
                    <NamespaceName>
                        <Value>App.Name.Space</Value>
                    </NamespaceName>
                    <ClassName>
                        <Value>CCProcessing</Value>
                    </ClassName>
                    <FunctionName>
                        <Pattern>GetSavedCC</Pattern>
                    </FunctionName>
                    <ApplyTo implements="true" overrides="true" extends="true"/>
                </FunctionIdentifier>
                <OutArguments>return</OutArguments>
            </DataflowSourceRule>

By inserting the rule, SCA was able to find the issues shown by WI. More importantly, SCA was able to find issues which weren't found by WI. Turned out that WI only scanned a portion of the application.

In short, it is important to exactly model your application in a static analysis tool to find the best results (reduce false positives and find all true issues). As it is not always obvious where a static analysis tool is missing true issues, a pen testing tool can help pointing out shortcomings in the result set. These shortcomings can then be modeled through custom rules. To write custom rules, the tools and documentation which SRG uses on day-to-day basis is available for our customers too.