Fedora updates for SCAP Security Guide 0.1.41

[Watson Yuuma Sato]

Hello,

I've proposed updates to Fedora packages for scap-security-guide-0.1.41.
If you can, please, test and provide karma.

Fedora 29 - https://bodhi.fedoraproject.org/updates/FEDORA-2018-0d60f79d06

Fedora 28 - https://bodhi.fedoraproject.org/updates/FEDORA-2018-bad4ea7d4f

Thank you for your time and at karma.

--
Watson Sato
Security Technologies | Red Hat, Inc
___
scap-security-guide mailing list -- scap-security-guide@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-guide@lists.fedorahosted.org

SCAP Security Guide 0.1.41

[Watson Yuuma Sato]

Hello everybody,

We have the pleasure to announce release of SCAP Security Guide 0.1.41.

Although it is named SCAP Security Guide, the project is now under 
ComplianceAsCode organization (https://github.com/ComplianceAsCode/content).
For more on this move, see 
https://lists.fedorahosted.org/archives/list/scap-security-guide@lists.fedorahosted.org/thread/TWSI5VHJZ73OSZYZVBI4CD7ZPVYUFNHO/


This release continues with fixes "under the hood", the checks and fixes 
are now better placed, in the same directory as the rule description.
We also feature new Products and new Profiles, test coverage for the 
rules was significantly improved, along with testing capabilities of 
SSGTestSuite.



Highlights of this release:

- Improved test scenario coverage of rules
- Improvements regarding content for Kubernetes for opencis-ocp-master 
Profile

- Introduction of concept of stable Profiles
- Addition of Ubuntu 1804 Product with ANSSI and standard Profiles
- Addition of OSPP 4.2 Profile for Fedora
- Addition of PCI-DSS Profile for Fedora
- Possibility to manually debug test scenarios
- Addition of Example Product
- Support to evaluate test scenarios on container images
- Introduction of SSG unit tests for build system functions
- Reorganization of checks and fixes to be closer to rule description

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/ComplianceAsCode/content/releases/tag/v0.1.41

Full changelog at:
* https://github.com/ComplianceAsCode/content/issues?q=milestone%3A0.1.41

Zip archives with pre-built benchmarks in DataStream form:
* 
https://github.com/ComplianceAsCode/content/releases/download/v0.1.41/scap-security-guide-0.1.41.zip

(Zip archive using OVAL-5.11.1 language version)
* 
https://github.com/ComplianceAsCode/content/releases/download/v0.1.41/scap-security-guide-0.1.41-oval-510.zip

(Zip archive using OVAL-5.10 language version only)

Thank you to everyone who contributed with issues, patches and discussions!

Happy hardening!

--
Watson Sato
Security Technologies | Red Hat, Inc
___
scap-security-guide mailing list -- scap-security-guide@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-guide@lists.fedorahosted.org

Fedora Updates for SCAP Security Guide

[Watson Yuuma Sato]

Hello,

There are Fedora updates for SCAP Security Guides package updating it to 
latest upstream, version 0.1.39.


Fedora 28 - https://bodhi.fedoraproject.org/updates/FEDORA-2018-3f713ee7a8

Fedora 27 - https://bodhi.fedoraproject.org/updates/FEDORA-2018-9516859f4b

Fedora 26 - https://bodhi.fedoraproject.org/updates/FEDORA-2018-6616f38201

It would be great if you could test and provide karma to them.

Thank you.

--
Watson Sato
Security Technologies | Red Hat, Inc
___
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org

SCAP Security Guide 0.1.39

[Watson Yuuma Sato]

Hello folks,

We have the pleasure to announce that SCAP Security Guide version 0.1.39
has been released.

Highlights of this release:

* XCCDF Rules moved to yaml format
* Jinja2 templating for Rules, Checks and remediation introduced
* Profile IDs simplified
* Product Oracle Linux 7 added
* Common Profile removed in favor of Standard Profile

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.39

Full changelog at:
* 
https://github.com/OpenSCAP/scap-security-guide/issues?q=milestone%3A0.1.39


Zip archives with pre-built benchmarks in DataStream form:
* 
https://github.com/OpenSCAP/scap-security-guide/releases/download/v0.1.39/scap-security-guide-0.1.39.zip 


(Zip archive using OVAL-5.11.1 language version)
* 
https://github.com/OpenSCAP/scap-security-guide/releases/download/v0.1.39/scap-security-guide-0.1.39-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!

--
Watson Sato
Security Technologies | Red Hat, Inc
___
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org

SCAP Security Guide 0.1.38

[Watson Yuuma Sato]

Hello folks,

We have the pleasure to announce that SCAP Security Guide version 0.1.38
has been released.

Highlights of this release:

* New License - BSD-3 Clause
* New Profiles for development introduced:
    * ANSSI
    * HIPAA
    * C2S-Docker
* Adoption of CTest for schema validation
* Several remediation fixes


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.38

Full changelog at:
* 
https://github.com/OpenSCAP/scap-security-guide/issues?q=milestone%3A0.1.38


Zip archives with pre-built benchmarks in DataStream form:
* 
https://github.com/OpenSCAP/scap-security-guide/releases/download/v0.1.38/scap-security-guide-0.1.38.zip 


(Zip archive using OVAL-5.11.1 language version)
* 
https://github.com/OpenSCAP/scap-security-guide/releases/download/v0.1.38/scap-security-guide-0.1.38-oval-5.10.zip 


(Zip archive using OVAL-5.10 language version only)

Great thanks to everyone who contributed with issues, patches and 
discussion.


Happy hardening!

--
Watson Sato
Security Technologies | Red Hat, Inc
___
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org

SCAP Security Guide 0.1.37

[Watson Yuuma Sato]

Hello folks,

We have the pleasure to announce that SCAP Security Guide version 0.1.37
has been released.

Highlights of this release:

* New Profile DISA STIG for Apache HTTP for RHEL7
* Support for Ansible remediations in SSG Test Suite
* Better content support for DISA STIG Viewer

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.37

Full changelog at:
* 
https://github.com/OpenSCAP/scap-security-guide/issues?q=milestone%3A0.1.37


Zip archives with pre-built benchmarks in DataStream form:
* 
https://github.com/OpenSCAP/scap-security-guide/releases/download/v0.1.37/scap-security-guide-0.1.37.zip 


(Zip archive using OVAL-5.11.1 language version)
* 
https://github.com/OpenSCAP/scap-security-guide/releases/download/v0.1.37/scap-security-guide-0.1.37-oval-5.10.zip 


(Zip archive using OVAL-5.10 language version only)

Great thanks to everyone who contributed with issues, patches and 
discussion.


Happy hardening!

--
Watson Sato
Security Technologies | Red Hat, Inc
___
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org

Re: Ansible vs bash fixup scripts

[Watson Yuuma Sato]

Hello Chuck,

On 12/12/17 17:35, Chuck Atkins wrote:
There seems to be a mix of ansible and bash for fix-up scripts, in 
that some rules only have bash fixes, others only have ansible fixes, 
while most have both, and a few still have none.  When applying 
remediation during a scan, which ones get used?
When doing on-line remediation, i.e. by option "--remediate", the bash 
fixes are applied.

Is there a way to specify?
Unfortunately no, the default is to use bash, and there is no way to 
change it.
If I have ansible installed, will the ansible fixes automatically get 
used?  If the ansible ones are being used?  Do the bash-only fixes get 
run as well?  What about rules that have both?
Ansible remediations are not applied automatically, oscap can't consume 
ansible fixes. They should be used by ansible to fix the machine.


Oscap can only generate a script fix based on one kind of remediation, 
it doesn't know how to use mainly one type of fix, and fill the gaps 
with other types of remediation, but this feature sounds interesting and 
useful.




Thanks
--
Chuck Atkins
Staff R Engineer, Scientific Computing
Kitware, Inc.



___
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org



--
Watson Sato
Security Technologies | Red Hat, Inc

___
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org

Re: Question about missing OVAL checks

[Watson Yuuma Sato]

On 22/11/17 00:01, Olivier BONHOMME wrote:

If you have an entry point for doing such a check into the OVAL language
spec, I would be happy to try to write the check :)

