DIACAP vs DIARMF & STIGs & CCEs.

[Greg Elin]

I was wondering if anyone was available to explain DIACAP transition to
DIARMF and what it means for STIGS and SSG?

Happy to have a public email thread, but also happy to take it offline.

Here is my summary understanding.

DoD developed its own list of information assurance controls under DIACAP
(DoD Information Assurance Certification and Accreditation Process).

In recent years (2010-2012), the DIACAP started transitioning to  DIARMF
(DoD Information Assurance Risk Management Framework) to align it with NIST
RMF, and to bring the catalog of controls into alignment with the controls
listed in 800-53, with some special overlays available for Defense-related
systems.

As of Spring 2014, that transition is complete.

But I'm trying to make sure I understand how the STIGs play into all of
this. When I look at the STIGs, I see different control number tracking
than from the 800-53s or the CCEs.

Is it the case that the Control catalog is now 800-53r4 for both civilian
and DoD, but DoD is using STIGs to get to platform specific details while
civilian side is using CCEs?

If there were just 5 or 6 documents about current/active control catalogs,
what would they be? 800-137, 800-53, 8510.1 and/or ... ???

Thanks...

Greg Elin
http://govready.org - Making FISMA compliance easier for innovators

email: [e-mail]
phone: [phone]

[Shawn Wells]

On 9/15/14, 5:02 PM, Greg Elin wrote:
> I was wondering if anyone was available to explain DIACAP transition
> to DIARMF and what it means for STIGS and SSG?
>
> Happy to have a public email thread, but also happy to take it offline.
>
> Here is my summary understanding.
>
> DoD developed its own list of information assurance controls under
> DIACAP (DoD Information Assurance Certification and Accreditation
> Process).
>
> In recent years (2010-2012), the DIACAP started transitioning to
>  DIARMF (DoD Information Assurance Risk Management Framework) to align
> it with NIST RMF, and to bring the catalog of controls into alignment
> with the controls listed in 800-53, with some special overlays
> available for Defense-related systems.
>
> As of Spring 2014, that transition is complete.
>
> But I'm trying to make sure I understand how the STIGs play into all
> of this. When I look at the STIGs, I see different control number
> tracking than from the 800-53s or the CCEs.
>
> Is it the case that the Control catalog is now 800-53r4 for both
> civilian and DoD, but DoD is using STIGs to get to platform specific
> details while civilian side is using CCEs?
>
> If there were just 5 or 6 documents about current/active control
> catalogs, what would they be? 800-137, 800-53, 8510.1 and/or ... ???
>
> Thanks...

The various RMF implementations call out NIST 800-53 as the place to
derive implementation requirements.

When DoD (via DISA FSO) goes through NIST 800-53 and pulls out things
they care about, they call it a STIG.
When Civilian (via NIST) goes through, the output is called USGCB.

NIST 800-53 has some high-level framework control, e.g. "ABC-1," could
say something along "Do secure passwords, using [agency defined] values
for length and complexity."

DISA FSO then takes that requirement defines it further into "Control
Correlation Identifiers":
CCI-12345 Passwords must be 12 characters
CCI-12346 Passwords must contain 2 upper case
CCI-12347 Passwords must contain 2 special chars

DISA has an entire spreadsheet of these CCI controls per product
category -- they call these the Security Requirements Guide (SRG). The
one RHEL must follow is the operating System SRG, and you can find the
underlying RHEL7 STIG requirements here:
http://people.redhat.com/swells/RHEL7_STIG_REQUIREMENTS.xlsx

When a vendor such as Red Hat creates implementation guidance -- exactly
what variable to change in some specific file -- that is mapped to a
Configuration Control Enumerator (CCE).

[Trey Henefield]

That is a great breakdown Shawn!

I think it would it be useful to create profiles that align with the RMF IA control baselines (low, moderate, high) and also include profiles that build upon the IA control baseline profiles to additionally support the current 5 overlays (CNSSI No. 1253).

Best regards,

Trey Henefield, CISSP
Senior IAVA Engineer

Ultra Electronics
Advanced Tactical Systems, Inc.
4101 Smith School Road
Building IV, Suite 100
Austin, TX 78744 USA

[e-mail]
Tel: [phone] ext. 647
Fax: [phone]
Mobile: [phone]

www.ultra-ats.com

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Shawn Wells
Sent: Tuesday, September 16, 2014 6:26 AM
To: [e-mail]
Subject: Re: DIACAP vs DIARMF & STIGs & CCEs.

