Transforming Your Utility's Tech Partners into Cybersecurity Allies

The standard definition of cybersecurity is the protection of information assets by addressing the threats to how it is processed, stored, and transported by internetworked systems. This definition provides the key to communications and systems security—at the core, those responsible for cybersecurity must thoroughly understand the internetworked connections and the paths information flows over in order for the utility to be able to buy, sell, and conduct the normal business activities each day.

Communications structures on the network are vital to the operations of any networked activity. These structures require many components to interchange information to other parts and equipment on the network as well as externally to outside devices and connections. The traffic that flows on these structures connects all of the various equipment, servers, workstations, and laptops and requires internetworked data exchange to work properly. Data exchange points are often where cybercriminals will steal data and user passwords from unsuspecting users. Using various forms of encryption on the links between these devices will stall or stop these malicious efforts and is highly recommended in today’s networking environments.

Network managers should begin with the basic network data component, the packet, and from there start to build the parts of the data exchanges that travel the network. Each device adds to and subtracts from these data exchanges as they traverse the network, which is moving the data from one location to another all the time. Since this data is always moving, at each point where it touches another device, managers should ensure there is a record of that activity in logs for further review. This gives the engineers data to monitor the health of the network for checks and balances on the components and parts of the network. The network administrators then review these logs for proper actions and activities to ensure all data is safe and secure as it is processed throughout the network path and traffic flow.

As the Department of Energy’s 2018 energy cybersecurity plan states: “Energy control systems are specially designed digital systems that operate real-time physical processes by dispatching commands to millions of nodes and devices dispersed across the energy delivery infrastructure. These systems exchange massive amounts of data at high speeds over cyber networks to monitor and control physical devices such as transformers, switches, compressors, pumps, and valves. This makes data availability and integrity of paramount importance to energy operations.”³

It’s also a best practice to evaluate software and system-level defects and bugs prior to final operational approval, and the processes needed for this management review effort should be both detailed and well as high level in their implementations. Utilities should ask third-party vendors if they are compliant with reliability standards developed by the North American Electric Reliability Corporation (NERC) and NIST’s Cybersecurity Framework, as well as other industry standards that have been developed over the past 30 years.

In the application development environment, utilities should expect vendors to conduct testing and review of the actual software code components as they are developed to make sure the code is designed and written correctly, as well as when components are placed together with related pieces of code to ensure proper and correct functioning. Once the vendor tests a module and combines it with other developed portions of code, the resulting unit that is created should be evaluated for proper logic flows, functioning, and completeness, all to ensure there are no bugs in the software or activity. Often units are assembled together to provide the full system software, which is also tested to prove it provides the intended functions, logic, actions, and results the programmers intended it to produce. This is a vital step in the development process, since it shows the requirements for the development are being met by the software as well as showing the code is operating as intended. Finally, the system-level examination should be performed, and this process is often conducted by outside reviewers. This step gives utilities an external view into the operation of the application and its software to provide proof the application is functioning properly and proficiently with respect to its intended purpose. This review often results in the discovery of software defects in the code—typically referred to as “bugs”—and identifies possible weaknesses in the logical flow of the processing. These defects and weaknesses are then assigned to the vendor’s programmers for repair and redesign. All of these evaluation efforts are designed to provide the software developer, systems integrators, and end users with the evidence needed for compliance to user requirements, development standards, and regulatory mandates.

Once of this effort is completed, utilities should expect the vendor to conduct operational testing of the full application to show that it will work properly in its intended operating environment with all of the other applications, systems, and devices the application will be operating with under normal circumstances. Upon successful completion, the utility should conduct a formal user acceptance test, which provides all stakeholders with the required reviews, tests, and formal acceptance of the application.

Rigorous operational testing provides utility management assurance that the system under review is meeting the operational requirements, that the user interactions with the system will not impede operations or security of the system, and that the security of the system meets or exceeds mandated requirements for confidentiality, integrity, and availability.

Therefore, the first step in the operational testing previously mentioned is for the utility to conduct vulnerability scan testing of the applications and systems on its network during operations. This step is critical to determining the health of the systems while they are running and producing the expected results. There are many vulnerability scan tools available today, and it is important to test scanners to ensure they are both functional and safe in the operating environment and will not interrupt the operations of the utility’s other applications and systems. Each of these scan tools will need network connectivity to the outside environment as they are often connected to the National Vulnerability Database maintained by the U.S. Government, which defines and lists all of the known vulnerabilities for operating systems, applications, databases, and platforms currently in use around the world. Some of the best practices with use of these scan tools include a scheduled scan time and sequencing after systems and applications are patched, results tracking reporting, and rescans after repair to confirm proper configurations of systems to minimize cyberexposures to internal and external risks.

Another area utilities should look for with third-party vendors is their security use case/abuse case testing of systems and applications. This type of testing centers around trying the “break” the system by testing the potential areas of deficiency on the system and flooding the system with deviations of inputs from the user perspective. Overloading the input fields with extra data, sending incorrect inputs into the system, and sending thousands of possible inputs in rapid sequences (called “fuzz” testing) are all ways to conduct this type of abuse case testing. The intent is to determine the error handling capabilities of the application or system and to ensure the application design accounts for these types of situations successfully and does not fail under duress.

Utilities should also expect third-party vendors to test applications and systems from the outside through penetration testing. In today’s cyberclimate, the ability of the hackers to identify exposures and vulnerabilities of the system through external testing is a very common practice. Penetration testing emulates these actions by the “bad guys” by utilizing the same tools and techniques that they use. Penetration testing allows a utility to identify potential deficiencies and weaknesses in the system and application security posture before the negative effects are realized and a breach happens. There are typically two types of these testing efforts. One is called “white-box” testing and is typically conducted by a known group call the “blue team.” This testing focuses on evaluating the applications and systems from an understanding of the applications and systems themselves. The other type of penetration testing is called “black-box” testing and is often conducted by a “red team,” which attacks the system from outside without knowing any of the internal network or particulars of the applications at all. This effort completely emulates what outside hackers and criminals do when they attack a system. This process often produces results that identify deficiencies in the security posture, the security control implementations, and the security actions taken by the utility’s cyberdefenders. Test results are then used to update and provide inputs to security remediation efforts of the software vendor to improve the security of the applications and systems.

Utilities should use this security baseline to manage and evaluate any change or particular event on a third-party system or application to gauge any differences in operations, maintenance, and security. The process for setting baselines requires a utility to identify the inventory of their IT assets, determine the current state of each inventoried item, then set the minimum security and configuration of that asset. Once that process is accomplished, the system or application settings, configurations, patch level, and minimum user settings are all recorded, and a master list is created with all pertinent data. This result is then called the Minimum Security Baseline (MSB) for that system or application, and the utility can use this MSB in a variety of tests during operation of that system or application to ensure continued security and operation criteria are met.

This MSB of operations, metrics, controls, and configuration settings is often controlled through a utility’s formal configuration management system. This process allows for performance and measurements against security standards and risk frameworks, which produce results for compliance and legal attestation purposes with additional proof of security of the system or application being assured to a measurable level for the utility and its third-party vendor. This MSB promotes the development, implementation, and operation of more secure information systems by establishing minimum levels of due diligence for information security and facilitating a more consistent, comparable, and repeatable approach for selecting and specifying security controls for information systems that meet minimum security requirements.

The concept of the MSB is also adjustable for the operation of systems and applications. Utilities should review security controls at least annually and, if necessary, revised and extended to reflect:

• Experience gained from using the controls.
• Any changing security requirements.
• New security technologies that may be available.