path: root/xml/SCAP/gentoo-xccdf.xml

<?xml version="1.0" encoding="UTF-8"?>
<Benchmark xmlns="http://checklists.nist.gov/xccdf/1.2" xmlns:h="http://www.w3.org/1999/xhtml" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" id="xccdf_org.gentoo.dev.swift_benchmark_gentoo-20130917-1" xsi:schemaLocation="http://checklists.nist.gov/xccdf/1.2 xccdf-1.2.xsd" resolved="0">
  <status date="2013-12-20">draft</status>
  <title>Gentoo Security Benchmark</title>
  <description>
    This benchmarks helps people in improving their system configuration to be
    more resilient against attacks and vulnerabilities.
  </description>
  <platform idref="cpe:/o:gentoo:linux"/>
  <version>20131220.1</version>
  <model system="urn:xccdf:scoring:default" />
  <model system="urn:xccdf:scoring:flat" />
  <model system="urn:xccdf:scoring:flat-unweighted" />
  <Profile id="xccdf_org.gentoo.dev.swift_profile_intensive" extends="xccdf_org.gentoo.dev.swift_profile_default">
    <title>Intensive validation profile</title>
    <description>
      This profile extends the default server profile by including tests that 
      are more intensive to run on a system. Tests such as full file system
      scans to find world-writable files or directories have an otherwise too
      large impact on the performance of a server. Tests include scripted
      validationn.
    </description>
  </Profile>
  <Profile id="xccdf_org.gentoo.dev.swift_profile_intensive-oval" extends="xccdf_org.gentoo.dev.swift_profile_default-oval">
    <title>Intensive validation profile (non-scripted)</title>
    <description>
      This profile extends the default server profile by including tests that 
      are more intensive to run on a system. Tests such as full file system
      scans to find world-writable files or directories have an otherwise too
      large impact on the performance of a server. Tests do not include
      scripted validation.
    </description>
  </Profile>
  <Profile id="xccdf_org.gentoo.dev.swift_profile_default-oval">
    <title>Default server setup settings (non-scripted)</title>
    <description>
      In this profile, we verify common settings for Gentoo Linux
      configurations. The tests that are enabled in this profile can be ran
      without visibly impacting the performance of the system. No scripted
      checks are executed.
    </description>
    <!-- The /tmp location is a separate file system -->
    <select idref="xccdf_org.gentoo.dev.swift_rule_partition-tmp" selected="true" />
    <!-- The /var location is a separate file system -->
    <select idref="xccdf_org.gentoo.dev.swift_rule_partition-var" selected="true" />
    <!-- The /var/log location is a separate file system -->
    <select idref="xccdf_org.gentoo.dev.swift_rule_partition-varlog" selected="true" />
    <!-- The /var/log/audit location is a separate file system -->
    <select idref="xccdf_org.gentoo.dev.swift_rule_partition-varlogaudit" selected="true" />
    <!-- The /home location is a separate file system -->
    <select idref="xccdf_org.gentoo.dev.swift_rule_partition-home" selected="true" />
    <!-- The /var/tmp location is a separate file system -->
    <select idref="xccdf_org.gentoo.dev.swift_rule_partition-vartmp" selected="true" />
    <!-- The /var partition is mounted with nodev -->
    <select idref="xccdf_org.gentoo.dev.swift_rule_partition-var-nodev" selected="true" />
    <!-- The /var/log partition is mounted with nodev -->
    <select idref="xccdf_org.gentoo.dev.swift_rule_partition-varlog-nodev" selected="true" />
    <!-- The /var/log/audit partition is mounted with nodev -->
    <select idref="xccdf_org.gentoo.dev.swift_rule_partition-varlogaudit-nodev" selected="true" />
    <!-- The /home partition is mounted with nodev -->
    <select idref="xccdf_org.gentoo.dev.swift_rule_partition-home-nodev" selected="true" />
    <!-- The /tmp partition is mounted with nodev -->
    <select idref="xccdf_org.gentoo.dev.swift_rule_partition-tmp-nodev" selected="true" />
    <!-- The /tmp partition is mounted with nosuid -->
    <select idref="xccdf_org.gentoo.dev.swift_rule_partition-tmp-nosuid" selected="true" />
    <!-- The /home partition is mounted with nosuid -->
    <select idref="xccdf_org.gentoo.dev.swift_rule_partition-home-nosuid" selected="true" />
    <!-- The /dev/shm partition is mounted with nosuid -->
    <select idref="xccdf_org.gentoo.dev.swift_rule_partition-devshm-nosuid" selected="true" />
    <!-- The /tmp partition is mounted with noexec -->
    <select idref="xccdf_org.gentoo.dev.swift_rule_partition-tmp-noexec" selected="true" />
     <!-- The /dev/shm partition is mounted with noexec -->
    <select idref="xccdf_org.gentoo.dev.swift_rule_partition-devshm-noexec" selected="true" />
    <!-- Kernel quota support must be enabled -->
    <select idref="xccdf_org.gentoo.dev.swift_rule_kernel-quota" selected="true" />
    <!-- No telnetd process is running -->
    <select idref="xccdf_org.gentoo.dev.swift_rule_telnetd-notrunning" selected="true" />
    <!-- No ftpd process is running -->
    <select idref="xccdf_org.gentoo.dev.swift_rule_ftpd-notrunning" selected="true" />
    <!-- sulogin is used as shell for single user boot (definition /etc/rc.conf) -->
    <select idref="xccdf_org.gentoo.dev.swift_rule_rcconf-sulogin" selected="true" />
    <!-- sulogin is used as shell for single user boot (definition /etc/inittab) -->
    <select idref="xccdf_org.gentoo.dev.swift_rule_inittab-sulogin" selected="true" />
    <!-- Verify that /etc/hosts.allow exists -->
    <select idref="xccdf_org.gentoo.dev.swift_rule_hostsallow-exists" selected="true" />
    <!-- Verify that /etc/at/at.allow exists -->
    <select idref="xccdf_org.gentoo.dev.swift_rule_atallow-exists" selected="true" />
  </Profile>
  <Profile id="xccdf_org.gentoo.dev.swift_profile_default" extends="xccdf_org.gentoo.dev.swift_profile_default-oval">
    <title>Default server setup settings</title>
    <description>
      In this profile, common settings for Gentoo Linux configurations are validated. 
      The tests can be ran without visibly impacting the performance of the system, and
      also includes the scripted evaluation checks (SCE).
    </description>
    <!-- The hardened toolchain must be installated and used -->
    <select idref="xccdf_org.gentoo.dev.swift_rule_installation-toolchain-hardened" selected="true" />
  </Profile>
  <Group id="xccdf_org.gentoo.dev.swift_group_intro">
    <title>Introduction</title>
    <description>
      <h:p>
      Since years, Gentoo Linux has a Gentoo Security Handbook
      which provides a good insight in secure system
      configuration for a Gentoo systems. Although this is important, an
      improved method for describing and tuning a systems' security state has
      emerged: SCAP, or the <h:em>Security Content Automation Protocol</h:em>.
      </h:p>
      <h:p>
      As such, this benchmark is an update on the security
      handbook, including both the in-depth explanation of settings as well as
      the means to validate if a system complies with this or not. Now, during
      the development of this benchmark document, not include all
      information from the Gentoo Security Handbook is included as some of the
      settings are specific to a service that is not all that default on a
      Gentoo Linux system or sufficiently separate that can benefit other
      distributions as well. Although these settings are important as well, it is
      best done in separate benchmarks for those services instead.
      </h:p>
      <h:p>
      Where applicable, this benchmark will refer to a different hardening guide
      for specific purposes (such as the Hardening OpenSSH benchmark).
      </h:p>
    </description>
    <reference href="http://www.gentoo.org/doc/en/security/security-handbook.xml">Gentoo
    Security Handbook</reference>
    <Group id="xccdf_org.gentoo.dev.swift_group_intro-security">
      <title>This is no security policy</title>
      <description>
        <h:p>
        It is <h:em>very important</h:em> to realize that this document is not a
        policy. There is no obligation to follow this to make a secure system
        nor should everything in this document be agreed upon. This document is
        a set of common best practices with the explanation (why is it a best practice)
        and method (how to implement the best practice).
        </h:p>
        <h:p>
        The purpose of this document is to guide readers in their quest to hardening
        their systems.  It will provide pointers that could help in deciding
        particular configuration settings and will do this hopefully using
        sufficient background information to allow readers to make a good choice.
	</h:p>
	<h:p>
        Readers might find settings they don't agree with. That's fine, but
        if there is disagreement about <h:em>why</h:em> it is documented, we would
        like to hear it so we can update the guide accordingly.
	</h:p>
      </description>
    </Group>
    <Group id="xccdf_org.gentoo.dev.swift_group_intro-scap">
      <title>A little more about SCAP and OVAL</title>
      <description>
        <h:p>
        Within SCAP, NIST has defined some new standards of which XCCDF and OVAL
        are notably important in light of this guide.
	</h:p>
        <h:ul>
          <h:li>
            XCCDF (Extensible Configuration Checklist Description Format) is
            a specification language for writing security checklists and benchmarks
          </h:li>
          <h:li>
            OVAL (Open Vulnerability and Assessment Language) is a standard to describe
            and validate system settings
          </h:li>
        </h:ul>
        <h:p>
        Thanks to the OVAL and XCCDF standards, a security engineer can now describe
        how the state of a system should be configured, how this can be checked
        automatically and even report on these settings. Furthermore, within the
        description, the engineer can make "profiles" of different states (such as
        a profile for a workstation, server (generic), webserver, LDAP server,
        ...) and reusing the states (rules) identified in a more global scope.
	</h:p>
      </description>
    </Group>
    <Group id="xccdf_org.gentoo.dev.swift_group_intro-using">
      <title>Using this guide</title>
      <description>
        <h:p>
        This guide is generated from SCAP content (more specifically, the XCCDF document)
        using <h:b>openscap</h:b>, a free software implementation for handling SCAP content.
        Within Gentoo, the package <h:code>app-forensics/openscap</h:code> provides the tools,
        and the following command is used to generate the HTML output:
	</h:p>
        <h:pre>