On 9/15/14, 5:02 PM, Greg Elin wrote:
> I was wondering if anyone was available to explain DIACAP transition 
> to DIARMF and what it means for STIGS and SSG?
>
> Happy to have a public email thread, but also happy to take it offline.
>
> Here is my summary understanding.
>
> DoD developed its own list of information assurance controls under 
> DIACAP (DoD Information Assurance Certification and Accreditation 
> Process).
>
> In recent years (2010-2012), the DIACAP started transitioning to  
> DIARMF (DoD Information Assurance Risk Management Framework) to align 
> it with NIST RMF, and to bring the catalog of controls into alignment 
> with the controls listed in 800-53, with some special overlays 
> available for Defense-related systems.
>
> As of Spring 2014, that transition is complete.
>
> But I'm trying to make sure I understand how the STIGs play into all 
> of this. When I look at the STIGs, I see different control number 
> tracking than from the 800-53s or the CCEs.
>
> Is it the case that the Control catalog is now 800-53r4 for both 
> civilian and DoD, but DoD is using STIGs to get to platform specific 
> details while civilian side is using CCEs?
>
> If there were just 5 or 6 documents about current/active control 
> catalogs, what would they be? 800-137, 800-53, 8510.1 and/or ... ???
>
> Thanks...

The various RMF implementations call out NIST 800-53 as the place to derive implementation requirements.

When DoD (via DISA FSO) goes through NIST 800-53 and pulls out things they care about, they call it a STIG.
When Civilian (via NIST) goes through, the output is called USGCB.

NIST 800-53 has some high-level framework control, e.g. "ABC-1," could say something along "Do secure passwords, using [agency defined] values for length and complexity."

DISA FSO then takes that requirement defines it further into "Control Correlation Identifiers":
CCI-12345 Passwords must be 12 characters
CCI-12346 Passwords must contain 2 upper case
CCI-12347 Passwords must contain 2 special chars

DISA has an entire spreadsheet of these CCI controls per product category -- they call these the Security Requirements Guide (SRG). The one RHEL must follow is the operating System SRG, and you can find the underlying RHEL7 STIG requirements here:
http://people.redhat.com/swells/RHEL7_STIG_REQUIREMENTS.xlsx

When a vendor such as Red Hat creates implementation guidance -- exactly what variable to change in some specific file -- that is mapped to a Configuration Control Enumerator (CCE).

--
SCAP Security Guide mailing list
[e-mail]
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
https://github.com/OpenSCAP/scap-security-guide/

Disclaimer
The information contained in this communication from [e-mail] sent at 2014-09-16 08:58:20 is confidential and may be legally privileged.
It is intended solely for use by [e-mail] and others authorized to receive it. If you are not [e-mail] you are hereby notified that
any disclosure, copying, distribution or taking action in reliance of the contents of this information is strictly prohibited and may be unlawful.

[David Smith]

Fortunately, NIST provides 800-53 Rev 4 in XML form to allow for just that
kind of wizardry.

