CYBERSECURITY IN DISTRICT HEATING INFRASTRUCTURES

Over the past decade, the risk of cyber-attacks has moved high on the agenda in most enterprises and organisations. Traditional risks from changing markets, shifting demographics, and new legislation generally happen slowly, so responsible management has the time and opportunity to react and manage the risk. However, cyber-attacks may happen over-night and target systems in unpredictable ways, potentially threatening the organisation’s very existence.

By Christian Damsgaard Jensen, Applied Mathematics & Computer Science, DTU (Technical University of Denmark)

Organized cyber-criminals have previously focused on private companies, such as the attack on Sony Pictures in 2014 or the NotPetya attack on Maersk in 2017. Still, they are now increasingly targeting public institutions and organizations, such as the ransomware in Baltimore in 2019 or the Conti group’s attack on HSE (Irish Health Services) in 2021. 

Since the outbreak of war in Ukraine, we have started to see attacks on critical infrastructure, such as the 2016 Christmas Ukraine power outage (the war in Ukraine began with the annexation of Crimea in 2014) and the Colonial Pipeline attack in 2021; critical infrastructure has previously been considered off-limits for cyber-criminals.

District heating (DH) services both private and public customers. Examples include homes, from individual homes to large housing estates, private companies and production facilities, and public buildings, such as hospitals and prisons. DH must, therefore, be considered critical infrastructure, where the board, directors, and all the employees share a common responsibility to ensure continuity of service to all their customers. 

From a cybersecurity perspective, this means that DH will be subject to existing and emerging legislation that governs the online world, both EU regulation, such as the Cybersecurity Act, NIS 2, the Cyber Resilience Act, and, of course, GDPR, but also national regulation from the country where the district heating utility operates.

Introduction

As indicated above, we have recently come to realize that critical infrastructure is not simply a label to put on systems, but the infrastructure is critical to both individuals and society. If a DH company fails because of a ransomware attack, thousands of individual households may be without heat in the middle of the winter, but if the company’s customers include a hospital or a prison, people who cannot or should not be moved may be without heat. 

Moreover, commercial customers, such as factories, who require high temperatures for their processes, will be unable to operate, and if district cooling is part of the services provided by the utility, cold storage facilities, and data centers may fail to deliver their services, which will have serious knock-on effects for food security and cloud computing services.

There is, therefore, an increasing focus from regulators and the public concerning the cybersecurity of critical infrastructure. The EU recently adopted the NIS 2 directive, which sets the baseline for cybersecurity risk management measures and reporting obligations across all sectors covered, including most critical infrastructure. 

NIS 2 is not an EU regulation, unlike GDPR, but it is a directive defining measures that each member state must implement in national legislation before 17 October 2024. The focus is on risk management, so national legislation and the organisations it regulates must follow a risk-based approach to cybersecurity, which aligns with current standards and best practices in the area. 

Taking a risk-based approach means that small organisations with few customers will not be covered by the NIS 2 regulation unless service failure may have large consequences for at least one of their customers. It is, therefore, important for all DH companies to perform a risk analysis, which must include an impact analysis of service failure to all their customers.

The directive also defines a scheme of fines for non-compliance, like the heavy fines in the GDPR, and it explicitly identifies the board’s responsibility to ensure that the board has sufficient cybersecurity expertise to implement a robust risk management framework for the organisation. 

Moreover, the board is responsible for ensuring that top management has the necessary cybersecurity expertise to implement the cybersecurity strategies and frameworks defined by the board and to oversee the development of required cybersecurity expertise throughout the organisation. If the board fails to fulfil this responsibility, individual board members may be held personally liable for the consequences of a cyber-attack.

Security Goals

To understand and discuss the security of systems, it is important to identify the security goals the system is designed to meet. Standard security properties include Confidentiality, Integrity, and Availability, often known as the CIA Triad. These properties often relate to data stored on or exchanged between computers, but focusing exclusively on these properties fails to address security issues in the context of the organisation, e.g., supporting the long-term strategic goals or the day-to-day business of the operation.

An organisation operating a DH infrastructure must achieve at least three goals: correctly and reliably collecting data necessary to bill their customers, protecting this customer data from unauthorized access, and monitoring and regulating their network according to a standard control loop. What are the respective security properties required to achieve each of these goals?

