Skip to content

redhatrises/scap-security-guide

Β 
Β 

Folders and files

NameName
Last commit message
Last commit date

Latest commit

Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 
Β 

Repository files navigation

Welcome!

All Contributors

Release Nightly ZIP Status Nightly 5.10 ZIP Status Link-checker Status CentOS CI Status Travis CI Build Status Scrutinizer Code Quality Profile Statistics

Evaluation report sample

The purpose of this project is to create security policy content for various platforms -- Red Hat Enterprise Linux, Fedora, Ubuntu, Debian, ... -- as well as products -- Firefox, Chromium, JRE, ... We aim to make it as easy as possible to write new and maintain existing security content in all the commonly used formats.

We build security content in various formats

NIST logo Β  Β  Ansible logo Β  Β  Bash logo

"SCAP content" refers to documents in the XCCDF, OVAL and Source DataStream formats. These documents can be presented in different forms and by different organizations to meet their security automation and technical implementation needs. For general use, we recommend Source DataStreams because they contain all the data you need to evaluate and put machines into compliance. The datastreams are part of our release ZIP archives.

"Ansible content" refers to Ansible playbooks generated from security profiles. These can be used both in check-mode to evaluate compliance, as well as run-mode to put machines into compliance. We publish these on Ansible Galaxy as well as in release ZIP archives.

"Bash fix files" refers to Bash scripts generated from security profiles. These are meant to be run on machines to put them into compliance. We recommend using other formats but understand that for some deployment scenarios bash is the only option.

Why?

We want multiple organizations to be able to efficiently develop security content. By taking advantage of the powerful build system of this project, we avoid as much redundancy as possible.

The build system combines the easy-to-edit YAML rule files with OVAL checks, Ansible task snippets, Bash fixes, and other files. Templating is provided at every step to avoid boilerplate. Security identifiers (CCE, NIST ID, STIG, ...) appear in all of our output formats but are all sourced from the YAML rule files.

We understand that depending on your organization's needs you may need to use a specific security content format. We let you choose.

Build system schema


We use an OpenControl-inspired YAML rule format for input. Write once and generate security content in XCCDF, Ansible, and others.

prodtype: rhel7

title: 'Configure The Number of Allowed Simultaneous Requests'

description: |-
    The <tt>MaxKeepAliveRequests</tt> directive should be set and configured to
    <sub idref="var_max_keepalive_requests" /> or greater by setting the following
    in <tt>/etc/httpd/conf/httpd.conf</tt>:
    <pre>MaxKeepAliveRequests <sub idref="var_max_keepalive_requests" /></pre>

rationale: |-
    Resource exhaustion can occur when an unlimited number of concurrent requests
    are allowed on a web site, facilitating a denial of service attack. Mitigating
    this kind of attack will include limiting the number of concurrent HTTP/HTTPS
    requests per IP address and may include, where feasible, limiting parameter
    values associated with keepalive, (i.e., a parameter used to limit the amount of
    time a connection may be inactive).

severity: medium

identifiers:
    cce: "80551-5"

Scan targets

Our security content can be used to scan bare-metal machines, virtual machines, virtual machine images (qcow2 and others), containers (including Docker), and container images.

We use platform checks to detect whether we should or should not evaluate some of the rules. For example: separate partition checks make perfect sense on bare-metal machines but go against recommended practices on containers.

Installation

From packages

The preferred method of installation is via the package manager of your distribution. On Red Hat Enterprise Linux and Fedora you can use:

yum install scap-security-guide

On Debian (sid), you can use:

apt install ssg-debian  # for Debian guides
apt install ssg-debderived  # for Debian-based distributions (e.g. Ubuntu) guides
apt install ssg-nondebian  # for other distributions guides (RHEL, Fedora, etc.)
apt install ssg-applications  # for application-oriented guides (Firefox, JBoss, etc.)

From release ZIP files

Download pre-built SSG zip archive from the release page. Each zip file is an archive with ready-made SCAP source datastreams.

From COPR

We maintain a COPR repository that provides unofficial builds of latest versions of openscap, scap-security-guide, scap-workbench, and openscap-daemon. The packages are suitable for use on Red Hat Enterprise Linux 6, 7 and 8 and CentOS 6, 7 and 8.

See https://copr.fedorainfracloud.org/coprs/openscapmaint/openscap-latest/ for detailed instructions.

From source

If ComplianceAsCode is not packaged in your distribution (it may be present there as scap-security-guide package), or if the version that is packaged is too old, you need to build the content yourself and install it via make install. Please see the Developer Guide document for more info. We also recommend opening an issue on that distributions bug tracker to voice interest.

Usage

