Checks vs. Fixes

fcaviggi at redhat.com fcaviggi at redhat.com
Fri Oct 4 12:50:23 UTC 2013


Hey Shawn,

I was thinking this trough last night - I was wondering if we can use 
checksums (sha256+) to determine if someone is using the "stock" 
configuration and replace it with a fully STIGed version - I'm thinking 
this would be best applicable to new installations of RHEL. I understand 
the need for  atomic fixes for pre-existing systems, where the SA has 
modified the defaults, but I can guarantee you that most people just 
want a STIG'ed box out of the gate on install. I'm just trying to think 
in terms of long term and short term goals - the quicker we can satisfy 
the majority of the users (the ones that want something STIG'ed out of 
the box) the better acceptance the product will have, the long term 
should be to modify things for the people that mucked with their 
configurations, which I'm arguing is a minority.

I go back to Star Trek II: Wrath of Khan with Spock, "It is logical. The 
needs of the many 
outweigh<http://www.imdb.com/name/nm0000638/?ref_=tt_trv_qu>...the needs 
of the few<http://www.imdb.com/name/nm0000559/?ref_=tt_trv_qu>...or the 
one."  We need to get the ship out of danger, and then worry about the 
needs of the few.

What do you think of my solution?

-Frank

On 10/03/2013 09:42 PM, Shawn Wells wrote:
> On 10/3/13 3:11 PM, fcaviggi at redhat.com wrote:
>> All,
>>
>> As a starting point for writing remediation fixes in the SSG - so, I 
>> did the following:
>>
>>     $ ls ~/scap-security-guide/RHEL6/input/checks/*.xml | awk '{ 
>> print $1 }' | sed s/\.[^\.]*$// > ~/checks
>>     $ ls ~/scap-security-guide/RHEL6/input/fixes/*.sh | awk '{ print 
>> $1 }' | sed s/\.[^\.]*$// > ~/fixes
>>     $ sdiff ~/fixes ~/checks | less
>>
>> There's fair a bit of work to be done for the fix remediations...
>>
>> Since I'm new to the project, I was wondering if there was any ideas 
>> or standards to how the SSG should distribute some of these fixes - 
>> for example - a wholesale replacement of the audit.rules and 
>> auditd.conf might be preferable than doing piecemeal sed's.
>
> It'd be omgz easier to `cp /usr/share/doc/audit-*/stig.rules 
> /etc/audit.rules`, and that likely is the right choice during an 
> initial provisioning process. But then SysAdmins tailor audit rules, 
> the system evolves, and we need to evaluate the audit.rules file 
> against specific auditing guidance items after the pristine 
> audit.rules template is manipulated.
>
> So, if a single rule must be remediated, we can't blow away the whole 
> audit.rules file. Super fun sed scripts it is =/
>
>
>> I also think the first script that needs to be run is to tar the 
>> current existing configurations (as a backup) before applying any fix 
>> just in case we do something that jacks the users modifications to 
>> the system.
>
> A prevailing thought has been to address backups once the remediations 
> are finished, as we'll have a better handle for which files will need 
> addressing.
>
> Forcing the backup (through XCCDF/OVAL) is tricky. One thought has 
> been to create an OVAL check -- which is listed first in the profile 
> -- which will *always* fail. The remediation for said OVAL would be to 
> perform the backups. Anyone have a better idea? =/
>
>> Anyway, just trying to get an idea of how to proceed set some goals 
>> for my contributions.
>
> These are /really/ good questions. Thanks for starting the conversation!
>
>
>
> _______________________________________________
> scap-security-guide mailing list
> scap-security-guide at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide


-- 
Frank Caviggia
Consultant, Public Sector
fcaviggi at redhat.com
(M) (571) 295-4560

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/scap-security-guide/attachments/20131004/1d226665/attachment.html>


More information about the scap-security-guide mailing list