We look at each of these goals and show how the relative importance of the three security properties changes for the three high-level security goals.

1. The collection of billing information is important to all utility companies. This data must be correct, complete, and consistent if a utility company is to issue accurate bills and retain its customers’ confidence. Moreover, if a utility company is unable to demonstrate that correct billing information is collected from its metering infrastructure, the regulator may ultimately revoke the organisation’s license to operate. Therefore, the priority of the three security properties must be Integrity, Availability, and Confidentiality (IAC) in order of decreasing importance.
2. In addition to collecting the metering information from all subscribers, the utility company must maintain customer information about each subscriber. This includes information about the name and address of the subscriber, payment methods, and history, e.g., if the customer is in arrears, so this is personal data regulated by GDPR.
   Therefore, the priority of the three security properties must be Confidentiality, Integrity, and Availability (CIA). Interestingly, billing information becomes customer data once received from the meter and associated with the individual customer, so the priority of security properties of meter data changes from when sent over the network to when it is received and stored on the DH organisations system. This is primarily important for the choice of security measures implemented to protect the data.
3. Finally, the utility must be able to control the production and distribution of heating throughout the network to meet its customers’ actual demand. Actively controlling the infrastructures requires controlling pumps and changing valve settings, which again requires reliable distribution of control signals throughout the district heating network. These control signals must arrive quickly and reliably, so the priority of the three security properties is Availability, Integrity, and Confidentiality (AIC).

Security Mechanisms

We have seen that the priority of the three security properties differs for each of the main security goals. In the following, we look more closely at the security challenges and mechanisms normally used to address these challenges.

Secure Collection of Billing Information

The secure collection of billing information relates to the correctness of the measurements performed by the heating meter and the security of the communication between the meter installed at the subscriber address and the backend systems installed at the district heating organisation.

Ensuring the integrity of the meter data requires the correct production, configuration, and operation; this includes protection against tampering by customers who may wish to reduce their bills. Most of these goals can be achieved by having certified professionals install the meter and putting a seal on the meter to allow detection of customer tampering. 

Protecting the integrity between the meters and the DH organisation’s backend systems requires the ability to authenticate the meter to the backend system and detect data modification in transit; both requirements are typically addressed using cryptography.

The availability of metering data means that the meter should function correctly and that there is reliable communication between the meter and the backend system. Meters are usually reliable if not tampered with (see integrity above). Still, they may be attacked by hackers if the meter is accessible from the Internet, so meters are often protected by a firewall or communication using a dedicated communication channel, such as a GSM, 4G, or 5G modem. 

Moreover, communication may fail if the normal connection between the meter and the DH organisation fails; this is particularly relevant for Internet communication that may be subjected to Denial of Service attacks, where the backend system is overwhelmed by network traffic from unrelated sources. Availability is primarily addressed by storing data temporarily on the meter so it can be retransmitted if the server did not receive it. This addresses most transient failures in the communication infrastructure. If high availability is required, separate communication channels may be employed; this is known as communication redundancy.

Confidentiality of meter data primarily relates to the communication between the meter and the backend system and is normally addressed by standard cryptographic means.

Protection of Customer Data

The protection of customer data is a standard data protection problem, which the CIA triad was developed to describe.

Confidentiality is ensured through access control, where only users who have been authorized to access data will be allowed to do so. This raises an interesting privacy issue when utilities wish to share data for different purposes, such as allowing the development of apps to calculate average temperatures and DH usage and compare this to the average in the neighbourhood. Due to GDPR, such sharing is difficult without sufficient anonymization, which is difficult to achieve. Finally, data should be encrypted at rest, particularly if stored in the cloud.

Integrity of customer data is usually achieved through the same access control mechanism as confidentiality. Encrypted data at rest can be integrity-protected by the same integrity mechanisms used to transmit meter data mentioned above.

Availability of customer data is mainly achieved by maintaining several copies on separate local storage servers or copying data to the cloud. Regardless of the solution, it is important to encrypt customer data before they are written to the local disk or cloud storage solution.

Controlling the District Heating Network

Controlling the DH network requires correct, complete, consistent, and timely input from the sensors installed. The first three properties can be achieved by the same mechanisms as the collection of billing information. However, the timely transfer of operational parameters from the sensors is necessary for the correct generation and distribution of heat in the network; this is why availability should be prioritized over integrity and confidentiality. 

