mappings to DISA STIG identifiers
by Jeffrey Blank
I have started a new subject/thread for this discussion.
Please note: Subscribers to the list should never reply to any
message, particularly one with a complex subject, and move to an
off-topic discussion. It quickly results in confusion for mail
clients which perform threaded display, as well as the list's web
archives.
As to David's question, there has been some informal discussion, but
we have also not fully settled on how to do this. This will be a
topic of an upcoming discussion, and it will also be key to ensuring
that there is good correspondence between the STIG profile in SSG and
the STIG which FSO releases.
The CAT level should be identified as Severity (and this should be
present in scan results).
Assuming your desired output is a table, can you describe what columns
would be in it?
What's an IAC?
On Tue, Sep 3, 2013 at 6:25 PM, Moessbauer, David
<david.moessbauer(a)progeny.net> wrote:
> A crucial piece of the current C&A Package is the need to appropriately identify any vulnerabilities found via scans, inclusive of the CAT level, both of which are identified in the STIG. Aside from this, the STIG ID provides means to identify the IAC of a given vulnerability as well.
>
> CCI mapping would help, however, as these are not unique, it does not fully accomplish the task at hand.
>
> Speaking as one that completes C&A Packages for purposes of ATO acquisition, I would argue that this is a critical mapping.
>
> v/r
>
> David Moessbauer
> (410) 627-5633 (M)
>
> The Information contained in or attached to this communication may be confidential and privileged proprietary intended only for the individual/s or entity to whom/which it is addressed. Any unauthorized use, distribution, copying or disclosure of this information is strictly prohibited. If you have received this communication in error please contact the sender immediately and delete from your system.
>
>
> -----Original Message-----
> From: scap-security-guide-bounces(a)lists.fedorahosted.org [mailto:scap-security-guide-bounces@lists.fedorahosted.org] On Behalf Of Shawn Wells
> Sent: Tuesday, September 03, 2013 3:25 PM
> Cc: scap-security-guide(a)lists.fedorahosted.org
> Subject: Re: Possibility of Fedora SCAP content to be served by SCAP security guide repository (either as subdirectory or via separated branch)?
>
> On 9/3/13 2:22 PM, Moessbauer, David wrote:
>> Is there a matrix that can be referenced that will map the DISA
>> STIG-ID (or Group ID) to the CCE Audit IDs? ...or any other mapping
>> that can be deduced
>>
>> In Example:
>> Group ID (Vulid): V-38487
>> Group Title: SRG-OS-000103
>> Rule ID: SV-50288r1_rule
>> Rule Version (STIG-ID): RHEL-06-000015
>
>
> That metadata hasn't been added... to be honest, nobody has found the mappings meaningful enough to do. Can you help us understand how it'd benefit you?
>
> Right now SSG rules are mapped back to the CCIs through various <ref> tags, e.g.:
> <ref nist="AC-6,AU-9" disa="22,32" />
>
> We could easily extend this to include a "stigid" name-pair value, should (a) the community be convinced this would help end-users, and (b) volunteers to perform the mapping _______________________________________________
> scap-security-guide mailing list
> scap-security-guide(a)lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
> _______________________________________________
> scap-security-guide mailing list
> scap-security-guide(a)lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
10 years, 7 months
Possibility of Fedora SCAP content to be served by SCAP security guide repository (either as subdirectory or via separated branch)?
by Jan Lieskovsky
Hello Jeff, Shawn, SCAP security guide people,
[Sorry if this is not the appropriate place to discuss the topic
below. If so, kindly direct me to proper contact people. Thank you.]
{Sorry for such a long post, but got much information to share.}
We have internally discussed possibility to start creating SCAP content
for Fedora distribution. Snippet of previous conversation(s) below:
Subj = Fedora SCAP content adoption [was: Re: Challenges in SCAP adoption]:
============================================================================
Hello guys,
please find below draft we have agreed upon so far how
Fedora SCAP content next steps should look like (from discussion
at #openscap):
#1 Create Fedora subdirectory (preferably with Fedora version subdirectory yet)
in the upstream SSG git repository,
#2 Create new Fedora package (to be posted for review and maintained by
me) to be generated based on the content of that directory,
#3 Content provided by this package should be the primary source of
content, when doing oscap scans on Fedora hosts in the future.
For the content of that Fedora directory itself:
- Red Hat Security Technologies Team point of view:
* to have 3-rd party standardized content, which would be subset
of content we currently have for RHEL-6 to be possible to scan Fedora hosts
too,
- Red Hat Product Security Team point of view:
* to have content / policy / rules to check issues interesting from
security point of view (like the recent Amazon rootpw kickstart issue was)
The standardized Fedora content would be generated and maintained by me.
For the security issues content the maintainer needs to be agreed upon yet
(probably Dhiru will take this responsibility?)
Questions / comments welcome.
Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team
Shawn Wells has replied to this with the following (selected only relevant bits
from the reply):
================================================================================
> For the content of that Fedora directory itself:
> - Red Hat Security Technologies Team point of view:
> * to have 3-rd party standardized content, which would be subset
> of content we currently have for RHEL-6 to be possible to scan Fedora hosts
> too,
As a starting point, the "common" profile from RHEL6 may be of interest.
It reflects rules we've found to be consistent across all baselines
(STIG, USGCB, FISMA) however has generic refine values for things like
password length. Code:
https://git.fedorahosted.org/cgit/scap-security-guide.git/tree/RHEL6/inpu...
Below is my proposal regarding initial Fedora directory content, as sent to Shawn in
private message:
====================================================================================
* Part #1 regarding repository content:
I have had brief look at the common profile (thank you for that
direction Shawn):
[1] https://git.fedorahosted.org/cgit/scap-security-guide.git/tree/RHEL6/inpu...
but prior proposing any actual content changes in the SSG repository,
wanted to check "how things works / are expected to work" (mainly
in the sense of relation with scap-security-guide mailing list people)
with you.
I can create Fedora package spec / src.rpm proposal - when creating
this one i think Fedora subdirectory should follow the common directory
structure, i.e.:
* distro/
* input
* output
* references
* transforms
* utils
subdirectories, the Makefile and README files.
For the beginning i would say the 'input' subdir should have at least 'intro'
subdir, and guide.xml && guide.xslt files (of course 'profiles', 'checks' etc.
to come later).
These are all technical things, i should be able to handle (submit that
Fedora package for review, when it's time comes etc.).
But what i mainly wanted to check with you being how i am expected to communicate
these changes on scap-security-guide mailing list. Should we first communicate this /
schedule a meeting with Jeffrey Blank regarding this? Will you communicate this with
Jeffrey? Or should these intentions be communicated on SSG mailing list first? Shawn,
your guidance here would be appreciated.
I think once this skeleton of Fedora directory is agreed upon, we can follow up
with discussion wrt to upcoming content (assuming to be based on subset of 'common.xml'
profile checks).
To summary:
===========
* after internal mailing communication we agreed on it's time to start creating
Fedora SCAP content,
* the current proposal is this content to live in SCAP security guide repository
under dedicated Fedora subdirectory (or under dedicated git branch),
* we can / will handle the technical issues (provide content for the subdirectory
[which after common SSG patch approval process would be committed into SSG repo],
create directory structure, create package for Fedora distribution, handle it's
review process etc. when it's time comes etc.,
* but prior actual sending of initial patch (realizing the above proposals),
wanted to communicate these intentions with you to see if you / SSG members
would have some objections against this to be realized. If so, please let us
know (also in case there is different procedure expected to be pursued,
when proposing such changes, let us know which one that is).
Thank you && Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team
10 years, 7 months
[PATCH] created Rule to restrict access to dmesg
by David Smith
---
RHEL6/input/system/permissions/execution.xml | 11 +++++++++++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/RHEL6/input/system/permissions/execution.xml b/RHEL6/input/system/permissions/execution.xml
index 86d2ea7..081832a 100644
--- a/RHEL6/input/system/permissions/execution.xml
+++ b/RHEL6/input/system/permissions/execution.xml
@@ -199,4 +199,15 @@ allow users to turn the feature on or off at will.</rationale>
</Rule>
</Group> <!--<Group id="enable_nx"> -->
+
+<Rule id="enable_dmesg_restriction">
+<title>Restrict Access to Kernel Message Buffer</title>
+<description><sysctl-desc-macro sysctl="kernel.dmesg_restrict" value="1" /></description>
+<ocil><sysctl-check-macro sysctl="kernel.dmesg_restrict" value="1" /></ocil>
+<rationale>Unprivileged access to the kernel syslog can expose sensitive kernel
+address information.</rationale>
+<ident cce="27366-4" />
+</Rule>
+
+
</Group> <!--<Group id="restrictions"> -->
--
1.7.1
10 years, 7 months
[PATCH 0/2] added XCCDF and OVAL for kernel.dmesg_restrict
by David Smith
This patch set introduces a new rule for restricting access to dmesg, and
template-created OVAL for checking the sysctl value. The OVAL was tested:
[dave@rhel6 checks] sysctl kernel.dmesg_restrict ; ./testcheck.py sysctl_kernel_dmesg_restrict.xml
kernel.dmesg_restrict = 1
Evaluating with OVAL tempfile : /tmp/sysctl_kernel_dmesg_restrictH4fcfB.xml
Writing results to : /tmp/sysctl_kernel_dmesg_restrictH4fcfB.xml-results
Definition oval:scap-security-guide.testing:def:100: true
Evaluation done.
David Smith (2):
new rule for restricting access to dmesg
new OVAL check for kernel.dmesg_restrict
.../input/checks/sysctl_kernel_dmesg_restrict.xml | 28 ++++++++++++++++++++
RHEL6/input/checks/templates/sysctl_values.csv | 1 +
RHEL6/input/system/permissions/execution.xml | 12 ++++++++
3 files changed, 41 insertions(+), 0 deletions(-)
create mode 100644 RHEL6/input/checks/sysctl_kernel_dmesg_restrict.xml
10 years, 7 months
Various False Positives?
by leam hall
Hey all,
Just ran oscap with the xml files available on the website (Benchmark
version 0.9). Here are the issues that seem to be false positives. Prefix
everything with "RHEL-06-000". These are all marked as fail but the server
meets the STIG.
9 rhnsd can be on if configured to Satellite server or similar
57 ucredit
58 ocredit
59 lcredit
73 /etc/issue
98 No ipv6 installed
99 "
165 adjtimex
167 settimeofday
169 stime // Also, the STIG is wrong. There is no x86_64 stime syscall
171 clock_settime
184-196, 200 chmod, chown, etc...
206-211 No telnet installed or turned on
240 /etc/ssh/sshd_config Banner
271 If there are no removable partitions this is not a finding.
278 If the file permissions are more restrictive then it is not a finding.
324 No X running
326 "
346 Finding reported on umask 022
348 No vsftp installed, thus no file.
506 "hushlogin"
507 PrintLastLog
Am I confused in thinking a system in run level 3 should net need to worry
about X/Gnome findings?
Leam
--
Mind on a Mission <http://leamhall.blogspot.com/>
10 years, 7 months
Fwd: SCAP Compliance Checker 3.1.1 Final Release
by Shawn Wells
FYI for those not on SPAWAR's distribution list
--
Shawn Wells
Director, Innovation Programs
shawn(a)redhat.com | 443.534.0130
@shawndwells
-------- Original Message --------
Subject: SCAP Compliance Checker 3.1.1 Final Release
Date: Tue, 3 Sep 2013 09:18:54 -0400
From: SSC LANT-SCC <ssc_lant-scc.fcm(a)navy.mil>
We would like to thank everyone that was involved in the SCC 3.1.1 Release Candidate testing over the past month. We are pleased to announce that we have finished development of SCC 3.1.1.
Since several bugs were fixed from SCC 3.1 to SCC 3.1.1, we highly recommend upgrading to SCC 3.1.1.
You'll be receiving an email from AMRDEC in the next hour with download instructions
Primary Changes from SCC 3.1 to 3.1.1
For All Platforms
. Update SCC to support cpe dictionary files with namespace prefixes.
. Updated NIST USGCB Windows XP/Vista/7 patch content to 07.31.2013 release.
. Updated all DISA STIG SCAP content based on July 24, 2013 release.
. Updated notification of Beta Expiration Days to be visible to end users.
For Windows
. Updated Windows file tests to support "Short filename" (8.3) as the path argument.
. Updated Registry Probe to Improve Support of Recursion Behavior.
. Updated Windows File Probe to Improve Support of Remote Analysis
. Updated SCC to Improve Support of Filters for Registry Objects.
. Fixed SCC to run from CD-ROM on Windows.
For UNIX
For all UNIX (Linux, Solaris, Mac OS X)
. Fixed SCC expiration issue.
For Linux
. Fixed IP address identification on Linux
For Solaris
. Fixed IP address identification on Solaris
For Mac OS X
. Updated SCC to start without error.
Doug Tanner
Code 58510
SPAWARSYSCEN Atlantic
10 years, 7 months