On Tue, Sep 16, 2014 at 8:58 AM, Trey Henefield <
[e-mail]> wrote:
> That is a great breakdown Shawn!
>
> I think it would it be useful to create profiles that align with the RMF
> IA control baselines (low, moderate, high) and also include profiles that
> build upon the IA control baseline profiles to additionally support the
> current 5 overlays (CNSSI No. 1253).
>
> Best regards,
>
> Trey Henefield, CISSP
> Senior IAVA Engineer
>
> Ultra Electronics
> Advanced Tactical Systems, Inc.
> 4101 Smith School Road
> Building IV, Suite 100
> Austin, TX 78744 USA
>
> [e-mail]
> Tel: [phone] ext. 647
> Fax: [phone]
> Mobile: [phone]
>
> www.ultra-ats.com
>
> -----Original Message-----
> From: [e-mail] [mailto:
> [e-mail]] On Behalf Of Shawn
> Wells
> Sent: Tuesday, September 16, 2014 6:26 AM
> To: [e-mail]
> Subject: Re: DIACAP vs DIARMF & STIGs & CCEs.
>
> On 9/15/14, 5:02 PM, Greg Elin wrote:
> > I was wondering if anyone was available to explain DIACAP transition
> > to DIARMF and what it means for STIGS and SSG?
> >
> > Happy to have a public email thread, but also happy to take it offline.
> >
> > Here is my summary understanding.
> >
> > DoD developed its own list of information assurance controls under
> > DIACAP (DoD Information Assurance Certification and Accreditation
> > Process).
> >
> > In recent years (2010-2012), the DIACAP started transitioning to
> > DIARMF (DoD Information Assurance Risk Management Framework) to align
> > it with NIST RMF, and to bring the catalog of controls into alignment
> > with the controls listed in 800-53, with some special overlays
> > available for Defense-related systems.
> >
> > As of Spring 2014, that transition is complete.
> >
> > But I'm trying to make sure I understand how the STIGs play into all
> > of this. When I look at the STIGs, I see different control number
> > tracking than from the 800-53s or the CCEs.
> >
> > Is it the case that the Control catalog is now 800-53r4 for both
> > civilian and DoD, but DoD is using STIGs to get to platform specific
> > details while civilian side is using CCEs?
> >
> > If there were just 5 or 6 documents about current/active control
> > catalogs, what would they be? 800-137, 800-53, 8510.1 and/or ... ???
> >
> > Thanks...
>
> The various RMF implementations call out NIST 800-53 as the place to
> derive implementation requirements.
>
> When DoD (via DISA FSO) goes through NIST 800-53 and pulls out things they
> care about, they call it a STIG.
> When Civilian (via NIST) goes through, the output is called USGCB.
>
> NIST 800-53 has some high-level framework control, e.g. "ABC-1," could say
> something along "Do secure passwords, using [agency defined] values for
> length and complexity."
>
> DISA FSO then takes that requirement defines it further into "Control
> Correlation Identifiers":
> CCI-12345 Passwords must be 12 characters
> CCI-12346 Passwords must contain 2 upper case
> CCI-12347 Passwords must contain 2 special chars
>
> DISA has an entire spreadsheet of these CCI controls per product category
> -- they call these the Security Requirements Guide (SRG). The one RHEL must
> follow is the operating System SRG, and you can find the underlying RHEL7
> STIG requirements here:
> http://people.redhat.com/swells/RHEL7_STIG_REQUIREMENTS.xlsx
>
> When a vendor such as Red Hat creates implementation guidance -- exactly
> what variable to change in some specific file -- that is mapped to a
> Configuration Control Enumerator (CCE).
>
> --
> SCAP Security Guide mailing list
> [e-mail]
> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
> https://github.com/OpenSCAP/scap-security-guide/
>
> *Disclaimer*
> The information contained in this communication from *
> [e-mail]  * sent at
> 2014-09-16 08:58:20 is private and may be legally privileged or export
> controlled. It is intended solely for use by *
> [e-mail]
>  * and others authorized to
> receive it. If you are not * [e-mail]
>  * you are hereby notified
> that any disclosure, copying, distribution or taking action in reliance of
> the contents of this information is strictly prohibited and may be unlawful.
>
> --
> SCAP Security Guide mailing list
> [e-mail]
> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
> https://github.com/OpenSCAP/scap-security-guide/

[Greg Elin]

Thanks for the explanation Shawn!

+1 Trey. The more baked starting points SSG offers the better.

You are giving me some ideas, Mt Smith.

Greg Elin
P: 917-304-3488
E:  [e-mail]

