coming soon: consistency checking scripts

Kevin Spargur kspargur at redhat.com
Wed Mar 14 18:46:54 UTC 2012


On 03/14/2012 02:23 PM, David Egts wrote:
> ----- Original Message -----
>> On 3/14/12 12:49 PM, "David Egts"<degts at redhat.com>  wrote:
>>
>>> ----- Original Message -----
>>>> On Wednesday, March 14, 2012 12:41:51 AM Spencer R. Shimko wrote:
>>>>> On 3/13/12 9:52 PM, "Shawn Wells"<shawn at redhat.com>  wrote:
>>>>>> On 3/13/12 9:44 PM, Steve Grubb wrote:
>>>>>>> On Tuesday, March 13, 2012 07:37:07 PM Jeffrey Blank wrote:
>>>>>>>>>   A nicely loaded question.
>>>>>>>>>
>>>>>>>>>   As you've noticed, we don't have any<fix>   tags.
>>>>>>>>>   Such commands, when available, are just in
>>>>>>>>>   the<description>
>>>>>>>>>    or
>>>>>>>> possibly
>>>>>>>>
>>>>>>>>>   <rationale>, and marked up with xhtml.
>>>>>>>>>
>>>>>>>>>   I also might expect there to be plenty of<Rule>s which
>>>>>>>>>   simply won't
>>>>>>>>>   have<fix>   tags (such as edits to configuration files
>>>>>>>>>   like
>>>>>>>>>   pam.d/system-auth or sshd_config, or disk partitioning
>>>>>>>> instructions).
>>>>>>>>
>>>>>>>>>   On the plus side, it would obviously be a cheap/easy way
>>>>>>>>>   to
>>>>>>>>>   annotate
>>>>>>>>>   remediation instructions.  On the minus side, I see it as
>>>>>>>>>   leading to
>>>>>>>>>   sed/awk in some of our output documents, and think this
>>>>>>>>>   will
>>>>>>>>>   make
>>>>>>>> them
>>>>>>>>
>>>>>>>>>   less approachable/comprehensible.  (I'm certainly fine
>>>>>>>>>   with
>>>>>>>>>   it being
>>>>>>>>>   there, and hidden.)
>>>>>>>>>
>>>>>>>>>   Is there a project/effort/output which would benefit
>>>>>>>>>   from<fix>
>>>>>>>> tags?
>>>>>>>>
>>>>>>> Yes. openscap can generate shell scripts from<fix>   tags. The
>>>>>>> gentoo
>>>>>>>
>>>>>>> demo shows
>>>>>>>
>>>>>>> this. The aqueduct project is creating remediation scripts in
>>>>>>> shell.
>>>>>>>
>>>>>>> So, it
>>>>>>>
>>>>>>> sounds like we ought to work towards one document with
>>>>>>> guidance,
>>>>>>> check,
>>>>>>>
>>>>>>> and fix
>>>>>>>
>>>>>>> so that we can make remediation easy.
>>>>>> FWIW, a big +1 to this.
>>>>> I understand that we can generate whatever we want from the
>>>>> <fix>
>>>>> tags but
>>>>> I want to ensure the generated content is consumable by the
>>>>> larger
>>>>> community.  Are the<fix>  tags flexible enough to support the
>>>>> forward
>>>>> movement of system configuration tools?
>>>>>
>>>>> I know the rest of this is long but bear with me here because,
>>>>> much
>>>>> like
>>>>> SCAP, there are a lot of relationships that must be addressed by
>>>>> a
>>>>> successful solution.
>>>> There are hard fixes and there are easy fixes. Let's look at one
>>>> publicly
>>>> available validated solution:
>>>>
>>>> http://people.redhat.com/sgrubb/files/usgcb/rhel5/workstation-ks.cfg
>>>>
>>>> NIST published an exact copy of that file. Look at what is being
>>>> done
>>>> to configure
>>>> the system. The vast majority break down to this:
>>>>
>>>> chkconfig
>>>> chmod
>>>> echo
>>>> gconftool-2
>>>> mkdir
>>>> rpm --import
>>>> sed
>>>> touch
>>>> useradd
>>>>
>>>> They are all one liners. Now if a package was required and it
>>>> needing
>>>> to be in a
>>>> specific configuration and it drags in dependencies and they also
>>>> have changes to
>>>> their configs or perhaps have multilpe daemons which may or may
>>>> not
>>>> need to be
>>>> enabled or disabled...we have a hard problem. In which case, maybe
>>>> the solution
>>>> is:
>>>>
>>>> echo "Requirement xyz cannot be met by this script, please solve
>>>> it
>>>> manually. Do
>>>> you understand? [y/n]"
>>>> read ANS
>>> That's a great idea.  It would also be good to have a yum-like "-y"
>>> option for automation.  One wouldn't want to run the remediation on
>>> 1000
>>> systems interactively by hand.
>> Are you thinking of something significantly different from the
>> secstate
>> effort?
>>
>> https://fedorahosted.org/secstate/
> If that's the accepted approach, great!  I'm just saying that automation (however we do it) is highly desired.
>
> So does SSG plan to provide secstate remediation content?  Apologies for the n00b question.
>
> Also, it looks like secstate is tied closely with Puppet (good intro for me = https://fedorahosted.org/secstate/wiki/RemediationContentHowTo).  How would one use secstate if their DAA doesn't allow packages from community supported sources (i.e., puppet from EPEL)?  Maybe Red Hat's possible formal support for Puppet in the future will eventually solve this, but I wonder what the plan would be in the mean time.
>
> Thanks for helping me learn more about this Spencer!
>
> Dave

Leveraging the SSG for fix automation would be ideal.  We already have a 
milestone for a complete prose guide that is being worked toward.  I'd 
suggest we add another for a guide with the complete prose and check 
content.  We can then add a third milestone for complete fix content, 
even if we have to resort to "go forth and remediate" for the more 
complex fixes.

-Kevin


>
>
>>
>>> I wonder if it would be good to have a to-do checklist / report at
>>> the
>>> end in say .csv?  Do as much as possible in an automated way, and
>>> then
>>> have a to-do list that people can print out, check the box when done
>>> with
>>> an element, do the next one, etc.
>> I forgot to mention this part below.  This is exactly what we are
>> working
>> towards.  We will generate a report that can used as part of the
>> larger
>> body of C&A evidence.  It will also generate an SRTM and developer
>> guidance ala SNAC.  This will effectively be a table that includes
>> automated and manual controls.  Then they can fill in the gaps.  We
>> will
>> be upstreaming the content and accompanying transformations into ssg
>> (aside from DCID 6/3 which is FOUO).
>>
>> --Spencer
>>
>>> Dave
>>>
>>>
>>>
>>>> And then when/if the remediation standards mature, we can address
>>>> the
>>>> hard
>>>> problems. Just making the simple solutions available is a big
>>>> first
>>>> step in the
>>>> right direction.
>>>>
>>>> -Steve
>>>>
>>>>
>>>>> While I would like to see a single source for all SCAP content,
>>>>> the
>>>>> mechanisms to address remediation under SCAP aren't mature.  It
>>>>> has
>>>>> taken
>>>>> the Puppet/Augeas teams a lot of effort to get to the current
>>>>> state
>>>>> which
>>>>> can be leveraged to address remediation while SCAP-standard
>>>>> remediation
>>>>> matures.  It may not be the ideal solution but it is a huge step
>>>>> in
>>>>> the
>>>>> right direction.  I think the goal here, and I think this is
>>>>> what
>>>>> Steve is
>>>>> saying, should be to start implementing a binding between the
>>>>> XCCDF, OVAL,
>>>>> and remediation content.  Of course this is supported by the
>>>>> defined
>>>>> standards but someone has to write the content to actually
>>>>> perform
>>>>> the
>>>>> binding.
>>>>>
>>>>> As Jeff states, there are going to be gaps. There won't always
>>>>> be
>>>>> remediation content available for numerous reasons.  We are
>>>>> trying
>>>>> to
>>>>> address part of that problem. Tresys is currently mapping
>>>>> several
>>>>> requirement sets to controls and implementation (DCID 6/3 PL4
>>>>> High/High,
>>>>> CNSSI 1253, NIST 800.53).  We are starting with the SNAC guide
>>>>> to
>>>>> provide
>>>>> the implementation guidance.  Where necessary we are writing
>>>>> Puppet
>>>>> content to address controls and remediation.  We are also
>>>>> writing
>>>>> OVAL
>>>>> content to complement and test the remediation content.
>>>>>
>>>>> I would appreciate comments and feedback on the above but I'm
>>>>> really
>>>>> interested in knowing the community's opinion on how to handle
>>>>> binding
>>>>> XCCDF/OVAL to remediation in the short-term.  The hope is that
>>>>> the
>>>>> remediation language will mature and the  remediation content we
>>>>> are all
>>>>> working on now can be re-used in the future.
>>>>>
>>>>> CLIP was developed to reduce the burden associated with creating
>>>>> a
>>>>> C&A'able solution based on Red Hat Enterprise Linux.  This has
>>>>> been
>>>>> accomplished through configuration, customization of packages,
>>>>> and
>>>>> providing supporting evidence mapping the implementation into
>>>>> requirements
>>>>> and controls.  We are now taking the next steps by:
>>>>> 1. ensuring all targeted requirement sets are in XCCDF,
>>>>> 2. ensuring the implementation guidance is available in a
>>>>> similar
>>>>> format
>>>>> (SNAC->XCCDF),
>>>>> 3. filling the implementation documentation gaps found in #2
>>>>> above
>>>>> (basically adding to SNAC guidance),
>>>>> 4. determining where OVAL content can test the implementation,
>>>>> 5. ensuring OVAL content is developed that addresses the gap
>>>>> identified in
>>>>> #4 above,
>>>>> 6. developing puppet content to address as many reqs and
>>>>> controls
>>>>> as we
>>>>> can.
>>>>>
>>>>> As if there aren't enough goals described above - I think the
>>>>> pen-ultimate
>>>>> goal for reqs management from Tresys' upcoming XCCDF/OVAL
>>>>> contributions to
>>>>> scap-security-guide is to see SCAP content that can be consumed
>>>>> by
>>>>> developers, accreditors, and admins.  We hope this binding will
>>>>> be
>>>>> flexible enough to facilitate tying the XCCDF to other types of
>>>>> content in
>>>>> the future, like OCIL.
>>>>>
>>>>> Thanks,
>>>>> --Spencer
>>>>>
>>>>>>> There are some fixes that are hard. I'd like to say we should
>>>>>>>
>>>>>>> incorprate the easy
>>>>>>>
>>>>>>> ones and identify the hard ones. Whene we have several of
>>>>>>> these,
>>>>>>> then
>>>>>>>
>>>>>>> we can
>>>>>>>
>>>>>>> start looking for how to solve the hard problems.
>>>>>> I'm not to concerned about the hard fixes, largely as they've
>>>>>> already
>>>>>> been addressed through CLIP and/or Aqueduct. For example,
>>>>>> DoDIIS
>>>>>> open
>>>>>> sourced their baseline (accredited to PL3) and we can pull a
>>>>>> good
>>>>>> bit
>>>>> >from that.
>>>>>> _______________________________________________
>>>>>> scap-security-guide mailing list
>>>>>> scap-security-guide at lists.fedorahosted.org
>>>>>> https://fedorahosted.org/mailman/listinfo/scap-security-guide
>>>>> _______________________________________________
>>>>> scap-security-guide mailing list
>>>>> scap-security-guide at lists.fedorahosted.org
>>>>> https://fedorahosted.org/mailman/listinfo/scap-security-guide
>>>> _______________________________________________
>>>> scap-security-guide mailing list
>>>> scap-security-guide at lists.fedorahosted.org
>>>> https://fedorahosted.org/mailman/listinfo/scap-security-guide
>>>>
>>> --
>>> David D. Egts, RHCA, RHCSS #805007796228001
>>> Principal Architect, Red Hat, Inc.
>>> _______________________________________________
>>> scap-security-guide mailing list
>>> scap-security-guide at lists.fedorahosted.org
>>> https://fedorahosted.org/mailman/listinfo/scap-security-guide
>> _______________________________________________
>> scap-security-guide mailing list
>> scap-security-guide at lists.fedorahosted.org
>> https://fedorahosted.org/mailman/listinfo/scap-security-guide
>>



More information about the scap-security-guide mailing list