# <h:b>oscap xccdf generate guide gentoo-xccdf.xml &gt; output.html</h:b></h:pre>
	<h:p>
        Secondly, together with this XCCDF XML, an OVAL XML file is made available.
        The two files combined allow OVAL interpreters to automatically validate
        various settings as documented in the benchmark.
	</h:p>
	<h:p>
	Finally, if certain tests are not available in OVAL yet, scripts are provided
	that can be executed through the SCE (Script Check Engine) support in openscap.
	As scripts are not guaranteed to have no impact on the system (or leave traces),
	<h:code>-oval</h:code> profiles are available that only enable the OVAL (and not SCE)
	checks.
	</h:p>
	<h:p>
        To validate the tests, the following commands can be used:
	</h:p>
        <h:pre>
# <h:b>export PROFILE="xccdf_org.gentoo.dev.swift_profile_default"</h:b>
# <h:b>oscap xccdf eval --profile ${PROFILE} gentoo-xccdf.xml</h:b></h:pre>
	<h:p>
        To generate a full report in HTML as well, use the next command:
	</h:p>
        <h:pre>
# <h:b>oscap xccdf eval --profile ${PROFILE} --results xccdf-results.xml \
  --report report.html gentoo-xccdf.xml</h:b></h:pre>
	<h:p>
        Finally, this benchmark will suggest some settings that do not reflect the
        will of the reader. That is perfectly fine - even more, some settings might even
        raise eyebrows left and right. This document will explain the reasoning behind
        the settings but deviations are always possible. If that is the case,
        disable the rules in the XCCDF document or, better yet, create a new profile
        and only refer to the tests that are required.
	</h:p>
      </description>
    </Group>
    <Group id="xccdf_org.gentoo.dev.swift_group_intro-profiles">
      <title>Available XCCDF Profiles</title>
      <description>
        <h:p>
        As mentioned earlier, the XCCDF document supports multiple profiles. For the time
        being, two profiles are defined:
	</h:p>
        <h:ul>
          <h:li>
            The <h:em>default</h:em> profile (xccdf_org.gentoo.dev.swift_profile_default) contains
            tests that are quick to validate
          </h:li>
	  <h:li>
	    The <h:em>default-oval</h:em> profile (xccdf_org.gentoo.dev.swift_profile_default-oval)
	    is like the default one, but does not call any other checker than OVAL
	    (so no scripts).
	  </h:li>
          <h:li>
            The <h:em>intensive</h:em> profile (xccdf_org.gentoo.dev.swift_profile_intensive)
            contains all tests, including those that take a while (for instance because they
            perform full file system scans)
          </h:li>
	  <h:li>
	    The <h:em>intensive-oval</h:em> profile (xccdf_org.gentoo.dev.swift_profile_intensive-oval)
	    is like the intensive one, but does not call any other checker than OVAL
	    (so no scripts).
	  </h:li>
        </h:ul>
	<h:p>
        Substitute the profile information in the commands above with the required profile.
	</h:p>
      </description>
    </Group>
    <Group id="xccdf_org.gentoo.dev.swift_group_intro-weights">
      <title>About the rule weights</title>
      <description>
        <h:p>
        Within this guide, weights are assigned to tests to give some importance to
        the rule (higher weight is more important) as well as a severity.
	</h:p>
	<h:p>
        The severity is one of the following:
	</h:p>
        <h:ul>
          <h:li>
            <h:em>high</h:em> constitutes a grave or critical problem. A rule with this severity
            <h:em>MUST</h:em> be tackled as it detected a misconfiguration that is easily
            exploitable and could lead to full system compromise.
          </h:li>
          <h:li>
            <h:em>medium</h:em> reflects a fairly serious problem. A rule with this severity
            <h:em>SHOULD</h:em> be tackled as it detected a misconfiguration that is easily
            exploitable.
          </h:li>
          <h:li>
            <h:em>low</h:em> reflects a non-serious problem. A rule with this severity
            has detected a misconfiguration but its influence on the overall system security
            is minor (if other compliance rules are followed).
          </h:li>
          <h:li>
            <h:em>info</h:em> reflects an informational rule. Failure to comply with this rule
            does not mean failure to comply with the document itself.
          </h:li>
        </h:ul>
	<h:p>
        It is important to understand though that rules with a low severity can still lead to 
        grave security problems if they are not met. Chaining of vulnerabilities or
        misconfiguration can still lead to full system compromise.
	</h:p>
	<h:p>
        For this reason, weights are added to rules as well. A higher weight has a more
        severe potential impact.
	</h:p>
	<h:p>
        Weights are the CVSS (or CCSS) score that is thought to be the case for a misconfiguration.
        They are calculated by NVD's CVSS calculator. Each rule is scored individually; a 
        "chain" of misconfigurations might lead to a significantly higher issue, but this would
        make it very hard to make proper scoring. 
	</h:p>
	<h:p>
        As an example, take the rule that says <h:code>/var</h:code> has to be on its own
        partition. The metrics we fill in in the calculator are currently based on the risk
        that the root file system is filled (no more free space), which can halt the system.
	</h:p>
        <h:ul>
          <h:li>
            The <h:em>related exploit range</h:em> (access vector) is "Local", because this is
            by itself not exploitable remotely - unless of course certain services are running
            that can fill up <h:code>/var</h:code>, but such assumptions are not taken.
          </h:li>
          <h:li>
            The <h:em>attack complexity</h:em> (access complexity) is "Low", as all that is
            needed is a local account and we can find the necessary ways to fill up
            <h:code>/var</h:code>.
          </h:li>
          <h:li>
            The <h:em>level of authentication needed</h:em> (authentication) is "Single"
            as the attacker needs one authentication step (local access) to exploit.
          </h:li>
          <h:li>
            The <h:em>confidentiality impact</h:em> is "None" (no data leakage)
          </h:li>
          <h:li>
            The <h:em>integrity impact</h:em> is "None" (no data manipulation)
          </h:li>
          <h:li>
            The <h:em>availability impact</h:em> is "Complete" (system crash or halt).
          </h:li>
        </h:ul>
	<h:p>
        This results in the CVSS base score of 4.6. The environmental score metrics and
        temporal score metrics are ignored as those are too specific for environments
        and organizations.
	</h:p>
      </description>
      <reference href="https://nvd.nist.gov/cvss.cfm?calculator&amp;version=2">NVD CVSS calculator</reference>
      <reference href="http://csrc.nist.gov/publications/nistir/ir7502/nistir-7502_CCSS.pdf">The Common Configuration Scoring System (PDF)</reference>
    </Group>
  </Group>
  <Group id="xccdf_org.gentoo.dev.swift_group_preinstallation">
    <title>Before startng</title>
    <description>
      Before starting to deploy Gentoo Linux and start hardening it, it is wise
      to take a step back and think about what to accomplish. Setting
      up a more secured Gentoo Linux isn't a goal, but a means to reach
      something. Most likely the system will become a Gentoo Linux powered server.
      What is this server for? Where will it be hosted? What services are scheduled to run
      on this operating system? Etc.
    </description>
    <Group id="xccdf_org.gentoo.dev.swift_group_preinstallation-architecturing">
      <title>Infrastructure architecturing</title>
      <description>
        <h:p>
        When considering the entire IT architecture, many architecturing
        frameworks exist to write down and further design infrastructure.
        There are very elaborate ones, like TOGAF (The Open Group Architecture
        Framework), but smaller ones exist as well.
	</h:p>
	<h:p>
        A well written and maintained infrastructure architecture helps to 
        position new services or consider the impact of changes on existing
        components.
	</h:p>
	<h:p>
        Security is about reducing risks, not about harassing people or making
        work for a system administrator harder. And reducing risks also means
        that a clear eye needs to be kept on the architecture and all its
        components. If there is no knowledge as to what is being integrated, where
        it is going to be installed or why, then hardening by itself will probably not
        do much to the secure state of the system.
	</h:p>
      </description>
    </Group>
    <Group id="xccdf_org.gentoo.dev.swift_group_preinstallation-requirements">
      <title>Mapping requirements</title>
      <description>
        <h:p>
        When designing a service, we need to take both functional and
        non-functional requirements into account. That does sound like
        overshooting for a simple server installation, but it is not. Is
        auditing considered? Where should the audit logs be sent to? What
        about authentication? Centrally managed, or manually set? And the server,
        will it only host a particular service, or will it provide several services?
	</h:p>
	<h:p>
        When hosting multiple services on the same server, make sure that the
        server is positioned within the network on an acceptable segment. It is
        not safe to host central LDAP infrastructure on the same system as
        a web server that is facing the Internet.
	</h:p>
      </description>
      <reference href="https://www.ibm.com/developerworks/rational/library/4706.html">IBM DeveloperWorks article on "Capturing Architectural Requirements"</reference>
    </Group>
    <Group id="xccdf_org.gentoo.dev.swift_group_preinstallation-nonsoftware">
      <title>Non-software security concerns</title>
      <description>
        From the next chapter onwards, the focus will be on the software side
        hardening. There are of course also non-software concerns that need to be
        taken care of.
      </description>
      <reference href="https://www.rfc-editor.org/info/rfc2196">Site Security Handbook (RFC2196)</reference>
      <Group id="xccdf_org.gentoo.dev.swift_group_preinstallation-nonsoftware-physical">
        <title>Physical security</title>
        <description>
	  <h:p>
          Make sure that the system is only accessible (physically) by trusted
          people. Fully hardening a system, only to have a malicious person
          take out the harddisk and run away with the confidential data is not
          something fun to experience.
	  </h:p>
	  <h:p>
          When physical security cannot be guaranteed (like with laptops), make
          sure that theft of the device only results in the loss of the hardware
          and not of the data and software on it (take backups!), and also that the
          data on it cannot be read by unauthorized people.
	  </h:p>
        </description>
        <reference
        href="http://www.sans.org/reading_room/whitepapers/awareness/data-center-physical-security-checklist_416">Data Center Physical Security Checklist (SANS, PDF)</reference>
      </Group>
      <Group id="xccdf_org.gentoo.dev.swift_group_preinstallation-nonsoftware-policies">
        <title>Policies and contractual agreements</title>
        <description>
	  <h:p>
          Create or validate the security policies in the organization. This is
          not only as a stick (against internal people who might want to abuse
          their powers) but also to document and describe why certain decisions
          are made (both architecturally as otherwise).
	  </h:p>
	  <h:p>
          Make sure that the reasoning for the guidelines is clear. If the policies ever
          need to be adjusted towards new environments or concepts (like "bring your own
          device") having the reasons for the (old) guidelines documented will make it much
          easier to write new ones.
	  </h:p>
        </description>
        <reference
        href="http://www.sans.org/reading_room/whitepapers/policyissues/technical-writing-security-policies-easy-steps_492">Technical Writing for IT Security Policies in Five Easy Steps (SANS, PDF)</reference>
        <reference
        href="https://www.sans.org/security-resources/policies/">Information Security Policy Templates (SANS)</reference>
      </Group>
    </Group>
  </Group>
  <Group id="xccdf_org.gentoo.dev.swift_group_installation">
    <title>Installation configuration</title>
    <description>
      Gentoo Linux allows us to update various parts of the system after installation,
      but it might be interesting to consider the following aspects during (or before)
      installation to not risk a huge migration project later.
    </description>
    <Group id="xccdf_org.gentoo.dev.swift_group_installation-storage">
      <title>Storage configuration</title>
      <description>
        Storage is of utmost importance in any environment. It needs to be
        sufficiently fast (performance), but also secure and
        manageable while remaining flexible to handle future changes.
      </description>
      <Group id="xccdf_org.gentoo.dev.swift_group_installation-storage-partitioning">
        <title>Partitioning</title>
        <description>
          Know which locations in the file system structure need to be on a 
          different partition or logical volume. Separate locations allow for a
          more distinct segregation (for instance, no hard links between different
          file systems) and low-level protection (file system corruption impact,
          but also putting the right data on the right storage media).
        </description>
        <reference href="http://www.pathname.com/fhs/">Filesystem Hierarchy
        Standard</reference>
        <Group id="xccdf_org.gentoo.dev.swift_group_installation-storage-partitioning-separate">
          <title>Separate file systems for important locations</title>
          <description>
	    <h:p>
            Having a separate file system for important locations has several advantages, but
            those advantages need to be weighted against the disadvantages of separate file
            systems.
	    </h:p>
	    <h:p>
            These disadvantages are:
	    </h:p>
            <h:ul>
              <h:li>
                Separate file systems mean that better disk space control is needed
                (governing free space). A file system that is given too much free space
                means that disk space is being wasted, but a file system that is not given
                enough free disk space will need to be grown quickly - if possibile. This
                also means that creating a proper partitioning setup with many different
                partitions (file systems) will take some time and calculations; many users
                have no good idea how much space they need to make available for a file system.
              </h:li>
              <h:li>
                Some file system locations need to be available early in the boot process.
                If those locations reside on different file systems, special precautions need
                to be taken to make those file systems available when the system is booted
                (such as creating an initial ram file system).
              </h:li>
            </h:ul>
	    <h:p>
            The advantages on the other hand:
	    </h:p>
            <h:ul>
              <h:li>
                A sudden disk space growth will eventually be stopped by the limits of the
                file system. If a non-critical file system is full, the impact on the overall
                system is limited. Without separate file systems, a full file system might 
                jeopardise the availability of the entire system.
              </h:li>
              <h:li>
                Specific mount options can be enabled on the file systems that improve the
                security of the file system (permissions) as well as performance. Such mount
                options include ownership details, allowing (or disallowing) setuid binaries,
                device files and more.
              </h:li>
              <h:li>
                Different file systems can be hosted on different devices (or even on network
                shares), allowing administrators to pick the most efficient storage device
                for a particular file system.
              </h:li>
            </h:ul>
	    <h:p>
            Considering these pros and cons, it is recommended to have at least the following
            file system locations to be on a different file system:
	    </h:p>
            <h:ul>
              <h:li>
                <h:code>/tmp</h:code> as this is a world-writable location and requires
                specific mount options. When possible, this location can be made a 
                <h:em>tmpfs</h:em> file system. This is to protect the root file system
                from being flooded.
              </h:li>
              <h:li>
                <h:code>/var</h:code> as this contains variable data (and thus is prone
                to grow extensively depending on the installed services). This is to protect
                the root file system from being flooded.
              </h:li>
              <h:li>
                <h:code>/var/log</h:code> as this contains logging data (and thus is prone
                to grow extensively depending on the services). This is to protect the 
                <h:code>/var</h:code> file system from being flooded, as this might impact
                various services (like databases, web servers, etc.).
              </h:li>
              <h:li>
                <h:code>/var/log/audit</h:code> as this contains (potentially sensitive)
                logging data. Some services refuse to continue if the audit target location
                is full. Having the location separate from <h:code>/var/log</h:code> protects
                the audit file system when <h:code>/var/log</h:code> would be flooded.
              </h:li>
              <h:li>
                <h:code>/home</h:code> as this is completely under the control of end users.
                It needs to be mounted with more secure settings (more about that later) and
                should be separate both to protect the root file system, but also to allow
                the <h:code>/home</h:code> location to be either shared or used elsewhere.
              </h:li>
              <h:li>
                <h:code>/var/tmp</h:code> which is a "second" <h:code>/tmp</h:code> location,
                but where the content is preserved after a reboot. Still, it is world-writable
                and requires specific mount options, and should be on a different file system
                to prevent <h:code>/var</h:code> to be flooded which might impact the
                availability of services.
              </h:li>
            </h:ul>
          </description>
          <Rule id="xccdf_org.gentoo.dev.swift_rule_partition-tmp" selected="false" severity="medium" weight="4.6">
            <title>/tmp is a separate file system</title>
            <fixtext>
              Create a file system for <h:code>/tmp</h:code>; make sure it is added in
              the <h:code>/etc/fstab</h:code> file and reboot the system.
            </fixtext>
            <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
              <check-content-ref name="oval:org.gentoo.dev.swift:def:5" href="gentoo-oval.xml" />
            </check>
          </Rule>
          <Rule id="xccdf_org.gentoo.dev.swift_rule_partition-var" selected="false" severity="medium" weight="4.6">
            <title>/var is a separate file system</title>
            <fixtext>
              Create a file system for <h:code>/var</h:code>; make sure it is added in
              the <h:code>/etc/fstab</h:code> file and reboot the system.
            </fixtext>
            <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
              <check-content-ref name="oval:org.gentoo.dev.swift:def:6" href="gentoo-oval.xml" />
            </check>
          </Rule>
          <Rule id="xccdf_org.gentoo.dev.swift_rule_partition-varlog" selected="false" severity="low" weight="2.1">
            <title>/var/log is a separate file system</title>
            <fixtext>
              Create a file system for <h:code>/var/log</h:code>; make sure it is added in
              the <h:code>/etc/fstab</h:code> file and reboot the system.
            </fixtext>
            <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
              <check-content-ref name="oval:org.gentoo.dev.swift:def:7" href="gentoo-oval.xml" />
            </check>
          </Rule>
          <Rule id="xccdf_org.gentoo.dev.swift_rule_partition-varlogaudit" selected="false" severity="low" weight="2.1">
            <title>/var/log/audit is a separate file system</title>
            <fixtext>
              Create a file system for <h:code>/var/log/audit</h:code>; make sure it is added in
              the <h:code>/etc/fstab</h:code> file and reboot the system.
            </fixtext>
            <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
              <check-content-ref name="oval:org.gentoo.dev.swift:def:8" href="gentoo-oval.xml" />
            </check>
          </Rule>
          <Rule id="xccdf_org.gentoo.dev.swift_rule_partition-home" selected="false" severity="medium" weight="4.6">
            <title>/home is a separate file system</title>
            <fixtext>
              Create a file system for <h:code>/home</h:code>; make sure it is added in
              the <h:code>/etc/fstab</h:code> file and reboot the system.
            </fixtext>
            <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
              <check-content-ref name="oval:org.gentoo.dev.swift:def:2" href="gentoo-oval.xml" />
            </check>
          </Rule>
          <Rule id="xccdf_org.gentoo.dev.swift_rule_partition-vartmp" selected="false" severity="low" weight="2.1">
            <title>/var/tmp is a separate file system</title>
            <fixtext>
              Create a file system for <h:code>/var/tmp</h:code>; make sure it is added in
              the <h:code>/etc/fstab</h:code> file and reboot the system.
            </fixtext>
            <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
              <check-content-ref name="oval:org.gentoo.dev.swift:def:17" href="gentoo-oval.xml" />
            </check>
          </Rule>
        </Group>
      </Group>
    </Group>
    <Group id="xccdf_org.gentoo.dev.swift_group_installation-toolchain">
      <title>Use a Hardened Toolchain</title>
      <description>
        <h:p>
        When Gentoo is installed, use the hardened stages and hardened toolchain.
        The hardened toolchain includes additional security patches, such as
        support for non-executable program stacks and buffer overflow detection.
	</h:p>
        <h:ul>
          <h:li>
            <h:em>Position Independent Executables (PIE)</h:em> and <h:em>Position Independent
            Code (PIC)</h:em> implements a memory hardening approach where the application
            (or library), when loaded to memory, does not have hard requirements where in
            memory it is loaded. Together with ASLR this makes it more difficult for exploits
            to know at which memory region certain data will be available.
          </h:li>
          <h:li>
            <h:em>Stack Smashing Protection (SSP)</h:em> adds markers outside buffer areas
            to detect buffer overflow attacks, killing the application rather than effectively
            having the overflow succeed.
          </h:li>
        </h:ul>
	<h:p>
        During installation, make sure that the <h:em>default</h:em> hardened
        toolchain is selected, not one of the <h:code>-hardenedno*</h:code> as
        those are toolchains where specific settings are disabled. The
        <h:code>-vanilla</h:code> one is a toolchain with no hardened patches.
	</h:p>
        <h:pre>
# <h:b>gcc-config -l</h:b>
 [1] x86_64-pc-linux-gnu-4.4.5 *
 [2] x86_64-pc-linux-gnu-4.4.5-hardenednopie
 [3] x86_64-pc-linux-gnu-4.4.5-hardenednopie.gcc-config-ref
 [4] x86_64-pc-linux-gnu-4.4.5-hardenednopiessp
 [5] x86_64-pc-linux-gnu-4.4.5-hardenednossp
 [6] x86_64-pc-linux-gnu-4.4.5-vanilla</h:pre>
      </description>
      <Rule id="xccdf_org.gentoo.dev.swift_rule_installation-toolchain-hardened" selected="false" severity="low" weight="0.0">
        <title>The hardened toolchain is used</title>
        <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_installation-toolchain-hardened">
          Use a hardened Gentoo profile and select the default compiler (not vanilla
          nor any of the hardenedno* ones).
        </fixtext>
        <check system="http://open-scap.org/page/SCE">
          <check-import import-name="stdout" />
          <check-content-ref href="bin/gentoo-sce_installation-toolchain-hardened.sh" />
        </check>
      </Rule>
    </Group> <!-- installation-toolchain -->
  </Group> <!-- installation -->
  <Group id="xccdf_org.gentoo.dev.swift_group_system">
    <title>System settings</title>
    <description>
      Within this chapter, the (recommended) settings that can be adjusted relatively easily
      are presented, even when a Gentoo installation has already been performed. This is the
      bulk of the security settings.
    </description>
    <Group id="xccdf_org.gentoo.dev.swift_group_system-fs">
      <title>File system related settings</title>
      <description>
        Servers and systems are about manipulating data. In this chapter, the security settings
        for file systems are explained.
      </description>
      <Group id="xccdf_org.gentoo.dev.swift_group_system-fs-mountoptions">
        <title>Appropriate mount options for the file systems</title>
        <description>
	  <h:p>
          Non-root file systems should be mounted with the <h:em>nodev</h:em> mount option.
          This mount option ensures that device files are not allowed on these file systems
          (and if they are there, they are ignored by the Linux kernel for any device
          operation).
	  </h:p>
	  <h:p>
          Having device files on non-root file systems could allow unauthorized people access
          to sensitive data (for instance when having a readable raw disk device files) or
          even manipulate the system.
	  </h:p>
	  <h:p>
          The privilege to create special device files (beyond regular sockets) such as
          character and block device files is handled through the CAP_MKNOD capability
          which is not granted to regular users. As such, the risk is when more privileged
          users or processes are tricked to create such device files.
	  </h:p>
	  <h:p>
          This setting is appropriate for file systems such as (non-exhaustive list):
	  </h:p>
          <h:ul>
            <h:li>
              <h:code>/var</h:code> (as it is recommended to be a separate file system)
            </h:li>
            <h:li>
              <h:code>/var/log</h:code> (as it is recommended to be a separate file system)
            </h:li>
            <h:li>
              <h:code>/var/log/audit</h:code> (as it is recommended to be a separate file system)
            </h:li>
            <h:li>
              <h:code>/home</h:code> (as it is recommended to be a separate file system)
            </h:li>
            <h:li>
              <h:code>/tmp</h:code> (as it is recommended to be a separate file system)
            </h:li>
          </h:ul>
	  <h:p>
          Specific file systems should also be mounted with the <h:em>nosuid</h:em> mount
          option. This prevents setuid binaries to run as a different user when hosted
          on this file system. As there are several locations where setuid binaries might
          be needed, this only affects particular file systems:
	  </h:p>
          <h:ul>
            <h:li>
              The <h:code>/tmp</h:code> file system should not be used for setuid binaries
              as this is a world-writable location and often target storage for attacks.
            </h:li>
            <h:li>
              The <h:code>/home</h:code> file system should not be used for setuid binaries
              as this is the home location for non-root users.
            </h:li>
            <h:li>
              The <h:code>/dev/shm</h:code> file system should not be used for any binaries
              (shared memory region).
            </h:li>
          </h:ul>
	  <h:p>
          Specific file systems should also be mounted with the <h:em>noexec</h:em> mount
          option. This prevents some automated attacks to execute certain payload (exploits)
          from these locations.
	  </h:p>
	  <h:p>
          This is just one of the many "layers" though, as executing payload can still be
          done using different methods. For instance, scripts can be invoked through the
          shell itself (rather than directly) and in the past, binaries could even be
          executed through the <h:code>ld-linux.so</h:code> binary (although this has
          been fixed).
	  </h:p>
	  <h:p>
          File systems for which <h:em>noexec</h:em> is recommended are:
	  </h:p>
          <h:ul>
            <h:li>
              The <h:code>/tmp</h:code> file system as it is a popular target to store exploit
              code in.
            </h:li>
            <h:li>
              The <h:code>/dev/shm</h:code> file system as it is meant as a shared memory
              location and is becoming a popular target to store exploit code in.
            </h:li>
          </h:ul>
        </description>
        <!-- CVSS2 AV:L/Au:M/C:C/I:C/A:C (high complexity as device node needs
             to be created first and is then only exploitable after local access.
             Multiple authentication (one to create device file, one to log on)
        -->
        <Rule id="xccdf_org.gentoo.dev.swift_rule_partition-var-nodev" selected="false" severity="low" weight="5.9">
          <title>/var is mounted with nodev</title>
          <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-var-nodev">Mount /var with nodev mount option</fixtext>
          <fix id="xccdf_org.gentoo.dev.swift_fix_partition-var-nodev"
            system="urn:xccdf:fix:system:commands"
            platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false">
mount -o remount,nodev /var
          </fix>
          <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
            <check-content-ref name="oval:org.gentoo.dev.swift:def:9" href="gentoo-oval.xml" />
          </check>
        </Rule>
        <Rule id="xccdf_org.gentoo.dev.swift_rule_partition-varlog-nodev" selected="false" severity="low" weight="5.9">
          <title>/var/log is mounted with nodev</title>
          <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-varlog-nodev">Mount /var/log with nodev mount option</fixtext>
          <fix id="xccdf_org.gentoo.dev.swift_fix_partition-varlog-nodev"
            system="urn:xccdf:fix:system:commands"
            platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false">
mount -o remount,nodev /var/log
          </fix>
          <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
            <check-content-ref name="oval:org.gentoo.dev.swift:def:10" href="gentoo-oval.xml" />
          </check>
        </Rule>
        <Rule id="xccdf_org.gentoo.dev.swift_rule_partition-varlogaudit-nodev" selected="false" severity="low" weight="5.9">
          <title>/var/log/audit is mounted with nodev</title>
          <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-varlogaudit-nodev">Mount /var/log/audit with nodev mount option</fixtext>
          <fix id="xccdf_org.gentoo.dev.swift_fix_partition-varlogaudit-nodev"
            system="urn:xccdf:fix:system:commands"
            platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false">
mount -o remount,nodev /var/log/audit
          </fix>
          <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
            <check-content-ref name="oval:org.gentoo.dev.swift:def:11" href="gentoo-oval.xml" />
          </check>
        </Rule>
        <Rule id="xccdf_org.gentoo.dev.swift_rule_partition-home-nodev" selected="false" severity="low" weight="5.9">
          <title>/home is mounted with nodev</title>
          <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-home-nodev">Mount /home with nodev mount option</fixtext>
          <fix id="xccdf_org.gentoo.dev.swift_fix_partition-home-nodev"
            system="urn:xccdf:fix:system:commands"
            platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false">
mount -o remount,nodev /home
          </fix>
          <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
            <check-content-ref name="oval:org.gentoo.dev.swift:def:4" href="gentoo-oval.xml" />
          </check>
        </Rule>
        <!-- Higher severity due to more best practices and world writeable,
             also more likely that exploit of process is done towards /tmp -->
        <Rule id="xccdf_org.gentoo.dev.swift_rule_partition-tmp-nodev" selected="false" severity="medium" weight="5.9">
          <title>/tmp is mounted with nodev</title>
          <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-tmp-nodev">Mount /tmp with nodev mount option</fixtext>
          <fix id="xccdf_org.gentoo.dev.swift_fix_partition-tmp-nodev"
            system="urn:xccdf:fix:system:commands"
            platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false">
mount -o remount,nodev /tmp
          </fix>
          <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
            <check-content-ref name="oval:org.gentoo.dev.swift:def:12" href="gentoo-oval.xml" />
          </check>
        </Rule>
        <Rule id="xccdf_org.gentoo.dev.swift_rule_partition-tmp-nosuid" selected="false" severity="medium" weight="5.9">
          <title>/tmp is mounted with nosuid</title>
          <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-tmp-nosuid">Mount /tmp with nosuid mount option</fixtext>
          <fix id="xccdf_org.gentoo.dev.swift_fix_partition-tmp-nosuid"
            system="urn:xccdf:fix:system:commands"
            platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false">
mount -o remount,nosuid /tmp
          </fix>
          <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
            <check-content-ref name="oval:org.gentoo.dev.swift:def:13" href="gentoo-oval.xml" />
          </check>
        </Rule>
        <Rule id="xccdf_org.gentoo.dev.swift_rule_partition-home-nosuid" selected="false" severity="low" weight="5.9">
          <title>/home is mounted with nosuid</title>
          <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-home-nosuid">Mount /home with nosuid mount option</fixtext>
          <fix id="xccdf_org.gentoo.dev.swift_fix_partition-home-nosuid"
            system="urn:xccdf:fix:system:commands"
            platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false">
mount -o remount,nosuid /home
          </fix>
          <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
            <check-content-ref name="oval:org.gentoo.dev.swift:def:3" href="gentoo-oval.xml" />
          </check>
        </Rule>
        <Rule id="xccdf_org.gentoo.dev.swift_rule_partition-devshm-nosuid" selected="false" severity="medium" weight="5.9">
          <title>/dev/shm is mounted with nosuid</title>
          <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-devshm-nosuid">Mount /dev/shm with nosuid mount option</fixtext>
          <fix id="xccdf_org.gentoo.dev.swift_fix_partition-devshm-nosuid"
            system="urn:xccdf:fix:system:commands"
            platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false">
mount -o remount,nosuid /dev/shm
          </fix>
          <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
            <check-content-ref name="oval:org.gentoo.dev.swift:def:14" href="gentoo-oval.xml" />
          </check>
        </Rule>
        <!-- Weight is 0 as this is a means to exploit, not exploitable by
             itself -->
        <Rule id="xccdf_org.gentoo.dev.swift_rule_partition-tmp-noexec" selected="false" severity="medium" weight="0.0">
          <title>/tmp is mounted with noexec</title>
          <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-tmp-noexec">Mount /tmp with noexec mount option</fixtext>
          <fix id="xccdf_org.gentoo.dev.swift_fix_partition-tmp-noexec"
            system="urn:xccdf:fix:system:commands"
            platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false">
mount -o remount,noexec /tmp
          </fix>
          <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
            <check-content-ref name="oval:org.gentoo.dev.swift:def:15" href="gentoo-oval.xml" />
          </check>
        </Rule>
        <Rule id="xccdf_org.gentoo.dev.swift_rule_partition-devshm-noexec" selected="false" severity="medium" weight="0.0">
          <title>/dev/shm is mounted with noexec</title>
          <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_partition-devshm-noexec">Mount /dev/shm with nosuid mount option</fixtext>
          <fix id="xccdf_org.gentoo.dev.swift_fix_partition-devshm-noexec"
            system="urn:xccdf:fix:system:commands"
            platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false">
mount -o remount,noexec /dev/shm
          </fix>
          <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
            <check-content-ref name="oval:org.gentoo.dev.swift:def:16" href="gentoo-oval.xml" />
          </check>
        </Rule>
      </Group> <!-- system-fs-mountoptions -->
      <Group id="xccdf_org.gentoo.dev.swift_group_system-fs-quotas">
        <title>Disk quota support</title>
        <description>
	  <h:p>
          Most file systems support the notion of <h:em>quotas</h:em> - limits
          on the amount of data / files that are allowed on that particular file system.
	  </h:p>
	  <h:p>
          To enable quotas, first configure the Linux kernel to include
          <h:code>CONFIG_QUOTA</h:code>.
	  </h:p>
	  <h:p>
          Next, install the <h:code>sys-fs/quota</h:code> package.
	  </h:p>
          <h:pre>
# <h:b>emerge quota</h:b></h:pre>
          <h:p>
          Then add <h:code>usrquota</h:code> and <h:code>grpquota</h:code> to
          the partitions (in <h:code>/etc/fstab</h:code>) where quotas need to be
          enabled on. For instance, the following snippet from
          <h:code>/etc/fstab</h:code> enables quotas on <h:code>/var</h:code>
          and <h:code>/home</h:code>.
	  </h:p>
          <h:pre>
/dev/mapper/volgrp-home /home ext4 noatime,nodev,nosuid,<h:b>usrquota,grpquota</h:b> 0 0
/dev/mapper/volgrp-var  /var  ext4 noatime,<h:b>usrquota,grpquota</h:b>              0 0</h:pre>
          <h:p>
          Finally, add the <h:code>quota</h:code> service to the boot runlevel.
	  </h:p>
          <h:pre>
# <h:b>rc-update add quota boot</h:b></h:pre>
          <h:p>
          Reboot the system so that the partitions are mounted with the correct
          mount options and that the quota service is running. Then the quotas for
          users and groups can be set up.
	  </h:p>
        </description>
        <reference
        href="http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch28_:_Managing_Disk_Usage_with_Quotas">Managing
        Disk Usage with Quotas (LinuxHomeNetworking)</reference>
        <reference href="http://www.gentoo.org/doc/en/kernel-config.xml#shorthand">Gentoo Linux Kernel Configuration - shorthand notation information</reference>
        <Rule id="xccdf_org.gentoo.dev.swift_rule_kernel-quota" selected="false" severity="low" weight="1.7">
          <title>The kernel supports quota (CONFIG_QUOTA)</title>
          <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_kernel-quota">Rebuild the Linux kernel with quota support (CONFIG_QUOTA)</fixtext>
          <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
            <check-content-ref name="oval:org.gentoo.dev.swift:def:18" href="gentoo-oval.xml" />
          </check>
        </Rule>
      </Group> <!-- system-fs-quotas -->
    </Group> <!-- system-fs -->
    <Group id="xccdf_org.gentoo.dev.swift_group_system-services">
      <title>System services</title>
      <description>
        <h:p>
        Services (daemons) are the primary reason for a server to exist.
        They represent the function of the server. For instance, a web server
        will run the apache2 or lighttpd service. A name server will run the
        named service.
	</h:p>
	<h:p>
        In this benchmark, the focus is on a limited set of system services. For
        the other services it is wise to consult other hardening guides specific
	for those services.
	</h:p>
      </description>
      <reference href="http://www.cisecurity.org">Center for Internet Security,
      host of many service benchmarks</reference>
      <Group id="xccdf_org.gentoo.dev.swift_group_system-services-disable">
        <title>Disable unsafe services</title>
        <description>
	  <h:p>
          It is recommended to disable (or even uninstall) the following services unless
          absolutely necessary. These services use plain-text protocols and are as such unsafe
          to use on (untrusted) networks.
	  </h:p>
          <h:ul>
            <h:li>Telnet service</h:li>
            <h:li>FTP Service</h:li>
          </h:ul>
	  <h:p>
          It is recommended to substitute these services with their more secure
          counterparts (like sFTP, SSH, ...).
	  </h:p>
        </description>
        <!-- Max score: password in clear text and your system is compromised (if it is root) -->
	<Rule id="xccdf_org.gentoo.dev.swift_rule_telnetd-notrunning" selected="false" severity="high" weight="10.0">
          <title>No telnet daemons are running</title>
          <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_telnetd-notrunning">Stop telnet services</fixtext>
          <fix id="xccdf_org.gentoo.dev.swift_fix_telnetd-notrunning"
            system="urn:xccdf:fix:system:commands"
            platform="cpe:/o:gentoo:linux" complexity="low" disruption="high" reboot="false">
for service in /etc/init.d/*telnet*;
do
  test -f ${service} &amp;&amp; run_init rc-service ${service##*/} stop;
done
          </fix>
          <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
            <check-content-ref name="oval:org.gentoo.dev.swift:def:19" href="gentoo-oval.xml" />
          </check>
        </Rule>
        <!-- Partial breach, assuming accounts are not system accounts -->
        <Rule id="xccdf_org.gentoo.dev.swift_rule_ftpd-notrunning" selected="false" severity="medium" weight="7.5">
          <title>No FTP daemons are running</title>
          <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_ftpd-notrunning">Stop FTPd services</fixtext>
          <fix id="xccdf_org.gentoo.dev.swift_fix_ftpd-notrunning"
            system="urn:xccdf:fix:system:commands"
            platform="cpe:/o:gentoo:linux" complexity="low" disruption="high" reboot="false">
for service in /etc/init.d/*ftp*;
do
  test -f ${service} &amp;&amp; run_init rc-service ${service##*/} stop;
