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