Remediation requirements (was Checks vs. Fixes)

Shawn Wells shawn at redhat.com
Thu Oct 10 20:50:49 UTC 2013


On 10/8/13 9:47 AM, Truhn, Chad M CTR NSWCDD, CXA30 wrote:
> * 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...
>
>
wanted to quickly acknowledge the thread -- many of the govvies have 
been off and are just getting unburied. Jeff or myself will respond 
shortly to this, but you've hit the nail on many of these topics!

-- 
Shawn Wells
Director, Innovation Programs
shawn at redhat.com | 443.534.0130
@shawndwells



More information about the scap-security-guide mailing list