Remediation requirements (was Checks vs. Fixes)

Truhn, Chad M CTR NSWCDD, CXA30 chad.m.truhn.ctr at navy.mil
Tue Oct 8 13:47:59 UTC 2013


* I didn't want to highjack the other 'Checks vs. Fixes' thread so I'm
spinning off on to another one.

I have spent a lot of time thinking about just this type of thing.
Currently the conversation is on auditing rules, but I think the topic
applies in multiple areas with regards to automated remediation.  From
what I have seen there are two main ways that SSG is used:

1) Fully SSG compliant machine (or as close as possible) for policy
reasons from above (DoD mandates STIG compliance, the customer says so,
etc)
2) Mostly SSG compliant machine because we all want to be secure, but we
are willing to forgo certain aspects out of necessity or convenience.

Regardless of which side of this you are on, everyone wants a tool that
makes this process as easy as possible for them.  Unfortunately, this is
hard.  If we can contain each remediation step into it's own little
environment I think it's possible to make both sides mostly happy.

To make that tougher, you can't ever assume what state a machine is in
when the SSG is run against it.  It could be a brand new build with
completely stock files or it could be a machine that has been in
production for years and has various changes (compliant or not) that
can't be changed wholesale.  And then to make it even worse, we can't
all use the same tools (like Puppet and Augeas or even perl) which could
potentially make the job easier.  There was some talk about later
versions having extra capabilities when possible, but for now it's
keeping everything as generic as possible.

I think it comes down to requirements.  Obviously I don't make these
decisions, but from the conversations I have seen and IMO they include
something along the lines of:

1) Must use RHEL delivered tools only and sticking to the most common
tools
	-- A conversation went on earlier this year where bash was
chosen as almost every machine has it.  I believe there was talk of
later versions supporting other tools though.

2) Each remediation step should take care of all things needed to make
that finding compliant, but should NOT change the way another finding is
handled
	-- To use audit as an example:  Which finding would do the
wholesale replace of the audit.rules file?  
		-- What happens if that finding is already satisfied and
the file isn't replaced and all other audit.rules findings are still
open?  
		-- Or if you replace it wholesale with every audit
finding then you are doing duplicate work and potentially blowing away
valid, non-SSG enforced changes.  Just because I have one line wrong
doesn't mean I want every line to be right.

3) No remediation change should be dependent on another remediation
change
	-- Similar to #2, but rather than step A breaking step B, step B
should not rely on step A in order for step B to be compliant


I am sure there are others that I am not thinking of right now, but I
hope I got the point across.  If these can be pretty clearly defined I
think a lot of the questions I see on this list could be answered by
stepping through this list.  It's not always the easy way, but I would
argue it's the RIGHT way.  And if someone wants to skip a remediation
step (-e 2, for example) everything else should apply as needed and then
the user can go on their merry way.  It would be a lot of Regex
terribleness, but I think it would be the most portable from system to
system and site to site.

Does that sound reasonable?

* I wish I could think of a good 'Do it right the first time' quote...



- Chad





More information about the scap-security-guide mailing list