Finish off old document

2 files changed, 252 insertions, 184 deletions

diff --git a/xml/SCAP/gentoo-oval.xml b/xml/SCAP/gentoo-oval.xml
index 4fe52b9..8cc1398 100644
--- a/xml/SCAP/gentoo-oval.xml
+++ b/xml/SCAP/gentoo-oval.xml
@@ -396,6 +396,37 @@
       <criterion test_ref="oval:org.gentoo.dev.swift:tst:23" comment="/etc/inittab single user settings refers only to '/sbin/rc single' or '/sbin/sulogin'" />
     </criteria>
   </definition>
+
+  <definition id="oval:org.gentoo.dev.swift:def:23" version="1" class="compliance">
+    <metadata>
+      <title>Verify that /etc/hosts.allow exists</title>
+      <affected family="unix">
+        <platform>Gentoo Linux</platform>
+      </affected>
+      <description>
+        This definition tests if /etc/hosts.allow exists. 
+      </description>
+    </metadata>
+    <criteria>
+      <criterion test_ref="oval:org.gentoo.dev.swift:tst:24" comment="/etc/hosts.allow exists" />
+    </criteria>
+  </definition>
+
+  <definition id="oval:org.gentoo.dev.swift:def:24" version="1" class="compliance">
+    <metadata>
+      <title>Verify that /etc/at/at.allow exists</title>
+      <affected family="unix">
+        <platform>Gentoo Linux</platform>
+      </affected>
+      <description>
+        This definition tests if /etc/at/at.allow exists. 
+      </description>
+    </metadata>
+    <criteria>
+      <criterion test_ref="oval:org.gentoo.dev.swift:tst:25" comment="/etc/at/at.allow exists" />
+    </criteria>
+  </definition>
+
 </definitions>
 
 <tests>
@@ -587,6 +618,20 @@
     <ind-def:state state_ref="oval:org.gentoo.dev.swift:ste:6" />
   </ind-def:textfilecontent54_test>
 
+  <unix-def:file_test id="oval:org.gentoo.dev.swift:tst:24"
+    version="1" check="all" check_existence="all_exist"
+    comment="Tests that /etc/hosts.allow exists">
+    <!-- The /etc/hosts.allow file -->
+    <unix-def:object object_ref="oval:org.gentoo.dev.swift:obj:14" />
+  </unix-def:file_test>
+
+  <unix-def:file_test id="oval:org.gentoo.dev.swift:tst:25"
+    version="1" check="all" check_existence="all_exist"
+    comment="Tests that /etc/at/at.allow exists">
+    <!-- The /etc/at/at.allow file -->
+    <unix-def:object object_ref="oval:org.gentoo.dev.swift:obj:15" />
+  </unix-def:file_test>
+
 </tests>
 
 <objects>
@@ -664,6 +709,16 @@
     <ind-def:instance operation="greater than or equal" datatype="int">1</ind-def:instance>
   </ind-def:textfilecontent54_object>
 
+  <unix-def:file_object id="oval:org.gentoo.dev.swift:obj:14"
+    version="1" comment="The /etc/hosts.allow file">
+    <unix-def:filepath>/etc/hosts.allow</unix-def:filepath>
+  </unix-def:file_object>
+
+  <unix-def:file_object id="oval:org.gentoo.dev.swift:obj:15"
+    version="1" comment="The /etc/at/at.allow file">
+    <unix-def:filepath>/etc/at/at.allow</unix-def:filepath>
+  </unix-def:file_object>
+
 </objects>
 
 <states>
diff --git a/xml/SCAP/gentoo-xccdf.xml b/xml/SCAP/gentoo-xccdf.xml
index bc6d977..6b3172e 100644
--- a/xml/SCAP/gentoo-xccdf.xml
+++ b/xml/SCAP/gentoo-xccdf.xml
@@ -71,6 +71,11 @@
     <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>
   <Group id="xccdf_org.gentoo.dev.swift_group_intro">
     <title>Introduction</title>
@@ -161,14 +166,14 @@
         To validate the tests, the following commands can be used:
         <h:pre># <h:b>oscap xccdf eval --profile xccdf_org.gentoo.dev.swift_profile_default gentoo-xccdf.xml</h:b></h:pre>
         <h:br />