Hello,

These OVAL tests might help:
- 
https://oval.mitre.org/language/version5.11/ovaldefinition/documentation/unix-definitions-schema.html#password_state
- 
https://oval.mitre.org/language/version5.11/ovaldefinition/documentation/unix-definitions-schema.html#file_test


I think you can use password_state to get hold of a list of users' home 
directory into a variable, and then use file_test to check for their 
existence.


Below are some examples of the tests, they are not exactly what you 
need, but you can get inspired by them :)

shared/checks/oval/no_files_unowned_by_user.xml
shared/checks/oval/accounts_password_all_shadowed.xml
shared/checks/oval/file_permissions_home_dirs.xml

--
Watson Sato
Security Technologies | Red Hat, Inc
___
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org

Re: stig-overlays.xml usage

[Watson Yuuma Sato]

On 15/11/17 13:15, Olivier BONHOMME wrote:

Dear OpenScap community,

I'm currently working for my company on checking the RHEL 7 SSG profile (0.1.36 
version) coverage against STIG 1.3 release.

While browsing the 0.1.36 release, I discovered the stig-overlays.xml which 
shows the matching between SSG rule and STIG rule.

Can anybody confirm that I can use that file in order to check the coverage 
rate of the SSG profile ?

Hello, Olivier.

I'd say yes, as the stig_overlay maps Rules in STIG to Rules in SSG. 
Rules that don't map to any Rule in SSG will have ruleid="".


