This audio was created using Microsoft Azure Speech Services
Modern digital remote monitoring platforms offer a lot of promise today….reduced downtime, reduced mean time to recovery (MTTR), less operations overhead, as well as improved efficiency for power and cooling systems. Perhaps most exciting are the platforms’ potential to offer ‘big data’ analytics for the electrical distribution network and mechanical plant. Collecting and analyzing the myriad of sensor and component data could lead to less costly predictive maintenance practices and new control schemes that have a real impact on OPEX. Imagine Field Services arriving right on time with the right parts to prevent a failure. Imagine the mechanical system adjusting fan speeds, valves, pumps, and temp settings automatically in real time to ensure optimal efficiency and control as the climate and load changes. This is the dream…and the realization of that dream is closer than you probably think.
Mikhail Gorbachev and Ronald ReaganDespite this promise, some will be hesitant to invest in a digital remote monitoring due to a lack of trust in the platform’s security. Sure, a monitoring network communicating to the outside world via cloud services using a third party vendor could be an attractive attack surface for cyber criminals. With cyber crime ever present and the threat constantly evolving, data center owners are right to be concerned. A properly architected and maintained remote monitoring platform, however, should allay these concerns. Borrowing the Russian proverb made famous by President Ronald Reagan, users should “trust, but verify”. Before buying, people should thoroughly evaluate platform vendors in the context of cyber security. I just co-authored a new white paper (WP239), “Addressing Cyber Security Concerns of Data Center Remote Monitoring Platforms”, that lays out a checklist of sorts on what to look for (or ask the vendor for proof of) in a secure platform. The following paragraphs briefly summarize this checklist.
Knowing how secure a platform is starts with understanding how it was developed. Mature vendors use a Secure Development Lifecycle (SDL) process that overlays the software development process. SDL is a process by which security is considered and evaluated throughout the development lifecycle of products. The use of an SDL process to govern development, deployment, and operation of a monitoring platform is good evidence that the vendor is taking appropriate measures to ensure security and regulatory compliance. The vendor should be using a process that is consistent with ISO 27034.
How the vendor manages its employees involved in the development, implementation, and operation of the platform is something else to understand. People are a common conduit for cyber attack and so it is important for the vendor to have taken steps to mitigate this threat. Background checks should be mandatory. New hires should go through initial and on-going cyber security training. Developers should have experience with SDL processes and operators ideally should have data center management experience. There should be a well-defined escalation process for handling security violations. The “principle of least privilege” should be in effect where users are only given access to IT and network functions that are needed to perform their job. All users should have individually identifiable accounts to enable full accountability and auditing of system access, use, and changes.
People and process aside, there are recommended design attributes and best practices to look for in the platform itself. The Gateway that collects customer data within the customer’s network should be the only one to initiate connections to the outside: from the gateway to the cloud service. No one outside of the gateway should be able to connect to it first. The gateway cannot be polled without a secure connection first being made by the gateway. Since the gateway does not need to allow inbound connections, this eliminates the gateway as a conduit for attack. The platform should only use secure Hyper Text Transfer Protocol (HTTPS). All authentications should use multi-factor authentication; e.g., using a combo of a username/password and a onetime PIN sent via text. Sensitive data should be encrypted while in rest and when in motion. And, also, the source code should meet current source code compliance standards such as NIST SP 800-53 Rev 4 and DISA STIG 3.9 (currently endorsed by the U.S. Government). On-going security testing and monitoring by a dedicated DevOps team is another critical aspect of the platform and its ability to deal with future, unforeseen threats. White Paper 239 mentioned above goes into the specific test practices to look for and delves deeper into all of the points made earlier.
“Trust, but verify” was a strategic diplomatic principle that served U.S.-Soviet relations well. It helped result in the (unexpectedly) peaceful transition away from the dark days of the Cold War and the freeing of millions from communism. Perhaps, with the same principle in mind we can begin to advance the state of data center operations and maintenance beyond the dark days of break/fix and static controls to an era of predictive maintenance and data-driven, automated operations.