-        To generate a full report in HTML as well, you can use the next command:
+        To generate a full report in HTML as well, use the next command:
         <h:pre># <h:b>oscap xccdf eval --profile xccdf_org.gentoo.dev.swift_profile_default --results xccdf-results.xml --report report.html gentoo-xccdf.xml</h:b></h:pre>
         <h:br />
         <h:br />
         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. We will try to document the reasoning behind
-        the settings but you are free to deviate from them. If that is the case,
+        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.
       </description>
@@ -278,9 +283,9 @@
       Before we start deploying Gentoo Linux and start hardening it, it is wise
       to take a step back and think about what we want to accomplish. Setting
       up a more secured Gentoo Linux isn't a goal, but a means to reach
-      something. Most likely, you are considering setting up a Gentoo Linux
-      powered server. What is this server for? Where will you put it? What other
-      services will you want to run on the same OS? Etc.
+      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>
@@ -298,10 +303,10 @@
         <h:br />
         Security is about reducing risks, not about harassing people or making
         work for a system administrator harder. And reducing risks also means
-        that you need to keep a clear eye out on your architecture and all its
-        components. If you do not know what you are integrating, where you are
-        putting it or why, then you have more issues to consider than hardening
-        a system.
+        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.
       </description>
     </Group>
     <Group id="xccdf_org.gentoo.dev.swift_group_preinstallation-requirements">
@@ -406,7 +411,7 @@
             Let's start with the disadvantages:
             <h:ul>
               <h:li>
-                Separate file systems mean that you need to do better disk space control
+                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
@@ -548,7 +553,7 @@
     <Group id="xccdf_org.gentoo.dev.swift_group_installation-toolchain">
       <title>Use a Hardened Toolchain</title>
       <description>
-        When you install Gentoo, use the hardened stages and hardened toolchain.
+        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:br />
@@ -839,19 +844,18 @@ mount -o remount,noexec /dev/shm
         <title>Disk quota support</title>
         <description>
           Most file systems support the notion of <h:em>quotas</h:em> - limits
-          on the amount of data / files you are allowed to have on that
-          particular file system.
+          on the amount of data / files that are allowed on that particular file system.
           <h:br />
           <h:br />
-          To enable quotas, first configure your Linux kernel to include
+          To enable quotas, first configure the Linux kernel to include
           <h:code>CONFIG_QUOTA</h:code>.
           <h:br />
           <h:br />
           Next, install the <h:code>sys-fs/quota</h:code> package.
           <h:pre># <h:b>emerge quota</h:b></h:pre>
           Then add <h:code>usrquota</h:code> and <h:code>grpquota</h:code> to
-          the partitions (in <h:code>/etc/fstab</h:code>) where you want to
-          enable quotas on. For instance, the following snippet from
+          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:pre>/dev/mapper/volgrp-home  /home  ext4  noatime,nodev,nosuid,<h:b>usrquota,grpquota</h:b>  0 0
@@ -861,8 +865,8 @@ mount -o remount,noexec /dev/shm
           <h:pre>
 # <h:b>rc-update add quota boot</h:b></h:pre>
           Reboot the system so that the partitions are mounted with the correct
-          mount options and that the quota service is running. Then you can
-          setup quotas for users and groups. 
+          mount options and that the quota service is running. Then the quotas for
+          users and groups can be set up.
         </description>
         <reference
         href="http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch28_:_Managing_Disk_Usage_with_Quotas">Managing
@@ -970,7 +974,9 @@ sed -i -e 's:^rc_shell=.*:rc_shell="/sbin/sulogin":g' /etc/rc.conf
         </Rule>
         <Rule id="xccdf_org.gentoo.dev.swift_rule_inittab-sulogin" selected="false" severity="medium" weight="6.0">
           <title>Test if 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</fixtext>
+          <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>
@@ -990,49 +996,82 @@ sed -i -e 's:^rc_shell=.*:rc_shell="/sbin/sulogin":g' /etc/rc.conf
           More information on the format of these files can be obtained through
           <h:b>man 5 hosts_access</h:b>.
         </description>
+        <Rule id="xccdf_org.gentoo.dev.swift_rule_hostsallow-exists" selected="false" severity="info" weight="0.0">
+          <title>Tests if /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>
+        <title>SSH service</title>
         <description>
           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 to proper hardening is definitely in place.
