That sounds great on paper, but it's a one size fits all approach that neglects the fact that not all systems will have the same set of controls. The set of controls may be different based on the control selection and tailoring process that each system has to go through. Not to mention no single SCAP benchmark can encompass all of the minimum required controls from the different control families.
Regards, Wei Chen
On Tue, Sep 16, 2014 at 8:58 AM, Trey Henefield < trey.henefield@ultra-ats.com> 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
Trey.Henefield@ultra-ats.com Tel: +1 512 327 6795 ext. 647 Fax: +1 512 327 8043 Mobile: +1 512 541 6450
www.ultra-ats.com
-----Original Message----- From: scap-security-guide-bounces@lists.fedorahosted.org [mailto: scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Shawn Wells Sent: Tuesday, September 16, 2014 6:26 AM To: scap-security-guide@lists.fedorahosted.org 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).
"Not to mention no single SCAP benchmark can encompass all of the minimum required controls from the different control families"
I'm not so sure about this one. Or rather, I'm wondering if a single SCAP benchmark can encompass the *maximum* required controls from the different control families.
In theory, a cross matrix of all regulations should provide a system that meets all regulations (and is probably unusable, but that's a different issue).
Do we have actual conflicting guidance between regs?
Trevor
On Tue, Sep 16, 2014 at 9:39 AM, Chen, Wei (Contractor)(CFPB) < Wei.Chen@cfpb.gov> wrote:
That sounds great on paper, but it's a one size fits all approach that neglects the fact that not all systems will have the same set of controls. The set of controls may be different based on the control selection and tailoring process that each system has to go through. Not to mention no single SCAP benchmark can encompass all of the minimum required controls from the different control families.
Regards, Wei Chen
On Tue, Sep 16, 2014 at 8:58 AM, Trey Henefield < trey.henefield@ultra-ats.com> 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
Trey.Henefield@ultra-ats.com Tel: +1 512 327 6795 ext. 647 Fax: +1 512 327 8043 Mobile: +1 512 541 6450
www.ultra-ats.com
-----Original Message----- From: scap-security-guide-bounces@lists.fedorahosted.org [mailto: scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Shawn Wells Sent: Tuesday, September 16, 2014 6:26 AM To: scap-security-guide@lists.fedorahosted.org 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 scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
Trevor makes an interesting point.
Representing a specific security policy is just one use case for a "profile".
A profile is just statement about a set of controls: a collection of controls plus variable settings.
A profile explicitly about audit rules, for example, could be a useful training tool. Another profile focused on services or libraries, could be useful gathering an adhoc inventory across many systems.
Greg Elin P: 917-304-3488 E: gregelin@gitmachines.com
Sent from my iPhone
On Sep 16, 2014, at 6:06 PM, Trevor Vaughan tvaughan@onyxpoint.com wrote:
"Not to mention no single SCAP benchmark can encompass all of the minimum required controls from the different control families"
I'm not so sure about this one. Or rather, I'm wondering if a single SCAP benchmark can encompass the *maximum* required controls from the different control families.
In theory, a cross matrix of all regulations should provide a system that meets all regulations (and is probably unusable, but that's a different issue).
Do we have actual conflicting guidance between regs?
Trevor
On Tue, Sep 16, 2014 at 9:39 AM, Chen, Wei (Contractor)(CFPB) Wei.Chen@cfpb.gov wrote: That sounds great on paper, but it's a one size fits all approach that neglects the fact that not all systems will have the same set of controls. The set of controls may be different based on the control selection and tailoring process that each system has to go through. Not to mention no single SCAP benchmark can encompass all of the minimum required controls from the different control families.
Regards, Wei Chen
On Tue, Sep 16, 2014 at 8:58 AM, Trey Henefield < trey.henefield@ultra-ats.com> 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
Trey.Henefield@ultra-ats.com Tel: +1 512 327 6795 ext. 647 Fax: +1 512 327 8043 Mobile: +1 512 541 6450
www.ultra-ats.com
-----Original Message----- From: scap-security-guide-bounces@lists.fedorahosted.org [mailto: scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Shawn Wells Sent: Tuesday, September 16, 2014 6:26 AM To: scap-security-guide@lists.fedorahosted.org 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 scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 tvaughan@onyxpoint.com
-- This account not approved for unencrypted proprietary information --
SCAP Security Guide mailing list scap-security-guide@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide https://github.com/OpenSCAP/scap-security-guide/
On 9/16/14, 3:06 PM, Trevor Vaughan wrote:
"Not to mention no single SCAP benchmark can encompass all of the minimum required controls from the different control families"
I'm not so sure about this one. Or rather, I'm wondering if a single SCAP benchmark can encompass the *maximum* required controls from the different control families.
In theory, a cross matrix of all regulations should provide a system that meets all regulations (and is probably unusable, but that's a different issue).
Do we have actual conflicting guidance between regs?
At the policy level (NIST C/I/A levels, STIG, USGCB) things are generally the same, but there are certainly downrange conflicts as agencies decide to customize the STIG. "My snowflake is more unique than yours, so I'm making the passwords 2 characters longer! And retaining logs for 30 days more!"
Snideness (sp?) aside, this is really a use case for overwrite/drift files. People can take the STIG and drop in an overlay XML file that deselects or adjusts refine values -- essentially an easy way for end-users to have profile inheritance. Documentation can generously be described as poor on this capability though...
/me nudges Simon & Martin to provide some URLS (I don't know any, and authoring this EMail from a plane so can't google)
There's also been ideas of having OpenSCAP take multiple --profile arguments. Would this be useful?
scap-security-guide@lists.fedorahosted.org
-
Chen, Wei (Contractor)(CFPB) -
Greg Elin -
Shawn Wells -
Trevor Vaughan