Availability of the communication channels ensures timely communication of measurements from the sensors installed in the network to the backend system and control commands from the backend system to the actuators that control the physical distribution of heating in the network. The timeliness requirement means that storing commands locally and retransmitting them again later, when communication channels have been re-established, is unacceptable, so subsystems must either be designed to enter autonomous operation if control signals are lost, or separate (fully redundant) communication channels must be built into the system.

Integrity and confidentiality of the control signals, parameter settings, and software updates exchanged between sensors, actuators, and the backend system can be protected by the same cryptographic means used to protect the integrity and confidentiality of billing information mentioned above.

Implementing Security in District Heating Systems

DH is a socio-technical system involving people and technology, so cybersecurity solutions must address organisational and technological concerns.

Organisational Considerations

Organisations must consider all risks that arise from their use of IT, regardless of whether this is from sensors and actuators embedded in artefacts of everyday life, such as thermostats, pumps, meters, or other remote-controlled infrastructure, or it is from administrative systems used for forecasting, billing, or administration. 

As mentioned above, implementing NIS 2 means that boards of critical infrastructure companies, such as DH utilities, must have sufficient cybersecurity qualifications to define risk management strategies and oversee the implementation of policies and controls to address cybersecurity issues. 

In addition to security education and training efforts, responsible organisations will run general security awareness programs to reduce the risk of employees becoming victims of social engineering, where an attacker tricks the employee to disclose sensitive information or provide access to protected resources or computer systems.

The goal must always be to increase the organisation’s robustness against cyber-attacks through developing security incident and disaster recovery plans (so-called playbooks) and running periodic exercises to ensure that all aspects of the plans are still relevant and feasible and that everybody in the organisation knows their role. 

Developing a good playbook requires a thorough risk analysis, which should also include a threat model. Risk analysis focuses on the cause and effect of unwanted events in the system (aka. security incidents), whereas threat analysis focuses on a threat agent’s motives, means, and opportunities; typically, an external hacker, but insider threats are also considered.

Risk analysis

Risk analysis is a mature area that has developed over centuries in public safety and the insurance industry. In most cases, the risk analyst will focus on security incidents and estimate their likelihood and consequential costs. Some potential security incidents may be well known and understood; this helps estimate the likelihood and consequence, but cybersecurity transcends natural hazards and must deal with an intelligent and motivated adversary. 

This means that systems must be analysed regularly with an eye to what can possibly go wrong, in addition to examining things that have gone wrong in the past or gone wrong in other systems. Standard risk management techniques, such as the ISO 31,000 family of standards, the ISO 27,005 standard on information security risk management, or NIST Special Publication 800-37 Rev2, provide a good foundation for risk analysis, but it is important to adapt the analysis to the specific system or infrastructure.

Threat Model

The threat model describes how an attacker may harm the system and its components. The focus is not so much on the assets and resources managed by the system but on the adversaries’ motives, tactics, techniques, and procedures (TTP). It is common to focus on external attackers, such as cyberespionage, cybercrime, cyber-activism, and cyber-terror, but the threats from insiders must also be considered.

The motives and capabilities of an external attacker determine the efforts employed to address the threats, e.g., cybercriminals aim to maximize profits and minimize threats, so they will not spend much effort attacking a low-yielding target. However, small organisations with low ransom payment capability may be hurt by cybercriminals if they share technology or infrastructure with larger organisations. 

The NotPetya attack that hit Maersk in 2017 is most likely an example of this, where Maersk was collateral damage in the conflict between Russian hackers and Ukraine. The technical controls described in the next section primarily focus on the threats from external attackers.

Insider threats are typically attributed to disgruntled or incompetent employees who destroy or leak data maliciously or by mistake. We must, however, also consider the threats from social engineering, where loyal and competent employees are tricked into disclosing information or providing system access to an unauthorised outsider. This suggests that all systems should be configured according to the Principle of Least Privilege, where employees can only access information and systems relevant to their current tasks.

Technological Considerations

Traditional security technologies focus on fortifying the perimeter, so malicious outsiders find it hard to enter and harm the internal systems. Most organisations separate their internal network from the Internet and only allow access to the inside network through its Firewall. The Firewall filters all network communication according to predefined policies, so only responses to communication originating inside the organisation, e.g., loading webpages or communication from authenticated and authorised outsiders, will be allowed through the Firewall. 