We assume you have installed ComplianceAsCode system-wide into a standard location from current upstream sources as instructed in the previous section.

There are several ways to consume ComplianceAsCode content, we will only go through a few of them here.

oscap tool

The oscap tool is a low-level command line interface that comes from the OpenSCAP project. It can be used to scan the local machine.

oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_rht-ccp --results-arf arf.xml --report report.html --oval-results /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml

After evaluation, the arf.xml file will contain all results in a reusable Result DataStream format, report.html will contain a human readable report that can be opened in a browser.

Replace the profile with other profile of your choice, you can display all possible choices using:

oscap info /usr/share/xml/scap/ssg/content/ssg-rhel7-ds.xml

Please see the OpenSCAP for more info.

SCAP Workbench

The SCAP Workbench is a graphical user interface for SCAP evaluation and customization. It is suitable for scanning a single machine, either local or remote (via SSH). New versions of SCAP Workbench have SSG integration and will automatically offer it when the application is started.

Please see the SCAP Workbench for more info.

oscap-ssh tool

oscap-ssh comes bundled with OpenSCAP 1.2.3 and later. It allows scanning a remote machine via SSH with an interface resembling the oscap tool.

The following command evaluates a machine with IP 192.168.1.123 with content stored on the local machine. Keep in mind that oscap has to be installed on the remote machine but the SSG content doesn't need to be.

oscap-ssh root@192.168.1.123 22 xccdf eval --profile xccdf_org.ssgproject.content_profile_usgcb-rhel6-server --results-arf arf.xml --report report.html /usr/share/xml/scap/ssg/content/ssg-rhel6-ds.xml

Ansible

To see a list of available Ansible Playbooks, run:

# ls /usr/share/scap-security-guide/ansible/
...
rhel6-playbook-standard.yml
rhel6-playbook-stig-rhel6-server-upstream.yml
rhel6-playbook-usgcb-rhel6-server.yml
rhel7-playbook-C2S.yml
rhel7-playbook-cjis-rhel7-server.yml
rhel7-playbook-common.yml
rhel7-playbook-docker-host.yml
rhel7-playbook-cui.yml
...

These Ansible Playbooks are generated from SCAP profiles available for the products.

To apply the playbook on your local machine run: (THIS WILL CHANGE CONFIGURATION OF THE MACHINE!)

ansible-playbook -i "localhost," -c local /usr/share/scap-security-guide/ansible/rhel7-playbook-rht-ccp.yml

Each of the Ansible Playbooks contains instructions on how to deploy them. Here is a snippet of the instructions:

...
# This file was generated by OpenSCAP 1.2.16 using:
#   $ oscap xccdf generate fix --profile rht-ccp --template urn:xccdf:fix:script:ansible sds.xml
#
# This script is generated from an OpenSCAP profile without preliminary evaluation.
# It attempts to fix every selected rule, even if the system is already compliant.
#
# How to apply this remediation role:
# $ ansible-playbook -i "192.168.1.155," playbook.yml
# $ ansible-playbook -i inventory.ini playbook.yml
...

Bash

To see a list of available Bash scripts, run:

# ls /usr/share/scap-security-guide/bash/
...
rhel7-script-hipaa.sh
rhel7-script-ospp.sh
rhel7-script-pci-dss.sh
...

These Bash scripts are generated from SCAP profiles available for the products. Similar to Ansible Playbooks, each of the Bash scripts contain instructions on how to deploy them.

Support

The SSG mailing list can be found at https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide.

If you encounter issues with OpenSCAP or SCAP Workbench, use https://www.redhat.com/mailman/listinfo/open-scap-list

You can also join the #openscap IRC channel on chat.freenode.net.

A little bit of history

This project started in 2011 as a collaboration between government agencies and commercial operating system vendors. The original name was SCAP Security Guide. The original scope was to create SCAP datastreams. Over time, it grew into the biggest open-source beyond-SCAP content project.

The next few years saw the introduction of not just government-specific security profiles but also commercial, such as PCI-DSS.

Later, the industry starts moving towards different security content formats, such as Ansible, Puppet, and Chef InSpec. The community reacted by evolving the tooling and helped transform SSG into a more general-purpose security content project. This change happened over time in 2017 and 2018. In September 2018, we decided to change the name of the project to avoid confusion.

We envision that the future will be format-agnostic. That's why opted for an abstraction instead of using XCCDF for the input format.

Further reading

The SSG homepage is https://www.open-scap.org/security-policies/scap-security-guide/.

Contributors ✨

Thanks goes to these wonderful people (emoji key):


Gabe Alford