done
          </fix>
          <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
            <check-content-ref name="oval:org.gentoo.dev.swift:def:20" href="gentoo-oval.xml" />
          </check>
        </Rule>
      </Group>
      <Group id="xccdf_org.gentoo.dev.swift_group_system-services-sulogin">
        <title>Require single-user boot to give root password</title>
        <description>
	  <h:p>
          When a system is booted in single user mode, some users might find it
          handy to immediately get a root prompt; many even have a specific
          bootloader entry to boot in single user mode.
	  </h:p>
	  <h:p>
          It is important that, for a more secure server environment, even
          booting in single user mode requires the user to enter the root
          password. This is already done by default in Gentoo through the
          <h:code>rc_shell</h:code> variable in <h:code>/etc/rc.conf</h:code>.
	  </h:p>
	  <h:p>
          Administrators should also make sure that no direct shells are provided
          in <h:code>/etc/inittab</h:code> for single-user mode. Gentoo's
          <h:code>/etc/inittab</h:code> definition should look like so:
	  </h:p>
          <h:pre>
su0:S:wait:/sbin/rc single
<h:b>su1:S:wait:/sbin/sulogin</h:b></h:pre>
        </description>
        <!-- CVSS2: AV:L/AC:H/Au:S/C:C/I:C/A:C (high attack complexity due to console access) -->
        <Rule id="xccdf_org.gentoo.dev.swift_rule_rcconf-sulogin" selected="false" severity="medium" weight="6.0">
          <title>sulogin is used for single-user boot (/etc/rc.conf)</title>
          <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_rcconf-sulogin">Set /sbin/sulogin for rc_shell</fixtext>
          <fix id="xccdf_org.gentoo.dev.swift_fix_rcconf-sulogin"
            system="urn:xccdf:fix:system:commands"
            platform="cpe:/o:gentoo:linux" complexity="low" disruption="low" reboot="false">