Last time stig_overlay.xml was updated in upstream was around 8 months 
ago, so the version there probably isn't STIG 1.3. And unfortunately I 
couldn't find to witch version it corresponds.


To generate an updated stig_overlays.xml file, please refer to our 
Developer Guide [1].


[1] 
https://github.com/OpenSCAP/scap-security-guide/blob/master/docs/manual/developer_guide.adoc#stig-overlay-content


--
Watson Sato
Security Technologies | Red Hat, Inc
___
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org

SCAP Security Guide 0.1.36

[Watson Yuuma Sato]

Hello folks,

We have the pleasure to announce that SCAP Security Guide version 0.1.36
has been released.

Highlights of this release:

 * Introduction of SCAP Security Guide Test Suite
 * Better alignment of RHEL6 and RHEL7 with DISA STIG
 * Remove JBoss EAP5 content due to being End-of-Life
 * New STIG Profile for JBOSS EAP 6
 * Updates in C2S Profile for RHEL 7
 * Variables can be directly tailored in Ansible roles
 * Content presents less false positives in containers
 * Major changes in directory layout
   * oval_5.11 directory removed
   * oval definitions moved to checks/oval
   * static checks are not in templates/static anymore


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.36

Full changelog at:
* 
https://github.com/OpenSCAP/scap-security-guide/issues?q=milestone%3A0.1.36


Zip archives with pre-built benchmarks in DataStream form:
* 
https://github.com/OpenSCAP/scap-security-guide/releases/download/v0.1.36/scap-security-guide-0.1.36.zip 


(Zip archive using OVAL-5.11.1 language version)
* 
https://github.com/OpenSCAP/scap-security-guide/releases/download/v0.1.36/scap-security-guide-0.1.36-oval-5.10.zip 


(Zip archive using OVAL-5.10 language version only)

Great thanks to everyone who contributed with issues, patches and 
discussion.


Happy hardening!

--
Watson Sato
Security Technologies | Red Hat, Inc
___
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org

SSG does not open SSH port in firewalld

[Watson Yuuma Sato]

Hello,

Regarding issue 
https://github.com/OpenSCAP/scap-security-guide/issues/2202, which is 
about remediation of Rule 'set_firewalld_default_zone' setting default 
zone of firewalld to drop, and as a consequence locking down the machine 
if no interface is assigned to a zone with SSH service enabled (because 
a interface with no zone assigned goes to default zone).


