A tool for support of SCAP content development
by Jan Cerny
Hello,
Nowadays, there is almost no support for OVAL content development.
The developers have to edit the XML files manually, there is no
analysis tool, no debugger or any other tool that could make
the content development faster and easier.
I have started working on a new utility that will be able to
debug OVAL checks, show step-by-step how they are evaluated,
browse collected objects and system characteristics, communicate
with probes, etc.
I'm working on design of the utility now. I'm considering many
alternatives, so I would like to ask you a few questions.
* Can you describe most common problems that you have to face
when you create the OVAL content?
* How do you usually solve these problems?
* Can you tell me an example when did you run into issues with OVAL?
* Imagine an ideal tool for an OVAL developer. What should it be
able to do? What would be its features?
I would appreciate any suggestions, remarks or other inputs.
Thank you very much for your reply.
Regards
Jan Černý
Security Technologies | Red Hat, Inc.
8 years, 7 months
scap-workbench and SSG -.1.25
by Ron Backman
I am using SCAP-Workbench 1.0.2 on CentOS 7 and just downloaded the lastest
Scap Sceucity Guides version 0.1.25
I am getting the following error. I tried opening a few of the other Data
Stream XML docs and am getting the same error. Is this DataStream (1.2) to
new for the SCAP -Workbench?
Ideas?
--------------------------------
19:49:48
info
scap-workbench 1.0.2, compiled with Qt 4.8.5, using openscap 1.1.1
19:50:00
except
Error while opening file. There was a problem with ScanningSession! Failed
to reload session. OpenSCAP error message: Invalid SCAP Source Datastream
(1.2) content in
/home/backman/Downloads/scap-security-guide-0.1.25/ssg-centos7-ds.xml.
[xccdf_session.c:352]
8 years, 8 months
Security & Compliance Auditing at Scale
by Šimon Lukašík
Hello OpenSCAPers!
I would like to highlight recent extension of OpenSCAP ecosystem.
Release 6.1 of Red Hat Satellite contains OpenSCAP plug-in that helps
you to set-up policies & continuous audits of the infrastructure. You
can explore the feature set in short video at
https://www.youtube.com/watch?v=p4uNlzYld-Y
Best regards,
--
Šimon Lukašík
Senior Software Engineer
Team Lead, Security Compliance, Red Hat, Inc.
8 years, 8 months
OpenSSH patch
by Ron Colvin
A patch for the SSH bug that bypassed the MaxAuthTries limit was just
patched. Has MaxAuthTries been considered as a control in the security
guide?
http://www.openssh.com/txt/release-7.0
https://threatpost.com/openssh-7-0-fixes-four-flaws/114265
--
********************************************************
Ron Colvin CISSP, CAP, CEH
Certified Security Analyst
NASA - Goddard Space Flight Center
<ron.colvin(a)nasa.gov>
Direct phone 301-286-2451
NASA Jabber (rdcolvin(a)im.nasa.gov) AIM rcolvin13
NASA LCS (ronald.d.colvin(a)nasa.gov)
********************************************************
8 years, 8 months
Fwd: scap
by Michael Boutillier
Hi all,
Thirst thanks a lot for the all the good work done here ;)
I experience a strange issue after building via make the ssg for
centos6 (0.1.24
release)
When running :
/usr/bin/oscap xccdf eval --profile pci-dss
/usr/share/xml/scap/ssg-centos6-xccdf/ssg-centos6-xccdf.xml
All check are not applicable
Looking at the content of the produced xccdf i notive that the platform tag
was still referencing rhel and not centos cpe
To make the resulting xccdf work on a centos6 I had to change the following
line in ssg-centos6-xccdf.xml:
*<ns0:platform idref="cpe:/o:linux: enterprise_linux:6" />*
by
*<ns0:platform idref="cpe:/o:centos:centos:6" />*
And now the command bellow work as expected
/usr/bin/oscap xccdf eval --profile pci-dss
/usr/share/xml/scap/ssg-centos6-xccdf/ssg-centos6-xccdf.xml
So I took a big breath and I try to run the enable-derivative.py by hand
When I run it with ds or xccdf the result differs :
*../../shared/utils/enable-derivatives.py --enable-centos -i
output/ssg-rhel6-xccdf.xml -o /tmp/mike-centos6-xccdf.xml*
*[mike@caprica 6]$ grep platform /tmp/mike-centos6-xccdf.xml |grep cent*
--> no output
*../../shared/utils/enable-derivatives.py --enable-centos -i
output/ssg-rhel6-ds.xml -o /tmp/mike-centos6-ds.xml*
*[mike@caprica 6]$ grep platform /tmp/mike-centos6-ds.xml |grep cent*
* <ns9:platform idref="cpe:/o:centos:centos:6" />*
--> we have the centos6 as expected
Digging deeper I thought that it is probably related to the following line:
* benchmarks.extend([*
* (XCCDF11_NS, elem)*
* for elem in list(root.findall(".//{%s}Benchmark" % (XCCDF11_NS)))*
* ])*
* benchmarks.extend([*
* (XCCDF12_NS, elem)*
* for elem in list(root.findall(".//{%s}Benchmark" % (XCCDF12_NS)))*
* ]) *
For a strange reason the root.findall seems not to work with the xccdf file
I could not find out why this is not working….
XCCDF :
*<Benchmark xmlns="http://checklists.nist.gov/xccdf/1.1
<http://checklists.nist.gov/xccdf/1.1>"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance
<http://www.w3.org/2001/XMLSchema-instance>" id="RHEL-6" resolved="1"
xml:lang="en-US">*
DS:
*<Benchmark xmlns="http://checklists.nist.gov/xccdf/1.2
<http://checklists.nist.gov/xccdf/1.2>"
id="xccdf_org.ssgproject.content_benchmark_RHEL-6" resolved="1"
xml:lang="en-US">*
To make a silly test I try the following
* benchmarks.extend([*
* (XCCDF11_NS, elem)*
* for elem in
list(root.findall("."))
*
* ])*
*../../shared/utils/enable-derivatives.py --enable-centos -i
output/ssg-rhel6-xccdf.xml -o /tmp/mikeeeee*
*[mike@caprica 6]$ grep centos /tmp/mikeeeee*
* <ns0:notice id="centos_warning"><html:div>*
* <ns0:platform idref="cpe:/o:centos:centos:6" />*
The result make me think i'm on looking on the right spot, but I could not
find out why.
Somebody got an idea of what is going on? Or am I totaly missing something
Regards
Mike
PS : the same issue seems to affect RHEL7
REPS: i try to build on centos6 and fedora 21 (just in case i had a strange
python dep issue or something) : same result
--
Michael Boutillier
8 years, 8 months
Re: [New Release] SCAP Security Guide 0.1.23 is now live
by Jan Lieskovsky
Hello Daniel,
thank you for checking.
----- Original Message -----
> From: "Dan Warburton" <dan.warburton(a)jvncomm.com>
> To: "SCAP Security Guide" <scap-security-guide(a)lists.fedorahosted.org>
> Sent: Monday, June 29, 2015 4:19:20 PM
> Subject: Re: [New Release] SCAP Security Guide 0.1.23 is now live
>
>
>
> Jan,
>
>
> Did you generate the per-builts? I do not see them.
No sorry, I didn't create them yet. Originally planned to make them
manually, then starting from the future versions to add new Makefile
target that would build them automatically.
But later I changed my mind - it's better to start creating them
automatically right from the scratch (read as add new SSG GitHub
repo Makefile target, that would create them upon request).
This way we can find an agreement wrt e.g. to paths, where the content
should be installed etc. (wanted to do this earlier, but in the meantime
got distracted by other issues).
I will do make that pull request tomorrow (so tomorrow in the evening
they could be available already).
Sorry for the delay (and thanks for the remainder!)
Regards, Jan.
--
Jan iankko Lieskovsky / Red Hat Security Technologies Team
>
>
>
>
>
>
>
> On June 23, 2015 at 11:53 AM Jan Lieskovsky <jlieskov(a)redhat.com> wrote:
>
>
> Hello folks,
>
> we are thrilled to announce the GA for the SCAP Security Guide of version
> 0.1.23
> -- the highlights for this release include:
>
> * Start porting of PCI-DSS profile from RHEL-6 to RHEL-7
> * Add OVAL-5.11 language support for RHEL-7 product if underlying system's
> oscap version supports OVAL-5.11 already
> * Start generating benchmarks for derivative OSes (CentOS, Scientific Linux)
> * Get rid of using symbolic links mechanism for OVAL checks shared across
> multiple products (RHEL/6, RHEL/7, and Fedora)
> * Enhance XML files validation performed via make validate target for all
> products
> (optimize speed, validate all XML files against schematron where possible
> etc.)
>
> For a more detailed Changelog / Release Notes for this release kindly have a
> look at:
> [1] https://github.com/OpenSCAP/scap-security-guide/releases
>
> For the instructions how to try the new upstream version from source tarball
> kindly have a look at:
> [2] https://github.com/OpenSCAP/scap-security-guide/wiki/Building-from-Source
>
> For the prebuilt XML files -- I will try to generate them within tomorrow and
> update the v0.1.23
> tag page appropriately when done.
>
> Please report any issues encountered with the newly added (but also formerly
> existing) SSG content
> via GH tickets interface:
> [3] https://github.com/OpenSCAP/scap-security-guide/issues/new
>
>
> Happy hardening!
>
> Regards, Jan
> --
> Jan iankko Lieskovsky (on behalf of the SCAP Security Guide upstream team)
> --
> SCAP Security Guide mailing list
> scap-security-guide(a)lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
> https://github.com/OpenSCAP/scap-security-guide/
>
>
> Dan Warburton / JVN Communications w: 609-485-4480 m: 609-457-0154
8 years, 8 months
"Make validate" fails
by Jan Cerny
Hello,
I have run make validate on RHEL7 content from current SSG upstream.
Make validate fails because there are many invalid references to
non-existent OVAL definitions.
Moreover, I have discovered that "validate" target in SSG Makefile
is commented out for RHEL7, OpenStack and RHEVM3 content. It's commented
out since August 2014. I think this is very unpleasant because we haven't
validated the RHEL content for a long time.
I have filed an issue on github:
https://github.com/OpenSCAP/scap-security-guide/issues/635
Regards
Jan Černý
Security Technologies | Red Hat, Inc.
8 years, 8 months
Symbolic link permissions cause test to fail
by Ron Backman
I am new to OpenSCAP and am stuck
Operating System is CentOS 7.1
oscap version is 1.1.1
I am using "ssg.rhel7.ds..xml" to scan with.
The Rule "Verify that Shared Library Files have Restrictive Permissions"
indicate a "FAIL"
I am using SCAP-Workbench. When I run a scan, that Rule fails. Apparently
the Rule is looking for NO Group or Other write permissions (555) But on
CentOS 7.1, the /lib and /lib64 directories do not exist by default and
Symbolic links are used instead. They point to the real directories
/usr/lib and /usr/lib64 respectively. By default, apparently, symbolic
links have file permissions of "777". This is why I think the test is
failing. I don't see how to do an effective "chmod" on a symbolic link.
So I thot I would simply take the directories of interest (/lib and /lib64)
out of the Rule criteria. But I don't know how to do that.
I need help correcting this Rule test so the test will indicate a "PASS".
I suppose I could actually delete the two symbolic links but I might break
something
Ideas?
Ron
8 years, 8 months