Re: [Open-scap] Suspect Error in ssg_rhel6-ds.xml: Incorrect reference to NIST SP 800-53r4 control category

[Shawn Wells]

On 2/17/16 2:06 PM, Jan Lieskovsky wrote:

Hello Mike,

   thank you for contacting us.

- Original Message -

>From: "Mike Kuhnkey"
>To:Open-scap-list@redhat.com
>Sent: Monday, February 15, 2016 1:29:47 AM
>Subject: [Open-scap] Suspect Error in ssg_rhel6-ds.xml: Incorrect reference to 
NIST SP 800-53r4 control category
>
>In the DataStream referred to above:
>
>line# 25738 http://nvlpubs.nist.gov/nistubs/SpecialPub
>lications/NIST.SP.800-53r4.pdf">194;
>line# 25739 http://iase.disa.mil/stigs/cci/Pages/index
>.aspx">194;
>
>Appears to be incorrect format for NIST SP-800-53r4 control
>categoryreference format should be of type AA-N.  Not NNN?

Can you clarify what those "AA-N" and "NNN" abbreviations refer to?
Or select an example from e.g.:
   [1]http://linguistics.byu.edu/faculty/henrichsenl/apa/APA10.html

you would like the SSG upstream to follow when creating the references?

Feel free to file an upstream RFE with an example wrt to this:
   [2]https://github.com/OpenSCAP/scap-security-guide/issues/new



A DISA CCI reference snuck into the NIST ref tag:
RHEL/6/input/xccdf/system/accounts/pam.xml:309:nist="IA-5(b),IA-5(c),194" disa="194"/>


Submitted patch upstream:
https://github.com/OpenSCAP/scap-security-guide/pull/1043



___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Testing OpenScap, but no vulns show up

[Shawn Wells]

On 3/8/16 10:58 AM, Joseph Spenner wrote:

Hello, I am testing after installing with the following instructions:
https://www.open-scap.org/resources/documentation/perform-vulnerability-scan-of-rhel-6-machine/

I downloaded CentOS 6.0 to use for a test, thinking there should be 
plenty of vulnerabilities since this was such an older release.  
However, I got zero vulnerabilities.


Is this an invalid test?


CentOS is (unsupported) community software, they do not publish or 
maintain vulnerability information in OVAL formats.


You'll want to re-run your test on RHEL :)

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

[Open-scap] Increase depth of table of contents?

[Shawn Wells]

'xccdf generate guide' currently creates HTML with a table of contents 
depth of two. Could we either:


a) Increase the default table of contents depth? For SSG, a depth of 3 
or 4 seems good. Ref code:

https://github.com/OpenSCAP/openscap/blob/maint-1.2/xsl/xccdf-guide-impl.xsl#L468

b) Create CLI argument for user-defined table of contents depth?

For the SSG content, generally XCCDF rules are nested 3 groupings down 
and are not displayed in the default Table of Contents setting.


___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Offline scanning - SCE, probes

[Shawn Wells]

On 4/14/16 4:07 AM, Jan Cerny wrote:

Hi Zbyněk,


- Original Message -

>From: "Zbynek Moravec"
>To:open-scap-list@redhat.com
>Sent: Wednesday, April 13, 2016 11:47:51 PM
>Subject: [Open-scap] Offline scanning - SCE, probes
>
>Hi
>
>We plan to implement offline scan support for SCE scripts. I would like to
>ask
>for our opinion.

Thanks for sharing this with the community!

+1!



>
>We have two? options how to deal with SCE offline scan support
>- 1] pass new root path to script (env variable)
>   - Script will decide how to scan new root, it can use path prefix, chroot..

This approach sounds like delegating the problem to authors of SCE checks 
scripts.
Each script will have to support offline scan in its own way.
But I suspect that somewhere in first line of those scripts chroot will be 
anyway called.


>- 2] oscap will do chroot before execute script
>   - Script don't need to know that it is in different root

I think that we want this second option, because then the SCE scipts
could be simple and universal and everybody will be able to use his old
content to scan his containers and VMs.
Another +1. The same content should work between RHEL deployment models 
(bare metal, docker, VMs).


___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Awesome work

[Shawn Wells]

On 5/9/16 8:07 PM, david.ol...@verizon.net wrote:


Fellow Open-Scappers:

I just got my Open-SCAP tool to work on CentOS 7 and works great.  In 
looking at the output, I noticed
that a significant number of CCEs do not have a numeric value to them, 
but appear to be left open.

Who gets to enter CCEs to the NIST CCE dictionary?



Red Hat requests a block of CCEs from NIST, and dumps them into the 
"cce-rhel-avail.txt" file:

https://github.com/OpenSCAP/scap-security-guide/blob/master/shared/references/cce-rhel-avail.txt

Anyone in the community can take a CCE out of the available list and 
assign to an XCCDF rule. We do ask that someone from Red Hat merges the 
patch, as once assigned it does become a binding identifier that Red Hat 
corporately attests to.


Noticed we're running low on CCEs. Just pinged NIST for more.
___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] SCAP editor

[Shawn Wells]

On 5/23/16 1:05 AM, Pravin Goyal wrote:


Hi All,

Drawing your attention towards http://www.g2-inc.com/escape.


Do we have a fair number of people who are using this (or wanted to 
use this but put it down since it is not kept up to date)?



I am trying to refresh the tool:

 1. Add support for OVAL 5.11.1 - for Windows, Linux, Unix and
Independent schemas only
 2. Add support for creating XCCDF 1.2 from OVAL 5.11.1 content (No
XCCDF development support as such. Just take OVAL as input and xsl
transform it into XCCDF 1.2)
 3. Strip down all other broken capabilities and schema versions (such
as OVAL 5.3 etc.)

To me, #1 is the most important thing and is most widely used. Is 
there anything else that I should look at?


Please let me know your comments.


- Adding a feature akin to the SSG testcheck.py scripts. If writing a 
singular OVAL check, it'd be great to compile that into proper SCAP 1.2 
compliant file and run it.

- Auto completion of OVAL definitions (ind:filepath, testcheck...)

--
Shawn Wells
Chief Security Strategist
U.S. Public Sector
sh...@redhat.com | 443.534.0130

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Informational value

[Shawn Wells]

On 7/1/16 3:38 AM, Jan Cerny wrote:

Regarding your second question, OpenSCAP >= 1.2.2 can display OVAL results
in the HTML report if you run it with "--oval-results", eg.:

# oscap xccdf eval --results results.xml --oval-results --report report.html 
my_benchmark.xml

The HTML report will look like in [2].

[1]http://csrc.nist.gov/publications/nistir/ir7275-rev4/NISTIR-7275r4.pdf  
(page 43)
[2]https://www.open-scap.org/wp-content/uploads/2015/09/ssg-rhel7-ds-xccdf.report.html


Can we have the findings showup in the default reports, e.g. those 
without --oval-results? Why burden the users with another CLI argument?


Also, some of the OVAL result summaries are very confusing. Compare "Set 
Last Logon/Access Notification" with the various object and type 
expressions listed in "Set Deny For Failed Password Attempts" it's 
not clear what all that means. "Last Logon" shows the text of the 
passing file, whereas "Failed Password Attempts" lists subexpressions 
instead.


Does this depend on how the OVAL rules are written, or OpenSCAP 
reporting? Reports would be easier to interpret if we showed the 
offending text, vs a "subexpression" value.


E.g.: current report from "failed password attempts":



Items not found violatingCheck pam_faillock.so preauth silent
present in /etc/pam.d/system-auth:


  Object*oval:ssg:obj:870*of type*textfilecontent54_object*

Behaviors   FilepathPattern Instance
no value 	/etc/pam.d/system-auth 
[\n][\s]*auth[\s]+required[\s]+pam_faillock\.so[\s]+preauth[\s]+silent[\s]+[^\n]*deny=([0-9]+)[\s]*[^\n]*[\n][\s]*auth[\s]+sufficient[\s]+pam_unix\.so[^\n]*[\n] 
	1



  State*oval:ssg:ste:871*of type*textfilecontent54_state*

Subexpression
6





Could be changed to:



Items not found violatingCheck pam_faillock.so preauth silent
present in /etc/pam.d/system-auth:


  Object*oval:ssg:obj:870*of type*textfilecontent54_object*

Behaviors   FilepathPattern Instance
no value 	/etc/pam.d/system-auth 
[\n][\s]*auth[\s]+required[\s]+pam_faillock\.so[\s]+preauth[\s]+silent[\s]+[^\n]*deny=([0-9]+)[\s]*[^\n]*[\n][\s]*auth[\s]+sufficient[\s]+pam_unix\.so[^\n]*[\n] 
	1



  State*of /etc/pam.d/system-auth***

Subexpression
FAIL: No lines match regex in /etc/pam.d/system-auth




___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] New COPR repository for OpenSCAP projects

[Shawn Wells]

On 7/19/16 11:31 AM, Martin Preisler wrote:

- Original Message -

>From: "Jan Cerny"
>To:open-scap-list@redhat.com
>Sent: Tuesday, July 19, 2016 9:19:04 AM
>Subject: [Open-scap] New COPR repository for OpenSCAP
>
>Hi all,
>
>We have created a new COPR repository that provides unofficial builds
>of latest versions of openscap, scap-security-guide, scap-workbench
>and openscap-daemon packages. The packages are suitable for use
>on Red Hat Enterprise Linux 5, 6 and 7 and CentOS 5, 6 and 7.
>The COPR repository is located on:
>https://copr.fedorainfracloud.org/coprs/openscapmaint/openscap-latest/
>
>The repo enables you to test the latest greatest OpenSCAP bits on RHEL and
>CentOS.
>
>The former repository isimluk/OpenSCAP will not be maintained anymore.
>Sorry for inconvenience.
>
>Best regards
>
>Jan Černý
>Security Technologies | Red Hat, Inc.

CC-ing scap-security-guide. The new COPR repo contains latest SSG packages
and might be useful to our community members.

The repo is:
https://copr.fedorainfracloud.org/coprs/openscapmaint/openscap-latest/

Instructions on how to enable the repo are on the page.


Thanks guys. Updated SSG's README.

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

[Open-scap] Compiling OpenSCAP

[Shawn Wells]

Was compiling OpenSCAP per directions:
http://static.open-scap.org/openscap-1.0/oscap_user_manual.html#devs

When running ./configure, receive following error:

checking for atomic builtins... yes
configure: error: in `/home/ec2-user/openscap':
configure: error: oscap-docker requires bzip2! Either disable 
oscap-docker or install bzip2.

See `config.log' for more details


However, I have bzip2 installed:

$ rpm -qv bzip2
bzip2-1.0.6-8.12.amzn1.x86_64


I believe the docs should be updated to say bzip2-devel is needed. Can 
this be added into the install docs?


___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Latest OpenSCAP changes to speed up SSG builds

[Shawn Wells]

On 8/2/16 2:51 PM, Martin Preisler wrote:

- Original Message -