One consequence of the perimeter security model, enforced by firewalls, is that an attacker who manages to breach the perimeter has easy access to all systems on the inside network; this is why perimeter security is sometimes called the eggshell model because it has a hard outer shell, but is all soft and gooey on the inside.

With the increasing integration of systems across organisations and aggregation of services from different Cloud providers, the security perimeter has blurred. Zero Trust Architectures (ZTA) have emerged to address many problems with open orchestration of servers and services from different providers. By removing implicit trust in other entities, ZTA promises security based on verifiable attributes, such as identities (user and device), credentials, and policies.

Zero Trust Architectures

Zero Trust Architectures are often defined through several fundamental principles (aka. the tenets of Zero Trust,) which typically include variations of the following five major tenets: Assume a Hostile Environment; Presume Breach; Scrutinize Explicitly; Apply Unified Analytics; and, perhaps most important, Never Trust, Always Verify.

Implementing a ZTA requires all users, devices, and applications to be continuously authenticated so that it becomes harder to exploit existing trust relationships between components in the system. The context of interactions must be considered and only be allowed to proceed if they fit the policy or profile for the specific users and devices. This means that interaction must be aborted outside the user’s regular working hours or origin (workstation or physical location) and the device requesting a service to be performed. In many ways, ZTA implements perimeter security for every system component, so the single large shell is replaced with many smaller shells; this can be visualized by thinking that the ostrich egg is replaced by caviar.

In addition to the overall system architecture, the security of a system requires secure components that are integrated in secure ways using secure communication protocols; this is sometimes called proactive security. This can be difficult for end users to determine directly, so it is crucial to identify relevant security goals and include these in the requirement specification when systems are developed or purchased. In addition, to secure the implementation and configuration of the systems included in the infrastructure, the system must also be managed and evolve in secure ways; this is sometimes called reactive security. In addition to logging all security-relevant events in the system and continuously monitoring these logs to determine whether the system is under attack, it is also common to hire external security experts to try and penetrate the security; this is called a penetration test or pen-test of the system. A lot of attention and money is paid to pen tests now. Any vulnerabilities uncovered by a pen test must be addressed. Still, it is essential to remember that even the most frequent and expensive pen-testing program does not replace a sound security architecture and substantial proactive security efforts.

Security Evaluation and Certification

Developing a security architecture that balances the security goals against other goals, such as the maintenance of physical infrastructure, requires an understanding of an organisations current security posture, the well-defined security goals that we discussed above, and gap analysis to inform the transformation from the security posture “as is” to the security posture required by legislation and regulation and expected by subscribers.

This implies an evaluation of the security posture of DH utilities, which normally follows some security maturity model. We do not discuss these models here beyond observing that they follow the same general pattern, from no structured approach to security through more structured approaches to security documented by self-assessment to very structured approaches following an externally defined framework and evaluated by an external certification agency.

Large DH utilities or utilities with subscribers considered part of the critical infrastructure, such as hospitals, cold storage, or vital production facilities, must aim for higher maturity levels. Smaller DH utilities, with relatively few mostly private households, may start off aiming for a lower maturity level. It is, however, important to note that more mature utilities are less likely to be compromised by a cybersecurity attack, so all utilities should aim as high as economically possible to ensure continuity of service and retain their subscribers’ trust. 

Summary and Conclusions

With the increasing dependence on DH and the increasing regulation of cybersecurity in critical infrastructure, security governance and the ability to demonstrate compliance with regulations and good security practices, in general, are receiving increasing focus.

We have examined the importance of explicit security goals that reflect the risk to the utility and its subscribers and described different techniques and technologies that may help achieve these goals. The purpose of this article is not to suggest how security-responsible employees in DH utilities should organize their work but to raise the security awareness of all employees in DH utilities and to help those smaller DH organisations realize that they form part of critical infrastructure that may soon be regulated. Few organisations are sufficiently large to justify an internal security department, so smaller organisations must hire external help from specialist security companies or by forming DH cybersecurity co-operatives that may serve many smaller DH utilities in the same geographical area.

For further information please contact: Christian Damsgaard Jensen, mailto:mcdje@dtu.dk