Hello,
My name is Tim Bradt. I am software developer at Signature Research, Inc. I have been charged with getting SCAP up and running on some of our systems.
We are running Arch Linux. I was wondering what the process would be for porting the RHEL7 guide to Arch as we need the DISA STIG for system approval.
Thanks for your help, Tim
Hi Tim,
This is a completely unofficial (and quite possibly non-helpful) response as I am primarily a user of OpenSCAP, not a developer nor do I work for NIST or any government agency for that matter.
But I run Arch locally on my desktop as do most of my infrastructure team members so this caught my eye. And I run OpenSCAP scans on RHEL/7.3 instances that we support.
The STIG for RHEL/7 has just recently been NIST certified which means stamped with their approval for use on government systems. There is no (certified) STIG for Debian, Arch, Ubuntu, etc.
In my opinion, this reflects a larger issue - a peeve of mine: While the government (in particular, the DHS which is driving the Continuous Diagnostics and Monitoring (CDM) process) is beginning to realize that static stamps of security (in particular, the FISMA/ATO which runs on a three-year cycle) no longer matches the fluid security threat landscape, they are not willing to embrace the major paradigm shift of rolling releases as found in Arch. The hesitancy is based in good intentions: if you exhaustively examine a system for security threats and stamp it SECURE then any changes to it could introduce new bugs/security holes.
But of course, new bugs/security holes are constantly being discovered in Windows 7, etc. Meanwhile, as new threat vectors are discovered, new system architectures evolve to remediate or completely disallow/disable the new threat, and these are available in new releases. If a bug is found, it is immediately patched. (I love Arch.)
The STIGs still serve a good purpose, as they enable system specific scanning of a large number of controls - I believe it has helped me ensure greater security of my RHEL/7 systems. But the snails pace of NIST certification and the inability to consider other operating systems and applications seems to be based in the goal of static security management.
Well, that was quite a ramble, but I will stop before I go on. You might also want to check out work that 18F did on securing Ubuntu 14.04 a couple years ago, see: https://github.com/fisma-ready/ubuntu-lts
And I am working toward proposing some initial steps toward greater flexibility, but they are not ready for publication yet. I'll drop a note here when they are.
Good luck with your Arch system. (And maybe someone else may have something more helpful to contribute.) =Fen
On Mon, Apr 17, 2017 at 1:42 PM, bradt@signatureresearchinc.com wrote:
Hello,
My name is Tim Bradt. I am software developer at Signature Research, Inc. I have been charged with getting SCAP up and running on some of our systems.
We are running Arch Linux. I was wondering what the process would be for porting the RHEL7 guide to Arch as we need the DISA STIG for system approval.
Thanks for your help, Tim _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists. fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@ lists.fedorahosted.org
On 4/17/17 2:24 PM, Fen Labalme wrote:
Hi Tim,
This is a completely unofficial (and quite possibly non-helpful) response as I am primarily a user of OpenSCAP, not a developer nor do I work for NIST or any government agency for that matter.
But I run Arch locally on my desktop as do most of my infrastructure team members so this caught my eye. And I run OpenSCAP scans on RHEL/7.3 instances that we support.
The STIG for RHEL/7 has just recently been NIST certified which means stamped with their approval for use on government systems. There is no (certified) STIG for Debian, Arch, Ubuntu, etc.
Slight correction, since this seems to be a self-perpetuating myth: DISA publishing a security checklist is not related to approval for use of any technology. DISA states as much on their FAQ:
Public reference: http://iase.disa.mil/stigs/Pages/faqs.aspx#STIG
Question: May I deploy a product if no STIG exists?
Answer: *_Yes_,* based on mission need and with DAA approval.
Question: What do I use if there is no STIG?
Answer: DISA FSO developed Security Requirement Guides (SRGs) to address technology areas. In the absence of a STIG, an SRG can be used to determine compliance with DoD policies._*If there is no applicable SRG or STIG, industry or vendor recommended practices may be used.*_ Examples include Center for Internet Security Benchmarks, Payment Card Industry requirements or the vendor's own security documentation.
Question: Does DISA FSO certify products for use in the DoD?
Answer: _*No.*_ DISA FSO certifies Information Systems for use in DISA. _*DISA FSO not does certify products for DoD use*_. SRGs/STIGs are designed to assist in implementing the secure deployment of products.
Local accreditation authorities often (incorrectly) treat STIG publications as a 'DoD product approval.' DoD CIO and DISA go out of their way to disassociate STIGs with approvals -- from their FAQs, to speaking at public events, and even calling it out in the STIG release memos.
In my opinion, this reflects a larger issue - a peeve of mine: While the government (in particular, the DHS which is driving the Continuous Diagnostics and Monitoring (CDM) process) is beginning to realize that static stamps of security (in particular, the FISMA/ATO which runs on a three-year cycle) no longer matches the fluid security threat landscape, they are not willing to embrace the major paradigm shift of rolling releases as found in Arch. The hesitancy is based in good intentions: if you exhaustively examine a system for security threats and stamp it SECURE then any changes to it could introduce new bugs/security holes.
I'll be touching on this at ICMC next month (the annual common criteria + FIPS conference). There are significant efforts to automate and modernize the formal evaluation regimes. For example, NIST's Automated Cryptographic Validation Testing:
http://csrc.nist.gov/projects/acvt/
As NIST states:/The structure and the rules under which the [cryptography validation regimes] operate worked _well for the level of the technology utilized by the Federal Government at the time when the programs were created more than two decades ago_. As technology has advanced however, the algorithm and module testing processes no longer satisfy current day industry and government operational needs. Testing is exceedingly long, well beyond typical product development cycles across a wide range of technologies. The resulting validated modules do not provide useful interfaces for integration into IT systems to enable run-time monitoring of modules for compliance with FISMA.
/
But of course, new bugs/security holes are constantly being discovered in Windows 7, etc. Meanwhile, as new threat vectors are discovered, new system architectures evolve to remediate or completely disallow/disable the new threat, and these are available in new releases. If a bug is found, it is immediately patched. (I love Arch.)
Arch isn't the only one who does that ;)
The STIGs still serve a good purpose, as they enable system specific scanning of a large number of controls - I believe it has helped me ensure greater security of my RHEL/7 systems. But the snails pace of NIST certification and the inability to consider other operating systems and applications seems to be based in the goal of static security management.
To be fair, the snail pace is not the governments fault. It's based on mission need. With (comparatively) few systems running things like Arch and Ubuntu, they simply get pushed lower in the queue. If there was a development community willing to create a configuration baseline for things like Ubuntu, SuSE, or Arch, they'd get published.
Would be great to see the additional OS' join up with OpenSCAP and SSG :)
Well, that was quite a ramble, but I will stop before I go on. You might also want to check out work that 18F did on securing Ubuntu 14.04 a couple years ago, see: https://github.com/fisma-ready/ubuntu-lts
What's the status of FISMA Ready?
And I am working toward proposing some initial steps toward greater flexibility, but they are not ready for publication yet. I'll drop a note here when they are.
Good luck with your Arch system. (And maybe someone else may have something more helpful to contribute.)
Tim,
I recommend you spend some time on the DISA STIG FAQ http://iase.disa.mil/stigs/Pages/faqs.aspx#STIG first question. I routinely run into (DoD) situations where a DAA (AODR), or subordinate to the DAA will reject platforms for which a STIG does not exist. I would recommend you start with your local Information Systems Security Manager (ISSM/IAPM) to ensure that you're not attempting to mitigate a DAA recommendation with a justification like "We spent all this money on Arch, we can't re-develop it for a different platform now". It's not impossible to do, but you need to get all players involved in the ATO recommendation on the same page from the start.
On Mon, Apr 17, 2017 at 7:25 PM, Shawn Wells shawn@redhat.com wrote:
On 4/17/17 2:24 PM, Fen Labalme wrote:
Hi Tim,
This is a completely unofficial (and quite possibly non-helpful) response as I am primarily a user of OpenSCAP, not a developer nor do I work for NIST or any government agency for that matter.
But I run Arch locally on my desktop as do most of my infrastructure team members so this caught my eye. And I run OpenSCAP scans on RHEL/7.3 instances that we support.
The STIG for RHEL/7 has just recently been NIST certified which means stamped with their approval for use on government systems. There is no (certified) STIG for Debian, Arch, Ubuntu, etc.
Slight correction, since this seems to be a self-perpetuating myth: DISA publishing a security checklist is not related to approval for use of any technology. DISA states as much on their FAQ:
Public reference: http://iase.disa.mil/stigs/Pages/faqs.aspx#STIG
Question: May I deploy a product if no STIG exists?
Answer: *Yes,* based on mission need and with DAA approval.
Question: What do I use if there is no STIG?
Answer: DISA FSO developed Security Requirement Guides (SRGs) to address technology areas. In the absence of a STIG, an SRG can be used to determine compliance with DoD policies.* If there is no applicable SRG or STIG, industry or vendor recommended practices may be used.* Examples include Center for Internet Security Benchmarks, Payment Card Industry requirements or the vendor's own security documentation.
Question: Does DISA FSO certify products for use in the DoD?
Answer: *No.* DISA FSO certifies Information Systems for use in DISA. *DISA FSO not does certify products for DoD use*. SRGs/STIGs are designed to assist in implementing the secure deployment of products.
Local accreditation authorities often (incorrectly) treat STIG publications as a 'DoD product approval.' DoD CIO and DISA go out of their way to disassociate STIGs with approvals -- from their FAQs, to speaking at public events, and even calling it out in the STIG release memos.
In my opinion, this reflects a larger issue - a peeve of mine: While the government (in particular, the DHS which is driving the Continuous Diagnostics and Monitoring (CDM) process) is beginning to realize that static stamps of security (in particular, the FISMA/ATO which runs on a three-year cycle) no longer matches the fluid security threat landscape, they are not willing to embrace the major paradigm shift of rolling releases as found in Arch. The hesitancy is based in good intentions: if you exhaustively examine a system for security threats and stamp it SECURE then any changes to it could introduce new bugs/security holes.
I'll be touching on this at ICMC next month (the annual common criteria + FIPS conference). There are significant efforts to automate and modernize the formal evaluation regimes. For example, NIST's Automated Cryptographic Validation Testing:
http://csrc.nist.gov/projects/acvt/
As NIST states:
*The structure and the rules under which the [cryptography validation regimes] operate worked well for the level of the technology utilized by the Federal Government at the time when the programs were created more than two decades ago. As technology has advanced however, the algorithm and module testing processes no longer satisfy current day industry and government operational needs. Testing is exceedingly long, well beyond typical product development cycles across a wide range of technologies. The resulting validated modules do not provide useful interfaces for integration into IT systems to enable run-time monitoring of modules for compliance with FISMA. *
But of course, new bugs/security holes are constantly being discovered in Windows 7, etc. Meanwhile, as new threat vectors are discovered, new system architectures evolve to remediate or completely disallow/disable the new threat, and these are available in new releases. If a bug is found, it is immediately patched. (I love Arch.)
Arch isn't the only one who does that ;)
The STIGs still serve a good purpose, as they enable system specific scanning of a large number of controls - I believe it has helped me ensure greater security of my RHEL/7 systems. But the snails pace of NIST certification and the inability to consider other operating systems and applications seems to be based in the goal of static security management.
To be fair, the snail pace is not the governments fault. It's based on mission need. With (comparatively) few systems running things like Arch and Ubuntu, they simply get pushed lower in the queue. If there was a development community willing to create a configuration baseline for things like Ubuntu, SuSE, or Arch, they'd get published.
Would be great to see the additional OS' join up with OpenSCAP and SSG :)
Well, that was quite a ramble, but I will stop before I go on. You might also want to check out work that 18F did on securing Ubuntu 14.04 a couple years ago, see: https://github.com/fisma-ready/ubuntu-lts
What's the status of FISMA Ready?
And I am working toward proposing some initial steps toward greater flexibility, but they are not ready for publication yet. I'll drop a note here when they are.
Good luck with your Arch system. (And maybe someone else may have something more helpful to contribute.)
scap-security-guide mailing list -- scap-security-guide@lists. fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@ lists.fedorahosted.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 04/17/2017 12:42 PM, bradt@signatureresearchinc.com wrote:
My name is Tim Bradt. I am software developer at Signature Research, Inc. I have been charged with getting SCAP up and running on some of our systems.
We are running Arch Linux. I was wondering what the process would be for porting the RHEL7 guide to Arch as we need the DISA STIG for system approval.
Hello Tim,
As others have mentioned already, the big job is to get an actual standard assembled for Arch Linux. Once that's done, writing SCAP content or other scripts is much more straightforward.
We've tried to tackle a translation of the RHEL 7 STIG into something that works for CentOS 7 and Ubuntu 16.04:
https://github.com/openstack/openstack-ansible-security https://docs.openstack.org/developer/openstack-ansible-security/
(There's also a RHEL 6 STIG implementation for Ubuntu 14.04, but we're deprecating that now.)
Some of that work may help you figure out how to translate the RHEL 7 STIG requirements for Arch Linux. Feel free to reach out if you need pointers. :)
- -- Major Hayden
On 4/17/17 3:28 PM, Major Hayden wrote:
On 04/17/2017 12:42 PM, bradt@signatureresearchinc.com wrote:
My name is Tim Bradt. I am software developer at Signature Research, Inc. I have been charged with getting SCAP up and running on some of our systems.
We are running Arch Linux. I was wondering what the process would be for porting the RHEL7 guide to Arch as we need the DISA STIG for system approval.
Hello Tim,
As others have mentioned already, the big job is to get an actual standard assembled for Arch Linux. Once that's done, writing SCAP content or other scripts is much more straightforward.
We've tried to tackle a translation of the RHEL 7 STIG into something that works for CentOS 7 and Ubuntu 16.04:
https://github.com/openstack/openstack-ansible-security https://docs.openstack.org/developer/openstack-ansible-security/
(There's also a RHEL 6 STIG implementation for Ubuntu 14.04, but we're deprecating that now.)
Some of that work may help you figure out how to translate the RHEL 7 STIG requirements for Arch Linux. Feel free to reach out if you need pointers.
Operating System STIGs are derived from DISA's Operating Systems Security Requirements Guide: http://iase.disa.mil/stigs/os/general/Pages/index.aspx
To get started, download a copy and map what controls are possible on Arch. For example, password complexity requirements can be met, however anything relating to cryptography/FIPS cannot.
Once you down-select the list of controls you can begin authoring configuration guidance. That is done with XCCDF in the OpenSCAP/SSG project. The build system is extensible enough that when a configuration rule overlaps with RHEL (e.g., something with PAM), we can tag the existing content and associate it with both RHEL and Arch. Same with the OVAL content. New XCCDF+OVAL can be generated for Arch-specific things.
The process is a bit mundane... but iterate through and you'll generate a configuration guide for Arch. I don't really have a feel for how different Arch is than mainline linux - but would wager this would be mostly a policy mapping exercise vs having to create lots of Arch-specific SCAP content.
I'm piggy backing on what Shawn is saying because I routinely bump into the FIPS and Common Criteria issue.
Common Criteria is actually easier to hand wave around since I haven't seen many systems that stick to CC as documented.
FIPS is more difficult since it is quite concrete and, until that changes, any non-FIPS certified system cannot be used to protect sensitive information.
This is the section from the CMVP website that always hits home:
FIPS 140-2 precludes the use of unvalidated cryptography *for the cryptographic protection* of sensitive or valuable data within Federal systems. Unvalidated cryptography is viewed by NIST as providing *no protection* to the information or data - in effect the data would be considered unprotected plaintext. *If the agency specifies that the information or data be cryptographically protected*, then FIPS 140-2 is applicable. In essence, if cryptography is required, then it must be validated.
Mapping Arch is definitely a good idea but, in theory, you can't do anything that requires data protection, like SSH, until Arch has a FIPS 140-2 approved cryptographic module (or Q4 2018 rolls around and/if the automated system rolls out).
Hopefully this is helpful.
Thanks,
Trevor
On Mon, Apr 17, 2017 at 2:28 PM, Major Hayden major@mhtx.net wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 04/17/2017 12:42 PM, bradt@signatureresearchinc.com wrote:
My name is Tim Bradt. I am software developer at Signature Research,
Inc. I have been charged with getting SCAP up and running on some of our systems.
We are running Arch Linux. I was wondering what the process would be for
porting the RHEL7 guide to Arch as we need the DISA STIG for system approval.
Hello Tim,
As others have mentioned already, the big job is to get an actual standard assembled for Arch Linux. Once that's done, writing SCAP content or other scripts is much more straightforward.
We've tried to tackle a translation of the RHEL 7 STIG into something that works for CentOS 7 and Ubuntu 16.04:
https://github.com/openstack/openstack-ansible-security https://docs.openstack.org/developer/openstack-ansible-security/
(There's also a RHEL 6 STIG implementation for Ubuntu 14.04, but we're deprecating that now.)
Some of that work may help you figure out how to translate the RHEL 7 STIG requirements for Arch Linux. Feel free to reach out if you need pointers. :)
Major Hayden -----BEGIN PGP SIGNATURE----- Version: GnuPG v2
iQIcBAEBCAAGBQJY9RdZAAoJEHNwUeDBAR+xjCAP/1xFonXK1mh0X7bzFtNedXe/ QUhNDx8rRayPCKWb5aWT3n4qarsdq97AVpaLnxgGI+SArZwGEY6/tZdZiq4Znfkr yZZ71XcARp3CzDk1pw5ukZWXgZ464mBC2wnEawkuYHCGy9J2oo1t1LL/7XikSpXw g6MqZqC/E+WOR9lLTAQi0yBdBfj27P3Imn4DB7aHqFEC4GgBJavBrFIW58fSxh/D qU9xORrS3QbE039/mAsvf9lqlA2yyATey+bMeeVKVs/c72F5fWql8lpXhnYa2Z5C lBQJF/A9ECHinQtLxcCeZUDR5sGhhDgd0IrlSC5wnVURoBGF7UAezSNSORZvjJUS f5yWkYOpIY5aPmQxnzPPcDMBKajjag0m9Q3sfTPOJgRb3tBHtCjkChGeun9xIhLd +7MwMZVp+IZzQh3e4VPJFJk+RdfAIAHmQK2ocT2fVkNnJwr1WB4yJq2awaa/348O P5AQx1YhiPEsMiem60gZrO1SC5KkZgNEo3DA4cNXMwYP/IbzIv2ZlGmzzzGaiW9H FfYSLUCBweg8488/SbdolgpTfws1pKcwaHmEyb00S1lmj7AwxmyYR1KSlDdKNzsm sPd8MJiUXJkhTR908OQbI1+5bXmXB80DwS8Grr63n+y7+fph3H5BNoLoyCE4h+Rd is+dK0rEGg7MoBxvsY8g =Iwuf -----END PGP SIGNATURE----- _______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists. fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@ lists.fedorahosted.org
Just to add to the thread and to stir the bucket...
Can we define the line " If the agency specifies that the information or data be cryptographically protected, then FIPS 140-2 is applicable. In essence, if cryptography is required, then it must be validated."? Isn't cryptographic protection up to the data owner? If not required, say due to a closed environment, couldn't there be an argument for ARCH?
I truly believe it all needs to be verifiable and begins with FIPS 140-2 approval but doesn't this line give some decision making to the data owner?
Jim
-----Original Message----- From: Trevor Vaughan [mailto:tvaughan@onyxpoint.com] Sent: Tuesday, April 18, 2017 1:18 PM To: SCAP Security Guide Subject: [Non-DoD Source] Re: Introduction and Questions
I'm piggy backing on what Shawn is saying because I routinely bump into the FIPS and Common Criteria issue.
Common Criteria is actually easier to hand wave around since I haven't seen many systems that stick to CC as documented.
FIPS is more difficult since it is quite concrete and, until that changes, any non-FIPS certified system cannot be used to protect sensitive information.
This is the section from the CMVP website that always hits home:
FIPS 140-2 precludes the use of unvalidated cryptography for the cryptographic protection of sensitive or valuable data within Federal systems. Unvalidated cryptography is viewed by NIST as providing no protection to the information or data - in effect the data would be considered unprotected plaintext. If the agency specifies that the information or data be cryptographically protected, then FIPS 140-2 is applicable. In essence, if cryptography is required, then it must be validated.
Mapping Arch is definitely a good idea but, in theory, you can't do anything that requires data protection, like SSH, until Arch has a FIPS 140-2 approved cryptographic module (or Q4 2018 rolls around and/if the automated system rolls out).
Hopefully this is helpful.
Thanks,
Trevor
On Mon, Apr 17, 2017 at 2:28 PM, Major Hayden major@mhtx.net wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 04/17/2017 12:42 PM, bradt@signatureresearchinc.com wrote: > My name is Tim Bradt. I am software developer at Signature Research, Inc. I have been charged with getting SCAP up and running on some of our systems. > > We are running Arch Linux. I was wondering what the process would be for porting the RHEL7 guide to Arch as we need the DISA STIG for system approval.
Hello Tim,
As others have mentioned already, the big job is to get an actual standard assembled for Arch Linux. Once that's done, writing SCAP content or other scripts is much more straightforward.
We've tried to tackle a translation of the RHEL 7 STIG into something that works for CentOS 7 and Ubuntu 16.04:
https://github.com/openstack/openstack-ansible-security https://github.com/openstack/openstack-ansible-security https://docs.openstack.org/developer/openstack-ansible-security/ https://docs.openstack.org/developer/openstack-ansible-security/
(There's also a RHEL 6 STIG implementation for Ubuntu 14.04, but we're deprecating that now.)
Some of that work may help you figure out how to translate the RHEL 7 STIG requirements for Arch Linux. Feel free to reach out if you need pointers. :)
- -- Major Hayden -----BEGIN PGP SIGNATURE----- Version: GnuPG v2
iQIcBAEBCAAGBQJY9RdZAAoJEHNwUeDBAR+xjCAP/1xFonXK1mh0X7bzFtNedXe/ QUhNDx8rRayPCKWb5aWT3n4qarsdq97AVpaLnxgGI+SArZwGEY6/tZdZiq4Znfkr yZZ71XcARp3CzDk1pw5ukZWXgZ464mBC2wnEawkuYHCGy9J2oo1t1LL/7XikSpXw g6MqZqC/E+WOR9lLTAQi0yBdBfj27P3Imn4DB7aHqFEC4GgBJavBrFIW58fSxh/D qU9xORrS3QbE039/mAsvf9lqlA2yyATey+bMeeVKVs/c72F5fWql8lpXhnYa2Z5C lBQJF/A9ECHinQtLxcCeZUDR5sGhhDgd0IrlSC5wnVURoBGF7UAezSNSORZvjJUS f5yWkYOpIY5aPmQxnzPPcDMBKajjag0m9Q3sfTPOJgRb3tBHtCjkChGeun9xIhLd +7MwMZVp+IZzQh3e4VPJFJk+RdfAIAHmQK2ocT2fVkNnJwr1WB4yJq2awaa/348O P5AQx1YhiPEsMiem60gZrO1SC5KkZgNEo3DA4cNXMwYP/IbzIv2ZlGmzzzGaiW9H FfYSLUCBweg8488/SbdolgpTfws1pKcwaHmEyb00S1lmj7AwxmyYR1KSlDdKNzsm sPd8MJiUXJkhTR908OQbI1+5bXmXB80DwS8Grr63n+y7+fph3H5BNoLoyCE4h+Rd is+dK0rEGg7MoBxvsY8g =Iwuf -----END PGP SIGNATURE-----
_______________________________________________ scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org mailto:scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org mailto:scap-security-guide-leave@lists.fedorahosted.org
Sort of. There are clear definitions of data that needs to be protected in other NIST documents.
NIST 800-53 is the direct result of a FISMA mandate and NIST 800-53 SC-12 and SC-13 make it pretty clear that any crypto in use needs to be NSA-approved and/or FIPS validated (which for public federal systems amounts to the same thing once you trace it all out).
However, if the local data owner and security personnel are willing to take the risk *and* those credentials cannot be used to get into any other Federal system *and* they're willing to look someone in the eye and blatantly say that they're ignoring FISMA...knock yourself out.
Waivers are generally only generated in 30, 60, and 90 day increments though so you're going to have to repeatedly jump through the paperwork hoop.
All that said, if your system has *no* protected data (PII, FOUO, SBU, whatever) and your credentials cannot be used to access any other Federal system, then you should be just fine. Trying to migrate from that to a compliant system for production use may be a real bear though.
Thanks,
Trevor
On Wed, Apr 19, 2017 at 10:17 AM, McIntyre, James T. (Farragut Suitland, MD) jmcintyre@nmic.navy.mil wrote:
Just to add to the thread and to stir the bucket...
Can we define the line " If the agency specifies that the information or data be cryptographically protected, then FIPS 140-2 is applicable. In essence, if cryptography is required, then it must be validated."? Isn't cryptographic protection up to the data owner? If not required, say due to a closed environment, couldn't there be an argument for ARCH?
I truly believe it all needs to be verifiable and begins with FIPS 140-2 approval but doesn't this line give some decision making to the data owner?
Jim
-----Original Message----- From: Trevor Vaughan [mailto:tvaughan@onyxpoint.com] Sent: Tuesday, April 18, 2017 1:18 PM To: SCAP Security Guide Subject: [Non-DoD Source] Re: Introduction and Questions
I'm piggy backing on what Shawn is saying because I routinely bump into the FIPS and Common Criteria issue.
Common Criteria is actually easier to hand wave around since I haven't seen many systems that stick to CC as documented.
FIPS is more difficult since it is quite concrete and, until that changes, any non-FIPS certified system cannot be used to protect sensitive information.
This is the section from the CMVP website that always hits home:
FIPS 140-2 precludes the use of unvalidated cryptography for the cryptographic protection of sensitive or valuable data within Federal systems. Unvalidated cryptography is viewed by NIST as providing no protection to the information or data - in effect the data would be considered unprotected plaintext. If the agency specifies that the information or data be cryptographically protected, then FIPS 140-2 is applicable. In essence, if cryptography is required, then it must be validated.
Mapping Arch is definitely a good idea but, in theory, you can't do anything that requires data protection, like SSH, until Arch has a FIPS 140-2 approved cryptographic module (or Q4 2018 rolls around and/if the automated system rolls out).
Hopefully this is helpful.
Thanks,
Trevor
On Mon, Apr 17, 2017 at 2:28 PM, Major Hayden major@mhtx.net wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 04/17/2017 12:42 PM, bradt@signatureresearchinc.com wrote: > My name is Tim Bradt. I am software developer at SignatureResearch, Inc. I have been charged with getting SCAP up and running on some of our systems. > > We are running Arch Linux. I was wondering what the process would be for porting the RHEL7 guide to Arch as we need the DISA STIG for system approval.
Hello Tim, As others have mentioned already, the big job is to get an actualstandard assembled for Arch Linux. Once that's done, writing SCAP content or other scripts is much more straightforward.
We've tried to tackle a translation of the RHEL 7 STIG intosomething that works for CentOS 7 and Ubuntu 16.04:
https://github.com/openstack/openstack-ansible-securityhttps://github.com/openstack/openstack-ansible-security https://docs.openstack.org/developer/openstack-ansible-security/ https://docs.openstack.org/developer/openstack-ansible-security/
(There's also a RHEL 6 STIG implementation for Ubuntu 14.04, butwe're deprecating that now.)
Some of that work may help you figure out how to translate theRHEL 7 STIG requirements for Arch Linux. Feel free to reach out if you need pointers. :)
- -- Major Hayden -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJY9RdZAAoJEHNwUeDBAR+xjCAP/1xFonXK1mh0X7bzFtNedXe/ QUhNDx8rRayPCKWb5aWT3n4qarsdq97AVpaLnxgGI+SArZwGEY6/tZdZiq4Znfkr yZZ71XcARp3CzDk1pw5ukZWXgZ464mBC2wnEawkuYHCGy9J2oo1t1LL/7XikSpXw g6MqZqC/E+WOR9lLTAQi0yBdBfj27P3Imn4DB7aHqFEC4GgBJavBrFIW58fSxh/D qU9xORrS3QbE039/mAsvf9lqlA2yyATey+bMeeVKVs/c72F5fWql8lpXhnYa2Z5C lBQJF/A9ECHinQtLxcCeZUDR5sGhhDgd0IrlSC5wnVURoBGF7UAezSNSORZvjJUS f5yWkYOpIY5aPmQxnzPPcDMBKajjag0m9Q3sfTPOJgRb3tBHtCjkChGeun9xIhLd +7MwMZVp+IZzQh3e4VPJFJk+RdfAIAHmQK2ocT2fVkNnJwr1WB4yJq2awaa/348O P5AQx1YhiPEsMiem60gZrO1SC5KkZgNEo3DA4cNXMwYP/IbzIv2ZlGmzzzGaiW9H FfYSLUCBweg8488/SbdolgpTfws1pKcwaHmEyb00S1lmj7AwxmyYR1KSlDdKNzsm sPd8MJiUXJkhTR908OQbI1+5bXmXB80DwS8Grr63n+y7+fph3H5BNoLoyCE4h+Rd is+dK0rEGg7MoBxvsY8g =Iwuf -----END PGP SIGNATURE----- _______________________________________________ scap-security-guide mailing list --scap-security-guide@lists.fedorahosted.org mailto:scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org mailto:scap-security-guide-leave@lists.fedorahosted.org
--
Trevor Vaughan Vice President, Onyx Point, Inc
(410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --
scap-security-guide mailing list -- scap-security-guide@lists. fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@ lists.fedorahosted.org
Sorry for the double post, but this just popped into my head.
*Technically*, you could run a Red Hat workstation with an Arch VM on top of it and either set up an SSH tunnel or an IPSec tunnel at the Red Hat layer and then full screen Arch after you ensure that all traffic is passing through the tunnel in question and it would meet the FIPS requirements.
Or, you could just set up an IPSec tunnel and drive all of your systems through that one connection as long as the local network was considered closed and trusted.
I don't know if it's worth all of the trouble, but it should suffice with documentation.
Trevor
On Wed, Apr 19, 2017 at 5:18 PM, Trevor Vaughan tvaughan@onyxpoint.com wrote:
Sort of. There are clear definitions of data that needs to be protected in other NIST documents.
NIST 800-53 is the direct result of a FISMA mandate and NIST 800-53 SC-12 and SC-13 make it pretty clear that any crypto in use needs to be NSA-approved and/or FIPS validated (which for public federal systems amounts to the same thing once you trace it all out).
However, if the local data owner and security personnel are willing to take the risk *and* those credentials cannot be used to get into any other Federal system *and* they're willing to look someone in the eye and blatantly say that they're ignoring FISMA...knock yourself out.
Waivers are generally only generated in 30, 60, and 90 day increments though so you're going to have to repeatedly jump through the paperwork hoop.
All that said, if your system has *no* protected data (PII, FOUO, SBU, whatever) and your credentials cannot be used to access any other Federal system, then you should be just fine. Trying to migrate from that to a compliant system for production use may be a real bear though.
Thanks,
Trevor
On Wed, Apr 19, 2017 at 10:17 AM, McIntyre, James T. (Farragut Suitland, MD) jmcintyre@nmic.navy.mil wrote:
Just to add to the thread and to stir the bucket...
Can we define the line " If the agency specifies that the information or data be cryptographically protected, then FIPS 140-2 is applicable. In essence, if cryptography is required, then it must be validated."? Isn't cryptographic protection up to the data owner? If not required, say due to a closed environment, couldn't there be an argument for ARCH?
I truly believe it all needs to be verifiable and begins with FIPS 140-2 approval but doesn't this line give some decision making to the data owner?
Jim
-----Original Message----- From: Trevor Vaughan [mailto:tvaughan@onyxpoint.com] Sent: Tuesday, April 18, 2017 1:18 PM To: SCAP Security Guide Subject: [Non-DoD Source] Re: Introduction and Questions
I'm piggy backing on what Shawn is saying because I routinely bump into the FIPS and Common Criteria issue.
Common Criteria is actually easier to hand wave around since I haven't seen many systems that stick to CC as documented.
FIPS is more difficult since it is quite concrete and, until that changes, any non-FIPS certified system cannot be used to protect sensitive information.
This is the section from the CMVP website that always hits home:
FIPS 140-2 precludes the use of unvalidated cryptography for the cryptographic protection of sensitive or valuable data within Federal systems. Unvalidated cryptography is viewed by NIST as providing no protection to the information or data - in effect the data would be considered unprotected plaintext. If the agency specifies that the information or data be cryptographically protected, then FIPS 140-2 is applicable. In essence, if cryptography is required, then it must be validated.
Mapping Arch is definitely a good idea but, in theory, you can't do anything that requires data protection, like SSH, until Arch has a FIPS 140-2 approved cryptographic module (or Q4 2018 rolls around and/if the automated system rolls out).
Hopefully this is helpful.
Thanks,
Trevor
On Mon, Apr 17, 2017 at 2:28 PM, Major Hayden major@mhtx.net wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 04/17/2017 12:42 PM, bradt@signatureresearchinc.com wrote: > My name is Tim Bradt. I am software developer at SignatureResearch, Inc. I have been charged with getting SCAP up and running on some of our systems. > > We are running Arch Linux. I was wondering what the process would be for porting the RHEL7 guide to Arch as we need the DISA STIG for system approval.
Hello Tim, As others have mentioned already, the big job is to get an actualstandard assembled for Arch Linux. Once that's done, writing SCAP content or other scripts is much more straightforward.
We've tried to tackle a translation of the RHEL 7 STIG intosomething that works for CentOS 7 and Ubuntu 16.04:
https://github.com/openstack/openstack-ansible-securityhttps://github.com/openstack/openstack-ansible-security https://docs.openstack.org/developer/openstack-ansible-secur ity/ https://docs.openstack.org/developer/openstack-ansible-security/
(There's also a RHEL 6 STIG implementation for Ubuntu 14.04, butwe're deprecating that now.)
Some of that work may help you figure out how to translate theRHEL 7 STIG requirements for Arch Linux. Feel free to reach out if you need pointers. :)
- -- Major Hayden -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJY9RdZAAoJEHNwUeDBAR+xjCAP/1xFonXK1mh0X7bzFtNedXe/ QUhNDx8rRayPCKWb5aWT3n4qarsdq97AVpaLnxgGI+SArZwGEY6/tZdZiq4Znfkr yZZ71XcARp3CzDk1pw5ukZWXgZ464mBC2wnEawkuYHCGy9J2oo1t1LL/7XikSpXw g6MqZqC/E+WOR9lLTAQi0yBdBfj27P3Imn4DB7aHqFEC4GgBJavBrFIW58fSxh/D qU9xORrS3QbE039/mAsvf9lqlA2yyATey+bMeeVKVs/c72F5fWql8lpXhnYa2Z5C lBQJF/A9ECHinQtLxcCeZUDR5sGhhDgd0IrlSC5wnVURoBGF7UAezSNSORZvjJUS f5yWkYOpIY5aPmQxnzPPcDMBKajjag0m9Q3sfTPOJgRb3tBHtCjkChGeun9xIhLd +7MwMZVp+IZzQh3e4VPJFJk+RdfAIAHmQK2ocT2fVkNnJwr1WB4yJq2awaa/348O P5AQx1YhiPEsMiem60gZrO1SC5KkZgNEo3DA4cNXMwYP/IbzIv2ZlGmzzzGaiW9H FfYSLUCBweg8488/SbdolgpTfws1pKcwaHmEyb00S1lmj7AwxmyYR1KSlDdKNzsm sPd8MJiUXJkhTR908OQbI1+5bXmXB80DwS8Grr63n+y7+fph3H5BNoLoyCE4h+Rd is+dK0rEGg7MoBxvsY8g =Iwuf -----END PGP SIGNATURE----- _______________________________________________ scap-security-guide mailing list --scap-security-guide@lists.fedorahosted.org mailto:scap-security-guide@lists.fedorahosted.org To unsubscribe send an email to scap-security-guide-leave@lists.fedorahosted.org mailto:scap-security-guide-leave@lists.fedorahosted.org
--
Trevor Vaughan Vice President, Onyx Point, Inc
(410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --
scap-security-guide mailing list -- scap-security-guide@lists.fedo rahosted.org To unsubscribe send an email to scap-security-guide-leave@list s.fedorahosted.org
-- Trevor Vaughan Vice President, Onyx Point, Inc (410) 541-6699 x788 <(410)%20541-6699>
-- This account not approved for unencrypted proprietary information --
scap-security-guide@lists.fedorahosted.org
-
bradt＠signatureresearchinc.com -
Fen Labalme -
Major Hayden -
McIntyre, James T. (Farragut Suitland, MD) -
Michael Cochran -
Shawn Wells -
Trevor Vaughan