>From: "Jan Lieskovsky"
>To: "Martin Preisler"
>Cc: "SCAP Security Guide", 
"open-scap-list"
>Sent: Monday, August 1, 2016 12:38:01 PM
>Subject: Re: Latest OpenSCAP changes to speed up SSG builds
>
>
>Hello Martin,
>
>[snip]
>
>I agree this change to be safe to be applied on Jenkins slaves
>(IOW it's functionally identical to version in previous oscap releases).

Thanks for the review, Jan!

I have applied the optimizations on Jenkins slaves and from my initial
testing the time required for pull request builds and normal CI builds
went down roughly 35-40%. It's not as much as I expected but it is
a noticeable improvement.

Old typical el7 SSG build + validate times: 30-40 minutes.
New typical el7 SSG build + validate times: 20-30 minutes.

The next big optimization lies in getting better hardware for Jenkins.
`make jenkins` takes 2m16.877s on my work laptop and 20+ minutes on
the OS1 nodes. That is a huge difference. And my laptop can't be called
a powerful machine, it's just a dual core i7 laptop.


OS1 is being decommissioned over the coming months. I'm not sure what 
(if any) environment is taking over for that.


What kind of computing power do we need? Perhaps we could look into a 
Reserved Instance on EC2.
___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Really nice tool

[Shawn Wells]

On 9/27/16 4:07 AM, Jan Cerny wrote:
> Hello David,
>
> - Original Message -
>> From: "david oliva" 
>> To: Open-scap-list@redhat.com
>> Sent: Tuesday, September 27, 2016 3:09:35 AM
>> Subject: [Open-scap] Really nice tool
>>
>>
>>
>> Dear Red Hat /OpenSCAP team:
>>
>>
>>
>>
>> Today 26 Sep 2016 Ihad the opportunity to run OpenSCAP on RHEL 7 for the
>> first time, andI am very pleased.
> Nice to hear that!
>
>> Installing OpenSCAP,and the SCAP Workbench was very straight forward with the
>> yum installcommand.
>>
>>
>>
>> - The content thatcame with the package was easy to run. I used the Workbench
>> to run the XCCDF content, created an XML report and looked at the report in
>> another browser.
> You can also generate a nice HTML report using "Show report" button.
>
>>
>>
>>
>> - It was very niceto see a good use of the CCE specification. The first
>> questioncoming to mind is, do you maintain a CCE dictionary that you can
>> makeavailable? A second question is, if a user wants to identify
>> aconfigurable parameter and no CCE is available, can the user (verylikely a
>> developer) request a CCE number?
> We don't maintain a CCE dictionary, the CCE numbers have been requested from 
> NIST.

Tables which map CCEs to NIST 800-53 references exist. For example, the
following is generated via 'make tables':
http://people.redhat.com/swells/scap-security-guide/RHEL/7/output/table-rhel7-nistrefs-ospp.html

Right now the tables are generated on a per-profile basis. That was
largely driven by user request. There's no reason we couldn't generate a
"master mapping table" if that'd be useful.

As Jan mentioned, CCE numbers are given to technology vendors by NIST.
For Red Hat technologies, we drop the CCEs into the
shared/references/cce-rhel-avail.txt file. From there, community members
can take an available CCE and assign them to a RedHat configuration rule
(e.g. in RHEL6 or RHEL7) via a pull request. Alternatively, open a
ticket requesting a mapping. Note that tickets on GitHub reflect
community initiatives -- no SLAs, just community effort. Tickets
directly against Red Hat (via customer support) carry SLAs. Both methods
are valid, just depends on how you chose to engage with the OpenSCAP
community :)


>> - Analyzing theoutput XML reveals that the findings are mapped to the
>> securitycontrols of SP 800-53 Rev 4. What a nice feature!.
>>
>>
>> - One of the videoson your site (
>> https://www.open-scap.org/security-policies/scap-security-guide/#documentation
>> )indicates that you are engaging a remediation mechanism and not
>> justdiscovering vulnerabilities. Are you using a remediation protocolor
>> specification in particular?
> Remediation is done by remediation scripts. The scripts are written in Bash.
> Those scripts are included in the SCAP content.
> The remediation can be run directly while scanning from SCAP Workbench or 
> oscap command line tool.
>
> Currently we are working on adding remediation in a from of Ansible playbooks.
> See https://blog-zbynek.rhcloud.com/2016/09/12/ssg-openscap-and-ansible/
>
>
>> - The output XMLshows a very nice use of the CPE specification.
>>
>>
>> - The use of XCCDFis also very good. Can you please, point me to a Red Hat
>> XCCDFrepository? Are you planning your content in the
>> NationalVulnerabilities Database?
> I suppose you mean that XCCDF that SCAP Workbench used for scanning your RHEL 
> machine.
> That XCCDF comes from the SCAP Security Guide project. SCAP Security guide is 
> an open-source
> set of security policies written in SCAP format.
> The source code is available at Github:
> https://github.com/OpenSCAP/scap-security-guide
> Latest release is here:
> https://github.com/OpenSCAP/scap-security-guide/releases/download/v0.1.30/scap-security-guide-0.1.30.zip
> We plan to submit the USGCB profile of SCAP Security Guide to NVD.

In regards to a "red hat repository," upstream would be the
OpenSCAP/SCAP Security Guide. Downstream in RHEL, content ships via the
"scap-security-guide" package.

We've been trying to get RHEL6 and RHEL7 content into the NIST NVD for
_*years*_. Seems an impossible task.


>> - I am interested inrunning a vulnerability scan (I would like to see how
>> OpenSCAP usesCVEs and CVSS)
> Yes, it is possible, and it's one of the most common use-cases of OpenSCAP.
> Red Hat provides a CVE streams for all the CVEs discovered in RHEL as a part 
> of Red Hat Security Advisories.
> See 
> https://www.open-scap.org/resources/documentation/perform-vulnerability-scan-of-rhel-6-machine/
> (It's for RHEL6, but in RHEL7 it's very similar)
>
>> - I did not see anyindication of using the Asset Identification (AI)
>> specification.
> OpenSCAP doesn't support this.
>
>> - I did not see anyindication of using the Asset Reporting Format (ARF)
>> specification.
> We fully support the ARF format, both in SCAP Workbench and oscap tool.
> In SCAP Workbench, it's possible to save results as ARF using Save results 
> button.
> Actually we recommend ARF as a be

[Open-scap] oscap-docker: OVAL vs XCCDF eval

[Shawn Wells]

Attempting to use oscap-docker on RHEL7 host, scanning RHEL7 containers.
I can use the OVAL scanner but not XCCDF eval. Is this a known issue?

e.g.

> # oscap-docker container rhel7.0 oval eval \
> --results oval-results.xml \
> --report report.html\
> /usr/share/xml/scap/ssg/content/ssg-rhel7-oval.xml
> ..
> Definition oval:ssg-xwindows_runlevel_setting:def:1: true
> Definition oval:ssg-wireless_disable_interfaces:def:1: true
> Definition oval:ssg-var_umask_for_daemons_as_number:def:1: true
> Definition oval:ssg-var_removable_partition_is_cd_dvd_drive:def:1: unknown
> Definition oval:ssg-var_accounts_user_umask_as_number:def:1: true
> Definition oval:ssg-userowner_shadow_file:def:1: true
> ..


But if using an actual profile:
> # oscap-docker container rhel7.0 xccdf eval \
> --profile
> xccdf_org.ssgproject.content_profile_stig-rhel7-server-upstream \
> --results xccdf-results.xml \
> --report report.html\
> /usr/share/xml/scap/ssg/content/ssg-rhel7-oval.xml
>
> OpenSCAP Error: Session input file was determined but it isn't an
> XCCDF file, a source datastream or an XCCDF tailoring file.
> [xccdf_session.c:135]
>
> Command: oscap xccdf eval --profile
> xccdf_org.ssgproject.content_profile_stig-rhel7-server-upstream
> --results oval-results.xml --report report.html
> /usr/share/xml/scap/ssg/content/ssg-rhel7-oval.xml failed!
>
> Error was:
>
> Command '['oscap', 'xccdf', 'eval', '--profile',
> 'xccdf_org.ssgproject.content_profile_stig-rhel7-server-upstream',
> '--results', 'oval-results.xml', '--report', 'report.html',
> '/usr/share/xml/scap/ssg/content/ssg-rhel7-oval.xml']' returned
> non-zero exit status 1

Also tried with XCCDF file, vs datastream:

> # oscap-docker container rhel7.0 xccdf eval \
> > --profile stig-rhel7-server-upstream \
> > --results xccdf-results.xml \
> > --report report.html \
> > /usr/share/xml/scap/ssg/content/ssg-rhel7-xccdf.xml
> WARNING: Skipping
> http://www.redhat.com/security/data/oval/com.redhat.rhsa-RHEL7.xml.bz2
> file which is referenced from XCCDF content
>
> Command: oscap xccdf eval --profile stig-rhel7-server-upstream
> --results xccdf-results.xml --report report.html
> /usr/share/xml/scap/ssg/content/ssg-rhel7-xccdf.xml failed!
>
> Error was:
>
> Command '['oscap', 'xccdf', 'eval', '--profile',
> 'stig-rhel7-server-upstream', '--results', 'xccdf-results.xml',
> '--report', 'report.html',
> '/usr/share/xml/scap/ssg/content/ssg-rhel7-xccdf.xml']' returned
> non-zero exit status 2


___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] oscap-docker: OVAL vs XCCDF eval

[Shawn Wells]

On 11/21/16 8:24 AM, Jan Cerny wrote:
> Hi Shawn,
>
> In first case you have a mistake, you are using OVAL content instead of XCCDF 
> in oscap xccdf evel.
>
> In second case there is a known bug.
> https://bugzilla.redhat.com/show_bug.cgi?id=1387248
> https://github.com/OpenSCAP/openscap/issues/475
> When oscap returns exit code 2 the system isn't compliant with the given 
> profile.
> However oscap-docker didn't handle the exit code correctly and reports an 
> error.
> The bug is fixed in OpenSCAP 1.2.12.

Thanks for the links! Following the RHEL BZ now.


___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] SCAP Security Guide 0.1.31

[Shawn Wells]

On 11/29/16 10:49 AM, Watson Yuuma Sato wrote:
> Hi folks,
>
> We have the pleasure to announce that SCAP Security Guide release
> 0.1.31
> has been created.
>
> Highlights of this release:
> * New Wind River Linux profiles,
> * Various STIG profile enhancements,
> * Ubuntu Xenial product has been added,
> * Support for Ansible remediations,
> * Refactored build process, with more shared content
> * The build system for RPM is simpler now,
> * SCAP benchmark for Red Hat Enterprise Linux 6 and Red Hat
>   Enterprise Linux 7 passes official NIST SCAP Content Validation Tool
> 1.2.1.15
>   requirements.
>
> For a more detailed overview of changes (bug fixes, enhancements)
> implemented
> in this release please have a look at more detailed changelog:
> * https://github.com/OpenSCAP/scap-security-guide/releases/tag/v0.1.31
>
> Full changelog at:
> *
> https://github.com/OpenSCAP/scap-security-guide/issues?q=milestone%3A0.1.31
>
> Zip archives with pre-built benchmarks in DataStream form:
> *
> https://github.com/OpenSCAP/scap-security-guide/releases/download/v0.1.31/scap-security-guide-0.1.31.zip
> (Zip archive using OVAL-5.11.1 language version)
> *
> https://github.com/OpenSCAP/scap-security-guide/releases/download/v0.1.31/scap-security-guide-0.1.31-oval-5.10.zip
> (Zip archive using OVAL-5.10 language version)
>
> As this is one of the biggest SSG releases ever made, the team would
> like to
> give a great thank you to all contributors.
>
> Happy hardening!
>
> With regards,
> Watson Sato (on behalf of the SCAP Security Guide upstream team) 

Where can I download RHEL RPMs (not trolling, promise!)?

COPR repos only have Fedora content:
https://copr.fedorainfracloud.org/coprs/openscapmaint/openscap-latest/package/scap-security-guide/

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] SCAP Security Guide 0.1.31

[Shawn Wells]

On 11/29/16 1:36 PM, Martin Preisler wrote:
> - Original Message -
>> From: "Shawn Wells" 
>> To: "Watson Yuuma Sato" , 
>> scap-security-gu...@lists.fedorahosted.org
>> Cc: open-scap-list@redhat.com
>> Sent: Tuesday, November 29, 2016 1:14:34 PM
>> Subject: Re: [Open-scap] SCAP Security Guide 0.1.31
>>
>> [snip]
>>
>> Where can I download RHEL RPMs (not trolling, promise!)?
>>
>> COPR repos only have Fedora content:
>> https://copr.fedorainfracloud.org/coprs/openscapmaint/openscap-latest/package/scap-security-guide/
> The COPR repos actually only have RHEL6 and 7 RPMs, don't mind the dist tag,
> it comes from the Fedora SRPM. Fedora gets scap-security-guide updates fairly
> quickly and doesn't need COPR.
>
> RHEL6 RPMS:
> https://copr-be.cloud.fedoraproject.org/results/openscapmaint/openscap-latest/epel-6-x86_64/00482175-scap-security-guide/
>
> RHEL7 RPMs:
> https://copr-be.cloud.fedoraproject.org/results/openscapmaint/openscap-latest/epel-7-x86_64/00482175-scap-security-guide/

Off-list.

Looks like we're only publishing CentOS RPMs. Can we publish RHEL RPMs too?

Might just be a naming thing. I see they're called
*.el7.centos.noarch.rpm. Perhaps create independent CentOS and el7 RPMS?
It's a branding concern.

I wouldn't spend significant time on it, and not sure how (if) I can
help with this either.
___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] SCAP Workbench 1.1.4

[Shawn Wells]