+          systems so proper hardening is definitely in place.
           <h:br />
           <h:br />
           Please use the "Hardening OpenSSH" guide for the necessary instructions.
         </description>
       </Group>
       <Group id="xccdf_org.gentoo.dev.swift_group_system-services-cron">
-        <title>Cron Service</title>
+        <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>
+          <title>Only allow trusted accounts cron access</title>
           <description>
-            Only allow trusted accounts to use cron. You should list trusted
-            accounts in <h:code>/etc/cron.allow</h:code>. 
+            Only allow trusted accounts to use cron. How to achieve this depends on the cron service
+            installed.
+            <h:br />
+            <h:br />
+            If vixie-cron is installed, then have (only) those users that need cron access take part in the
+            <h:em>cron</h:em> unix group. 
+            <h:br />
+            <h:br />
+            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.
           </description>
         </Group>
       </Group>
       <Group id="xccdf_org.gentoo.dev.swift_group_system-services-at">
-        <title>At Service</title>
+        <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>
+          <title>Only allow trusted accounts at access</title>
           <description>
-            Only allow trusted accounts to use at. You should list trusted
-            accounts in <h:code>/etc/at.allow</h:code>.
+            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:br />
+            <h:br />
+            The format of these files is one username per line.
           </description>
+          <Rule id="xccdf_org.gentoo.dev.swift_rule_atallow-exists" selected="false" severity="low" weight="0.0">
+            <title>Tests if /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>
+        <title>NTP service</title>
         <description>
           With NTP, systems can synchronise their clocks, ensuring correct date
           and time information. This is important as huge clock drift could
@@ -1040,26 +1079,21 @@ sed -i -e 's:^rc_shell=.*:rc_shell="/sbin/sulogin":g' /etc/rc.conf
           commands.
         </description>
         <Group id="xccdf_org.gentoo.dev.swift_group_system-services-ntp-sync">
-          <title>Synchronise The System Clock</title>
+          <title>Synchronise the system clock</title>
           <description>
-            Synchronise your systems' clock with an authorative NTP server, and
-            use the same NTP service for all your systems.
+            Synchronise the systems' clock with an authorative NTP server, and
+            use the same NTP service for all other systems.
             <h:br />
             <h:br />
-            You can accomplish this by regularly executing <h:b>ntpdate</h:b>,
-            but you can also use a service like <h:code>net-misc/ntp</h:code>'s
+            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>.
           </description>
         </Group>
       </Group>
     </Group>
-  </Group> <!-- system -->
-    <!--
-    <Group id="gt-system-services">
-      
-    </Group>
-    <Group id="gt-system-portage">
-      <title>Portage Settings</title>
+    <Group id="xccdf_org.gentoo.dev.swift_group_system-portage">
+      <title>Portage settings</title>
       <description>
         The package manager of any system is a very important tool. It is
         responsible for handling proper software deployments, but also offers
@@ -1068,11 +1102,11 @@ sed -i -e 's:^rc_shell=.*:rc_shell="/sbin/sulogin":g' /etc/rc.conf
         <h:br />
         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 you use Portage as
+        secure environment within Portage (assuming that Portage is used as
         package manager) are important.
       </description>
-      <Group id="gt-system-portage-use">
-        <title>USE Flags</title>
+      <Group id="xccdf_org.gentoo.dev.swift_group_system-portage-use">
+        <title>USE flags</title>
         <description>
           USE flags in Gentoo are used to tune the functionality of many
           components and enable or disable features.
@@ -1101,7 +1135,7 @@ sed -i -e 's:^rc_shell=.*:rc_shell="/sbin/sulogin":g' /etc/rc.conf
           <h:br />
           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 you to identify allowed (and denied) hosts or
+          mechanism which allows configuring allowed (and denied) hosts or
           network segments on application level.
           <h:br />
           <h:br />
@@ -1111,26 +1145,24 @@ sed -i -e 's:^rc_shell=.*:rc_shell="/sbin/sulogin":g' /etc/rc.conf
           client-certificate based authentication mechanism.
           <h:br />
           <h:br />
-          You should set the USE flags globally in
-          <h:code>/etc/make.conf</h:code>.
+          Set the USE flags globally in <h:code>/etc/portage/make.conf</h:code>
+          so they are applicable to all installed software.
           <h:br />