sed -i -e 's:^rc_shell=.*:rc_shell="/sbin/sulogin":g' /etc/rc.conf
          </fix>
          <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
            <check-content-ref name="oval:org.gentoo.dev.swift:def:21" href="gentoo-oval.xml" />
          </check>
        </Rule>
        <Rule id="xccdf_org.gentoo.dev.swift_rule_inittab-sulogin" selected="false" severity="medium" weight="6.0">
          <title>sulogin is used for single-user boot (/etc/inittab)</title>
          <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_inittab-sulogin">
            Set /sbin/sulogin or '/sbin/rc single' for single-user boot in /etc/inittab
          </fixtext>
          <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
            <check-content-ref name="oval:org.gentoo.dev.swift:def:22" href="gentoo-oval.xml" />
          </check>
        </Rule>
      </Group>
      <Group id="xccdf_org.gentoo.dev.swift_group_system-services-tcpwrappers">
        <title>Properly Configure TCP Wrappers</title>
        <description>
	  <h:p>
          With TCP wrappers, services that support TCP wrappers (or those
          started through <h:b>xinetd</h:b>) should be configured to only accept
          communication with trusted hosts. With the use of
          <h:code>/etc/hosts.allow</h:code> and <h:code>/etc/hosts.deny</h:code>,
          proper access control lists can be created.
	  </h:p>
	  <h:p>
          More information on the format of these files can be obtained through
          <h:b>man 5 hosts_access</h:b>.
	  </h:p>
        </description>
        <Rule id="xccdf_org.gentoo.dev.swift_rule_hostsallow-exists" selected="false" severity="info" weight="0.0">
          <title>/etc/hosts.allow exists</title>
          <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_hostsallow-exists">
            Create and properly configure /etc/hosts.allow
          </fixtext>
          <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
            <check-content-ref name="oval:org.gentoo.dev.swift:def:23" href="gentoo-oval.xml" />
          </check>
        </Rule>
      </Group>
      <Group id="xccdf_org.gentoo.dev.swift_group_system-services-ssh">
        <title>SSH service</title>
        <description>
	  <h:p>
          The SSH service is used for secure remote access towards a system, but
          also to provide secure file transfers. It is very commonly found on Unix/Linux
          systems so proper hardening is definitely in place.
	  </h:p>
	  <h:p>
          Please use the "Hardening OpenSSH" guide for the necessary instructions.
	  </h:p>
        </description>
      </Group>
      <Group id="xccdf_org.gentoo.dev.swift_group_system-services-cron">
        <title>Cron service</title>
        <description>
          A cron service is used to schedule tasks and processes on predefined
          times. Cron is most often used for regular maintenance tasks.
        </description>
        <Group id="xccdf_org.gentoo.dev.swift_group_system-services-cron-acl">
          <title>Only allow trusted accounts cron access</title>
          <description>
	    <h:p>
            Only allow trusted accounts to use cron. How to achieve this depends on the cron service
            installed.
	    </h:p>
	    <h:p>
            If vixie-cron or cronie is installed, then have (only) those users that need cron access
	    take part in the <h:em>cron</h:em> unix group. 
	    </h:p>
	    <h:p>
            If dcron is used, then make sure <h:code>/usr/sbin/crontab</h:code> is only executable by
            root and the cron unix group, and make sure (only) those users that need cron access take part
            in the <h:em>cron</h:em> unix group.
	    </h:p>
          </description>
        </Group>
      </Group>
      <Group id="xccdf_org.gentoo.dev.swift_group_system-services-at">
        <title>At service</title>
        <description>
          The at service allows users to execute a task once on a given time.
          Unlike cron, this is not scheduled repeatedly - once executed, the
          task is considered completed and at will not invoke it again.
        </description>
        <Group id="xccdf_org.gentoo.dev.swift_group_system-services-at-acl">
          <title>Only allow trusted accounts at access</title>
          <description>
	    <h:p>
            Only allow trusted accounts to use at. Unlike cron access, at access is governed through
            the <h:code>/etc/at/at.allow</h:code> file. If the <h:code>at.allow</h:code> file does not
            exist but <h:code>/etc/at/at.deny</h:code> does, then all names <h:em>not</h:em> mentioned in
            the file are allowed to run at. The most secure method is to use the <h:code>at.allow</h:code>
            method.
	    </h:p>
	    <h:p>
            The format of these files is one username per line.
	    </h:p>
          </description>
          <Rule id="xccdf_org.gentoo.dev.swift_rule_atallow-exists" selected="false" severity="low" weight="0.0">
            <title>/etc/at/at.allow exists</title>
            <fixtext fixref="xccdf_org.gentoo.dev.swift_fix_atsallow-exists">
              Create and properly configure /etc/at/at.allow
            </fixtext>
            <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
              <check-content-ref name="oval:org.gentoo.dev.swift:def:24" href="gentoo-oval.xml" />
            </check>
          </Rule>
        </Group>
      </Group>
      <Group id="xccdf_org.gentoo.dev.swift_group_system-services-ntp">
        <title>NTP service</title>
        <description>
	  <h:p>
          With NTP, systems can synchronise their clocks, ensuring correct date
          and time information. This is important as huge clock drift could
          cause misinterpretation of log files or even unwanted execution of
          commands.
	  </h:p>
        </description>
        <Group id="xccdf_org.gentoo.dev.swift_group_system-services-ntp-sync">
          <title>Synchronise the system clock</title>
          <description>
	    <h:p>
            Synchronise the systems' clock with an authorative NTP server, and
            use the same NTP service for all other systems.
	    </h:p>
	    <h:p>
            This can be accomplished by regularly executing <h:b>ntpdate</h:b>,
            but can also be handled using a service like <h:code>net-misc/ntp</h:code>'s
            <h:b>ntpd</h:b>.
	    </h:p>
          </description>
        </Group>
      </Group>
    </Group>
    <Group id="xccdf_org.gentoo.dev.swift_group_system-portage">
      <title>Portage settings</title>
      <description>
        <h:p>
        The package manager of any system is a very important tool. It is
        responsible for handling proper software deployments, but also offers
        features that should not be neglected, like security patch roll-out.
	</h:p>
	<h:p>
        For Gentoo, the package manager offers a great deal of flexibility (as
        that is the goal of Gentoo anyhow). As such, good settings for a more
        secure environment within Portage (assuming that Portage is used as
        package manager) are important.
	</h:p>
      </description>
      <Group id="xccdf_org.gentoo.dev.swift_group_system-portage-use">
        <title>USE flags</title>
        <description>
	  <h:p>
          USE flags in Gentoo are used to tune the functionality of many
          components and enable or disable features.
	  </h:p>
	  <h:p>
          For a well secured environment, there are a couple of USE flags that
          should be set in a global manner. These USE flags are
	  </h:p>
          <h:ul>
            <h:li>
              <h:code>pam</h:code> to enable Pluggable Authentication
              Modules support
            </h:li>
            <h:li>
              <h:code>tcpd</h:code> for TCP wrappers support
            </h:li>
            <h:li>
              <h:code>ssl</h:code> for SSL/TLS support
            </h:li>
          </h:ul>
	  <h:p>
          <h:b>Pluggable Authentication Modules</h:b> are a powerful mechanism
          to manage authentication, authorization and user sessions.
          Applications that support PAM can be tuned to the liking of the
          organization, leveraging central authentication, password policies,
          auditing and more.
	  </h:p>
	  <h:p>
          With <h:b>TCP wrappers</h:b>, services can be shielded from
          unauthorized access on host level. It is an access control level
          mechanism which allows configuring allowed (and denied) hosts or
          network segments on application level.
	  </h:p>
	  <h:p>
          Finally, leveraging <h:b>Secure Sockets Layer</h:b> (or the
          standardized <h:b>Transport Layer Security</h:b>) allows applications
          to encrypt network communication or even implement a
          client-certificate based authentication mechanism.
	  </h:p>
	  <h:p>
          Set the USE flags globally in <h:code>/etc/portage/make.conf</h:code>
          so they are applicable to all installed software.
	  </h:p>
          <h:pre>