πŸ’» πŸ› πŸ“ πŸ’Ό πŸ–‹ πŸ“– 🎨 πŸ’‘ πŸ“‹ πŸ” πŸ€” πŸš‡ 🚧 πŸ“¦ πŸ“† πŸ’¬ πŸ‘€ πŸ”§ ⚠️ βœ… πŸ“’ πŸ““ πŸ“Ή

Ε imon LukaΕ‘Γ­k

πŸ’» ⚠️ πŸ› πŸ“ πŸ–‹ πŸ“– πŸ’‘ πŸ€” πŸš‡ 🚧 πŸ“¦ πŸ”Œ πŸ’¬ πŸ‘€ πŸ”§ βœ… πŸ“’ πŸ““ πŸ“Ή

Ilya Okomin

πŸ’»

lsteinke

πŸ’»

Alexander Bergmann

πŸ’»

Jayson Cofell

πŸ’»

Watson Yuuma Sato

πŸ’»

Jan Lieskovsky

πŸ’» πŸ› πŸ–‹ πŸ“ πŸ’‘ πŸ“‹ πŸ€” 🚧 πŸ“¦ πŸ‘€ πŸ”§ πŸ“’

Jan Černý

πŸ› πŸ“ πŸ’» πŸ–‹ πŸ“– πŸ’‘ πŸ€” 🚧 πŸ“¦ πŸ’¬ πŸ‘€ πŸ”§ ⚠️ πŸ“’

jeffblank

πŸ› πŸ’Ό πŸ’» πŸ–‹ πŸ“– πŸ’‘ πŸ“‹ πŸ’΅ πŸ” πŸ“’ βœ… πŸ“Ή

Alexander Scheel

πŸ’» πŸ“

MatΔ›j Týč

πŸ› πŸ“ πŸ’» πŸ–‹ πŸ“– πŸ’‘ πŸ“‹ πŸ€” 🚧 πŸ“¦ πŸ‘€ πŸ”§ ⚠️ βœ… πŸ“’

Shawn Wells

πŸ› πŸ“ πŸ’Ό πŸ’» πŸ–‹ πŸ“– πŸ’‘ πŸ“‹ πŸ’΅ πŸ” πŸ€” 🚧 πŸ“† πŸ’¬ πŸ‘€ πŸ”§ ⚠️ βœ… πŸ“’ πŸ““ πŸ“Ή

Gabriel Gaspar Becker

πŸ› πŸ’» πŸ–‹ πŸ“– 🚧 πŸ’¬ πŸ‘€ πŸ”§ ⚠️

vojtapolasek

πŸ’» ⚠️ πŸ› πŸ‘€ πŸ’¬

Marek Haičman

πŸ› πŸ’» πŸ“† ⚠️ πŸ“’

Jan Pazdziora

πŸ’»

Matus Marhefka

πŸ’» ⚠️ πŸ‘€ πŸ’¬

Maura Dailey

πŸ’»

Philippe Thierry

πŸ’»

Milan Lysonek

πŸ’» ⚠️

Robert McAllister

πŸ’»

Jakub Hrozek

πŸ’»

Xirui Yang

πŸ’»

Thomas SjΓΆgren

πŸ’»

maltek

πŸ’»

Keith Jackson

πŸ’»

MollyJoBault

πŸ’»

Jon Thompson

πŸ’»

Jean-Baptiste DONNETTE

πŸ’»

Juan Osorio Robles

πŸ’» ⚠️ πŸ€” πŸ‘€ πŸ“’

Eric Christensen

πŸ’»

Olivier Bonhomme

πŸ’»

Martin Preisler

πŸ› πŸ“ πŸ’Ό πŸ’» πŸ–‹ πŸ“– 🎨 πŸ’‘ πŸ“‹ πŸ” πŸ€” πŸš‡ 🚧 πŸ“¦ πŸ“† πŸ’¬ πŸ‘€ πŸ”§ ⚠️ βœ… πŸ“’ πŸ““ πŸ“Ή

lukek1

πŸ’»

Dave Smith

πŸ› πŸ“ πŸ’Ό πŸ’» πŸ–‹ πŸ“– 🎨 πŸ’‘ πŸ“‹ πŸ” πŸ€” πŸš‡ 🚧 πŸ“¦ πŸ“† πŸ’¬ πŸ‘€ πŸ”§ ⚠️ βœ… πŸ“’ πŸ““ πŸ“Ή

Trey Henefield

πŸ’» ⚠️

Pat Riehecky

πŸ’»

Lucy Kerner

πŸ“ πŸ’Ό πŸ“‹ πŸ” πŸ€” βœ… πŸ“’ πŸ“Ή

James Cassell

