Hi ! I'm trying to help a company I work for to pass an audit, and we've been told we need trusted NTP sources (RedHat doesn't cut it). Being located in Nigeria, Africa, I'm not very knowledgeable about trusted sources therein. Please can anyone help with sources that wouldn't mind letting us sync from them? Thanks a lot!
On 06/02/2014 10:03, Notify Me wrote:
I'm trying to help a company I work for to pass an audit, and we've been told we need trusted NTP sources (RedHat doesn't cut it).
So presuming that your company is using RH or Fedora or CentOS something, the auditors are claiming that Red Hat, Inc is trusted enough to provide a precompiled based operating system with no feasible means of proving its reliability, but that they're not trustworthy enough to provide a clock synchronisation service? My head spins. Get new auditors. Your current ones are stupid. Nick
We're a redhat shop, and we use redhat auth which by default uses redhat NTP sources. Sounds odd to me too. They claim this is what PCI DSS demands. On Feb 6, 2014 11:43 AM, "Nick Hilliard" <nick@foobar.org> wrote:
On 06/02/2014 10:03, Notify Me wrote:
I'm trying to help a company I work for to pass an audit, and we've been told we need trusted NTP sources (RedHat doesn't cut it).
So presuming that your company is using RH or Fedora or CentOS something, the auditors are claiming that Red Hat, Inc is trusted enough to provide a precompiled based operating system with no feasible means of proving its reliability, but that they're not trustworthy enough to provide a clock synchronisation service?
My head spins.
Get new auditors. Your current ones are stupid.
Nick
On 06/02/2014 11:46, Notify Me wrote:
We're a redhat shop, and we use redhat auth which by default uses redhat NTP sources. Sounds odd to me too. They claim this is what PCI DSS demands.
PCI DSS states:
10.4.3 Time settings are received from industry-accepted time sources.
The default RHEL time servers are defined as X.rhel.ntp.org. Many people would consider ntp.org as industry-accepted, and there are several PCI-DSS auditing companies out there who explicitly recommend using pool.ntp.org for this purpose. If that's not good enough, the PCI DSS standards explicitly state in the NTP interpretation section:
More information on NTP can be found at www.ntp.org, including information about time, time standards, and servers.
So, if PCI themselves view ntp.org as being authoritative about NTP I can't see any reason why the time servers they publish wouldn't pass an audit. Nick
Once upon a time, Nick Hilliard <nick@foobar.org> said:
So presuming that your company is using RH or Fedora or CentOS something, the auditors are claiming that Red Hat, Inc is trusted enough to provide a precompiled based operating system with no feasible means of proving its reliability, but that they're not trustworthy enough to provide a clock synchronisation service?
Red Hat does not provide an NTP service themselves. The default NTP config on a Red Hat Enterprise Linux system uses rhel.pool.ntp.org. I suppose some auditor could dislike the "openness" of pool.ntp.org (basically anybody can join). If that is the case, your best bet is to do some combination of the following: - As others have suggested, set up your own stratum-1 clock (can be done for around $100). Ideally you'd set up more than one. - Set up several servers with a static set of NTP servers rather than the general pool servers. See the lists on www.pool.ntp.org; look under the docs for setting up a server to join the pool. You don't have to actually join the pool, but following those docs is a good way to set up a stable server. After that, point the rest of your servers at your "master" servers, rather than the public pool. -- Chris Adams <cma@cmadams.net>
On Thu, Feb 6, 2014 at 9:03 PM, Notify Me <notify.sina@gmail.com> wrote: I'm trying to help a company I work for to pass an audit, and we've
been told we need trusted NTP sources (RedHat doesn't cut it). Being located in Nigeria, Africa, I'm not very knowledgeable about trusted sources therein.
Obviously "trusted" time sources are important, but at the end of the day you have to trust someone who ultimately has the least risk (there is never no risk) you are able to achieve. I appreciate "least level of risk" is subjective to your auditors opinion (in this case) :-) Just wanted to mention, having a good number of servers (not blindly trusting <= 3 unique sources) adds some additional protection against 'false-tickers'. Even "trusted" time-sources have their off-days due to a myriad of technical reasons. Configure multiple, relatively high stratum (taking into account how many stratum's you intend to serve downstream), low-jitter/rtt, good-quality, time-sources. Also, risk changes over time, so vigilant monitoring is important too! Regards, Chris.
participants (4)
-
Chris Adams -
Chris Keladis -
Nick Hilliard -
Notify Me