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 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>





--

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




--
Trevor Vaughan
Vice President, Onyx Point, Inc

-- This account not approved for unencrypted proprietary information --



--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788

-- This account not approved for unencrypted proprietary information --