On 1/13/17 12:00 PM, Watson Yuuma Sato wrote:
>
> Hi,
>
> A new release of SCAP Workbench is out!
>
> This release brings a lot of bug fixes and improvements, including
> a lot of UX improvements and fixes for inappropriate error messages
> (fetch remote resources and query capabilities).
>
> Keep in mind that Windows and MacOSX builds use unreleased OpenSCAP from 
> master branch (OpenSCAP/openscap 557e16a) and scap-security-guide 
> version 0.1.31 (OpenSCAP/scap-security-guide feb6160).
>
> Changelog:
> https://github.com/OpenSCAP/scap-workbench/issues?q=milestone%3A1.1.4
>
> Release page:
> https://github.com/OpenSCAP/scap-workbench/releases/tag/1.1.4
> 

Thanks for your work on this!

Couple immediate things:
- Noticed all the non-RHEL content disappeared
- Only the RHEL7 CCP, STIG, Common, and "test" profiles are included.
What happened to the others, e.g. FBI CJIS? RHEL6 seems to have all the
profiles.
- Rule titles no longer appear correctly in RHEL7 content (seems fine in
RHEL6)



___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] SCAP Workbench 1.1.4

[Shawn Wells]

On 1/17/17 11:54 AM, Watson Yuuma Sato wrote:
>
> I noticed your screenshot doesn't show the count of selected rules for
> each profile.
>
> And the concatenated profile title is something that was fixed recently.
> If you edited the customization file, at least once after creating it,
> the wrong title is now in the customization file itself,
> so you will need to edit the file with a text editor to fix it.
>
> Could you please confirm the version of the workbench used for this
> screenshot?

Used your latest OSX build. Versioning output:

SCAP Workbench 1.1.0, compiled with Qt 4.8.6, using OpenSCAP 1.3.0


___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] SCAP Workbench 1.1.4

[Shawn Wells]

On 1/23/17 11:29 AM, Shawn Wells wrote:
>
>
> On 1/17/17 11:54 AM, Watson Yuuma Sato wrote:
>>
>> I noticed your screenshot doesn't show the count of selected rules
>> for each profile.
>>
>> And the concatenated profile title is something that was fixed recently.
>> If you edited the customization file, at least once after creating
>> it, the wrong title is now in the customization file itself,
>> so you will need to edit the file with a text editor to fix it.
>>
>> Could you please confirm the version of the workbench used for this
>> screenshot?
>
> Used your latest OSX build. Versioning output:
>
> SCAP Workbench 1.1.0, compiled with Qt 4.8.6, using OpenSCAP 1.3.0
>

 which I just noticed is weird.

Went to the OpenSCAP website and downloaded the latest:
https://github.com/OpenSCAP/scap-workbench/releases/download/1.1.4/scap-workbench-1.1.4.dmg

Looks like last time I did "keep old version" or something =/
:: hangs head in shame ::
___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] inconsistent reporting on auditd

[Shawn Wells]

On 1/25/17 9:55 AM, Jan Cerny wrote:
> Hi,
>
> It might be a bug, but also there can be another reason why this rule failed.
>
> First thing that I would try is to add "--oval-results" to your command
> and run the scan again. This option adds more details into the HTML report,
> which hopefully could help you with identifying the problem.
>
> Best Regards
>
> Jan Černý
> Security Technologies | Red Hat, Inc.
>
> - Original Message -
>> From: "Luke Hinds" 
>> To: open-scap-list@redhat.com
>> Sent: Tuesday, January 24, 2017 11:40:19 PM
>> Subject: [Open-scap] inconsistent reporting on auditd
>>
>> Hi,
>>
>> When performing a xccdf scan of Centos 7 I am finding the report of auditd
>> rule entries inconsistent with how the file is configured.
>>
>> The following is reported as a fail, yet its an exact match for the scap
>> report entry:
>>
>> https://i.imgur.com/m1q7CLf.png
>>
>> The following is a pass:
>>
>> https://i.imgur.com/LqDiRPO.png
>>
>> My command:
>>
>> # oscap xccdf eval --profile common --report ~/report-xccdf.html --results
>> ~/results.xml --cpe
>> /usr/share/xml/scap/ssg/content/ssg-rhel7-cpe-dictionary.xml
>> /usr/share/xml/scap/ssg/content/ssg-centos7-xccdf.xml
>>
>> Should I raise this as a bug?

What version of SSG?

I don't recall the SSG version that it was patched in, but the original
RHEL7 OVAL content only accepted audit rules with "-k foo", not "-F
key=foo", as shown in your audit.rules.

The patch was made 16-DEC, so may not be shipping in RHEL yet...

https://github.com/OpenSCAP/scap-security-guide/commit/66f76d6158a1cd44a91f7f27286022755065e4b6

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] vulnerability scan to detect security flaws, new/ unpatched CVEs

[Shawn Wells]

On 1/27/17 2:53 AM, Sona Sarmadi wrote:
>
> Thanks for your quick reply Shawn. 
>
> I am trying to figure out how OVAL definitions work.
>
> For example if I want to detect unpatched CVEs in my RedHat Linux 6, I
> should use OVAL definition below: 
>
> https://www.redhat.com/security/data/oval/Red_Hat_Enterprise_Linux_6.xml
>
> Does this file (*Red_Hat_Enterprise_Linux_6.xml)*contains all CVEs
> which affects Redhat Linux 6 or only those which have been fixed?
>
> If I haven’t applied all fixes provided by RedHat, will the command
> below detect and report those CVEs?
>
> oscap oval eval --results rhsa-results-oval.xml --report
> oval-report-RedHat6.html *Red_Hat_Enterprise_Linux_6.xml* 
>
> I am asking this because I haven’t updated my RedHat for a while, I
> think I should at least get some kernel CVEs reported, but the result
> is all green.
>

If there was a RHSA released, there should be a corresponding SCAP
check. Ref:
https://access.redhat.com/articles/221883

The command is correct. It seems a bit odd that you have no findings, if
your system hasn't been patched for awhile (e.g. stock install of RHEL
6.8).


WRT how the OVAL works, an example from the firefox patches last week:

- First, OVAL will see what RHEL version you're on, and even derivative
(RHEL6 vs RHEL6 Workstation vs RHEL6 Desktop):
> 
> 
> 
> 
> 
> 

- Second, it will check what version of firefox is installed (e.g. if
it's the old nonpatched version, fail the check). It will also make sure
the RPM is signed by RedHat, so we're not passing RPMs released by 3rd
parties.
>  xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#linux"; check="at
> least one" comment="firefox is earlier than
> 0:45.7.0-1.el6_8"id="oval:com.redhat.rhsa:tst:20170190008" version="602">
> 
> 
> 
>
>  xmlns="http://oval.mitre.org/XMLSchema/oval-definitions-5#linux"; check="at
> least one" comment="firefox is signed with Red Hat redhatrelease2
> key"id="oval:com.redhat.rhsa:tst:20170190009" version="602">
> 
> 
> 


___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] tailoring file not working

[Shawn Wells]

On 3/29/17 11:52 AM, Mohanraj, Bharath wrote:
>
> Can you try replacing,
>
>  
>
> --profile xccdf_org.ssgproject.content_profile_pci-dss
>
>  
>
> With
>
>  
>
> --profile xccdf_org.ssgproject.content_profile_pci-dss_with_ot
>

+1

Remember to point OpenSCAP at the tailor file, not the original datastream.





>  
>
> *From:*open-scap-list-boun...@redhat.com
> [mailto:open-scap-list-boun...@redhat.com] *On Behalf Of *Josh Moore
> *Sent:* Wednesday, March 29, 2017 6:49 PM
> *To:* open-scap-list@redhat.com
> *Subject:* [Open-scap] tailoring file not working
>
>  
>
> I am working on creating a tailored PCI profile that accounts for
> items covered by our provider.  So I want to tailer the profile to
> remove what I consider to be false positives. I have created the
> tailoring file on my Mac desktop and copied it to my centos 7 test
> machine.  However, when I run the oscap command on the centOS server
> the tailoring file is ignored.  Any idea of what I am doing wrong?
>
>  
>
> oscap xccdf eval --tailoring-file tailoring.xml --report report.html
>  --profile xccdf_org.ssgproject.content_profile_pci-dss
> /usr/share/xml/scap/ssg/content/ssg-centos7-ds.xml
>
>  
>
> Tailoring File content:
>
> 
>
> http://checklists.nist.gov/xccdf/1.2
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__checklists.nist.gov_xccdf_1.2&d=CwMFaQ&c=UrUhmHsiTVT5qkaA4d_oSzcamb9hmamiCDMzBAEwC7E&r=ylluGgiy6YcBNWxAWKqJ9Q&m=VwBwnTVJ6mbd1LCcB1mmKlR4TDm7H5rmbFpbSTdl8o8&s=9rqddwDp15TZtPAQFqFc1Cfp3tmrR5nqYnTRme9xenk&e=>"
> id="xccdf_scap-workbench_tailoring_default">
>
>href="/usr/share/xml/scap/ssg/content/ssg-centos7-ds.xml"/>
>
>   1
>
>id="xccdf_org.ssgproject.content_profile_pci-dss_with_ot"
> extends="xccdf_org.ssgproject.content_profile_pci-dss">
>
> http://www.w3.org/1999/xhtml
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_1999_xhtml&d=CwMFaQ&c=UrUhmHsiTVT5qkaA4d_oSzcamb9hmamiCDMzBAEwC7E&r=ylluGgiy6YcBNWxAWKqJ9Q&m=VwBwnTVJ6mbd1LCcB1mmKlR4TDm7H5rmbFpbSTdl8o8&s=DKeXAv2csKLxOp4wSQI6DAH1VtLlOc0plYIVpTPuVVs&e=>"
> xml:lang="en-US" override="true">PCI-DSS v3 Control Baseline for Red
> Hat Enterprise Linux 7 [CUSTOMIZED]
>
> http://www.w3.org/1999/xhtml
> <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.w3.org_1999_xhtml&d=CwMFaQ&c=UrUhmHsiTVT5qkaA4d_oSzcamb9hmamiCDMzBAEwC7E&r=ylluGgiy6YcBNWxAWKqJ9Q&m=VwBwnTVJ6mbd1LCcB1mmKlR4TDm7H5rmbFpbSTdl8o8&s=DKeXAv2csKLxOp4wSQI6DAH1VtLlOc0plYIVpTPuVVs&e=>"
> xml:lang="en-US" override="true">This is a *draft* profile for PCI-DSS
> v3
>
>  selected="false"/>
>
>  idref="xccdf_org.ssgproject.content_group_smart_card_login"
> selected="false"/>
>
>   
>
> 
>
>
> Thanks,
>
>  
>
> Josh Moore
>
> Chief Architect
>
> TarokoSoftware
>
>
>
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list

-- 
Shawn Wells
Chief Security Strategist
U.S. Public Sector
sh...@redhat.com | 443.534.0130 

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] SCAP Security Guide 0.1.32

[Shawn Wells]

Thank you! Looking forward to downloading the data stream and testing it. I can 
start the process to get the new release posted to Nist .

Shawn Wells

> On Mar 30, 2017, at 8:22 AM, Watson Yuuma Sato  wrote:
> 
> Hello folks,
> 
> We have the pleasure to announce that SCAP Security Guide version 0.1.32 has
> has been release.
> 
> Highlights of this release:
> 
> * New CMake build system
> * Improved NIST 800-171 profile
> * Initial RHVH profile
> * New CPE to identify systems like machines (bare-metal and VM) and 
> containers (image and container)
> * Template clean up in lots of remediations
> 
> For a more detailed overview of changes (bug fixes, enhancements) implemented
> in this release please have a look at more detailed changelog:
> * https://github.com/OpenSCAP/scap-security-guide/releases/tag/v0.1.32
> 
> Full changelog at:
> * https://github.com/OpenSCAP/scap-security-guide/issues?q=milestone%3A0.1.32
> 
> Zip archives with pre-built benchmarks in DataStream form:
> * 
> https://github.com/OpenSCAP/scap-security-guide/releases/download/v0.1.32/scap-security-guide-0.1.32.zip
>  
> (Zip archive using OVAL-5.11.1 language version)
> * 
> https://github.com/OpenSCAP/scap-security-guide/releases/download/v0.1.32/scap-security-guide-0.1.32-oval-5.10.zip
>  
> (Zip archive using OVAL-5.10 language version only)
> 
> Thank you to everyone who contributed with issues, patches and discussion.
> 
> Happy hardening!
> 
> With regards,
> Watson Sato
> 
> 
> -- 
> Watson Sato
> Security Technologies | Red Hat, Inc
> ___
> scap-security-guide mailing list -- scap-security-gu...@lists.fedorahosted.org
> To unsubscribe send an email to 
> scap-security-guide-le...@lists.fedorahosted.org

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] SCAP Security Guide 0.1.32