There is PR https://github.com/OpenSCAP/scap-security-guide/pull/2285 
which introduced a remediation for Rule 'firewalld_sshd_port_enabled' 
that will assign the first Ethernet interface found to a zone with SSH 
enabled, this will avoid lock down of the machine.


But the question is, how useful is this remediation? Would it work in 
your infrastructure?
There is concern that this scenario is too complex for a remediation to 
fix correctly and in a suitable way for everybody. There is too many 
unknowns about configuration, hardware, SSH use cases.


We may be in a situation that any remediation implemented will do more 
harm than good.


Dropping remediations for 'set_firewalld_default_zone' and 
'firewalld_sshd_port_enabled' can be asafer solution for 
https://github.com/OpenSCAP/scap-security-guide/issues/2202, as the fix 
for these rules are not straight forward.



With regards,

--
Watson Sato
Security Technologies | Red Hat, Inc

___
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org

SCAP Security Guide 0.1.35

[Watson Yuuma Sato]

Hello folks,

We have the pleasure to announce that SCAP Security Guide version 0.1.35
has been released.

Highlights of this release:

 * Remove Red Hat Enterprise Linux 5 content due to being End-of-Life 
March 31, 2017

 * Added several templates for OVAL checks
 * Removal of input directory
 * Many optimizations in build process
 * Different title for PCI-DSS Benchmark variants


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.35

Full changelog at:
* 
https://github.com/OpenSCAP/scap-security-guide/issues?q=milestone%3A0.1.35


Zip archives with pre-built benchmarks in DataStream form:
* 
https://github.com/OpenSCAP/scap-security-guide/releases/download/v0.1.35/scap-security-guide-0.1.35.zip 


(Zip archive using OVAL-5.11.1 language version)
* 
https://github.com/OpenSCAP/scap-security-guide/releases/download/v0.1.35/scap-security-guide-0.1.35-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!

--
Watson Sato
Security Technologies | Red Hat, Inc
___
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org

Re: VMs, containers vs. bare-metal machines in SSG

[Watson Yuuma Sato]

On 19/01/17 18:40, Watson Yuuma Sato wrote:

On 20/10/16 20:30, Martin Preisler wrote:

We have had increasing requests to scan containers and VM storage images
for compliance. In those use-cases a lot of our rules don't make sense.
For example separate partition for /tmp isn't really applicable to 
containers.


I thought about how we can deal with this in SSG. We have several 
options:


1) Separate benchmark and datastreams for containers and VM storage 
images:

ssg-rhel7-ds.xml and ssg-rhel7-container-ds.xml

2) Separate profile for containers and VM storage images:
pci-dss and pci-dss-container

3) Use applicability and CPE platforms to distinguish between what is 
being
scanned. That allows us to use the same pci-dss profile for 
bare-metal, VM,

VM storage image and container image.

Right now I am leaning towards 3) because it "unlocks" the feature
transparently to our users. There is nothing extra they have to study to
start scanning containers. The downside is that we will have to add 
"fake"
CPE IDs for platforms like "vm-storage" and "container". Rules that 
apply

to everything will have no  element in them. Rules that apply
to just containers will have something like:



or



Official NIST CPE ID dictionary has these related CPE IDs
cpe:/a:redhat:docker:1.5.0-27
cpe:/a:linuxcontainers:lxc:0.5.0
cpe:/a:redhat:libvirt:1.2.7

Not sure we want to go with any of those though. I would like to keep it
container and VM tech agnostic.

Before I start hacking this I would like to hear your thoughts.



Hi folks,

Following idea 3, here is a WIP PR to tackle this matter.
https://github.com/OpenSCAP/scap-security-guide/pull/1645

Please, share your concerns...


Hello again,

Following idea 3, most of obvious (e.g. partition, grub, kernel) rules 
got marked as machine using CPE "cpe:/a:machine".
Now there are some Rules witch are harder to decide whether they make 
sense or not for containers.


Take for example, Rules related to sshd.
Technically, ssh can run fine in a container, but it is not recommended, 
there are other ways to access a running container.
An exception to running ssh in, is that this container's purpose is to 
be an ssh server.