-          <h:pre>
-USE="... pam tcpd ssl"</h:pre>
+          <h:pre>USE="... pam tcpd ssl"</h:pre>
         </description>
       </Group>
-      <Group id="gt-system-portage-webrsync">
-        <title>Fetching Signed Portage Tree</title>
+      <Group id="xccdf_org.gentoo.dev.swift_group_system-portage-webrsync">
+        <title>Fetching signed portage tree</title>
         <description>
           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 you can find the instructions again:
-          <h:pre>
-# <h:b>mkdir -p /etc/portage/gpg</h:b>
+          but as it is quite easy, here are the instructions again:
+          <h:pre># <h:b>mkdir -p /etc/portage/gpg</h:b>
 # <h:b>chmod 0700 /etc/portage/gpg</h:b>
-# <h:b>gpg - -homedir /etc/portage/gpg - -keyserver subkeys.pgp.net - -recv-keys 0x239C75C4 0x96D8BF6D</h:b>
-# <h:b>gpg - -homedir /etc/portage/gpg - -edit-key 0x239C75C4 trust</h:b>
-# <h:b>gpg - -homedir /etc/portage/gpg - -edit-key 0x96D8BF6D trust</h:b></h:pre>
-          After this, you can edit <h:code>/etc/make.conf</h:code>:
+# <h:b>gpg --homedir /etc/portage/gpg --keyserver subkeys.pgp.net --recv-keys 0x239C75C4 0x96D8BF6D</h:b>
+# <h:b>gpg --homedir /etc/portage/gpg --edit-key 0x239C75C4 trust</h:b>
+# <h:b>gpg --homedir /etc/portage/gpg --edit-key 0x96D8BF6D trust</h:b></h:pre>
+          After this, edit <h:code>/etc/portage/make.conf</h:code>:
           <h:pre>
 FEATURES="webrsync-gpg"
 PORTAGE_GPG_DIR="/etc/portage/gpg"
@@ -1138,42 +1170,40 @@ SYNC=""</h:pre>
         </description>
       </Group>
     </Group>
-    <Group id="gt-system-kernel">
-      <title>Kernel Configuration</title>
+    <Group id="xccdf_org.gentoo.dev.swift_group_system-kernel">
+      <title>Kernel configuration</title>
       <description>
         The Linux kernel should be configured using a sane security standard in
         mind. When using grSecurity, additional security-enhancing settings can
         be enabled.
         <h:br />
         <h:br />
-        For further details, I refer to the "Hardening the Linux kernel" guide.
+        For further details, please refer to the "Hardening the Linux kernel" guide.
       </description>
       <reference href="http://www.gentoo.org/doc/en/kernel-config.xml#shorthand">Gentoo Kernel Configuration Guide - Shorthand notation information</reference>
     </Group>
-    <Group id="gt-system-bootloader">
-      <title>Bootloader Configuration</title>
+    <Group id="xccdf_org.gentoo.dev.swift_group_system-bootloader">
+      <title>Bootloader configuration</title>
       <description>
         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.
       </description>
-      <Group id="gt-system-bootloader-grubpass">
-        <title>Password Protect GRUB</title>
+      <Group id="xccdf_org.gentoo.dev.swift_group_system-bootloader-grub1pass">
+        <title>Password protect GRUB (legacy)</title>
         <description>
           It is recommended to password-protect the GRUB configuration so that
-          you cannot modify boot options during a boot without providing the
+          the boot options cannot be modified during a boot without providing the
           valid password.
           <h:br />
           <h:br />
-          You can accomplish this by inserting <h:code>password abc123</h:code>
+          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 if you do not like having a clear-text password in
-          the configuration file, you can hash it. Just start <h:b>grub</h:b>
+          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:br />
-          <h:pre>
-# <h:b>grub</h:b>
+          <h:pre># <h:b>grub</h:b>
 
 GRUB version 0.92 (640K lower / 3072K upper memory)
 
@@ -1186,26 +1216,24 @@ Encrypted: $1$18u.M0$J8VbOsGXuoG9Fh3n7ZkqY.
 
 grub&gt; <h:b>quit</h:b></h:pre>
           <h:br />
-          You can then use this hashed password in <h:code>grub.conf</h:code>
-          using <h:code>password - -md5
-          $1$18u.M0$J8VbOsGXuoG9Fh3n7ZkqY.</h:code>.
+          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>.
         </description>
       </Group>