USE="... pam tcpd ssl"</h:pre>
        </description>
      </Group>
      <Group id="xccdf_org.gentoo.dev.swift_group_system-portage-webrsync">
        <title>Fetching signed portage tree</title>
        <description>
	  <h:p>
          Gentoo Portage supports fetching signed tree snapshots using
          <h:b>emerge-webrsync</h:b>. This is documented in the Gentoo Handbook,
          but as it is quite easy, here are the instructions again:
	  </h:p>
          <h:pre>
# <h:b>mkdir -p /etc/portage/gpg</h:b>
# <h:b>chmod 0700 /etc/portage/gpg</h:b>
# <h:b>export SRV="subkeys.pgp.net"</h:b>
# <h:b>export KEY="0x96D8BF6D"</h:b>
# <h:b>gpg --homedir /etc/portage/gpg --keyserver ${SRV} --recv-keys ${KEY}</h:b>
# <h:b>gpg --homedir /etc/portage/gpg --edit-key ${KEY} trust</h:b></h:pre>
          <h:p>
          After this, edit <h:code>/etc/portage/make.conf</h:code>:
	  </h:p>
          <h:pre>
FEATURES="webrsync-gpg"
PORTAGE_GPG_DIR="/etc/portage/gpg"
SYNC=""</h:pre>
        </description>
      </Group>
    </Group>
    <Group id="xccdf_org.gentoo.dev.swift_group_system-kernel">
      <title>Kernel configuration</title>
      <description>
        <h:p>
        The Linux kernel should be configured using a sane security standard in
        mind. When using grSecurity, additional security-enhancing settings can
        be enabled.
	</h:p>
	<h:p>
        For further details, please refer to the "Hardening the Linux kernel" guide.
	</h:p>
      </description>
      <reference href="http://www.gentoo.org/doc/en/kernel-config.xml#shorthand">Gentoo Kernel Configuration Guide - Shorthand notation information</reference>
    </Group>
    <Group id="xccdf_org.gentoo.dev.swift_group_system-bootloader">
      <title>Bootloader configuration</title>
      <description>
        <h:p>
        The bootloader (be it GRUB or another tool) is responsible for loading
        the Linux kernel and handing over system control to the kernel. But boot
        loaders also allow for a flexible approach on kernel loading, which can
        be (ab)used to work around security mechanisms.
	</h:p>
      </description>
      <Group id="xccdf_org.gentoo.dev.swift_group_system-bootloader-grub1pass">
        <title>Password protect GRUB (legacy)</title>
        <description>
	  <h:p>
          It is recommended to password-protect the GRUB configuration so that
          the boot options cannot be modified during a boot without providing the
          valid password.
	  </h:p>
	  <h:p>
          This can be accomplished by inserting <h:code>password abc123</h:code>
          in <h:code>/boot/grub/grub.conf</h:code> (which will set the password
          to "abc123"). But as clear-text passwords in the configuration file are insecure as well,
          hash the passwords. Just start <h:b>grub</h:b>
          and, in the grub-shell, type <h:b>md5crypt</h:b>.
	  </h:p>
          <h:pre>