[Shawn Wells]

Downloaded and tested the content using STIG profile. Found a few issues
with this release:

- 1x OVAL error
- 62x remediation failures/errors
- 50x rules missing DoD mappings

Made a GitHub project to track these issues:
https://github.com/OpenSCAP/scap-security-guide/projects/7

We'll want to get these resolved before uploading to NIST and before
this release makes it into downstream releases (e.g. RHEL 7.4 rebase).
What's the best way to start working these bugs? Is there a deadline for
when these bugs must be resolved for inclusion downstream?




On 3/30/17 9:07 AM, Shawn Wells wrote:
> Thank you! Looking forward to downloading the data stream and testing it. I 
> can start the process to get the new release posted to Nist .
>
> Shawn Wells
>
>> On Mar 30, 2017, at 8:22 AM, Watson Yuuma Sato  wrote:
>>
>> Hello folks,
>>
>> We have the pleasure to announce that SCAP Security Guide version 0.1.32 has
>> has been release.
>>
>> Highlights of this release:
>>
>> * New CMake build system
>> * Improved NIST 800-171 profile
>> * Initial RHVH profile
>> * New CPE to identify systems like machines (bare-metal and VM) and 
>> containers (image and container)
>> * Template clean up in lots of remediations
>>
>> For a more detailed overview of changes (bug fixes, enhancements) implemented
>> in this release please have a look at more detailed changelog:
>> * https://github.com/OpenSCAP/scap-security-guide/releases/tag/v0.1.32
>>
>> Full changelog at:
>> * https://github.com/OpenSCAP/scap-security-guide/issues?q=milestone%3A0.1.32
>>
>> Zip archives with pre-built benchmarks in DataStream form:
>> * 
>> https://github.com/OpenSCAP/scap-security-guide/releases/download/v0.1.32/scap-security-guide-0.1.32.zip
>>  
>> (Zip archive using OVAL-5.11.1 language version)
>> * 
>> https://github.com/OpenSCAP/scap-security-guide/releases/download/v0.1.32/scap-security-guide-0.1.32-oval-5.10.zip
>>  
>> (Zip archive using OVAL-5.10 language version only)
>>
>> Thank you to everyone who contributed with issues, patches and discussion.
>>
>> Happy hardening!
>>
>> With regards,
>> Watson Sato
>>
>>
>> -- 
>> Watson Sato
>> Security Technologies | Red Hat, Inc
>> ___
>> scap-security-guide mailing list -- 
>> scap-security-gu...@lists.fedorahosted.org
>> To unsubscribe send an email to 
>> scap-security-guide-le...@lists.fedorahosted.org

-- 
Shawn Wells
Chief Security Strategist
U.S. Public Sector
sh...@redhat.com | 443.534.0130 

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] results not being checked in disa stig

[Shawn Wells]

On 4/5/17 1:43 PM, Greg Hennessy wrote:
> I am exploring the use of open-scap to verify my machines meet
> the DISA stigs. If I run oscap against the 
> /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml file  things seem to work
> as expected. If I run oscap against the file from iase.disa.mil
> , all 
> of the results show "notchecked". Does anyone have a sugguestion as to
> how to force the checks to happen?
>
> My typed command line is:
>
> # oscap xccdf eval --profile MAC-2_Public  --report
> /tmp/disa_stig.html
> U_Red_Hat_Enterprise_Linux_7_STIG_V1R1_Manual-xccdf.xml

DISA does not publish automation content -- so it's impossible to use
their content.
___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] results not being checked in disa stig

[Shawn Wells]

On 4/5/17 2:54 PM, Greg Hennessy wrote:
> Bummer
>
> On Wed, Apr 5, 2017 at 1:53 PM, Shawn Wells  <mailto:sh...@redhat.com>> wrote:
>
>
>
> On 4/5/17 1:43 PM, Greg Hennessy wrote:
>> I am exploring the use of open-scap to verify my machines meet
>> the DISA stigs. If I run oscap against the 
>> /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml file  things
>> seem to work
>> as expected. If I run oscap against the file from iase.disa.mil
>> <http://iase.disa.mil>, all 
>> of the results show "notchecked". Does anyone have a sugguestion
>> as to
>> how to force the checks to happen?
>>
>> My typed command line is:
>>
>> # oscap xccdf eval --profile MAC-2_Public  --report
>> /tmp/disa_stig.html
>> U_Red_Hat_Enterprise_Linux_7_STIG_V1R1_Manual-xccdf.xml
>
> DISA does not publish automation content -- so it's impossible to
> use their content.
>

With that said, we're tracking to having a SSG profile align more
directly against the content DISA published. Here's a dashboard with the
missing pieces:

https://github.com/OpenSCAP/scap-security-guide/projects/7

Patches most welcome, especially to build out missing OVAL!
___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] fetch remote resources on RHEL7 fails

[Shawn Wells]