If mark these as machine only they will never apply to containers and we 
will need new Rules to evaluate ssh inside containers.
If they are left as is, they will continue to be evaluated for 
containers, installing ssh, increasing attack surface and possibly 
causing false positives.


We would like SSG to have sane defaults for these Rules, but still allow 
for tailoring for exception scenarios.


In https://github.com/OpenSCAP/scap-security-guide/pull/2235 I started a 
prototype for Idea 1, to have separate datastreams for containers. But 
that showed to not be a good idea.
So I changed it to idea 2, with separate Profiles for containers. Main 
idea is to generate these Profiles automatically from existing Profiles 
and use information already present in Rules to filter out the ones not 
recommended for containers.


Also, there is new idea of adding "container-base" Profile with basic 
configuration for containers, I see it like a "standard" Profile for 
containers.


So, container Profiles would have Rules which are not recommended for 
containers dropped, and inherit Rules from "container-base".


Looking forward for your thoughts.

--
Watson Sato
Security Technologies | Red Hat, Inc
___
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org

Re: RHEL 7.4 oscap-anaconda - profile descriptions

[Watson Yuuma Sato]

On 03/08/17 15:36, Watson Yuuma Sato wrote:

On 03/08/17 11:07, Marek Haicman wrote:

On 08/03/2017 02:28 AM, Shawn Wells wrote:

Hey Guys

 Just downloaded the RHEL 7.4 installation media and attempted 
to use the oscap-anaconda features. Selected "security" during the 
installer, and noticed a few things:


(1) The CUI/NIST 800-171 profile has the description from OSPP:


(2) There are multiple RHEL7 STIG options:


I'm not sure how/why this is happening.

The 800-171 profile does extend OSPP. Do we need a "extends" for the 
profile description field?
https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/7/input/profiles/nist-800-171-cui.xml 





___
scap-security-guide mailing list -- 
scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to 
scap-security-guide-le...@lists.fedorahosted.org



Hey Shawn,
ad (2) this is known issue 
https://bugzilla.redhat.com/show_bug.cgi?id=1437106