Sent from my iPhone
> On Sep 16, 2014, at 9:01 AM, David Smith  wrote:
>
> Fortunately, NIST provides 800-53 Rev 4 in XML form to allow for just that kind of wizardry.
> > On Tue, Sep 16, 2014 at 8:58 AM, Trey Henefield  wrote:
> >
> > That is a great breakdown Shawn!
> >
> > I think it would it be useful to create profiles that align with the RMF IA control baselines (low, moderate, high) and also include profiles that build upon the IA control baseline profiles to additionally support the current 5 overlays (CNSSI No. 1253).
> >
> > Best regards,
> >
> > Trey Henefield, CISSP
> > Senior IAVA Engineer
> >
> > Ultra Electronics
> > Advanced Tactical Systems, Inc.
> > 4101 Smith School Road
> > Building IV, Suite 100
> > Austin, TX 78744 USA
> >
> > [e-mail]
> > Tel: [phone] ext. 647
> > Fax: [phone]
> > Mobile: [phone]
> >
> > www.ultra-ats.com
> >
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On Behalf Of Shawn Wells
> > Sent: Tuesday, September 16, 2014 6:26 AM
> > To: [e-mail]
> > Subject: Re: DIACAP vs DIARMF & STIGs & CCEs.
> >
> > On 9/15/14, 5:02 PM, Greg Elin wrote:
> > > I was wondering if anyone was available to explain DIACAP transition 
> > > to DIARMF and what it means for STIGS and SSG?
> > >
> > > Happy to have a public email thread, but also happy to take it offline.
> > >
> > > Here is my summary understanding.
> > >
> > > DoD developed its own list of information assurance controls under 
> > > DIACAP (DoD Information Assurance Certification and Accreditation 
> > > Process).
> > >
> > > In recent years (2010-2012), the DIACAP started transitioning to 
> > > DIARMF (DoD Information Assurance Risk Management Framework) to align 
> > > it with NIST RMF, and to bring the catalog of controls into alignment 
> > > with the controls listed in 800-53, with some special overlays 
> > > available for Defense-related systems.
> > >
> > > As of Spring 2014, that transition is complete.
> > >
> > > But I'm trying to make sure I understand how the STIGs play into all 
> > > of this. When I look at the STIGs, I see different control number 
> > > tracking than from the 800-53s or the CCEs.
> > >
> > > Is it the case that the Control catalog is now 800-53r4 for both 
> > > civilian and DoD, but DoD is using STIGs to get to platform specific 
> > > details while civilian side is using CCEs?
> > >
> > > If there were just 5 or 6 documents about current/active control 
> > > catalogs, what would they be? 800-137, 800-53, 8510.1 and/or ... ???
> > >
> > > Thanks...
> >
> > The various RMF implementations call out NIST 800-53 as the place to derive implementation requirements.
> >
> > When DoD (via DISA FSO) goes through NIST 800-53 and pulls out things they care about, they call it a STIG.
> > When Civilian (via NIST) goes through, the output is called USGCB.
> >
> > NIST 800-53 has some high-level framework control, e.g. "ABC-1," could say something along "Do secure passwords, using [agency defined] values for length and complexity."
> >
> > DISA FSO then takes that requirement defines it further into "Control Correlation Identifiers":
> > CCI-12345 Passwords must be 12 characters
> > CCI-12346 Passwords must contain 2 upper case
> > CCI-12347 Passwords must contain 2 special chars
> >
> > DISA has an entire spreadsheet of these CCI controls per product category -- they call these the Security Requirements Guide (SRG). The one RHEL must follow is the operating System SRG, and you can find the underlying RHEL7 STIG requirements here:
> > http://people.redhat.com/swells/RHEL7_STIG_REQUIREMENTS.xlsx
> >
> > When a vendor such as Red Hat creates implementation guidance -- exactly what variable to change in some specific file -- that is mapped to a Configuration Control Enumerator (CCE).
> >
> > --
> > SCAP Security Guide mailing list
> > [e-mail]
> > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
> > https://github.com/OpenSCAP/scap-security-guide/
> >
> > Disclaimer
> > The information contained in this communication from [e-mail] sent at           2014-09-16 08:58:20 is private and may be legally privileged or export controlled. It is intended solely for use by [e-mail] and others authorized to receive it. If you are not [e-mail] you are hereby notified that any disclosure, copying, distribution or taking action in reliance of the contents of this information is strictly prohibited and may be unlawful.
> >
> > --
> > SCAP Security Guide mailing list
> > [e-mail]
> > https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
> > https://github.com/OpenSCAP/scap-security-guide/
>
> -- 
> David Smith
> Sr. Information Security Engineer
> Secure Innovations, LLC
> -- 
> SCAP Security Guide mailing list
> [e-mail]
> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
> https://github.com/OpenSCAP/scap-security-guide/

[Shawn Wells]

On 9/16/14, 5:58 AM, Trey Henefield wrote:
> That is a great breakdown Shawn!
>
> I think it would it be useful to create profiles that align with the
> RMF IA control baselines (low, moderate, high)

Definitely. I started on this path sometime ago via the nist-cl-il-al
profile. I then got distracted by other things and never finished.

The idea was that nist-c{onfidentiality}l-i{ntegriy}l-a{availability}l
could be inherited by a m/m/m, which then gets inherited by a h/h/h
profile.

Check out the profile. It has the various low/low/low NIST 800-53
requirements in comments, but they need mapping to an SSG rule.
> and also include profiles that build upon the IA control baseline
> profiles to additionally support the current 5 overlays (CNSSI No. 1253).

The CSCF is against the Cross Domain overlay.... I think there may be
others they had to meet too.  Luke?