-      <Group id="gt-system-bootloader-lilopass">
-        <title>Password Protect LILO</title>
+      <Group id="xccdf_org.gentoo.dev.swift_group_system-bootloader-lilopass">
+        <title>Password protect LILO</title>
         <description>
           It is recommended to password-protect the LILO configuration so that
-          you cannot modify boot options during a boot without providing the
-          valid password.
+          modifying the boot options during a boot without providing the
+          valid password is not possible.
           <h:br />
           <h:br />
-          You can accomplish this by inserting <h:code>password=abc123</h:code>
+          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:br />
-          <h:pre>
-password=abc123
+          <h:pre>password=abc123
 restricted
 delay=3
 
@@ -1223,8 +1251,8 @@ image=/boot/bzImage
         </description>
       </Group>
     </Group>
-    <Group id="gt-system-auth">
-      <title>Authentication and Authorization Settings</title>
+    <Group id="xccdf_org.gentoo.dev.swift_group_system-auth">
+      <title>Authentication and authorization settings</title>
       <description>
         An important part in a servers' security is its authentication and
         authorization support. We have already described how to build in PAM
@@ -1232,8 +1260,8 @@ image=/boot/bzImage
         authorization settings are mode than just compiling in the necessary
         functionality.
       </description>
-      <Group id="gt-system-auth-securetty">
-        <title>Restrict root System Logon</title>
+      <Group id="xccdf_org.gentoo.dev.swift_group_system-auth-securetty">
+        <title>Restrict root system logon</title>
         <description>
           To restrict where the root user can directly log on, edit
           <h:code>/etc/securetty</h:code> and specify the supported terminals
@@ -1246,16 +1274,15 @@ image=/boot/bzImage
           <h:br />
           A recommended setting is to only allow root user login through the
           console and the physical terminals (<h:code>tty0-tty12</h:code>).
-          <h:pre>
-console
+          <h:pre>console
 tty0
 tty1
 ...
 tty12</h:pre>
         </description>
       </Group>
-      <Group id="gt-system-auth-userlogin">
-        <title>Allow Only Known Users to Login</title>
+      <Group id="xccdf_org.gentoo.dev.swift_group_system-auth-userlogin">
+        <title>Allow only known users to login</title>
         <description>
           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
@@ -1264,13 +1291,13 @@ tty12</h:pre>
           log on from.
           <h:br />
           <h:br />
-          By enabling these settings, you reduce the risk that a functional
+          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.
         </description>
       </Group>
-      <Group id="gt-system-auth-resources">
-        <title>Restrict User Resources</title>
+      <Group id="xccdf_org.gentoo.dev.swift_group_system-auth-resources">
+        <title>Restrict user resources</title>
         <description>
           When facing a DoS (Denial-of-Service) attack, reducing the impact of
           the attack can be done by limited resource consumption. Although the
@@ -1293,7 +1320,7 @@ tty12</h:pre>
               PAM-aware.
             </h:li>
           </h:ul>
-          Generally, you should suffice with setting
+          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:br />
@@ -1309,8 +1336,8 @@ tty12</h:pre>
 # <h:b>man limits</h:b></h:pre>
         </description>
       </Group>
-      <Group id="gt-system-auth-password">
-        <title>Enforce Password Policy</title>
+      <Group id="xccdf_org.gentoo.dev.swift_group_system-auth-password">
+        <title>Enforce password policy</title>
         <description>
           Usually most organizations have a password policy, telling their users
           how long their passwords should be and how often the passwords should
@@ -1322,16 +1349,14 @@ tty12</h:pre>
           <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 to help you en
-          route.
+          (using comments) and it has a full manual page as well.
           <h:br />
           <h:br />
           A second important player when dealing with password policies is the
-          <h:code>pam_cracklib.so</h:code> library. You can then use this in 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:pre>
-auth      required pam_unix.so shadow nullok
+          <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
@@ -1341,10 +1366,10 @@ session   required pam_unix.so</h:pre>
           password, contain 2 digits and 2 non-alphanumeric characters.
         </description>
       </Group>
-      <Group id="gt-system-auth-ripper">
-        <title>Review Password Strength Regularly</title>
+      <Group id="xccdf_org.gentoo.dev.swift_group_system-auth-ripper">
+        <title>Review password strength regularly</title>
         <description>
