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
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:
Description: "EC2: DescribeRegions - 'Regions that are currently available'"
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> </xsl:text>"
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'
Notice in the output that a diff is included for ease in auditing.
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.
not_expectbut 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_goodcan be specified in a rule but must be separated by a comma.
- The feature is implemented as a standalone feature in an
.incfile, and can be easily used in any Nessus plugin as well.