Adding enterprise capability - an includeConfig directive for audit.rules?

[Steve Grubb]

On Wednesday, March 27, 2013 08:38:07 PM Burn Alting wrote:
> All,
> 
> Has anyone considered allowing an includeConfig statement for
> audit.rules (or auditd.conf if need be)?
> 
> The action would be to, at that point in the parse (or the end of the
> file, if auditd.conf holds the directive), open the nominated directory
> and any files within, and parse them.
> 
> The idea is to allow for localization of audit. At an enterprise level
> one would deploy the common, corporate set of rules
> in /etc/audit/audit.rules. Should a local system need additional rules
> such as tailored file watches, workstation or capability specific
> monitoring, these could appear in files in the includeConfig directory.
> That way, distribution mechanisms such as puppet, rpm satellite server,
> apt repositories, etc can maintain the corporate set of rules without
> changing localized configurations on updates.

Sorry for the late reply, been out a bit and am trying to catch up on email.

Well...have you heard of SCAP? Its a whole framework for assessing the 
security posture of a system based on open standards to prevent vendor lockin. 
It can also allow for continuous monitoring, boot up attestation via TNC, 
patch management, and we are working on some basic level of remediation.

More info about SCAP can be found at these sites:
http://scap.nist.gov/
http://makingsecuritymeasurable.mitre.org/

We have an openscap project
http://www.open-scap.org/

There is an SCAP Security Guide which will become a STIG:
https://fedorahosted.org/scap-security-guide/

And its being integrated into various systems management tools. The reason I 
mention this is that currently there is no way that you could evaluate audit 
rules from an SCAP based tool with a decomposed set of audit rules. The OVAL 
interpreter is the limitation. It does not have any method of being able to 
smartly assemble the collective audit rules to assess if the system is in 
compliance. In the audit system, the order of rules matters and that is one of 
the problems OVAL would have to be specified and coded to understand.

So with SCAP in mind, the options seem to be:

1) Build a rule compiler that assembles a master audit.rules file from 
sources but only 1 set of rules are loaded.
2) Request a change in OVAL 5.11 to support this kind of setup. Sometime 
around 2014 NIST should have it approved and content developers can use it. 
This means holding off the functionality a bit because we can't allow audit 
configurations that cannot be monitored.
3) ??  (Any other ideas)

OVAL has limited capability for reading file formats. Changes in capability 
have a long lead time. Audit configuration is very important to be able to 
assess from SCAP. For example, the DISA STIG and USGCB would mandate it. I 
think someone is working on a DSS-PCI profile which would also include some 
form of audit rule tests.

In my opinion, the ability to assess the audit system's compliance has to take 
SCAP into account and solutions to allow drop in audit rule additions ought to 
fit within those limitations. I would imagine the same set of people that care 
about audit rules are nearly the same set of people that care about SCAP.

-Steve