πŸ’»

Dominique Blaze

πŸ’»

Justin Stephenson

πŸ’»

Evgeny Kolesnikov

πŸ’» πŸ€”

tedbrunell

πŸ’» πŸ’Ό πŸ” βœ… πŸ“’ πŸ“Ή

Mike Palmiotto

πŸ’» ⚠️ πŸ”§ πŸ“¦

Chris Reynolds

πŸ’»

dehuo0

πŸ’»

brianmillett

πŸ’»

Gautam Satish

πŸ› πŸ’»

cyarbrough76

πŸ’»

lfisher47

πŸ’»

Khary Mendez

πŸ’» πŸ“’

Alijohn Ghassemlouei

πŸ’»

Mixer9

πŸ’»

Joshua Roys

πŸ’»

hex2a

πŸ’»

Axel Nennker

πŸ’»

Paul

πŸ’»

Kenneth Peeples

πŸ’»

Kenyon Ralph

πŸ’»

Chuck Atkins

πŸ’»

Chris Ruffalo

πŸ’»

Nick Carboni

πŸ’»

Caitlin

πŸ’»

jiatianzhen

πŸ’»

rwilmoth

πŸ’» πŸ€” πŸ“’ πŸ’Ό

rprice

πŸ’» πŸ“’ πŸ’Ό

Robin Price II

πŸ’» πŸ“’ πŸ“Ή βœ…

Nathan Kinder

πŸ’» πŸ’Ό

neo-aeon

πŸ’»

k-stailey

πŸ’»

Jesse Roland

πŸ’»

Stephan Joerrens

πŸ’»

cooper-ornl

πŸ’»

rodneymercer

πŸ’»

Joe Nall

πŸ’» ⚠️ πŸ›

agilmore2

πŸ’»

Jibzzz

πŸ’»

Steve Grubb

πŸ’»

shaneboulden

πŸ’» πŸ’Ό

sdunne

πŸ’» πŸ’Ό

Rick Renshaw

πŸ’»

Peter Vrabec

πŸ› πŸ“ πŸ’Ό πŸ’» πŸ” πŸ€” πŸ“† πŸ’¬ πŸ‘€ πŸ”§ ⚠️ βœ… πŸ“’ πŸ“Ή

Bryan Schneiders

πŸ’»

Orion Poplawski

πŸ’»

Matt Rogers

πŸ’»

mralph-rh

πŸ’»

Max P

πŸ’»

Joshua Glemza

πŸ’»

Frank lin Piat

πŸ’»

Derek Thurston

πŸ’» πŸ’Ό

dhanushkar-wso2

πŸ’»

VadimDor

πŸ’»

Firas AlShafei

πŸ’»

Yasir Imam

πŸ’» πŸ’Ό πŸ“’

RCHAYES

πŸ’»

Mark Shoger

πŸ’» πŸ’Ό

jstookey

πŸ’»

ghylock

πŸ’»

angystardust

πŸ’»

Klaas

πŸ’»

NoSLZZP

πŸ’» πŸ’Ό πŸ€”

Ajay Chenampara

πŸ’»

Kazuki Omo

πŸ’»

J. Alexander Jacocks

πŸ’» πŸ’Ό πŸ“’ πŸ“Ή βœ…

Greg Elin

πŸ’» πŸ“’ πŸ“Ή

Frank Caviggia

πŸ’»

Jared Hocutt

πŸ’Ό πŸ“ πŸ€” πŸ“’ πŸ“Ή

Brad

πŸ’Ό πŸ€” πŸ“’ πŸ“Ή βœ…

matmille

πŸ’Ό πŸ€” πŸ“’ βœ…

Jason Dudash

πŸ€” πŸ“’ βœ…

Donny Davis

πŸ€” πŸ“’ βœ…

Bill Hirsch

πŸ€” πŸ“’ βœ… πŸ“Ή

rlucente-se-jboss

πŸ’» πŸ€” πŸ“’ βœ…

Lee Kinser

πŸ’» πŸ€” πŸ“’ βœ…

Michal Ε rubaΕ™

πŸ’»

Lucas Yamanishi

πŸ’»

pekramp

πŸ’»

Nick

πŸ’»

Christopher Lee

πŸ’»

anixon-rh

πŸ’»

This project follows the all-contributors specification. Contributions of any kind welcome!

About

Baseline compliance content in SCAP formats

Resources

License

Stars

Watchers

Forks

Packages

No packages published

Languages

  • Python 43.0%
  • Shell 28.3%
  • XSLT 14.8%
  • CMake 6.0%
  • HTML 6.0%
  • Go 1.8%
  • Other 0.1%