On 7/21/17 2:06 PM, Chuck Atkins wrote:
But it's a good thread!
Wow, so this whole thread really took on a life of it's own, far
outside the scope of my original intent. So to try to bring it
(and very representative of open source conversations, which is
The profile split started when ...
Thanks for the background info, it helps to understand why
things are the way they are.
If having DISA release updated content is important to you ...
Not specifically, that just makes it easier since the
auditors know the DISA STIG and that what they ask about. So
long as I have a good profile with sound security practices
that I can justify to my ODAA auditor then I'm satisfied. The
OSPP profile should fit that purpose well and if I explain it
to auditors, I'm 70-80% confident I can get them on board with
SSG content contains metadata that maps every configuration check to
corresponding policy. Maybe sharing those policy mapping tables will
help boost confidence?
Here's one for NIST 800-171 (Controlled Unclassified):
And another mapping checks back to DISA OS SRG (aka their STIG
And another back to NIST 800-53:
The reports can also be sorted by the policy mappings. Here's a
sample report from the 800-171 profile:
Under the "Rule Overview" you'll see a drop down called "Group Rules
by". Select the NIST 800-53 drop down and you'll see the report
re-styled like this:
That's a fair statement. The profile is intended for attesting bare
metal/virtual/containers, desktop or server. The configuration
checks, such as those for GNOME, will only run if GNOME is actually
Here are the dconf/GNOME control selections in case you're curious:
Skimming quickly through the profile, I think the "must remove X11"
rule was dropped. Instead, it's more of "if X11 or GNOME is
installed, we verify the following settings."
Most system settings check if they're applicable before attesting
them. AKA the SSH checks won't run unless SSH is installed (lookin'
at you, Trevor Vaughan).