On 10/25/2012 02:28 PM, Jeffrey Blank wrote:
We will certainly have rules available to that end.
The question is whether you want it encoded as part a compliance
enforcement regime for a wide variety of use cases. Previous consensus
discussion indicated that a single NTP server in an enclave was common
practice, but that that system (acting as an NTP server) commonly used
multiple sources for time.
What would you want to enforce on all systems, as that is our constraint?
Anyone who wishes to _ensure_ time synchronization will use three or
more NTP servers. This is normally a requirement levied for logging and
audit purposes, but interesting things can happen to, e.g., license
servers and clients thereof when clocks drift. Kerberos and AD are also
sensitive to clock drift, as are software authenticators, etc. A
one-second negative clock slew will cause an RSA Authentication Manager
RADIUS service to decide life is no longer worth living (ask me how I know).
Anyone who needs not ensure time synchronization can use less than
three, with an increased expectation of interesting failure modes.
When one server is used, the local system will track it for better or
worse, until it becomes unavailable, at which point the local clock skew
takes over until the server becomes available again, at which point a
fast slew will occur.
With a quorum, there is far more assurance of accuracy as well as
avoidance of fast slews.
Multiple lower stratum NTP servers are cheap as chips to provide, even
in "enclaves". Most commercial network gear can provide NTP.
_______________________________________________
scap-security-guide mailing list
scap-security-guide@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/scap-security-guide