-          Regularly check the strength of your users' passwords. There are tools
+          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.
@@ -1356,15 +1381,15 @@ session   required pam_unix.so</h:pre>
         </description>
       </Group>
     </Group>
-    <Group id="gt-system-session">
-      <title>Session Settings</title>
+    <Group id="xccdf_org.gentoo.dev.swift_group_system-session">
+      <title>Session settings</title>
       <description>
         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.
       </description>
-      <Group id="gt-system-session-mesg">
-        <title>Disable Access to User Terminals</title>
+      <Group id="xccdf_org.gentoo.dev.swift_group_system-session-mesg">
+        <title>Disable access to user terminals</title>
         <description>
           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
@@ -1375,45 +1400,37 @@ session   required pam_unix.so</h:pre>
           actions. 
           <h:br />
           <h:br />
-          You can disable this by setting <h:code>mesg n</h:code> in
+          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.
         </description>
       </Group>
     </Group>
-    <Group id="gt-system-fileprivileges">
-      <title>File and Directory Privileges and Integrity</title>
+    <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="gt-system-fileprivileges-worldrw">
-        <title>Limit World Writable Files and Locations</title>
+      <Group id="xccdf_org.gentoo.dev.swift_group_system-fileprivileges-worldrw">
+        <title>Limit world writable files and locations</title>
         <description>
           Limit (or even remove) the use of world writable files and locations.
-          If a directory is world writable, you probably want to have the
+          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:br />
           <h:br />
-          You can use <h:code>find</h:code> to locate such files or directories.
-          <h:pre>
-# <h:b>find / -perm +o=w ! \( -type d -perm +o=t \) ! -type l -print</h:b></h:pre>
+          Use <h:code>find</h:code> to locate such files or directories.
+          <h:pre># <h:b>find / -perm +o=w ! \( -type d -perm +o=t \) ! -type l -print</h:b></h:pre>
           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).
         </description>
-        <Rule id="rule-world-writeable-sticky" selected="false">
-          <title>World writeable directories must have sticky bit set</title>
-          <description>World writeable directories must have sticky bit set</description>
-          <check system="http://oval.mitre.org/XMLSchema/oval-definitions-5">
-            <check-content-ref href="gentoo-oval.xml" name="oval:@@OVALNS@@.static:def:2" />
-          </check>
-        </Rule>
       </Group>
-      <Group id="gt-system-fileprivileges-suidsgid">
-        <title>Limit Setuid and Setgid File and Directory Usage</title>
+      <Group id="xccdf_org.gentoo.dev.swift_group_system-fileprivileges-suidsgid">
+        <title>Limit setuid and setgid file and directory usage</title>
         <description>
           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
@@ -1433,8 +1450,8 @@ session   required pam_unix.so</h:pre>
           the mentioned (parent) directory.
         </description>
       </Group>
-      <Group id="gt-system-fileprivileges-logs">
-        <title>Logs Only Readable By Proper Group</title>
+      <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
@@ -1443,8 +1460,8 @@ session   required pam_unix.so</h:pre>
           <h:code>wheel</h:code>).
         </description>
       </Group>
-      <Group id="gt-system-fileprivileges-rootonly">
-        <title>Files Only Used By Root Should be Root-Only</title>
+      <Group id="xccdf_org.gentoo.dev.swift_group_system-fileprivileges-rootonly">
+        <title>Files only used by root should be root-only</title>
         <description>
           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
@@ -1464,44 +1481,44 @@ session   required pam_unix.so</h:pre>
           </h:ul>
         </description>
       </Group>
-      <Group id="gt-system-fileprivileges-hids">
-        <title>Review File Integrity Regularly</title>
+      <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>
-  <Group id="gt-data">
-    <title>Data Flows</title>
+    </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 your server (and which data
-      this is). You will need this anyhow when you want to add firewalls, but it
+      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="gt-data-backup">
-      <title>Backup Your Data</title>
+    <Group id="xccdf_org.gentoo.dev.swift_group_data-backup">
+      <title>Backup the data</title>
       <description>
-        Make sure that your data is backed up. This is not only in case of
-        server loss, but also when you accidentally remove files or have an
+        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="gt-data-backup-automate">
-        <title>Automated Backups</title>
+      <Group id="xccdf_org.gentoo.dev.swift_group_data-backup-automate">
+        <title>Automated backups</title>
         <description>
