Energy trading and risk management (ETRM) systems have been gaining momentum since the 1990s and continue to be at the heart of many energy companies’ information technology landscapes. In many cases, these applications have been developed and continually enhanced for decades and carry with them a legacy of outdated technologies and software development standards.

While major ETRM vendors have made improvements to their platforms in recent years to address these limitations, relatively few customers stay on the leading edge of software releases. Also, most of the traditional ETRM solutions were originally developed as on-premises solutions and most clients continue to operate them this way. These, and other factors, combine to create the potential for significant cybersecurity risk.

Many companies made significant investments in terms of time and money in the original implementation of their ETRM solution. Over the years, however, these applications have become increasingly integrated with other key enterprise systems like enterprise resource planning (ERP), data warehouses, as well as to external parties such as exchanges/brokers and market data services further expanding cyber risk profile.

The initial capital outlay and recurring operating expense have left little appetite for additional patching or upgrades in the absence of a key new piece of functionality demanded by the business to drive a benefits case even though it’s exactly these steps that serve to reduce the potential exposure.

The Cyber Risk

Energy companies are known to be top targets for malicious actors—particularly those of the state-sponsored and “hacktivist” varieties. Outdated software at any level or layer of the ETRM solution architecture presents a security vulnerability that these cyber threat actors will seek to exploit.

Oftentimes, older applications are incompatible with the latest, most secure operating system (OS), database (DB), and runtime software so these key components also can’t be upgraded. A greater number of older components increase the potential attack surface, and the more aged they are means there are more known exploits available to any would-be hacker.

This software patching “log jam” created by an out-of-date application results in situations like:

• Running older versions of Java, the .NET framework, etc.
• Using past versions of an SQL server or Oracle databases.
• Hosting the application and database on obsolete versions of Windows or Linux.

In more extreme cases, this situation can spiral out to middleware software, custom integration, and touchpoints with third parties such as price data and measurement services. Custom code can be at an increased risk for exploits like credential stuffing or SQL injection, among others.

MORE: What You Need To Know Before Starting An ETRM System Implementation Process

Taken together, these gaps can leave your IT systems exposed to dozens, if not hundreds, of potential cyber exploits. It’s not just about malicious actors gaining access to sensitive trading data, or that they could take a critical commercial and risk system offline, but that the ETRM can be used as a platform to attack other assets on the business network.

Mitigating Actions

The obvious answer is to upgrade the ETRM system, but it can be challenging and time-consuming to build a benefits case, gain approval, and secure funding for a large project. While an organization considers the longer-term prospects of an upgrade or potential re-platforming initiative, below are steps that can be taken immediately to reduce the risk of a cyber incident.

MORE: Postmodern ETRM: Why Technology Should Impact Your Investment Decisions In Trading Systems

• Apply the latest versions and patches of the OS and DB that are compatible with the ETRM vendor’s software—same for components and frameworks like Java and .NET.
• Harden your DB and application servers by removing unnecessary components and access, closing ports, limiting RDP/SSH to whitelisted IP addresses only, etc.
• Run vulnerability scans on your ETRM system’s servers and remediate identified issues by priority.
• Use secure connections running current cryptographic protocols such as TLS (Transport Layer Security)—note that SSL has been deprecated due to known vulnerabilities.
• Consider enabling data encryption in-transit and at rest (either in the DB or storage layer) where feasible.
• Conduct static and/or dynamic code analysis on all custom interfaces and components and remediate security defects by severity.
• Ensure that end-point protection is in place for all devices from the end user’s system, through remote access like Terminal Server or Citrix, to the middle tier and database servers of the ETRM itself.
• Enable logging and leverage a SIEM (Security Information and Event Management) solution to detect unusual activity and provide early warning of a potential breach.
• Segment the network to put legacy systems in their own “box” where access to/from can be limited to those individuals and systems that truly have a need.

The items listed above cover a wide range of costs and complexity, can be implemented in a variety of logical sequences and can be paced in a manner that’s achievable by most IT departments.

Conclusion

At a time when IT, risk, and commercial leaders are being asked to do more with less it can be difficult to justify large investments like those necessary to upgrade or replace an ETRM system. However, the very real risk posed by a potential cybersecurity breach demands prompt and prudent action to be taken to secure the systems comprising a company’s trading and risk IT landscape.

Actions like those previously recommended can go a long way in reducing the ETRM system’s potential attack surface and become a harder target for cyber threat actors.