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(a)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(a)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(a)mhtx.net> wrote:
>
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 04/17/2017 12:42 PM, bradt(a)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-secur
> ity/
> <
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(a)lists.fedorahosted.org
> <mailto:scap-security-guide@lists.fedorahosted.org>
> To unsubscribe send an email to
> scap-security-guide-leave(a)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(a)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 --
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699 x788
-- This account not approved for unencrypted proprietary information --