Known Good Auditing

Compliance auditing is all about consistency and conformance to a known good standard, and being able to demonstrate a system matches it repeatedly. If a system deviates from a known good value it is critical to know about it, so that you can isolate what happened and any impact that may result from the deviation. This is typically done with a combination of regex, expect, not_expect, and other similar types of compliance directives. This method is versatile and functional, but eventually hits a limitation when comparing two blobs of text. No matter how well-formed your regex syntax is, there simply isn’t a way around comparing a large blob of text against a known good value. With this in mind, you can utilize a feature that is designed to do this allowing for the comparison of a blob of text against a “known good” value.

For the feature to work, the user must copy the acceptable value to a known_good keyword. More than one good values are allowed but are separated by a comma. For example:

<custom_item>

Description: "EC2: DescribeRegions - 'Regions that are currently available'"

type: EC2

aws_action: "DescribeRegions"

xsl_stmt: "<xsl:template match=\"/\">"

xsl_stmt: "<xsl:for-each select=\"//ec2:item\">"

xsl_stmt: "Region: <xsl:value-of select=\"ec2:regionName\"/> End-Point: <xsl:value-of select=\"ec2:regionEndpoint\"/><xsl:text>&#10;</xsl:text>"

xsl_stmt: "</xsl:for-each>"

xsl_stmt: "</xsl:template>"

known_good: 'us-east-1:

Region: eu-west-1 End-Point: ec2.eu-west-1.amazonaws.com

Region: sa-east-1 End-Point: ec2.sa-east-1.amazonaws.com

Region: us-east-1 End-Point: ec2.us-east-1.amazonaws.com

Region: ap-northeast-1 End-Point: ec2.ap-northeast-1.amazonaws.com

Region: ap-northeast-2 End-Point: ec2.ap-northeast-1.amazonaws.com

Region: us-west-2 End-Point: ec2.us-west-2.amazonaws.com

Region: us-west-1 End-Point: ec2.us-west-1.amazonaws.com

Region: ap-southeast-2 End-Point: ec2.ap-southeast-2.amazonaws.com'

</custom_item>

Notice in the output that a diff is included for ease in auditing.

Use Cases

One of the most useful use cases of this feature is to create a “Gold Standard” audit with all known good values. For example, users would be able to run a scan against a target configured to meet the requirements, grab “known_good” values from the .nessus file, update the audit file, and run the scan again to receive an “all pass” result.

Miscellaneous

  • known_good overrides expect and not_expect but does take into account regex. So if a regex is specified, the output will be compared against the regex-filtered data.
  • More than one known_good can be specified in a rule but must be separated by a comma.
  • The feature is implemented as a standalone feature in an .inc file, and can be easily used in any Nessus plugin as well.