# <h:b>grub</h:b>

GRUB version 0.92 (640K lower / 3072K upper memory)

[ Minimal BASH-like line editing is supported. ... ]

grub&gt; <h:b>md5crypt</h:b>

Password: <h:em>abc123</h:em>
Encrypted: $1$18u.M0$J8VbOsGXuoG9Fh3n7ZkqY.

grub&gt; <h:b>quit</h:b></h:pre>
          <h:p>
          This hashed password can now be used in <h:code>grub.conf</h:code>
          using <h:code>password --md5 $1$18u.M0$J8VbOsGXuoG9Fh3n7ZkqY.</h:code>.
	  </h:p>
        </description>
      </Group>
      <Group id="xccdf_org.gentoo.dev.swift_group_system-bootloader-lilopass">
        <title>Password protect LILO</title>
        <description>
	  <h:p>
          It is recommended to password-protect the LILO configuration so that
          modifying the boot options during a boot without providing the
          valid password is not possible.
	  </h:p>
	  <h:p>
          This can be accomplished  by inserting <h:code>password=abc123</h:code>
          followed by <h:code>restricted</h:code> in the
          <h:code>/etc/lilo.conf</h:code> file. It is also possible to do this
          on a per-image level.
	  </h:p>
          <h:pre>
password=abc123
restricted
delay=3

