Thanks that is the exact kind of artifact I was looking for - though I do understand that
its current state may not be 4.0.
Regarding the NIST controls; yes I know this is eventually coming down the pike (at least
as of last I heard), but there is a need to address accreditations in the interim. And
as the Navy is my branch of interest, I expect it may still be a little while until these
controls are fully replaced.
If in the future this also included the NIST controls, that would be very helpful in
POA&M transitions to the newer controls.
V/r
David W. Moessbauer
System Engineer
Progeny Systems Corporation
david.moessbauer(a)progeny.net
SIPR: david.moessbauer.ctr(a)progeny.spawar-chas.navy.smil.mil
(410) 627-5633 (M)
(703) 368-6107 x315 (O) / x125 (lab)
Sent from my Verizon Wireless 4G LTE Smartphone
-------- Original message --------
From: Jeffrey Blank <blank(a)eclipse.ncsc.mil>
Date: 09/03/2013 23:13 (GMT-05:00)
To: scap-security-guide(a)lists.fedorahosted.org
Subject: (nwl) Re: mappings to DISA STIG identifiers
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):
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(a)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(a)lists.fedorahosted.org
[mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of
Jeffrey Blank
Sent: Tuesday, September 03, 2013 9:30 PM
To: scap-security-guide(a)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(a)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(a)lists.fedorahosted.org
> [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf
> Of Shawn Wells
> Sent: Tuesday, September 03, 2013 3:25 PM
> Cc: scap-security-guide(a)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(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
> _______________________________________________
> scap-security-guide mailing list
> scap-security-guide(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
_______________________________________________
scap-security-guide mailing list
scap-security-guide(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
_______________________________________________
scap-security-guide mailing list
scap-security-guide(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
_______________________________________________
scap-security-guide mailing list
scap-security-guide(a)lists.fedorahosted.org