mappings to DISA STIG identifiers

Jeffrey Blank blank at eclipse.ncsc.mil
Wed Sep 4 03:13:31 UTC 2013


Ah, gotcha.

I can't find the authoritative memo that says so (DIARMF-related?),
but what I'd been hearing for a while is that the DoD will be adopting
the NIST 800-53 controls (via CNSS 1253).  Can anyone else speak to
this from the policy angle?  I assume this is why the older DoD IA
controls are not explicitly included with the RHEL 6 STIG. I assume
this represents represents DoD thinking (11 months ago, anyway):
http://csrc.nist.gov/groups/SMA/ispab/documents/minutes/2012-10/ispab_oct2012_dcussatt_dod-rmf-transition-brief.pdf

As for such a table, we're generating something similar already:
http://scap-securityguide.rhcloud.com/RHEL6/output/table-stig-rhel6.html

However, the STIG-related references here likely aren't accurate, as
we haven't account for any changes made by FSO, so I can't recommend
using this yet.  Once we can synchronize with them and establish the
undesirability of any future private changes, it should be possible to
scalably reduce costs for C&A activities by providing such
commonly-used tables in the project.





On Tue, Sep 3, 2013 at 10:08 PM, Moessbauer, David
<david.moessbauer at progeny.net> wrote:
> At a minimum, I would suggest that such a table would contain
>
> a unique identifier such as the Group ID (Vulid) or the Rule Version
> (STIG-ID),
> the CCE number currently detailed in the SCAP results and
> the Severity (CAT).
>
> With this all can be easily linked back to the pertinent STIG.  The IA
> Control was also presented in the prior iteration of the UNIX Checklist and
> earlier versions of the RHEL5 XCCDF.
>
>
> An IAC is the 'Information Assurance Control' as defined in DoDD 8500.01 and
> enumerated in DoDI 8500.2.
>
> The definition detailed in paragraph E2.1.19 of Directive states that "an IA
> Control is an objective IA condition of integrity, availability or
> confidentiality achieved through the application of specific safeguards or
> through the regulation of specific activities that is expressed in a
> specified format, i.e., a control number, a control name, control text, and
> a control class. Specific management, personnel, operational, and technical
> controls are applied to each DoD information system to achieve an
> appropriate level of integrity, availability, and confidentiality in
> accordance with reference"
>
> The following is an excerpt of a couple of them as displayed in this
> Instruction, where the 5 digit identifier is the IAC (IE: 'DCCB-2')
>
> DCCB-2 Control Board
> All information systems are under the control of a chartered Configuration
> Control Board
> that meets regularly according to DCPR-1. The IAM is a member of the CCB.
>
> DCCS-2 Configuration Specifications
> A DoD reference document such as a security technical implementation guide
> or security
> recommendation guide constitutes the primary source for security
> configuration or
> implementation guidance for the deployment of newly acquired IA- and
> IA-enabled IT
> products that require use of the product's IA capabilities. If a DoD
> reference document is
> not available, the system owner works with DISA or NSA to draft
> configuration guidance
> for inclusion in a Departmental reference guide.
>
> DCCT-1 Compliance Testing
> A comprehensive set of procedures is implemented that tests all patches,
> upgrades, and
> new AIS applications prior to deployment.
>
>
> BTW:  apologize for my prior hijacking of subject lineā€¦
>
> v/r
>
> David Moessbauer
> (410) 627-5633 (M)
>
> The Information contained in or attached to this communication may be
> confidential and privileged proprietary intended only for the individual/s
> or entity to whom/which it is addressed. Any unauthorized use, distribution,
> copying or disclosure of this information is strictly prohibited. If you
> have received this communication in error please contact the sender
> immediately and delete from your system.
>
>
> -----Original Message-----
> From: scap-security-guide-bounces at lists.fedorahosted.org
> [mailto:scap-security-guide-bounces at lists.fedorahosted.org] On Behalf Of
> Jeffrey Blank
> Sent: Tuesday, September 03, 2013 9:30 PM
> To: scap-security-guide at lists.fedorahosted.org
> Subject: (nwl) mappings to DISA STIG identifiers
>
> I have started a new subject/thread for this discussion.
>
> Please note: Subscribers to the list should never reply to any message,
> particularly one with a complex subject, and move to an off-topic
> discussion.  It quickly results in confusion for mail clients which perform
> threaded display, as well as the list's web archives.
>
> As to David's question, there has been some informal discussion, but we have
> also not fully settled on how to do this.  This will be a topic of an
> upcoming discussion, and it will also be key to ensuring that there is good
> correspondence between the STIG profile in SSG and the STIG which FSO
> releases.
>
> The CAT level should be identified as Severity (and this should be present
> in scan results).
>
> Assuming your desired output is a table, can you describe what columns would
> be in it?
>
> What's an IAC?
>
>
>
> On Tue, Sep 3, 2013 at 6:25 PM, Moessbauer, David
> <david.moessbauer at progeny.net> wrote:
>> A crucial piece of the current C&A Package is the need to appropriately
>> identify any vulnerabilities found via scans, inclusive of the CAT level,
>> both of which are identified in the STIG.  Aside from this, the STIG ID
>> provides means to identify the IAC of a given vulnerability as well.
>>
>> CCI mapping would help, however, as these are not unique, it does not
>> fully accomplish the task at hand.
>>
>> Speaking as one that completes C&A Packages for purposes of ATO
>> acquisition, I would argue that this is a critical mapping.
>>
>> v/r
>>
>> David Moessbauer
>> (410) 627-5633 (M)
>>
>> The Information contained in or attached to this communication may be
>> confidential and privileged proprietary intended only for the individual/s
>> or entity to whom/which it is addressed. Any unauthorized use, distribution,
>> copying or disclosure of this information is strictly prohibited. If you
>> have received this communication in error please contact the sender
>> immediately and delete from your system.
>>
>>
>> -----Original Message-----
>> From: scap-security-guide-bounces at lists.fedorahosted.org
>> [mailto:scap-security-guide-bounces at lists.fedorahosted.org] On Behalf
>> Of Shawn Wells
>> Sent: Tuesday, September 03, 2013 3:25 PM
>> Cc: scap-security-guide at lists.fedorahosted.org
>> Subject: Re: Possibility of Fedora SCAP content to be served by SCAP
>> security guide repository (either as subdirectory or via separated branch)?
>>
>> On 9/3/13 2:22 PM, Moessbauer, David wrote:
>>> Is there a matrix that can be referenced that will map the DISA
>>> STIG-ID (or Group ID) to the CCE Audit IDs?  ...or any other mapping
>>> that can be deduced
>>>
>>> In Example:
>>> Group ID (Vulid):  V-38487
>>> Group Title:  SRG-OS-000103
>>> Rule ID:  SV-50288r1_rule
>>> Rule Version (STIG-ID):  RHEL-06-000015
>>
>>
>> That metadata hasn't been added... to be honest, nobody has found the
>> mappings meaningful enough to do. Can you help us understand how it'd
>> benefit you?
>>
>> Right now SSG rules are mapped back to the CCIs through various <ref>
>> tags, e.g.:
>> <ref nist="AC-6,AU-9" disa="22,32" />
>>
>> We could easily extend this to include a "stigid" name-pair value,
>> should (a) the community be convinced this would help end-users, and
>> (b) volunteers to perform the mapping
>> _______________________________________________
>> scap-security-guide mailing list
>> scap-security-guide at lists.fedorahosted.org
>> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
>> _______________________________________________
>> scap-security-guide mailing list
>> scap-security-guide at lists.fedorahosted.org
>> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
> _______________________________________________
> scap-security-guide mailing list
> scap-security-guide at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
>
>
> _______________________________________________
> scap-security-guide mailing list
> scap-security-guide at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
>


More information about the scap-security-guide mailing list