image=/boot/bzImage
        read-only
        password=def456
        restricted</h:pre>
	   <h:p>
           The <h:code>restricted</h:code> keyword is needed to have LILO only
           ask for the password if a modification is given. If the defaults are
           used, then no password needs to be provided.
	   </h:p>
	   <h:p>
           Rerun <h:code>lilo</h:code> after updating the configuration file.
	   </h:p>
        </description>
      </Group>
    </Group>
    <Group id="xccdf_org.gentoo.dev.swift_group_system-auth">
      <title>Authentication and authorization settings</title>
      <description>
        <h:p>
        An important part in a servers' security is its authentication and
        authorization support. We have already described how to build in PAM
        support (through the Portage USE flags), but proper authentication and
        authorization settings are mode than just compiling in the necessary
        functionality.
	</h:p>
      </description>
      <Group id="xccdf_org.gentoo.dev.swift_group_system-auth-securetty">
        <title>Restrict root system logon</title>
        <description>
	  <h:p>
          To restrict where the root user can directly log on, edit
          <h:code>/etc/securetty</h:code> and specify the supported terminals
          for the root user.
	  </h:p>
	  <h:p>
          When properly configured, any attempt to log on as the root user from
          a non-defined terminal will result in logon failure.
	  </h:p>
	  <h:p>
          A recommended setting is to only allow root user login through the
          console and the physical terminals (<h:code>tty0-tty12</h:code>).
	  </h:p>
          <h:pre>
console
tty0
tty1
...
tty12</h:pre>
        </description>
      </Group>
      <Group id="xccdf_org.gentoo.dev.swift_group_system-auth-userlogin">
        <title>Allow only known users to login</title>
        <description>
	  <h:p>
          When PAM is enabled, the <h:code>/etc/security/access.conf</h:code>
          file is used to check which users are allowed to log on and not
          (through the <h:b>login</h:b> application). These limits are based on
          username, group and host, network or tty that the user is trying to
          log on from.
	  </h:p>
	  <h:p>
          By enabling these settings, the risk is reduced that a functional
          account (say <h:code>apache</h:code>) is abused to log on with, or
          that a new account is created as part of an exploit.
	  </h:p>
        </description>
      </Group>
      <Group id="xccdf_org.gentoo.dev.swift_group_system-auth-resources">
        <title>Restrict user resources</title>
        <description>
	  <h:p>
          When facing a DoS (Denial-of-Service) attack, reducing the impact of
          the attack can be done by limited resource consumption. Although the
          component that is under attack will even more quickly fail, the impact
          towards the other services on the system (including remote logon to
          fix things) is more limited.
	  </h:p>
	  <h:p>
          In Gentoo Linux, the following methods are available to limit
          resources.
	  </h:p>
          <h:ul>
            <h:li>
              <h:code>/etc/security/limits.conf</h:code> defines the
              resource limits for logins that are done through a PAM-aware
              component (default in our setup)
            </h:li>
            <h:li>
              <h:code>/etc/limits</h:code> defines the resource limits for
              logins that are done through login programs that are not
              PAM-aware.
            </h:li>
          </h:ul>
	  <h:p>
          Generally, it should suffice to set up
          <h:code>/etc/security/limits.conf</h:code>, which is the configuration
          file used by the <h:code>pam_limits.so</h:code> module.
	  </h:p>
	  <h:p>
          Note that the settings are applicable on a <h:em>per login
          session</h:em> basis.
	  </h:p>
	  <h:p>
          More information on these files and their syntax can be obtained
          through their manual pages.
	  </h:p>
          <h:pre>