On 4/6/17 11:10 AM, Przemek Klosowski wrote:
>
> On a fresh-out-of-the-box+updated RHEL7 (with
> openscap-scanner-1.2.10-3.el7_3.x86_64)
>
> oscap xccdf eval --profile
> xccdf_org.ssgproject.content_profile_common --report
> /tmp/report.html /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml
> This content points out to the remote resources. Use
> `--fetch-remote-resources' option to download them.
> WARNING: Skipping
> http://www.redhat.com/security/data/oval/Red_Hat_Enterprise_Linux_7.xml
> file which is referenced from XCCDF content
>
> The scan goes off/generates reports, but in order to heed the the
> WARNING, I try to get the latest remote OVAL file
>
> oscap xccdf eval --fetch-remote-resources --profile
> xccdf_org.ssgproject.content_profile_common --report
> /tmp/report-remote.html
> /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml
> Downloading:
> http://www.redhat.com/security/data/oval/Red_Hat_Enterprise_Linux_7.xml
> ... ok
> OpenSCAP Error: Unable to parse XML from user memory buffer
> [oscap_source.c:254]
> Failed to create OVAL definition model from:
> 'http://www.redhat.com/security/data/oval/Red_Hat_Enterprise_Linux_7.xml'.
> [xccdf_session.c:787]
>
> and the scan terminates. Is that a problem with the remote file
> (Red_Hat_Enterprise_Linux_7.xml) or an 'oscap' bug?
>

I get the exact same error - looks like a bug

$ cat /etc/redhat-release ; uname -a ; rpm -qv openscap-scanner ; free -m
Red Hat Enterprise Linux Server release 7.3 (Maipo)
Linux devbox 3.10.0-514.10.2.el7.x86_64 #1 SMP Mon Feb 20 02:37:52 EST
2017 x86_64 x86_64 x86_64 GNU/Linux
openscap-scanner-1.2.10-3.el7_3.x86_64

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Pleas explain this

[Shawn Wells]

On 4/12/17 1:15 PM, Greg Silverman (CS) wrote:
>
> Many of the generated fixes uses this idiom
>
> IFS=$’\n’ …
>
> unset $IFS 
>
> IFS is a variable, but, $IFS is a character string, so, unsetting it
> does not restore IFS to its default value. What am I missing?
>

Those lines are from the audit remediation templates, e.g.:
https://github.com/OpenSCAP/scap-security-guide/blob/master/shared/xccdf/remediation_functions.xml#L97#L99

> IFS=$'\n' matches=($(sed -s -n -e "/${pattern}/!d" -e "/${arch}/!d" -e
> "/${group}/!d;F" /etc/audit/rules.d/*.rules))
> # Reset IFS back to default
> unset $IFS

Because the variable is used multiple times (e.g. each audit
remediation), it is a good practice to completely remove the
variable/data from the system between function calls.

For example:

$ stringVar="This is my string"
$ echo $stringVar
This is my string

$ unset stringVar

$ echo $stringVar
-bash: stringVar: unbound variable

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Stigviewer

[Shawn Wells]

On 4/12/17 7:08 PM, Matthew wrote:
> Curious, what's the best way to use openscap, and be able to get
> results for stigviewer?

IIRC, stigviewer can consume OVAL results. Something like:

oscap xccdf eval --profile stig --report human-readable.html --results
stigviewer-readable.xml ssg-rhel7-ds.xml

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Tuning/Customisation of SSG OVAL

[Shawn Wells]

On 4/19/17 4:17 AM, Jan Cerny wrote:
> Hi,
>
> Some of the rules in SCAP Security guide can be parametrized using "XCCDF 
> Value".
> Those values can be set in SCAP Workbench. However that's not the case of this
> particular rule, the value is hard-coded in regular expressions across the
> file. We use parametrized values for example in rules that specify minimal
> length of a password etc.
>
> The fastest way would be to replace the auid in OVAL file manually.
> Better way would be to rework the rules so that they're parametrized using
> XCCDF Values.

Parametizing auid's in the upstream code seems like the right thing to
do. Especially if you'd have to do it anyway for a local fork (which
would be hell to maintain).

We can expose the parameter internally to the XCCDF and have the default
value be the operating system default of 1000.

Sébastien - If you're willing to work on this, happy to help with
guidance on how to get started in the SSG codebase. Let us know.

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] the sed_command idiom

[Shawn Wells]

On 4/19/17 2:20 PM, Greg Silverman (CS) wrote:
>
> The generated scripts use this idiom
>
>  
>
> sed_command=”sed –i …”
>
>  
>
> where the ellipsis is replaced a follow symlink option if the file
> being edited is a symbolic link. There are some errors when running
> the generated remediation script, such as
>
>  
>
> “sed  -i “ command not found.
>
>  
>
> As an alternative, I change the script to say
>
>  
>
> sed_command_params=”sed –I …”
>
>  
>
> sed ${command_params}
>
>  
>
> This works. It seems more reasonable to me because we do not want a
> different command, we want different parameters to the sed command.
>

Seems to work. Would you be willing to make patches for this?
___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] [Newbie] Way to search the archives?

[Shawn Wells]

On 6/13/17 9:42 AM, leam hall wrote:
> Hey Mike, sorry if I'm dense. I looked at the URL and it seems to be
> the initial welcome page. Messages go back as far as 2009, how do I
> search what has already been answered?

google for "centos site:https://www.redhat.com/archives/open-scap-list/";

sans quotes.

to save you time though: CentOS content is now built natively upstream.
Should see something like "ssg-centos7-ds.xml"

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Logos and other materials for SCAP projects

[Shawn Wells]

On 7/17/17 2:59 PM, Martin Preisler wrote:
> Hi,
> I have gathered all the logos and other graphics and put them into a
> GitHub repository to make sure they don't get lost. Most of these (if
> not all) have been created by Lenka Horakova.
>
> https://github.com/OpenSCAP/promo
>
> If you have any other materials we'd appreciate pull requests. I'd
> also appreciate tips and recommendations how to make nice and
> reasonably priced sticker sheets . Maybe we could even try to get
> t-shirts done with these.

Have used StickerMule before:
https://www.stickermule.com/products/die-cut-stickers

Corp Red Hat also has some marketing relationships with similar
companies. They all seem comparably priced, though.

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] what profile to use in RHEL7

[Shawn Wells]

On 7/18/17 1:09 PM, Martin Preisler wrote:
> On Mon, Jul 17, 2017 at 6:44 PM, Smith, Cathy  wrote:
>> Folks
>>
>> I’m trying to build a customized profile for RHEL7.   I’m not sure about the
>> list of profile names offered through the oscap command and the list shown
>> in the SCAP Workbench.  For example, in RHEL6 the oscap command listed a
>> profile usgcb-rhel6-server, and that corresponded to the United States
>> Government Configuration Baseline (USGCB) in SCAP Workbench.  The RHEL 7
>> SCAP Workbench has a profile for USGCB, but there is no profile listed by
>> that name by the oscap info command.  Does anyone know of a list that shows
>> the relationship between the profile listed by the oscap command and the
>> profiles in the SCAP Workbench?
>>
>> Thank you for your assistance.
> The IDs and titles don't always match. This is exactly the case with
> the USGCB / OSPP profile for RHEL7. Its title is "United States
> Government Configuration Baseline (USGCB / STIG)" but its ID is
> xccdf_org.ssgproject.content_profile_ospp-rhel7.
>
> I usually go to https://static.open-scap.org to figure this out. Click
> on the product, then browse profiles. The page will always tell you
> both title and ID of each.
>
> Hope this helps!


As a future OpenSCAP RFE, could the 'oscap info' output be modified to
show the profile title? e.g.

Title: United States Baseline
XCCDF ID: org.open-scap-ospp-rhel7

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] what profile to use in RHEL7

[Shawn Wells]

On 7/18/17 2:28 PM, Martin Preisler wrote:
> On Tue, Jul 18, 2017 at 1:34 PM, Shawn Wells  wrote:
>>
>> On 7/18/17 1:09 PM, Martin Preisler wrote:
>>
>> On Mon, Jul 17, 2017 at 6:44 PM, Smith, Cathy  wrote:
>>
>> Folks
>>
>> I’m trying to build a customized profile for RHEL7.   I’m not sure about the
>> list of profile names offered through the oscap command and the list shown
>> in the SCAP Workbench.  For example, in RHEL6 the oscap command listed a
>> profile usgcb-rhel6-server, and that corresponded to the United States
>> Government Configuration Baseline (USGCB) in SCAP Workbench.  The RHEL 7
>> SCAP Workbench has a profile for USGCB, but there is no profile listed by
>> that name by the oscap info command.  Does anyone know of a list that shows
>> the relationship between the profile listed by the oscap command and the
>> profiles in the SCAP Workbench?
>>
>> Thank you for your assistance.
>>
>> The IDs and titles don't always match. This is exactly the case with
>> the USGCB / OSPP profile for RHEL7. Its title is "United States
>> Government Configuration Baseline (USGCB / STIG)" but its ID is
>> xccdf_org.ssgproject.content_profile_ospp-rhel7.
>>
>> I usually go to https://static.open-scap.org to figure this out. Click
>> on the product, then browse profiles. The page will always tell you
>> both title and ID of each.
>>
>> Hope this helps!
>>
>>
>>
>> As a future OpenSCAP RFE, could the 'oscap info' output be modified to show
>> the profile title? e.g.
>>
>> Title: United States Baseline
>> XCCDF ID: org.open-scap-ospp-rhel7
> I think Jan Cerny can see the future:
> https://github.com/OpenSCAP/openscap/pull/781

Hah! Nice, Jan :)

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] OpenSCAP support to Solaris and FreeBSD

[Shawn Wells]

On 7/19/17 12:41 PM, Jordan Caraballo wrote:
>
> Hi guys,
>
> Are there any future or ongoing plans to support Solaris and FreeBSD
> operating systems?
>
> Both to run OpenSCAP and to have compliance files from the
> SCAP-Security-Guide.
>
There were 1-2 people from Oracle interested in porting OpenSCAP to
Solaris. Not sure what happened to that interest. Nobody has mentioned
FreeBSD before (that I know about).

On the SSG side, there's no specific effort. Patches welcome if you'd be
interested in this.

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] OpenSCAP support to Solaris and FreeBSD

[Shawn Wells]

On 7/19/17 1:39 PM, Jordan Caraballo wrote:
>
> Hi Shawn,
>
> Thanks for your reply! I will start digging into them to see if I can
> start developing some patches.
>
> I apologize if these are naive questions:
>
> - CIS has some pdf benchmark files for FreeBSD. Is this a good start
> for recreating the rules to assess the system?
>

Most likely. CIS generally has great starting points.

Minor note: There have been issues in the past with creating a "CIS"
profile. We've needed to add language such as "this profile is
_/inspired/_ from CIS." Claiming anything meets CIS benchmarks, without
paying licensing to CIS, is a violation of their EULA and copyright.
Reference the language in the RHEL C2S profile for example text.


> - On the other hand, there are vulnerabilities files available for
> FreeBSD https://svn.freebsd.org/ports/head/security/vuxml/vuln.xml and
> Solaris http://linux.oracle.com/security/oval/com.oracle.elsa-all.xml.bz2.
> What we would need is openscap and openscap-utils working on both OS's?
>

Defer to the core OpenSCAP tool team. I've no idea.


___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Ubuntu Profile

[Shawn Wells]

On 8/29/17 8:17 PM, Christopher wrote:
> Hi,
>
> How do you use one of Ubuntu profiles in the scap-security-guide directory to 
> scan a remote system? 
>
> When I launch the SCAP Workbench the only default guides listed in the SCAP 
> Security Guide GUI are:  CentOS6, CentOS7, Firefox and JRE.   

What version of SCAP Workbench, and on what platform?

When I load it up (default install), I see content for RHEL, Fedora,
CentOS, Scientific,  Ubuntu, Chrome, etc. About 23 options.

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] [open-scap] scan percentage with respect to rules specified by STIG

[Shawn Wells]

On 9/5/17 4:38 AM, Wesley Ceraso Prudencio wrote:
> I'm not an expert, but if I got it right, we currently cover approximately 
> 85% of STIG rules for RHEL7 and 23% for RHEL6.

Something seems off

In RHEL6, the STIG profile extends the common profile:
> $ head -1 stig-rhel6-server-upstream.xml
> 

So, adding in rules from 'common' and STIG profiles:
> $ grep -v ' 182
>
> $ grep -v ' 68

Then subtracting things that are turned off:
> $ grep false stig-rhel6-* | wc -l
> 4

= 246 rules.

Then compared to RHEL6 STIG from DISA:
> $ grep " 259

246 / 259 = 95%

Some gaps are expected (e.g. update 3rd party patches, install 3rd party
software), so we'll never have 100% until baseline owners drop such
rules. This is common across most third parties (e.g. CIS), not just DISA.

. now ensuring the content of the selected rules aligns between
DISA and SSG is another question :)


___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] [open-scap] scan percentage with respect to rules specified by STIG

[Shawn Wells]

On 9/6/17 9:58 AM, Wesley Ceraso Prudencio wrote:
> Thanks Shawn, I didn't notice the extension from common profile.

Of course.

It's incredibly hard to keep tabs on what 3rd parties are putting into
their baselines so while our rule counts may be close, there's
little assurance that mappings are kept updated and rule content aligns.
It's been awhile since anyone has combed through DISA's RHEL6
content. wonder if there's enough community interest to warrant it.

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] scap-workbench remote scan doesnt work

[Shawn Wells]

On 9/21/17 8:44 AM, DD Donny Lie wrote:
> Hello,
> I have a CentOS 7 with installed openscap-scanner
> and I use scap-workbench from my laptop with VM RHEL 7, trying to
> remote scan the CentOS 7,
>
> It succeed login via SSH but Diagnostics says:
> *error    
> *
> *Failed to locate oscap on remote machine. Please, check that
> openscap-scanner is installed on the remote machine.*
>
> Am I missing something?


Looks like you need to install openscap-scanner on your endpoint.
___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] How does rpminfo_test work?

[Shawn Wells]

On 11/9/17 1:09 PM, Chuck Atkins wrote:
> I'm using the compiled datastream SCAP content for Red Hat security
> advisories
> (https://www.redhat.com/security/data/metrics/ds/com.redhat.rhsa-RHEL7.ds.xml).
>  
> From what I can tell, most of the checks are testing if a package
> version indicates whether or not it's already patched.  Most of these
> are via the OVAL rpminfo_test.  What I don't understand is how it
> actually works; i.e.:
>
>    comment="java-1.7.0-openjdk is earlier than 1:1.7.0.55-2.4.7.2.el7_0"
> id="oval:com.redhat.rhsa:tst:20140675005" version="601">
>    
>    
>   
>
> Somehow this test passes even if I don't have the java-1.7.0-openjdk
> package installed.  Shouldn't it be false in that case since the "at
> least one" check wouldn't be satisfied?  I understand why you would
> want it to be true; so that your tests would pass if not applicable
> and pass/fail based on version if it was, but it seems to me you would
> need to implement that via a more complicated condition involving both
> a test for existence and a test for version info.  I just don't see
> how the single rpminfo_test achieves that and passes in this case.

Really good question and one that comes up often.

That test calls an object:
>    version="601">
>    java-1.7.0-openjdk
>   

And refers to a state:
>    version="601">
>    1:1.7.0.55-2.4.7.2.el7_0
>   

At surface value, you'd think the "at least one" check would read
something like:

# Am I vulnerable?
if [ oval:com.redhat.rhsa:obj:20140675005 ] || [
oval:com.redhat.rhsa:ste:20140675003 ]; then
    echo "VULNERABLE"
else
    echo "NOT VULNERABLE"
fi

 at which case, if java-1.7.0-openjdk is even *installed*, the
condition of "at least one" would be satisfied and the system marked
vulnerable.

In reality the rpminfo_test definitions /extend/ the standard test types
and require an object (oval:com.redhat.rhsa:obj:20140675005) and looks
for an optional state (oval:com.redhat.rhsa:ste:20140675003) to measure
against. If state is given, the test logic is more like this:

# Am I vulnerable?
if [ oval:com.redhat.rhsa:obj:20140675005 ] && [
oval:com.redhat.rhsa:ste:20140675003 ]; then
    echo "VULNERABLE"
else
    echo "NOT VULNERABLE"
fi

Hope this helps.

. and yes, this is an example of how OVAL can be crummy to author
and peer review.
___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Introduction: Beth Lynn Eicher, new contributor as a security specialist

[Shawn Wells]

On 12/1/17 9:34 PM, Beth Lynn Eicher wrote:
>
> Greetings,
>
> I am excited to be involved in the OpenSCAP community as a security
> specialist. My research as a hopeful grant recipient of the Department
> of Energy Small Business Innovation Research program drives me to
> contribute to OpenSCAP. My topic of research is how to secure a High
> Performance Computing ecosystem and I am convinced that OpenSCAP is
> the way to go. After attending the OpenSCAP tutorial at the USENIX
> Large Installation System Administrator conference under the diversity
> scholarship, I could not be more convinced of OpenSCAP’s capabilities
> of automating at scale the monumental task of securing a supercomputer.
>
> I have worked as a system administrator in research computing for over
> 17 years. At times it was my responsibility as a subject matter expert
> to bring one component of this ecosystem to compliance. The work was
> often tedious with manually configuration verification and penetration
> testing.  I have tried CIS-CAT but I found the scripts inflexible. The
> inability of CIS-CAT to port your own security plan goes against my
> personal preference of freedom.  I applaud Red Hat for sponsoring a
> superior solution. 
>
> In full disclosure, I have always been a fan of Red Hat and I am an
> active Fedora Project contributor. FAS:bethlynn
>
> Thank you very much for allowing me to introduce myself. I’m very much
> looking forward to working with OpenSCAP.
>

Welcome! A few years ago Lockheed Martin presented at Red Hat Summit
about their use of SCAP on the DoD Centralized Super Facility. It's a
cross-domain supercomputer for U.S. Intelligence processing. Their story
begins on page 40:
https://shawnwells.io/wp-content/uploads/2015-06-25-Summit-Security-Compliance-Made-Easier.pdf

LMCO also received government approval to open source their RHEL6 baseline:
https://github.com/OpenSCAP/scap-security-guide/blob/master/rhel6/profiles/CSCF-RHEL6-MLS.xml

Their work with the CNSSI 1253 overlays was incorporated into RHEL7 as well:
https://github.com/OpenSCAP/scap-security-guide/blob/master/rhel7/profiles/ospp-rhel7.xml#L11

Sometimes we still hear "security slows my processing," or the dreaded
"we turn SELinux off for performance." Helping the community understand
what you've seen for HPC systems, or broadly what impact security
settings have on performance-based systems, would be a very valuable
contribution.
___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] OpenSCAP for embedded/network devices

[Shawn Wells]

On 1/8/18 4:19 PM, Lee Wilson wrote:
>
>
> Hi Watson,
>
>
> Thanks for your detailed reply and apologies for my delay in
> responding.  Went off to look for something else that may do the job.
>
>
> The link that Eric has provided was initially what got me thinking
> about using OpenSCAP to do this task, it's real shame the approach of
> needing an agent was taken.
>
>
> Interestingly enough though, we've started looking into Ansible
> (another RedHat sponsored project) and that does have some support for
> appliance type devices (if not exactly perfect) as it principally
> agentless (as long as python exists somewhere).  My scope has also
> expanded from just Cisco to also include F5, Palo Alto and other
> network appliance vendors.
>
>
> In my original reply, I gave a rough list of tasks that perhaps could
> be run to achieve whats needed (and it looks very similar to a list of
> Plays).  Having reviewed Ansible I'm thinking could those "Plays" be
> put into an Ansible Playbook and have it go and gather all the
> required info for example running 'show version' or 'show run logging'
> against a network device, format this in the required results format
> that oscap expects and then invoke it to generate the report.
>
>
> Really keen to not reinvent the wheel here but I'm probably way out on
> a limb. If this isn't possible maybe us Network Engineers will just
> need to fork OpenSCAP and make it work without an agent.something
> tells me this won't be happening any time soon 😉
>
>
> Thanks again
>

OpenSCAP is a tool, SCAP is the content language.

Today OpenSCAP does not work on Cisco/networking devices, but there are
other SCAP tools that do. One of the better known ones is jOVAL:
https://jovalcm.com/

SCAP Security Guide could still house content for evaluating Cisco IOS
and JunOS... but you'd have to use something like jOVAL to scan your
endpoints.

Alternatively, there are new projects standing up that will ship Ansible
content that may be of interest to you.
___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] https://www.open-scap.org/ down?

[Shawn Wells]

Seems restored now (approx 11am US EST).


> On Jan 20, 2018, at 5:21 AM, Šimon Lukašík  wrote:
> 
> 
> Can you guys please take a look?
> 
> ~š.
> 
> ___
> Open-scap-list mailing list
> Open-scap-list@redhat.com
> https://www.redhat.com/mailman/listinfo/open-scap-list

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] oscap results stored in central database?

[Shawn Wells]

On 1/31/18 10:22 PM, Luke Salsich wrote:
> Hey all,
>
> I've been using OpenSCAP for a while on our servers and really
> appreciate what it does. 
>
> I've been looking around for a way to store scan results and then
> query them and I can't seem to locate any plugins or apps which do
> this other than SCAPTimony. 
>
> SCAPTimony sounds great, but I'm not sure it's currently maintained
> and I don't really want to dive into Foreman just to store Oscap results. 
>
> What does the community use for this kind of scan / report storing and
> querying? 
>
> We're currently using Ansible AWX to run scans and to manage
> remediation. Love to find a way to pull that XML into a central
> database...

This week was DevConf in Brno [0] and this very topic came up multiple
times! The quick answer being broad agreement that "yes this must happen."

There are partner projects like Foreman (upstream) and Satellite
(downstream) which integrate scanning into their embedded databases. In
general there is a desire to unify SCAP with OpenControl for central
reporting though.

Many are in transit from Brno back home over the next few days, or
recovering locally from staying out all night for the past week :) Some
responses might be slightly delayed because of this.

If you could have database integration with SCAP what all would you
want it to do? Could you help the community form a few user stories?


[0] https://devconf.cz/cz/2018
___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] oscap results stored in central database?

[Shawn Wells]

On 2/1/18 1:21 PM, Luke Salsich wrote:
> Thanks for the comments guys. It helps me understand where things are
> and where they might be going.
>
> For me, I would write a (initial) user story much along the lines of:
>
> "I would like to be able to parse oscap results into a MySQL database
> so that I can compare specific aspects of these results to others from
> the same server or from other servers."
>
> I word it like this because I (personally) am not looking for a larger
> application framework (user interface, authentication, etc) that has
> to come along with the central database. I also like the idea of not
> being tied to one database engine and/or using a standardized API, but
> an API sounds like a few stories down the road.
>
> Anyway, I'm grateful for the thoughts. I was initially just checking
> to make sure that before I start working on converting the XML to SQL
> (probably with xslt and Python) that someone else hasn't already done
> that. I hate it when I build something only to find out later that
> someone in the community has already built it (and probably way better).

Imagine something like https://osquery.io/, except with enriched
compliance data.


___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] openscap version support

[Shawn Wells]

On 2/5/18 2:10 PM, r hartikainen wrote:
> Hello everyone
>
> I am trying to find answer how Openscap should be used when there is need to 
> run different minor versions of operating system, in my case its about rhel 
> 7.2 and the very latest 7.x.
> I have piece of software that requires me to stay with rhel 7.2, naturally 
> extended update support is needed for this. Target would be to use scap 
> workbench to select options for implementation and then use it to both OS 
> versions, 7.2 and the latest available.
>
> What I have not found is the answer to the compatibility issue, can I pick 
> the very latest scap policy provided in 7.4, modify and use it also with 7.2 
> eus? 

You'll find differences with each content provider.

When it comes to the SCAP Security Guide content shipping natively in
RHEL, it's designed for RHEL 7.x.

I actually don't know how EUS errata is handled (e.g. if everything is
backported). Marek Haicman is the product owner within Red Hat for
OpenSCAP and SSG he may know (and lurks on this list).

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] First try at remote scanning

[Shawn Wells]

On 2/28/18 9:24 AM, Geoffry Roberts wrote:
> All,
>
> I tried my first remote. scan and don't understand the result.
>
> I ran the following, which is almost a cut and past from the manual:
>
> oscap-ssh root@ xccdf eval --profile MAC-3_Sensitive --report
> report.html
> /U_Canonical_Ubuntu_V1R1_STIG/U_Canonical_Ubuntu_V1R1_Manual_STIG/U_Canonical_Ubuntu_STIG_V1R1_Manual-xccdf.xml
>
> This is the result:
> This script only supports '-h', '--help', '--v', '--version', 'info',
> 'xccdf eval', 'oval eval' and 'oval collect'.
>
> What does it mean? I am using the supported xccdd eval.  The xccdd
> file comes from DISA.  

Looking at DISA's filename, it appears the content is their *manual*
XCCDF file. Meaning no OVAL checks.

Before troubleshooting to much, you may want to confirm this file
contains OVAL checks. Quick way is to attempt a local run on the
endpoint using the same arguments (oscap xccdf eval --profile foo
/path/to/file.xml). If you're familiar w/SCAP XML you could peek into
their file(s) as well.
___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] [Suspected Spam] Re: OSCAP Scanner Binaries

[Shawn Wells]

On 4/24/18 1:12 PM, Mohanraj, Bharath wrote:
>
> Thanks for the info… 
>
> The first thing I want to avoid is my enduser machines hitting the
> internet for downloading packages… So, I prefer having them as RPM
> files locally and trigger installation of the same… But, in case the
> RPM installation fails for some reason, then just placing the files at
> required locations will be my fallback…
>
> Do you see any problems with this approach, that might affect oscap
> functionality?
>

While technically possible, using the operating systems native package
manager is generally recommended.

You can download the RPM file from Red Hat using the links/instructions
Mike Harris sent.

>From there a "yum localinstall " could be used.
___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] [Suspected Spam] Re: OSCAP Scanner Binaries

[Shawn Wells]

On 4/26/18 1:09 PM, Mohanraj, Bharath wrote:


I tried to download only the oscap rpms by using the below command,

*yum install --downloadonly --downloaddir=/opt/oscaprpm 
openscap-scanner***


**

And once the above command is triggered, it downloaded the below bunch 
of RPMs…


My intention here is to get the rpms downloaded, copy it to my other 
RHEL machines that don’t have yum… and directly install the rpms… and 
I’m interested in running the oscap to scan my RHEL machines…


Now, my question here is, should I install all the downloaded RPMs to 
get the oscap scanning work?


The other RPMs contain needed libraries or deprencies of the OpenSCAP 
tooling.


This all seems very unusual. YUM is installed on *every* RHEL host out 
of the box. Administrators would actively have to remove it for this use 
case to be applicable.


Even if OpenSCAP and associated dependencies were installed through 
RPMs, YUM would still be available (and likely ideal) to install 
software through.
___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] [Suspected Spam] Re: OSCAP Scanner Binaries

[Shawn Wells]

On 4/26/18 7:00 PM, Christopher Wiedmaier wrote:
How can I be removed from this list?  I have completed the unsubscribe 
steps multiple times but I still end up receiving e-mails. 

https://www.redhat.com/mailman/listinfo/open-scap-list

Under the "openscap-list subscribers" section (last section on the page) 
there is a field to enter your EMail and button for unsubscribe.


If having issues, you can ping Martin Preisler (mprei...@redhat.com) and 
he can manually remove.


___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] [Suspected Spam] Re: OSCAP Scanner Binaries

[Shawn Wells]

On 4/27/18 1:18 AM, Mohanraj, Bharath wrote:


Thanks Shawn for the clarification…

One last thing I want to mention here is… some of the RHEL boxes in my 
environment are locked down from internet.. .so they will not have 
access to the repository to fetch oscap binaries, and that’s the 
reason I had raised this question. Do you have any better suggestion 
for this scenario?




Could implement an on-premise YUM repo. This would give administrators 
the standard YUM functionality. A few RHT articles:


- "How to create a local mirror of the latest update for Red Hat 
Enterprise Linux 5, 6, 7 without using Satellite server?"

https://access.redhat.com/solutions/23016

This article may also be helpful:
"How can we regularly update a disconnected system (A system without 
internet connection)?"

https://access.redhat.com/solutions/29269
___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Let me poll the community

[Shawn Wells]

On 5/14/18 7:26 PM, Geoffry Roberts wrote:
A few weeks ago I saw a thread or two where some were seeking a means 
of analyzing large volumes of SCAP result sets.


I'd like to ask the community as to what extent this represents a 
problem?


People I know who are using SCAP are scanning on a small scale and can 
read the results manually.  It makes sense to me that as volumes rise 
some form automation would be in order.


What say ye?


My own work revolves around containers these days. Scan results are 
ephemeral. Once the scan is complete (and passed) the CI/CD moves on. 
Outputs (container images) are immutable. No need to continuously rescan 
them or keep stale records around.


For lots of legacy virtualization workloads, something like Satellite, 
Tenable, or even ePO, is used to aggregate the scans over time.


___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] SCAP customizations and OS migrations

[Shawn Wells]

On 6/3/18 11:59 PM, Robert Sanders wrote:

Marek,
   Thank you for your reply.  While I understand how it can be difficult to 
compare between versions, I've found it very useful to do so.  I've written a 
very rough hack (as in, one step better than a stone axe) that will compare 
multiple profile/content pairs, and/or customizations.  This includes trying to 
apply one customization to a more recent profile/content.  It basically loops 
over the rules, showing where any of the input files 'differ'.  Isn't perfect, 
but it does help highlight places where things have issues.  If my management 
allows, I may make this available to the community.

Sounds useful! Hope you're able to share.

   I have seen the issue regarding update to a tailoring file.  I'd actually 
gotten to the point of manually tweaking my tailoring file as I need to make 
changes, using an 'expendable' tailoring file to get the new lines.  Do you 
know if this is on the list of things to be fixed at some point?


___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Scanning Ubuntu / Debian servers with openscap

[Shawn Wells]

On 8/22/18 2:01 PM, Marek Haicman wrote:

On 08/22/2018 07:37 PM, Dhanushka Parakrama wrote:

Hi Team

I'm new to Openscap

I able to scan my redhat and centos machines with Openscap  for 
  compliance  .


oscap xccdf eval --profile "usgcb-rhel6-server" --report 
/tmp/report.html /usr/share/xml/scap/ssg/content/ssg-rhel6-xccdf.xml


1.  Is there any way to scan Ubuntu and Debian machine for certain 
complicate ?

2.  Are there any XCCDF files for ubunti and Debain ?


Thanks in Advance
Dhanushka



Hello Dhanushka,
if you take a look at our upstream github release page 
https://github.com/OpenSCAP/scap-security-guide/releases there is 
"scap-security-guide-0.1.40.zip" archive. This archive contains 
datastreams for all products we generate content for.


Mind you, RHEL content is more complete than the rest, mostly because 
of Red Hat contributors.


Ubuntu packages SSG natively. Their last build appears to be 27-JULY-2018:
https://launchpad.net/ubuntu/+source/scap-security-guide


___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Can we remove some service checks from the profile

[Shawn Wells]

On 9/5/18 6:20 AM, Dhanushka Parakrama wrote:

Hi Team

I  Wanted to remove the few service checks from the profile 
*xccdf_org.ssgproject.content_profile_anssi_np_nt28_high (Eg: Ensure 
/tmp Located On Separate Partition , 
*xccdf_org.ssgproject.content_rule_partition_for_tmp ) and build new 
*ssg-centos6-ds.xml* check file how can i do that ?


That's a common use case! Consider evaluating SCAP Workbench. It's a GUI 
tool to tailor what rules are enabled/disabled in your security profile.


Homepage:
https://www.open-scap.org/tools/scap-workbench/

Blog "Customizing SCAP Security Guide for your use-case 
" 
by Jan Cerny is a good place to start!
___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] question on addon_fedora_oscap

[Shawn Wells]

On 10/4/18 3:05 AM, Jan Cerny wrote:

Hi,

Unfortunately, the "tailoring" feature is broken in Anaconda Addon.

However, there is a workaround, suggested by Watson Yuuma Sato (adding him to 
this conversation).
Let me copy-paste his idea:

There is a tool that can combine the tailoring to the datastream or XCCDF file. 
So it is possible
to embed the tailoring into content file and get it through "content-url" field.

Quick howto commands and instructions below:
Grab the combine-tailoring tool
$ git clonehttps://github.com/mpreisler/combine-tailoring.git
cd combine-tailoring

Combine tailoring and content
./combine-tailoring.py --output ssg-rhel7-ds-combined.xml 
/usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml 
ssg-rhel7-ds-standard-tailoring.xml

Serve the file ssg-rhel7-ds-combined.xml in your network, and
in the kickstart:
- change content-type to datastream or xccdf
- add field content-url and point to your new combined content
- change profile to the id of your customized profile, please note that it must 
be the full id.

For example:
%addon org_fedora_oscap
content-type = datastream
content-url =http://192.168.0.2/content/ssg-rhel7-ds-combined.xml
profile = xccdf_org.ssgproject.content_profile_standard_customized
%end


Hopefully it helps.


Where can we find the BZ tracking fixing tailoring in Anaconda? Will 
this be included in the RHEL 7.6 release?


Also - where can we find the KBase article documenting the work around 
on the customer portal?


___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] OpenSCAP 1.3.0

[Shawn Wells]

On 10/9/18 7:38 AM, Jan Cerny wrote:

Hello OpenSCAPers,

We are thrilled to announce general availability of OpenSCAP 1.3.0 release.

This is the first release from maint-1.3 maintenance branch. API/ABI is not
compatible with 1.2.x releases. API/ABI is not compatible with 1.3.0_alpha
releases.

Changes from 1.3.0_alpha2:
   - New features
 - Introduced a virtual '(all)' profile selecting all rules
 - Verbose mode is a global option in all modules
 - Added Microsoft Windows CPEs
 - oscap-ssh can supply SSH options into an environment variable
   - Maintenance
 - Removed SEXP parser
 - Added Fedora 30 CPE
 - Fixed many Coverity defects (memory leaks etc.)
 - SCE builds are enabled by default
 - Moved many low-level functions out of public API
 - Removed unused and dead code
 - Updated manual pages
 - Numerous small fixes

Key differences from 1.2.x series:
- Basic Microsoft Windows support
- Removed deprecated command line interfaces
- Removed deprecated API symbols
- Probes are not separate processes anymore
- CMake used as build system
- CTest used as a test framework

Download:
https://github.com/OpenSCAP/openscap/releases/download/1.3.0/openscap-1.3.0.tar.gz

SHA512:
9405d0f17b60ab4a52ddd0f49d0e2395eb2540f0d07d68dfd142e2b8b2988e88cf127230523e68f67d3d22a6dd4eb2397f9468c923d19bb7cb059abf487ab5a1

Audit, Fix, And Be Merry!


Thanks Jan!

How far along is Windows support? Saw the mention of 'basic' -- but how 
should OpenSCAP on Windows be positioned?


For example:
- How many Windows probes are implemented?
- Does OpenSCAP on Windows pass the NIST automated tooling?
- Where can we send people who want to find out more?

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] OpenSCAP 1.3.0

[Shawn Wells]

On 10/10/18 5:01 AM, Jan Cerny wrote:

Hi,

OpenSCAP support for Windows hasn't been improved much since the
1.3.0_alpha1 releases. The only thing that we have done
recently is that we added Windows CPEs to the inbuilt CPE dictionary.


How far along is Windows support? Saw the mention of 'basic' -- but how
should OpenSCAP on Windows be positioned?

OpenSCAP 1.3.0 can be compiled and installed on Windows, it runs, it produces
"some" results. But it's very bad.


- How many Windows probes are implemented?

OpenSCAP 1.3.0 for Windows has the following 4 probes:
* system_info
* registry
* wmi57
* accesstoken


- Does OpenSCAP on Windows pass the NIST automated tooling?

Nobody tried that. I expect that it doesn't pass.


- Where can we send people who want to find out more?

For people that would like to contribute code I would point them to developer's
manual where they can find how to build it on Windows.
https://github.com/OpenSCAP/openscap/blob/master/docs/developer/developer.adoc

For normal users we don't have anything.
I think we definitely should mention that it exists onwww.open-scap.org.

The problem with OpenSCAP for Windows is that nobody is working on that now,
and it is not tested at all. Also, it is not supported by Red Hat in any way.

Understand the Windows support is community driven.

IIRC, wasn't there someone building a master thesis about this work? Has 
that been completed?



I'm sorry if the release announcement email caused a confusion.
I mentioned the Windows support under "Key differences from 1.2.x series"
because the 1.3.0_alpha1 and 1.3.0_alpha2 releases were intended as 
pre-releases.
I supposed most people didn't follow their changelog. I wanted to point out 
there
at least the main differences of 1.3.0 for users of 1.2.x releases.

However, as usually, the full changelog is located at:
https://github.com/OpenSCAP/openscap/blob/master/NEWS


Nah, wouldn't say confusion. Wasn't sure of the broader Windows support 
so figured I'd just ask!
___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Disable STIG

[Shawn Wells]

On 10/22/18 7:22 AM, Gaurav Kamathe wrote:

Hello All,

I am a QA who needs to test some functionality when STIG is enabled on 
a server (RHEL) by the user.
However the software does not provide any way to disable STIG (factory 
reset is the only option).
Is there a workaround for this? Can i disable it from the backend or 
in someway reverse the changes that were done when STIG was enabled 
for testing purposes?

Please let me know or point me in the right direction.
Thanks.


Hi Gaurav,

    Currently there is no "undo" option. Most people reload their 
container/VM/endpoint with a fresh install if needed.


-Shawn

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Benchmark for Canonical Ubuntu 16.04 LTS

[Shawn Wells]

On 11/27/18 6:23 PM, Boucher, William wrote:


Hi folks,

I am currently hardening an Ubuntu embedded system for delivery to a 
customer.


I have downloaded the “Canonical Ubuntu 16.04 LTS STIG Ver 1, Rel 1” 
from DISA, and I have obtained a copy of the SCAP Compliance checker 
tool “SCC 5.0.2 Ubuntu 16 AMD64”.


What I am missing is an SCAP Benchmark file for Ubuntu 16.04. Does one 
exist?


I would like to use OpenSCAP to harden then scan this IS. The 
Open-SCAP BASE page says that Ubuntu is supported, so I can get the 
tools installed. But without a benchmark how would I proceed from there?




Looks like DISA does not publish SCAP content for their Ubuntu STIG:

https://iase.disa.mil/stigs/scap/Pages/index.aspx


___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Hardening Redhawk 6.5

[Shawn Wells]

On 1/29/19 11:14 PM, Boucher, William wrote:


Hi folks,

I’ve been tasked with applying the RedHat 6 STIG to several RedHawk 
6.5 systems.


Running oscap should be relatively easy, to see where a base install 
sits initially (RedHawk is RedHat with modifications for embedded 
realtime use).


The RedHawk site talks about testing RedHawk performance after 
applying the RedHat STIG (in a white paper), but it makes no mention 
on how to apply it.




RedHawk Linux doesn't have a STIG or common criteria, so not sure what 
security configuration guides (if any) are available.


If the RHEL STIGs can be applied to it, akin to CentOS, the 
ComplianceAsCode user guide might be helpful:


https://github.com/ComplianceAsCode/content/blob/master/docs/manual/user_guide.adoc

Specifically remediation section:
https://github.com/ComplianceAsCode/content/blob/master/docs/manual/user_guide.adoc#remediation



Applying it manually is an option, but I’d sure like to automate some.

But my question really concerns adding packages (like selinix). 
RedHawk discourages using yum (with the RedHat repositories) to update 
packages, as there may be incompatibilities between the standard 
packages and the RedHawk modifications to the OS.


Perhaps I should direct this question to RedHawk support, but I 
thought I’d ask it here first to get your input.


Not sure how RedHawk works. If they're layering RedHawk software ontop 
of Red Hat instances, then you'd have a Red Hat subscription for every 
node (and could ask Red Hat support). If RedHawk is distributing their 
own independent linux distro, it'd be appropriate to query them about 
package management.



___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

[Open-scap] When to expect OVAL probes for OpenShift?

[Shawn Wells]

When can OpenSCAP probes be expected for OpenShift?

Need ability to parse configuration data that would be returned by "oc 
get" style commands.


Thanks!

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] When to expect OVAL probes for OpenShift?

[Shawn Wells]

On 2/4/19 6:08 PM, Steve Grubb wrote:

On Mon, 4 Feb 2019 11:06:00 -0500
Shawn Wells  wrote:


When can OpenSCAP probes be expected for OpenShift?

Are you talking about new OVAL tests?




Probes so that OVAL tests could be created. Akin to the systemd probes.

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Using profiles not distributed in scap-security-guide

[Shawn Wells]

On 2/6/19 1:11 PM, Greg Silverman wrote:


We want to use the DISA STIG for RHEL 7 V2R2 profile. The latest 
scap-security-guide RPM has V1R4. How is a profile xml file consumed 
by oscap?




Most use cases are covered in the RHEL documentation:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/sect-using_oscap

That said, has DISA started to publish OVAL for their content? Was under 
the impression they did not (only publish XCCDF).


___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] When to expect OVAL probes for OpenShift?

[Shawn Wells]

On 2/4/19 2:27 PM, William Munyan wrote:


Hey Shawn,

I’ll add to Steve’s point that if there is not current OVAL support 
for the constructs you need, then the new OVAL 
tests/objects/states/items would need to be created in either a new 
OVAL schema or (more likely) as additions to the existing Linux 
schema.  Once created a proposal can be made to the OVAL language team 
through an issue and pull request to the official OVAL Language GitHub 
.  The newly released proposal 
process can be found here 
.


Once proposed, the OVAL community can provide feedback and 
implementations to prove the concept and progress the proposal along 
towards adoption.  Ultimately, the area supervisor for the Linux 
schemas will need to be involved as well.  The supervisor for Linux is 
currently Simon Lukasik.


I’m happy to help out with any schema development, and potential 
implementation of proposed updates as well (although I’ll freely admit 
negligible knowledge of OpenShift).  The language governance, proposal 
and adoption process are all recently “released” so if you find 
yourself needing help with the process, don’t hesitate to reach out.




Thanks Bill & Steve.

So then, to rephrase the question, when will there be OVAL 
tests/subjects/states/items for OpenShift, akin to how there are for 
systemd and SELinux?


Would be extremely surprising to learn this process hasn't been started 
already, but getting the sense it hasn't been. Not really sure who to 
direct the question to likely Marek and Matej?


___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Using profiles not distributed in

[Shawn Wells]

On 2/8/19 2:34 PM, Greg Silverman wrote:

Let me ask in a different way.

DISA published xml files 
withhttps://iasecontent.disa.mil/stigs/zip/U_Red_Hat_Enterprise_Linux_7_V2R2_STIG_SCAP_1-2_Benchmark.zip.
 The zip's xml file contains a list of vulnerabilities for RHEL7, the Version 2 
Release 2 (V2R2) selection of vulnerabilities. scap-security-guides versions 
1.40+ contain a DISA profile and that profile contains the V1R4 list of 
vulnerabilities.

1. Can oscap v 1.2.17 consume the xml files at the DISA URL and evaluate a 
RHEL7 machine?



DISA only publishes what's called XCCDF -- essentially, human-readable 
prose. DISA does not publish any automation that would result in a 
pass/fail configuration scan.


The most any SCAP tool could do with this content, including OpenSCAP, 
would be to transform it from XML to HTML to ease reading:


$ oscap xccdf generate guide \
U_Red_Hat_Enterprise_Linux_7_V2R2_STIG_SCAP_1-2_Benchmark.xml \
> ~/disa-guide.html



2. How do xml files like the ones at that URL get incorporated in a 
scap-security-guide, as was done with the DISA V1R4 files?


Manually.

Unfortunately DISA does not coordinate their content with DoD, NIST, 
NSA, or even Red Hat. These parties only find out about DISA's content 
when it's made publicly available.


And also unfortunately, DISA does not provide a changelog of what was 
changed. That means someone needs to go through the DISA content and 
compare it by hand. From there a series of tickets are opened to discuss 
alignment:


https://github.com/ComplianceAsCode/content/issues?q=is%3Aissue+is%3Aopen+label%3A%22DISA+Content+Issues%22

Once that ticket queue is resolved, the two bodies of content will be in 
alignment.



___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] When to expect OVAL probes for OpenShift?

[Shawn Wells]

On 2/11/19 7:38 PM, Steve Grubb wrote:

On Thursday, February 7, 2019 1:23:58 PM EST Shawn Wells wrote:

So then, to rephrase the question, when will there be OVAL
tests/subjects/states/items for OpenShift, akin to how there are for
systemd and SELinux?

Those were created specifically to address problems in drafting content for
the USGCB settings a long time ago. They were created because there was no
other good way of getting the information.


Would be extremely surprising to learn this process hasn't been started
already, but getting the sense it hasn't been. Not really sure who to
direct the question to likely Marek and Matej?

Things aren't created until there's a demonstrated need. What are the
underlying configuration that you are trying to read? What parts of the config
are needed? Where is this information kept?


Seems like there is a ever growing backlog of probes that need creation.

Quick examples of polling dconf db, and parsing "oc get" commands for 
OpenShift settings. Neither keeps their state in config files so need to 
use those commands specifically.




Just wanted to show how the systemd tests were created:
http://making-security-measurable.1364806.n2.nabble.com/Proposal-for-OVAL-5-11-systemd-test-td7583274.html

There was some discussion about what the intended use would be. What
questions would the test answer? Then some discussion about syntax and
attribute vs elements, etc. Right now, I think anyone that could help needs a
little better definition of the problem you are seeing.



Excellent. Thank you -- will review to help me learn the correct 
vernacular.


At this point, getting the impression there's been zero work on creating 
OpenShift probes though.


___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] V-73159 - Question on requisite vs required in pam.d/system-auth

[Shawn Wells]

On 2/14/19 12:21 PM, Marek Haicman wrote:

Hello, according to the v2r2, the check is supposed to be:
```
# cat /etc/pam.d/system-auth | grep pam_pwquality

