RHEL7 scanning (UNCLASSIFIED)

Shawn Wells shawn at redhat.com
Wed Jul 2 02:40:01 UTC 2014


On 7/1/14, 12:11 PM, Shawn Wells wrote:
>
> On 7/1/14, 12:03 PM, Jan Lieskovsky wrote:
>> Hello Ray,
>>
>>    thank you for checking with us (and sorry for late reply).
>>
>> ----- Original Message -----
>>> >From: "Ray V CTR USARMY ARL Shaw (US)"<ray.v.shaw.ctr at mail.mil>
>>> >To: "SCAP Security Guide"<scap-security-guide at lists.fedorahosted.org>
>>> >Sent: Tuesday, July 1, 2014 5:36:24 PM
>>> >Subject: RE: RHEL7 scanning (UNCLASSIFIED)
>>> >
>>> >Classification: UNCLASSIFIED
>>> >Caveats: NONE
>>> >
>>> >Hope I'm not being a bother, but if possible, would someone mind 
>>> weighing in
>>> >on this?  Scanning on RHEL7 isn't particularly useful right now, 
>>> and we'd
>>> >like to lock it down as soon as possible.
>>> >
>>> >Thanks,
>>> >
>>> >--
>>> >Ray Shaw (Contractor, STG)
>>> >Army Research Laboratory
>>> >CIO, Unix Support
>>> >
>>> >
>>>> > >-----Original Message-----
>>>> > >From: Shaw, Ray V CTR USARMY ARL (US)
>>>> > >Sent: Tuesday, June 24, 2014 10:31 AM
>>>> > >To: 'SCAP Security Guide'
>>>> > >Subject: RHEL7 scanning (UNCLASSIFIED)
>>>> > >
>>>> > >Classification: UNCLASSIFIED
>>>> > >Caveats: NONE
>>>> > >
>>>> > >By default, it looks like only the partition checks are enabled 
>>>> when
>>>> > >scanning with the stig-rhel7-server-upstream profile (on 
>>>> RHEL7).  If I
>>>> > >edit
>>>> > >the profile to enable all of the ones that RHEL6 has enabled 
>>>> (and then
>>>> > >remove the few that don't exist for RHEL7), I get a total of 56 
>>>> checks.
>>>> > >
>>>> > >[If anyone is curious, out of the box it passes 35 and fails 21,
>>>> > >assuming
>>>> > >it's partitioned correctly.]
>>>> > >
>>>> > >We're starting on RHEL7 to prepare our configuration management 
>>>> system,
>>>> > >etc.
>>>> > >for when 7 is blessed and we can deploy it, and of course STIGs 
>>>> are a
>>>> > >big
>>>> > >part of that.  Is it reasonable to expect that they will closely
>>>> > >parallel
>>>> > >the RHEL6 STIG?  Permissions/ownership, audit rules, sysctl, 
>>>> GDM, etc.
>> There definitely is motivation the RHEL-7 content to cover same areas 
>> of the
>> system as RHEL-6 one was / is doing (plus add specific rules for the 
>> enhancements /
>> new features that appeared in RHEL-7).
>>
>> Of course this effort will take some time, therefore I would not want 
>> to promise
>> any ETAs / time periods to you. Couple of the reasons for the delayed 
>> RHEL-7 content
>> delivery:
>> * existing RHEL-6 rules need to be re-tested against RHEL-7 system 
>> (if they still work
>>    properly),
>> * some features / capabilities will require OVAL language 
>> enhancements (this process
>>    by itself takes some time),
>> * the newly introduced features will require completely new rules to 
>> be written.
>>
>> In short yes, there definitely is willingness RHEL-7 content to be as 
>> much capable as
>> currently the RHEL-6 one is. But I would like to avoid to need to 
>> express some statements,
>> when this will happen (basically the community can expect the RHEL-7 
>> content to be
>> improved in the upcoming releases).
>>
>> That's fwiw regarding SCAP content author PoV. For the timeline / 
>> updates regarding official RHEL-7
>> STIG content evolution (& locations for its download etc.), please 
>> ask Shawn
>> <- Shawn can you possibly weigh on this?
>
> I've been speaking with DISA FSO, and have the new RHEL7 OS SRG 
> requirements. Will get them posted this afternoon (US Eastern) with a 
> proper writeup of where things are headed.

Created an initial wiki page to track RHEL7 STIG progress. Not much 
there, but will be the primary landing page for updates, documents, and 
general communication:
https://github.com/OpenSCAP/scap-security-guide/wiki/RHEL7-STIG-Project-Page

You'll find a link to DISA FSO's requirements on the wiki page. FSO 
released a new OS SRG this year for which RHEL7 will have to attest 
against. A direct link:
http://people.redhat.com/swells/RHEL7_STIG_REQUIREMENTS.xlsx

Next Steps:
- In the second column of FSO's spreadsheet you will notice the CCI 
number. The next step is to sort through each CCI and bucket them as 
follows:
     * Impractical Requirement: aka, expecting RHEL to antivirus scan 
all incoming TCP/IP packets: RHEL is not an A/V
     * Cannot be configured out of compliance: aka, automatic auditing 
of user login events doesn't require a specific configuration check, as 
this is hard coded behavior
     * Permanent Findings: Things that will always be a finding, and 
must be mitigated
     * Questionable Requirement: Things we need clarification on

     I've created a wiki page to start the bucketing process. I'll be 
going through the requirements over the next couple days... extra eyes 
are most welcome! Please add comments here:
https://github.com/OpenSCAP/scap-security-guide/wiki/RHEL7-STIG-Settings-Review

- Once the spreadsheet is reviewed, are there things which should be 
added into the STIG which were not covered in a CCI? Place them on the wiki:
https://github.com/OpenSCAP/scap-security-guide/wiki/RHEL7-STIG-Settings-Review#non-requirement-but-should-be-included

Once we've a handle on the "CCI bucketing," Red Hat will formally submit 
the comments to DISA FSO. They'll make a determination on which 
requirements will be dropped (e.g. if they agree on Impractical / 
Questionable items), and which CCI requirements can be labelled as 
Permanent Non-Findings (aka, we don't have to write guidance against 
them at all). Ideally, we'll be submitting that list to DISA FSO on Friday.

Wanted to get this quick call to action out to the community. It's 2239, 
I'm still at the office, and I'm now heading home to bed ;) Will respond 
more in the AM to outline estimated timelines.

Shawn


More information about the scap-security-guide mailing list