-          Automate backups on the system. If you need to perform a backup
-          manually, then you are doing it wrong and will start forgetting it.
+          Automate backups on the system. If the backups are performed manually
+          then they are done wrong and someone will eventually forget it.
           <h:br />
           <h:br />
-          You can use scheduling software like <h:code>cron</h:code> to
+          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>.
         </description>
       </Group>
-      <Group id="gt-data-backups-coverage">
-        <title>Full Data Coverage</title>
+      <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
@@ -1509,22 +1526,21 @@ session   required pam_unix.so</h:pre>
           or even weeks.
         </description>
       </Group>
-      <Group id="gt-data-backups-history">
+      <Group id="xccdf_org.gentoo.dev.swift_group_data-backups-history">
         <title>Retention</title>
         <description>
-          Ensure that your backups use a long enough retention. It is not wise
+          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
-          you might want to recover a file that was corrupted long before you
-          took your last backup.
+          there will be a time that a file needs to be recovered that was corrupted
+          long before the last backup was taken.
           <h:br />
           <h:br />
-          There is no perfect retention period however, as the more backups you
-          keep, the more storage you require and the more you need to invest in
-          managing your backups.
+          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:br />
           <h:br />
-          In most cases, you will want to introduce a "layered" approach on
-          retention. For instance, you can
+          In most cases, introduce a "layered" approach on retention. For instance:
           <h:ul>
             <h:li>keep daily backups for a week</h:li>
             <h:li>
@@ -1539,38 +1555,38 @@ session   required pam_unix.so</h:pre>
           </h:ul>
         </description>
       </Group>
-      <Group id="gt-data-backups-location">
-        <title>Off-site Backups</title>
+      <Group id="xccdf_org.gentoo.dev.swift_group_data-backups-location">
+        <title>Off-site backups</title>
         <description>
-          Keep your backups off-site in case of disaster. But consider this
-          location carefully. Investigate how fast you can put the backup there,
-          but also retrieve it in case you need it. Also investigate if this
-          location is juridically sane (are you allowed to put your location
-          there, and do you trust this off-site location).
+          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:br />
           <h:br />
           Also ensure that the backups are stored securely. If necessary,
-          encrypt your backups.
+          encrypt the backups.
         </description>
       </Group>
-      <Group id="gt-data-backups-validate">
-        <title>Validate and Test</title>
+      <Group id="xccdf_org.gentoo.dev.swift_group_data-backups-validate">
+        <title>Validate and test</title>
         <description>
-          Validate that your backup system works. Try recovering files (for
+          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>
-  <Group id="gt-removal">
-    <title>Decommissioning Servers</title>
+  </Group> <!-- Data flows -->
+  <Group id="xccdf_org.gentoo.dev.swift_group_removal">
+    <title>Decommissioning servers</title>
     <description>
-      When you want to decommission a server, you should take care that its data
+      When a server needs to be decommissioned, make sure that its data
       is safeguarded from future extraction.
     </description>
-    <Group id="gt-removal-wipedisk">
-      <title>Wipe Disks</title>
+    <Group id="xccdf_org.gentoo.dev.swift_group_removal-wipedisk">
+      <title>Wipe disks</title>
       <description>
         Clear all data from the disks on the server in a secure manner.
         Applications like <h:b>shred</h:b> (part of
@@ -1579,14 +1595,11 @@ session   required pam_unix.so</h:pre>
         <h:br />
         <h:br />
         It is recommended to perform full disk wipes rather than file wipes.
-        If you need to do this on file level, see if you can disable file system
-        journaling during the wipe session as journaling might "buffer" the
+        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.
       </description>
-      <reference
-      href="http://csrc.nist.gov/publications/nistpubs/800-88/NISTSP800-88_rev1.pdf">NIST
-      Publication "Guidelines for Media Sanitization" (PDF)</reference>
+      <reference href="http://csrc.nist.gov/publications/nistpubs/800-88/NISTSP800-88_rev1.pdf">NIST Publication "Guidelines for Media Sanitization" (PDF)</reference>
     </Group>
-  </Group>
-  -->
+  </Group> <!-- Removal -->
 </Benchmark>