Things change in unexpected ways, even in network time servers, which in their most basic form are “just clocks.” Back in the day, new software releases came out chock full of new features and, to a lesser extent, bug fixes. We promoted those new features and benefits as the best thing ever and that your network could possibly be impaired without them. Well, times are changing: impairment has a new twist. Rather than not getting the most out of your network, it’s about fortification of what’s already there, or will be.

Enter the new SyncServer S600/S650 release version 2.2 software. I think it has one, maybe two, new features that customers requested. Sure, we’re working on the next best thing in the lab, but this release is primarily for further hardening network security.

What drives a release like this is the brutal security testing of the SyncServers, primarily by large US banks. While I’m glad banks pay a great deal of attention to security—particularly the ones that have my money— the in-depth security testing they’re willing to tell us about is remarkable and the changes they require to the product for internal compliance. It’s as if they tested the accuracy and key timing features of the time server, found them sufficient, then moved on to the more important testing of security.

For example, one large bank shared that they first attempted to hack the network time server externally. Then, they legitimately logged into the SyncServer as a valid admin user and began to try and hack it from within. A bit of a Trojan horse approach, but there was not much interest in what mischief could be done manipulating the time server as a legitimate admin, like changing the time, but rather how the time server could potentially be highjacked for other nefarious purposes.

I must say, though, that the SyncServer is inevitably becoming tougher and more robust by responding to all the security-related feedback. Years ago, we would get copies of reports from port scans and common vulnerabilities and exposures (CVE)-probing programs pointing out a whole host of vulnerabilities. We doggedly worked through them and I can now report we seem to be ahead of at least the CVEs we all know about. But that’s the interesting thing about CVEs: all is safe and secure until it’s not, when the next CVE is reported and we jump to respond . . . which leads me to my final observation on this topic: how do you warranty a product against yet-to-be-discovered CVEs?

My answer is that software support equals network security. The network landscape is a dynamic and dangerous place. CVEs are regularly published and the slow-to-react are easy targets. Just ask Equifax and how their massive data breach was directly attributable to the Apache Struts CVE-2017-5638 announced a few months prior.

For the SyncServer S600/S650 models, it’s the low profile but ever important incremental releases like version 2.2 that keep the drumbeat pace of never-ending security hardening as a form of network security and protection. Personally, I’m thankful my employer is committed to helping my bank keep my money safe. After all, it’s just a clock, right? I think not.

If you would like to learn more about the secure Microsemi SyncServer NTP time servers, this link will get you started.

And now for the disclaimer: these postings are my own and do not represent Microchip’s positions, strategies, or opinions.

I welcome your comments and feedback; connect with me on LinkedIn.

Tags: GPS, Network Time Server, NTP Time Servers, Synchronization, Timing