For (1) that description is the same that SCAP Workbench displays, 
and oscap generates from the guides (as can be seen 
http://static.open-scap.org/ssg-guides/ssg-rhel7-guide-index.html).
  Extend concatenates description of extended profile and the 
extending one. Is it a bug?

This is not a bug.
To replace extended description, extending description element should 
have attribute override="true", like the title element has.
Well, this is a bug if description of CUI/NIST 800-171 is not expected 
to be appended to description of OSPP Profile.




Marek
___
scap-security-guide mailing list -- 
scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to 
scap-security-guide-le...@lists.fedorahosted.org





--
Watson Sato
Security Technologies | Red Hat, Inc
___
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org

Re: RHEL 7.4 oscap-anaconda - profile descriptions

[Watson Yuuma Sato]

On 03/08/17 11:07, Marek Haicman wrote:

On 08/03/2017 02:28 AM, Shawn Wells wrote:

Hey Guys

 Just downloaded the RHEL 7.4 installation media and attempted to 
use the oscap-anaconda features. Selected "security" during the 
installer, and noticed a few things:


(1) The CUI/NIST 800-171 profile has the description from OSPP:


(2) There are multiple RHEL7 STIG options:


I'm not sure how/why this is happening.

The 800-171 profile does extend OSPP. Do we need a "extends" for the 
profile description field?
https://github.com/OpenSCAP/scap-security-guide/blob/master/RHEL/7/input/profiles/nist-800-171-cui.xml 





___
scap-security-guide mailing list -- 
scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to 
scap-security-guide-le...@lists.fedorahosted.org



Hey Shawn,
ad (2) this is known issue 
https://bugzilla.redhat.com/show_bug.cgi?id=1437106


For (1) that description is the same that SCAP Workbench displays, and 
oscap generates from the guides (as can be seen 
http://static.open-scap.org/ssg-guides/ssg-rhel7-guide-index.html).
  Extend concatenates description of extended profile and the 
extending one. Is it a bug?

This is not a bug.
To replace extended description, extending description element should 
have attribute override="true", like the title element has.




Marek
___
scap-security-guide mailing list -- 
scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to 
scap-security-guide-le...@lists.fedorahosted.org



--
Watson Sato
Security Technologies | Red Hat, Inc
___
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org

SCAP Security Guide 0.1.34

[Watson Yuuma Sato]

Hello folks,

We have the pleasure to announce that SCAP Security Guide version 0.1.33
has been released.

Highlights of this release:

* Unification of where templates and csv reside
* Optimization and clean up of build system
* Lots of Ansible remediations added
* Bash remediation functions file is now generated by build system

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.34

Full changelog at:
* 
https://github.com/OpenSCAP/scap-security-guide/issues?q=milestone%3A0.1.34


Zip archives with pre-built benchmarks in DataStream form:
* 
https://github.com/OpenSCAP/scap-security-guide/releases/download/v0.1.34/scap-security-guide-0.1.34.zip 


(Zip archive using OVAL-5.11.1 language version)
* 
https://github.com/OpenSCAP/scap-security-guide/releases/download/v0.1.34/scap-security-guide-0.1.34-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!

--
Watson Sato
Security Technologies | Red Hat, Inc
___
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org

SCAP Security Guide 0.1.33

[Watson Yuuma Sato]

Hello folks,

We have the pleasure to announce that SCAP Security Guide version 0.1.33
has been released.

Highlights of this release:

* DISA RHEL7 STIG profile alignment improved
* Introduction of remediation roles
* RPM and DEB test packages are built by CMake with CPack
* Lots of remediation fixes

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.33

Full changelog at:
* 
https://github.com/OpenSCAP/scap-security-guide/issues?q=milestone%3A0.1.33


Zip archives with pre-built benchmarks in DataStream form:
* 
https://github.com/OpenSCAP/scap-security-guide/releases/download/v0.1.33/scap-security-guide-0.1.33.zip 


(Zip archive using OVAL-5.11.1 language version)
* 
https://github.com/OpenSCAP/scap-security-guide/releases/download/v0.1.33/scap-security-guide-0.1.33-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!

--
Watson Sato
Security Technologies | Red Hat, Inc
___
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org

Re: OVAL+remediations for SELinux booleans

[Watson Yuuma Sato]

On 20/04/17 22:28, Shawn Wells wrote:

We have several sebool XCCDFs in shared/xccdf/system/selinux, however it
appears OVAL and remediations are not being generated.

For example from shared/xccdf/system/selinux.xml :


..



Which has an entry in the selinux_booleans.csv file:

$ grep -rin fips_mode shared/templates/selinux_booleans.csv
52:fips_mode,enable

After running a make, no OVAL gets attached in the datastream:

 
.
   https://nvd.nist.gov/cce/index.cfm;>CCE-80418-7
   http://scap.nist.gov/schema/ocil/2;>
 
   
 

So I cleaned out my build directory and re-ran 'make -j4 rhel7' and saw
some errors:

WARNING: OVAL check 'sebool_abrt_upload_watch_anon_write' was not
found, removing  element from the XCCDF rule.
WARNING: OVAL check 'sebool_antivirus_can_scan_system' was not found,
removing  element from the XCCDF rule.
WARNING: OVAL check 'sebool_auditadm_exec_content' was not found,
removing  element from the XCCDF rule.
WARNING: OVAL check 'sebool_cron_userdomain_transition' was not found,
removing  element from the XCCDF rule.

Is there a reason the seboolean checks aren't getting build into
datastreams?
The template and script that generates the OVAL checks for SELinux 
booleans are out of the build system, generate-from-templates.py is not 
using them.

Any reason why it was left out?

I'll give it a look and try to add it to the build system.

___
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org



--
Watson Sato
Security Technologies | Red Hat, Inc
___
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org

Re: VMs, containers vs. bare-metal machines in SSG

[Watson Yuuma Sato]

On 19/01/17 18:40, Watson Yuuma Sato wrote:

On 20/10/16 20:30, Martin Preisler wrote:

We have had increasing requests to scan containers and VM storage images
for compliance. In those use-cases a lot of our rules don't make sense.
For example separate partition for /tmp isn't really applicable to 
containers.


I thought about how we can deal with this in SSG. We have several 
options:


1) Separate benchmark and datastreams for containers and VM storage 
images:

ssg-rhel7-ds.xml and ssg-rhel7-container-ds.xml

2) Separate profile for containers and VM storage images:
pci-dss and pci-dss-container

