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(a)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