<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 12/17/2013 05:47 AM, Jan Lieskovsky
      wrote:<br>
    </div>
    <blockquote class=" cite"
      id="mid_1819457031_18521079_1387277259135_JavaMail_root_redhat_com"
cite="mid:1819457031.18521079.1387277259135.JavaMail.root@redhat.com"
      type="cite">
      <pre wrap="">slightly related with my previous post, and with experience seen
from customer systems (whole system not rebooted for many of days,
possibly even for years to ensure its work / compatibility), wondering if
the agencies focused on computer security have a recommendation / 
requirement underlying system reboots to be scheduled on regular
basis (like once per month).</pre>
    </blockquote>
    <br>
    I think this could be an "optional" setting for organizations that
    embrace such a practice.<br>
    <br>
    I do not think that it would be appropriate as an essential,
    requisite setting.<br>
    <br>
    Some operating systems do not require rebooting to apply kernel
    updates. Some operating systems can be configured to reboot
    subsequent to a kernel update.<br>
    <br>
    <blockquote class=" cite"
      id="mid_1819457031_18521079_1387277259135_JavaMail_root_redhat_com"
cite="mid:1819457031.18521079.1387277259135.JavaMail.root@redhat.com"
      type="cite">
      <pre wrap="">As already mentioned, on one hand there can be often seen scenarios
when customer(s) don't reboot the system due the fear of breaking
the functionality / compatibility. Such behaviour on the other hand
obviously means, that for example fixes for selected security flaws
(mainly in the kernel) can't be applied completely / correctly,
leaving the system in question still vulnerable to particular attack.

Therefore was thinking if we would want to introduce XCCDF rule /
recommendation requiring the system to be rebooted on regular basis
(like once per month looks reasonable, but opened for proposals),
to ensure this (kernel still being vulnerable) wouldn't happen.

Besides that (I think) even when the reboot should result into
system not being bootable, it's better to find it immediately,
than after period like ~3 years (many of fixes applied at once =&gt;
harder to find out which concrete one actually caused the failure
to boot).</pre>
    </blockquote>
    <br>
    Best to find out sooner than later, unless someone else is destined
    to handle it.<br>
    <br>
    <blockquote class=" cite"
      id="mid_1819457031_18521079_1387277259135_JavaMail_root_redhat_com"
cite="mid:1819457031.18521079.1387277259135.JavaMail.root@redhat.com"
      type="cite">
      <pre wrap="">The corresponding OVAL check could see if there exists particular crontab
entry scheduling reboot once per month (and fail if not). The fix then
would be to add such crontab entry (possibly including "wall" notification
with some delay prior actually performing the reboot).</pre>
    </blockquote>
    <br>
    A proper check would be to determine whether system uptime exceeded
    an arbitrary ([<i>Assignment: organization-defined</i>]) duration.
    This would apply regardless of how system restart was initiated.<br>
    <br>
    A more precise check would be to determine whether any outstanding
    updates deemed essential were applied (via a reboot or other means).
    This is an expression of <a
href="http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r4.pdf">SP
      800-54</a> SI-2.<br>
    <br>
    Regards,<br>
    <br>
    Gary<br>
    <br>
  </body>
</html>