3) Use applicability and CPE platforms to distinguish between what is 
being
scanned. That allows us to use the same pci-dss profile for 
bare-metal, VM,

VM storage image and container image.

Right now I am leaning towards 3) because it "unlocks" the feature
transparently to our users. There is nothing extra they have to study to
start scanning containers. The downside is that we will have to add 
"fake"
CPE IDs for platforms like "vm-storage" and "container". Rules that 
apply

to everything will have no  element in them. Rules that apply
to just containers will have something like:



or



Official NIST CPE ID dictionary has these related CPE IDs
cpe:/a:redhat:docker:1.5.0-27
cpe:/a:linuxcontainers:lxc:0.5.0
cpe:/a:redhat:libvirt:1.2.7

Not sure we want to go with any of those though. I would like to keep it
container and VM tech agnostic.

Before I start hacking this I would like to hear your thoughts.



Hi folks,

Following idea 3, here is a WIP PR to tackle this matter.
https://github.com/OpenSCAP/scap-security-guide/pull/1645

The PR is in a state good for review.

Changes are not intended to be extensive and complete, the aim is to get 
the ball
rolling and check whether we are in the same page regarding how to mark 
the rules.


Thank you.


Please, share your concerns...

--
Watson Sato
Security Technologies | Red Hat, Inc




--
Watson Sato
Security Technologies | Red Hat, Inc
___
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org

Re: VMs, containers vs. bare-metal machines in SSG

[Watson Yuuma Sato]

On 20/10/16 20:30, Martin Preisler wrote:

We have had increasing requests to scan containers and VM storage images
for compliance. In those use-cases a lot of our rules don't make sense.
For example separate partition for /tmp isn't really applicable to containers.

I thought about how we can deal with this in SSG. We have several options:

1) Separate benchmark and datastreams for containers and VM storage images:
ssg-rhel7-ds.xml and ssg-rhel7-container-ds.xml

2) Separate profile for containers and VM storage images:
pci-dss and pci-dss-container

3) Use applicability and CPE platforms to distinguish between what is being
scanned. That allows us to use the same pci-dss profile for bare-metal, VM,
VM storage image and container image.

Right now I am leaning towards 3) because it "unlocks" the feature
transparently to our users. There is nothing extra they have to study to
start scanning containers. The downside is that we will have to add "fake"
CPE IDs for platforms like "vm-storage" and "container". Rules that apply
to everything will have no  element in them. Rules that apply
to just containers will have something like:



or



Official NIST CPE ID dictionary has these related CPE IDs
cpe:/a:redhat:docker:1.5.0-27
cpe:/a:linuxcontainers:lxc:0.5.0
cpe:/a:redhat:libvirt:1.2.7

Not sure we want to go with any of those though. I would like to keep it
container and VM tech agnostic.

Before I start hacking this I would like to hear your thoughts.



Hi folks,

Following idea 3, here is a WIP PR to tackle this matter.
https://github.com/OpenSCAP/scap-security-guide/pull/1645

Please, share your concerns...

--
Watson Sato
Security Technologies | Red Hat, Inc
___
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org

SCAP Workbench 1.1.4

[Watson Yuuma Sato]

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/openscap557e16a) and scap-security-guide
version 0.1.31 (OpenSCAP/scap-security-guidefeb6160).

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 



--
Watson Sato
Security Technologies | Red Hat, Inc.

___
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org

SCAP Security Guide 0.1.31

[Watson Yuuma Sato]

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)
___
scap-security-guide mailing list -- scap-security-guide@lists.fedorahosted.org
To unsubscribe send an email to scap-security-guide-le...@lists.fedorahosted.org