Radoslaw Skorupka writes: >Although PCI-DSS does not mention explicitly NTP, but this is the only >solution for mainframe, which in turn requires STP enablement, which >means $$$, which is quite unique among other platforms, because others >can act as NTP client for free.
No, you cannot assume that. PCI-DSS does not apparently require a specific time protocol. It requires (or at least steers toward) particular outcomes involving time, in particular that the time be protected, correct, and consistent. From what I've read the PCI-DSS time-related requirements are in the 10.4.x sections (which might be numbered differently in another revision of PCI-DSS). The 10.4.3 part is interesting: "Time settings are received from industry-accepted time sources." Is, for example, monthly dual staffed operator console input of time settings per an audited procedures manual while listening to a WWV broadcast via dial-up telephone (while the update action is tamper-proof video recorded) and with downstream NTP consistent with 10.4.3? I don't know. That's up to the auditor and the industry. (The headline requirement doesn't actually say that the time settings must be received in an *automated* way.) Does "free" NTP (in a particular implementation) provide protected, correct, and consistent time capabilities per PCI-DSS? Not necessarily -- that's up to the auditor and the industry, too. It depends on the definitions of words like "protected," "correct," "consistent," and "trusted." "Free" NTP might not be any/most of those things, particularly in certain non-mainframe virtualized environments. By the way, I'm rather tired of the implicit and explicit criticisms that Server Time Protocol (STP) has a separate charge. So it does. So what? If you need STP, include its cost in your budgeting, negotiate, and/or make whatever decisions you want to make, just as you do with additional capacity (in whatever forms), software licenses, maintenance, storage, staffing, networking, facilities, and the myriad other mainframe and non-mainframe IT costs. There are *plenty* of things you don't pay extra for when you get a zEnterprise mainframe that you do pay extra for (if they're even available) on other platforms. If you *don't* need STP, that's fine too -- and then you don't pay for something you don't need. On the technical merits STP and related time services (including STP's support for NTP standards) are not comparable to "free" NTP and its hardware implementations elsewhere. STP (and the hardware underneath) is unique, with unique qualities and capabilities. IBM decided to recoup STP costs from customers who need STP (i.e. from only those who use it), not from all mainframe customers. Maybe you'd prefer that non-STP mainframe customers subsidize you if you need STP -- I can certainly understand that -- but that didn't happen. It is what it is. In many cases multi-zEnterprise customers only need STP on select machines, not on all machines. Consequently they only pay for STP on the machines that require it, not on all machines they own or lease. OK, but why doesn't IBM offer a "substandard," more basic NTP implementation at no additional charge, and then you can upgrade to the unique/high quality STP (and support those engineering costs) if you want it? Said another way, why doesn't IBM offer something like a PC-class NTP function on zEnterprise? And the answer to that question is another question: do you really want IBM to implement lower quality time services on zEnterprise? I'd vote no, but I'm only one vote. (And does doing that even make economic sense?) Or, should IBM raise the price for everyone (or lower the price less for everyone) so that everyone with zEnterprise gets STP at no additional charge? IBM hasn't chosen to do that, but is that what everyone (or at least what most customers) want? Interesting question! If you think the answer is yes, that the price of zEnterprise ought to increase for everyone (or decrease less for everyone) so that everyone gets STP on every zEnterprise machine at no additional charge, tell your friendly IBM representative. Presumably the most interesting views will be those of customers who don't need (or at least haven't ordered) STP, and presumably customers who need STP would have some fairly predictable views. :-) I'm agnostic on the question. (Perhaps the peculiar nature of institutional budgeting and procurement processes means that STP ought to be a standard feature, even if the price of zEnterprise increases -- or decreases less -- because then there's only one procurement process instead of two in certain instances, and the IT "geeks" like me in the house really want STP even if it can't survive procurement. In other words, maybe you need help working around your own institution's dysfunctions. :-) Maybe!) Likewise, if you think there are standard, no additional charge zEnterprise features and functions that IBM should instead make separately chargeable so that some customers pay less and others pay more, tell that to your friendly IBM representative, too. Be careful what you wish for, though. :-) Writing only for myself here, as always. -------------------------------------------------------------------------------------------------------- Timothy Sipples GMU VCT Architect Executive (Based in Singapore) E-Mail: sipp...@sg.ibm.com ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