password required pam_pwquality.so retry=3

If the command does not return an uncommented line containing the 
value "pam_pwquality.so", this is a finding.


If the value of "retry" is set to "0" or greater than "3", this is a 
finding.

```
and there's nothing about `required`. So it's up to your setup, I believe.



Exactly. There's nuance there.

The DISA content is ensuring pam_pwquality is being used, and retry has 
an appropriate value.


requisite or required is not part of the check... just example of how 
things could be setup.


___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Open a ticket?

[Shawn Wells]

On 2/18/19 9:04 AM, Todd Williams wrote:


I am trying to find out how to go about opening a ticket against 
openSCAP, can anyone point me in the right direction?



Depends where you're consuming it.

If using a commercial linux distro, would suggest opening a ticket with 
them directly. For Red Hat, that'd be here:

https://access.redhat.com/support/cases/#/case/new

If using the upstream bits, the code repo + tickets are here:
https://github.com/OpenSCAP/openscap/


___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Phasing out the RHEL6 CI

[Shawn Wells]

On 2/26/19 12:07 PM, Boucher, William wrote:

My only concern is that sometimes a government customer will mandate using some 
flavor of RHEL 6, for whatever reason they may have. For example, we have a 
government customer mandating we use 6.5 at the moment. And they are perfectly 
happy to have us STIG the 6.5 OS manually, page by page, if there is no way to 
automate it.



The end of RHEL 6's maintenance support 2 phase isn't until 30-NOV-2020 
[0]. Until then OpenSCAP should be prepared to release security 
advisories (RHSAs) and urgent bug fixes (RHBAs) for OpenSCAP.


Developers judgement call whether downstream RHSAs and RHBAs can be 
released in a timely, high-quality manner, without an upstream CI.


In reality there may have been little to no RHSAs or RHBAs for OpenSCAP. 
However it's the Red Hat brand promise that if there ever are, we'll be 
ready.



[0] https://access.redhat.com/support/policy/updates/errata

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

[Open-scap] Atomic Scan still based off RHEL 7.6?

[Shawn Wells]

Pulling the latest atomic scan shows the container image is still based 
on RHEL 7.6 (vs 7.7) and contains very old scap-security-guide package.


When will it be rebased?

___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Need help on openscap SSG question

[Shawn Wells]

Would need to understand where the content is coming from. Perhaps 
scap-security-guide in RHEL, and if so, what RHEL and SSG version?

Note red hat doesn’t publish rhel6 content in the National Checklist Program 
since rhel6 is out of active maintenance:

https://nvd.nist.gov/ncp/repository?authority=Red+Hat&startIndex=0

Once the content source/version version is identified , the content can be ran 
through the NIST content validator tooling to see if there are problems with 
the content itself.



> On Apr 29, 2019, at 11:19 AM, Jan Cerny  wrote:
> 
> Hi,
> 
> I have no idea. Does Nessus have any "verbose" mode to get more
> helpful error message?
> 
> Including scap-security-guide list in this conversation because there
> might be people familiar with using SSG with Nessus.
> 
> Regards
> 
>> On Mon, Apr 29, 2019 at 4:54 PM Riaz Ebrahim  wrote:
>> 
>> Hi Jan Cerny,
>> 
>> Thanks a lot for your response, Your answer was very useful to understand 
>> about SSG files. As per your advice i tried with 
>> scap-security-guide-0.1.43-oval-510.zip  and XML validation error was gone, 
>> but encountering new error as below from nessus
>> 
>> "ssg-rhel6-ds-1.zip : Default namespace not found in OVAL"
>> 
>> Do you get any clue by seeing this error?. Thanks in advance :)
>> 
>> Thanks,
>> Riaz
>> 
>>> On Mon, Apr 29, 2019 at 2:44 PM Jan Cerny  wrote:
>>> 
>>> Hi,
>>> 
>>> I will try to answer, but I don't use Nessus, so I'm not sure what is
>>> the exact reason of this fail.
>>> 
>>> In general, the SSG files are validated against SCAP XML schemas, so
>>> they are valid SCAP content.
>>> However, SCAP standard consist of multiple separate specifications.
>>> Strictly speaking, the SSG datastream
>>> doesn't conform to SCAP 1.2 specification, because the datastream
>>> contains OVAL checks conforming to OVAL
>>> version 5.11 which is a part of SCAP 1.3. For SCAP 1.2 conformance it
>>> would need to use OVAL checks
>>> in version 5.10 or older.
>>> 
>>> According to this forum thread, it seems that Nessus doesn't support
>>> OVAL 5.11 it yet, but they say it's planned to be updated
>>> https://community.tenable.com/s/question/0D5f25hKRwqCAG/nessus-pro-7-trouble-getting-oval-scans-to-work
>>> 
>>> It could be a problem that Nessus expects datastreams that  contain
>>> OVAL 5.10 only.
>>> Try using the SSG datastreams that contain OVAL 5.10 only. They can be
>>> downloaded from
>>> https://github.com/ComplianceAsCode/content/releases/download/v0.1.43/scap-security-guide-0.1.43-oval-510.zip
>>> I hope Nessus should be able to consume these files.
>>> 
>>> The reason why we use 5.11 is that it contains new checks that allows
>>> us to check easily system services using systemd
>>> and other new things introduced in RHEL 7. The aforementioned
>>> datastreams that contain OVAL 5.10 only
>>> have limited abilities in comparison with those containing OVAL 5.11.
>>> 
>>> Best Regards
>>> 
>>> Jan Černý
>>> Security Technologies | Red Hat, Inc.
>>> 
>>> 
 On Sat, Apr 27, 2019 at 6:34 AM Riaz Ebrahim  
 wrote:
 
 I need help on openscap SSG project.
 
 I am currently exploring SCAP Auditing feature from Nessus console. I 
 understood that Nessus supports SCAP Content (1.0 or 1.1 or 1.2) which can 
 be downloaded from NIST repository (https://nvd.nist.gov/ncp/repository) 
 based on the target host version. This works great, However when i use 
 SCAP from OpenSCAP SSG (example "ssg-rhel6-ds.xml”), i am getting error as 
 “sg-rhel6-ds. .zip :  sg-rhel6-ds.xml failed XML Schema validation” .
 
 I would like to what is the difference between openSSG scap data stream &  
 scap1.2 content downloaded from NIST repository. How i can convert openssg 
 data stream (Example - ssg-rhel6-ds.xml) to NIST scap 1.2 format.
 
 
 My objective - To use openscap SSG from Nessus. Nessus scap scanning 
 expects SCAP 1.0, 1.1 or 1.2 content(in zip format).
 
 
 Thanks in advance!
 
 ___
 Open-scap-list mailing list
 Open-scap-list@redhat.com
 https://www.redhat.com/mailman/listinfo/open-scap-list
> 
> 
> 
> --
> Jan Černý
> Security Technologies | Red Hat, Inc.
> ___
> scap-security-guide mailing list -- scap-security-gu...@lists.fedorahosted.org
> To unsubscribe send an email to 
> scap-security-guide-le...@lists.fedorahosted.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: 
> https://lists.fedorahosted.org/archives/list/scap-security-gu...@lists.fedorahosted.org
___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Help needed - to Quantify severity levels

[Shawn Wells]

On 6/7/19 5:02 AM, harshad wadkar wrote:

Respected Madam / Sir,

I am referring the following url to know about open-scap and Ubuntu 
secure configuration.

https://static.open-scap.org/ssg-guides/ssg-ubuntu1604-guide-anssi_np_nt28_average.html

I have one query :
1. At present, the severities are labelled as unknown, low, medium and 
high.
    a) Is there any mechanism or logic, which will quantify these 
severity levels.
    e.g. low : 0 to < 3, medium : 3 to < 6 and high : 6 to 9 (as given 
in OWASP -

    Owasp risk rating methodology. https://www.owasp.org/index.php/OWASP_
Risk_Rating_Methodolog)
    b) If yes, requesting you share the information / document / url 
with me.


Your guidance is vital to me - waiting for the reply.




They correlate to the DISA Vulnerability Severity Category Code Definitions:



CAT I (HIGH):
Any vulnerability, the exploitation of which will directly and 
immediately result in loss of Confidentiality, Availability, or 
Integrity.



CAT II (MEDIUM):
Any vulnerability, the exploitation of which has a potential to result 
in loss of Confidentiality, Availability, or Integrity.


CAT III (LOW):
Any vulnerability, the existence of which degrades measures to protect 
against loss of Confidentiality, Availability, or Integrity.




Historically used the DISA ratings because much of the original 
community was from Government work (United States, then international) 
and the language was fairly standardized.


___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Help needed - to Quantify severity levels

[Shawn Wells]

On 6/18/19 3:45 PM, Trevor Vaughan wrote:
At some point, these should probably be changed to correlate with the 
Vulnerability Severity Assessment Scale as outlined in the NIST 800-30 
since it is well defined, a public standard at no cost, and 0-100 
which lines up with most people's internal "gut feeling".



Sounds reasonable. Looks like "TABLE D-6: ASSESSMENT SCALE – RANGE OF 
EFFECTS FOR NON-ADVERSARIAL THREAT SOURCES" seems most applicable [0]. 
Is that what you were thinking?


Worried the broader 800-30 requires advanced multidimensional 
calculus yes, could result in better ratings than the DISA scale, 
but if its to hard to use... nobody will use it.



[0] Page 68 @ 
https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-30r1.pdf


___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] Wish to disable check or remediation of STIG rules to remove X Windows and to use smart card

[Shawn Wells]

On 6/25/19 11:36 AM, Boucher, William wrote:


I figured it out!



That's great! To help others down the road who may have a similar issue, 
what was the fix?


___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list

Re: [Open-scap] timing rule evaluation times

[Shawn Wells]

On 8/7/19 2:58 PM, Greg Silverman wrote:
Is there any way within oscap to record the time taken for each rule’s 
evaluation to complete? We sometimes see it taking over an hour to 
complete on RHEL7 and want to understand why.



Could try verbose mode. Not sure if timestamps are generated. Something 
like:


$ oscap xccdf eval --profile ${profile} --results ~/scan-results.xml 
*--verbose devel */path/to/your/content.xml



Worst case you could create a for loop iterating through all the rules 
in your profile. Would have to grep out all the rules in your profile, 
but the SCAP command would be something like:


$ time oscap xccdf eval --profile ${profile} --rule ${rule} 
/path/to/your/content.xml



___
Open-scap-list mailing list
Open-scap-list@redhat.com
https://www.redhat.com/mailman/listinfo/open-scap-list