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

[Steve Grubb]

On Wednesday, April 03, 2013 09:37:23 PM Burn Alting wrote:
> Thanks for these comments Steve.
> 
> I will come up with a solution based on option one. Perhaps along the
> line of a script (to suit both auditd.init and auditd.service) that
> 	a. Looks for a known directory, say /etc/audit/auditd.rules

I was thinking something like /etc/audit/rules.d/  or something ending in '.d' 
under the audit directory so that selinux labels are the same.

> 	b. If not empty, it will concatenate all files of the form xxx.rules,
> stripping comments and blank lines. The xxx will determine sort.

Sure. I think some people prefix numbers to the name to help guide the ordering 
like udev.


> 	c. If the resultant file is not empty, it can
> replace /etc/audit/audit.rules.

Sure. The question is should it do that always on start? What about reload? 
Should it replace it only if its changed? (writing to /etc/audit/audit.rules 
is an auditable event...we probably want to minimize that.)

Thanks,
-Steve


> On Tue, 2013-04-02 at 14:03 -0400, Steve Grubb wrote:
> > 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