# <h:b>man limits.conf</h:b>
# <h:b>man limits</h:b></h:pre>
        </description>
      </Group>
      <Group id="xccdf_org.gentoo.dev.swift_group_system-auth-password">
        <title>Enforce password policy</title>
        <description>
	  <h:p>
          Usually most organizations have a password policy, telling their users
          how long their passwords should be and how often the passwords should
          be changed. Most users see this as an annoying aspect, so it might be
          best to enforce this policy.
	  </h:p>
	  <h:p>
          Enforcing password policies is (partially) part of the
          <h:code>sys-apps/shadow</h:code> package (which is installed by
          default) and can be configured through the
          <h:code>/etc/login.defs</h:code> file. This file is well documented
          (using comments) and it has a full manual page as well.
	  </h:p>
	  <h:p>
          A second important player when dealing with password policies is the
          <h:code>pam_cracklib.so</h:code> library. This can be used in the
          appropriate <h:code>/etc/pam.d/*</h:code> files. For instance, for the
          <h:code>/etc/pam.d/passwd</h:code> definition:
	  </h:p>
          <h:pre>
auth     required pam_unix.so shadow nullok
account  required pam_unix.so
<h:b>password required pam_cracklib.so difok=3 retry=3 \
                                  minlen=8 dcredit=-2 \
				  ocredit=-2</h:b>
password required pam_unix.so md5 use_authok
session  required pam_unix.so</h:pre>
          <h:p>
          In the above example, the password is required to be at least 8
          characters long, differ more than 3 characters from the previous
          password, contain 2 digits and 2 non-alphanumeric characters.
	  </h:p>
        </description>
      </Group>
      <Group id="xccdf_org.gentoo.dev.swift_group_system-auth-ripper">
        <title>Review password strength regularly</title>
        <description>
	  <h:p>
          Regularly check the strength of the users' passwords. There are tools
          out there, like <h:code>app-crypt/johntheripper</h:code> which, given
          a <h:code>/etc/shadow</h:code> file (or sometimes even LDAP dump) try
          to find the passwords for the users.
	  </h:p>
	  <h:p>
          When such a tool can guess a users' password, that users' password
          should be expired and the user should be notified and asked to change
          his password.
	  </h:p>
        </description>
      </Group>
    </Group>
    <Group id="xccdf_org.gentoo.dev.swift_group_system-session">
      <title>Session settings</title>
      <description>
        <h:p>
        Unlike authentication and authorization settings, a <h:em>session</h:em>
        setting is one that is applicable to an authenticated and authorized
        user when he is logged on to the system.
	</h:p>
      </description>
      <Group id="xccdf_org.gentoo.dev.swift_group_system-session-mesg">
        <title>Disable access to user terminals</title>
        <description>
	  <h:p>
          By default, user terminals are accessible by others to write messages
          to (using <h:b>write</h:b>, <h:b>wall</h:b> or <h:b>talk</h:b>). It is
          adviseable to disable this unless explicitly necessary.
	  </h:p>
	  <h:p>
          Messages can confuse users and trick them into performing malicious
          actions. 
	  </h:p>
	  <h:p>
          This can be disabled by setting <h:code>mesg n</h:code> in
          <h:code>/etc/profile</h:code>. A user-friendly method for doing so in
          Gentoo is to create a file <h:code>/etc/profile.d/disable_mesg</h:code> which
          contains this command.
	  </h:p>
        </description>
      </Group>
    </Group>
    <Group id="xccdf_org.gentoo.dev_group_system-fileprivileges">
      <title>File and directory privileges and integrity</title>
      <description>
        Proper privileges on files makes it far more difficult to malicious
        users to obtain sensitive information or write/update files they should
        not have access to.
      </description>
      <Group id="xccdf_org.gentoo.dev.swift_group_system-fileprivileges-worldrw">
        <title>Limit world writable files and locations</title>
        <description>
	  <h:p>
          Limit (or even remove) the use of world writable files and locations.
          If a directory is world writable, it makes sense to have the
          sticky bit set on it as well (like with <h:code>/tmp</h:code>).
	  </h:p>
	  <h:p>
          Use <h:code>find</h:code> to locate such files or directories.
	  </h:p>
          <h:pre>
# <h:b>find / -perm +o=w ! \( -type d -perm +o=t \) ! -type l -print</h:b></h:pre>
          <h:p>
          The above command shows world writable files and locations, unless it
          is a directory with the sticky bit set, or a symbolic link (whose
          world writable privilege is not accessible anyhow).
	  </h:p>
        </description>
      </Group>
      <Group id="xccdf_org.gentoo.dev.swift_group_system-fileprivileges-suidsgid">
        <title>Limit setuid and setgid file and directory usage</title>
        <description>
	  <h:p>
          The <h:em>setuid</h:em> and <h:em>setgid</h:em> flags for files and
          directories can be used to work around authentication and
          authorization measures taken on the system. So their use should be
          carefully guarded.
	  </h:p>
	  <h:p>
          In case of files, the setuid or setgid bit causes the application (if
          the file is marked as executable) to run with the privileges of the
          file owner (setuid) or group owner (setgid). It is necessary for
          applications that need elevated privileges, like <h:b>su</h:b> or
          <h:b>sudo</h:b>.
	  </h:p>
	  <h:p>
          In case of directories, the setgit bit causes newly created
          files in that directory to automatically be owned by the same group as
          the mentioned (parent) directory.
	  </h:p>
        </description>
      </Group>
      <Group id="xccdf_org.gentoo.dev.swift_group_system-fileprivileges-logs">
        <title>Logs only readable by proper group</title>
        <description>
          No log file in <h:code>/var/log</h:code> should be world readable. Log
          files should be limited by particular groups (either the group
          representing the service, like <h:code>apache</h:code> or
          <h:code>portage</h:code>, or a specific administrative group like
          <h:code>wheel</h:code>).
        </description>
      </Group>
      <Group id="xccdf_org.gentoo.dev.swift_group_system-fileprivileges-rootonly">
        <title>Files only used by root should be root-only</title>
        <description>
	  <h:p>
          Some files, like <h:code>/etc/shadow</h:code>, are meant to be read
          (and perhaps modified) by root only. These files should never have
          privileges for group- or others.
	  </h:p>
	  <h:p>
          A nonexhaustive list of such files is:
	  </h:p>
          <h:ul>
            <h:li>
              <h:code>/etc/shadow</h:code> which contains account password
              information (including password hashes)
            </h:li>
            <h:li>
              <h:code>/etc/securetty</h:code> which contains the list of
              terminals where root is allowed to log on from
            </h:li>
          </h:ul>
        </description>
      </Group>
      <Group id="xccdf_org.gentoo.dev.swift_group_system-fileprivileges-hids">
        <title>Review file integrity regularly</title>
        <description>
          Deploy intrusion detection tool(s) to validate the integrity and
          privileges on important files. <h:code>app-forensics/aide</h:code> is
          an example of such a tool.
        </description>
      </Group>
    </Group> 
  </Group> <!-- system -->
  <Group id="xccdf_org.gentoo.dev.swift_group_data">
    <title>Data flows</title>
    <description>
      Clearly map out how data flows in and out of the server (and which data
      this is). This will be needed anyhow when firewalls are configured, but it
      also improves integration of the server in a larger infrastructure.
    </description>
    <Group id="xccdf_org.gentoo.dev.swift_group_data-backup">
      <title>Backup the data</title>
      <description>
        Make sure that the data is backed up. This is not only in case of
        server loss, but also to protect against accidental file removal or an
        awkward bug in a service that deleted important information.
      </description>
      <Group id="xccdf_org.gentoo.dev.swift_group_data-backup-automate">
        <title>Automated backups</title>
        <description>
	  <h:p>
          Automate backups on the system. If the backups are performed manually
          then they are done wrong and someone will eventually forget it.
	  </h:p>
	  <h:p>
          Use scheduling software like <h:code>cron</h:code> to
          automatically take backups on regular intervals, or use a central
          backup solution like <h:code>bacula</h:code>.
	  </h:p>
        </description>
      </Group>
      <Group id="xccdf_org.gentoo.dev.swift_group_data-backups-coverage">
        <title>Full data coverage</title>
        <description>
          Many users that do take backups only do this on what they seem as
          important files. However, it is wise to make full system backups too
          as recreating an entire system from scratch could otherwise take days
          or even weeks.
        </description>
      </Group>
      <Group id="xccdf_org.gentoo.dev.swift_group_data-backups-history">
        <title>Retention</title>
        <description>
	  <h:p>
          Ensure that the backups use a long enough retention. It is not wise
          to take a single backup and overwrite this one over and over again, as
          there will be a time that a file needs to be recovered that was corrupted
          long before the last backup was taken.
	  </h:p>
	  <h:p>
          There is no perfect retention period however, as the more backups are 
          kept, the more storage is required and the more money or time needs to be invested in
          managing the backups.
	  </h:p>
	  <h:p>
          In most cases, introduce a "layered" approach on retention. For instance:
	  </h:p>
          <h:ul>
            <h:li>keep daily backups for a week</h:li>
            <h:li>
              keep weekly backups (say each monday backup) for a month
            </h:li>
            <h:li>
              keep monthly backups (say each first monday) for a year
            </h:li>
            <h:li>
              keep yearly backups for 30 years
            </h:li>
          </h:ul>
        </description>
      </Group>
      <Group id="xccdf_org.gentoo.dev.swift_group_data-backups-location">
        <title>Off-site backups</title>
        <description>
	  <h:p>
          Keep the backups off-site in case of disaster. But consider this
          location carefully. Investigate how fast the backup can be put there,
          but also how fast it can be retrieved it in case of need. Also investigate if this
          location is juridically sane (is it allowed to put the data on this location
          and is this off-site location trusted).
	  </h:p>
	  <h:p>
          Also ensure that the backups are stored securely. If necessary,
          encrypt the backups.
	  </h:p>
        </description>
      </Group>
      <Group id="xccdf_org.gentoo.dev.swift_group_data-backups-validate">
        <title>Validate and test</title>
        <description>
          Validate that the backup system works. Try recovering files (for
          instance on a second server or different location) or even entire
          systems (virtualization is a great help here) and do this regularly.
        </description>
      </Group>
    </Group>
  </Group> <!-- Data flows -->
  <Group id="xccdf_org.gentoo.dev.swift_group_removal">
    <title>Decommissioning servers</title>
    <description>
      When a server needs to be decommissioned, make sure that its data
      is safeguarded from future extraction.
    </description>
    <Group id="xccdf_org.gentoo.dev.swift_group_removal-wipedisk">
      <title>Wipe disks</title>
      <description>
        <h:p>
        Clear all data from the disks on the server in a secure manner.
        Applications like <h:b>shred</h:b> (part of
        <h:code>sys-apps/coreutils</h:code>) can be used to security wipe data
        or even entire partitions or disks.
	</h:p>
	<h:p>
        It is recommended to perform full disk wipes rather than file wipes.
        If this needs to be done on file level, see if the file system
        journaling can be disabled during the wipe session as journaling might "buffer" the
        secure writes and only write the end result to the disk.
	</h:p>
      </description>
      <reference href="http://csrc.nist.gov/publications/nistpubs/800-88/NISTSP800-88_rev1.pdf">NIST Publication "Guidelines for Media Sanitization" (PDF)</reference>
    </Group>
  </Group> <!-- Removal -->
</Benchmark>