Configuring and Applying SCAP Policies During Installation

Over the past few decades we have seen great advancements in the IT industry.  In fact, the industry itself seems to be growing at an increasingly faster pace.  However, as the industry grows so to does its evil twin – the figurative sum of all threats to IT security.

On the bright side, along with a steady stream of ever-evolving security issues and threats, there has also been a great effort to mitigate and, when possible, entirely eliminate such threats.  This is accomplished by either fixing the bugs that allowed these issues and threats to exist (in the first place) or by fixing the configurations and protectionary mechanisms of systems so as to prevent attackers from finding success.

As 2015 has been no stranger to news stories about data leakages, various security flaws, and new types of malware – one could easily conclude that “the dark side” is winning this seemingly eternal race.

However, taking the complexity of today’s IT solutions into account, I would say that the situation is not as bad as it seems; in fact, things are almost in a surprisingly fair state.  While my own opinion is, of course, highly subjective – I posit that a vast majority of all IT security issues are not a symptom of severe design flaws or of “new-to-the-world” ingenious attacks.  Rather, contemporary security issues are more usually catalyzed by somebody not following a given set of well-known policies that could (proactively) prevent such issues from happening (read: human/user error).

Be it developers not following best practices for writing secure code, administrators not following policies for the secure configuration of servers, or users not following policies for secure passwords and/or not embracing defensive behaviour when using IT assets – there is a clear and common theme.  As it turns out, one of the biggest problems is that while (security) policies are defined they are often ignored and thus in many environments such policies are not only recommended – they are strictly required.

With a mind to address these issues, the Security Content Automation Protocol (SCAP) was created. SCAP is a set of standards – defining formats of files that can be used for definitions and (semi-)automated evaluation, application, and checking of security policies.  Many organizations and institutions use SCAP to define policies for their IT infrastructure. Examples are the Payment Card Industry Data Security Standard (PCI DSS) and the United States Government Configuration Baseline (USGCB) specifications targeting protection of cardholder data and systems deployed across the federal agencies, respectively.  Many such specifications (inclusive of the aforementioned two) are available for free and can be tailored and applied to any systems being deployed for nearly any purpose.

That said, despite the relatively “low barriers to entry”, use of these standards is far from pervasive as administrators often lack time and/or resources and, while unfortunate, security risks are often times underestimated.

It’s also worth noting that while not a problem today, there was once an issue where tools (for processing of such security content) were scarce.  Happily, this issue is no longer of concern as free and open-source solutions now exist – for example, administrators might consider the OpenSCAP project.

To facilitate SCAP content processing engineers at Red Hat have been working on tools and libraries that allow users to easily inspect systems, tailor and apply policies, and to conduct periodic evaluations of security content.  This functionality is integrated into Red Hat’s products and solutions (e.g. Red Hat Enterprise Linux). The most recent result of the integration work is the OSCAP Anaconda Add-on (available now with the beta release of Red Hat Enterprise LInux 7.2).  This additional functionally integrates the tools and libraries from the OpenSCAP project with the Anaconda OS installer and brings SCAP policy application to the OS installation process.

Why merge SCAP policy application into the installation process?  There are, in fact, many reasons why such integration into the installation process is useful.  These reasons range from technical reasons (e.g. some policies define restrictions for partitioning and storage configuration and some policies have to be applied before the system is used for the first time) to reasons of convenience (e.g. installations can be automated with kickstart files including the SCAP policy application) to reasons related to (simple) awareness of best practices (e.g. the installation becomes a compulsory step that all administrators have to take and this gives them an easy way to choose a security policy / profile for their newly deployed system – essentially it reminds them that they should always do so and teaches them that it’s no longer “too complicated to bother with”).

With the introduction of Red Hat Enterprise Linux 7 the installer, Anaconda, was redesigned so as to feature heightened extensibility.  The beta release of Red Hat Enterprise Linux 7.2 makes use of this extensibility by integrating the OSCAP Anaconda Add-on into the installation process.  It brings support for a special %addon org_fedora_oscap kickstart section and a new GUI screen (the so called “spoke“) that can be used the specify security policies (SCAP content + profile IDs) which are then applied during the installation process in two phases, namely: 1) by first checking the desired configuration of the newly installed system and then 2) checking of the newly installed system itself.  In both of these phases, automatic fixes are applied where possible and results of the content application are reported. The pre-installation content application makes use of an extension to the SCAP format by means of special pre-installation rules (described in the documentation) tagged with a special identifier that marks them as restrictions that need to be applied before the system is installed. Unless the configuration meets all the requirements as specified by the policy – the system installation is stopped and the user is asked to fix the configuration or choose a different policy. The post-installation content application runs the oscap scanner in the remediation mode that applies fixes for unmet conditions as part of the system scan. The results of the scan are then stored in the installed system for the administrator to check and compare with results of future periodic scans.

oscap_anaconda_oneWith the beta release of Red Hat Enterprise Linux 7.2 – Security Policy is now a configurable option during installation.

Although this new Add-on can consume any SCAP content, many administrators don’t know where to find such content or they may have trouble tailoring the content for their particular system or use case. As is usual in the IT industry, standards and official documents are limping behind the real-world – a world full of the latest and greatest technologies – and the same applies to official security policies (being distributed in the SCAP format or in some other form). This is why Red Hat’s engineers contribute to the SCAP Security Guide project (SSG) which focuses on the development of SCAP content for various free and open-source projects.  Red Hat Enterprise Linux is one of those projects and with a generous amount of SCAP content available for Red Hat Enterprise Linux 5 and Red Hat Enterprise Linux 6, the project now focuses more and more on the development of SCAP content for Red Hat Enterprise Linux 7. Thus, the SSG content is a logical choice for the default SCAP content used by the OSCAP Anaconda Add-on. Users still have an easy way to use any other content, but by default the SSG content is loaded and one of its security profiles can be chosen for the newly installed system based on the
purpose and use case of the system.

oscap_anaconda_twoChoosing a profile using the new OSCAP Anaconda Add-on.

Summary

Security, by default, is something like the “Holy Grail” of all IT projects and technologies. Even though “absolute security” is practically impossible to achieve – it’s a great target and everyone with something (e.g. data) to protect should try to get as close as possible to. Red Hat Enterprise Linux is well-known for its security features and fast reaction to new security issues and threats. However, no matter how safe a given system is – a wrong configuration can create serious security flaws and provide attackers a way to misuse it. The OSCAP Anaconda Add-on introduced in this article tries to mitigate this issue by integrating the OpenSCAP toolset and the SCAP Security Guide content with the Anaconda installer – thereby providing an easy way to choose and apply security policies in one of the very first steps of system deployment — the OS installation.

Although the Add-on already provides quite a number of features – input from users is extremely important for us.  To this end, if you have a tip for a new feature or if you have any comments / thoughts / ideas about the current status of the Add-on, please let us know in the comments section (below).  Open source is about open collaboration so let’s help make the IT world more secure in an open and collaborative way!

One final note: the OSCAP Anaconda Add-on project started as a master thesis (supervised by Red Hat).  For those who are interested to learn more about SCAP, the Anaconda installer, or the integration of the two – feel free to read the full text of the master thesis by clicking here.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s