Use Case - Threat Modeling Smart Buildings with IEC/ANSI 62443

Smart building automation systems are neither IT nor OT systems, although these two types of environments are converging as the requirements for shared infrastructure and cross-domain information and data flows are increasing. Smart building environments represent such a convergence where a number of IoT technologies are connected to and managed by IT systems (e.g., for analytics). They include a range of components; from sensors, actuators, control systems, access control, security cameras, HVAC systems, to mobile devices and apps, or cloud storage and analytics. There are three standard families that are being used for IT and IoT/OT networks, including in smart buildings; ISO 27000, IEC 62443, and NIST 800 series. The following briefly discusses the applicability of these standard families to smart buildings.

Coverage

The main question here would be on coverage, i.e., does a given standard have sufficient coverage, as in it contains control mechanisms and rules that fit smart buildings' needs, and can be used to create specific processes to counteract threats and reduce risk and vulnerabilities in those environments and their components. All of the following standard families provide guidelines for that:

ISO 27000: security and privacy controls are developed in ISO 27400 for IoT system environments¹. ISO 27570 is also specifically designed for privacy in smart cities². IT-specific ISO 27001 requirements and 27002 controls also apply.
IEC 62443: this standard series is specifically designed for security risks to OT networks, and applies to IoT networks. Figure 1 (from ISASecure) shows its application to smart buildings³.
NIST 800: the SP 800-82 aims at securing ICS/OT environments, and specifically mentions building automation systems in the standard as shown in Figure 2. 62443 is broader, however, and defines technologies and controls while 800-82 includes implementation and adaptation guidance for controls defined in 800-53. NIST also has the Smart Connected Systems Division which includes the IoT devices and infrastructure group, and other groups developing best practices and frameworks for the security, privacy, safety, reliability, interoperability, and resilience of these systems^{4 5}.

Discussion

Stakeholders in smart building environments, or any IoT or smart connected system, must ensure that the equipment and processes used for automation and control meet certain standards to avoid security issues. For smart building automation, there are three avenues:

Standards that are specific to the smart buildings (or cities, as smart buildings are an integral part of smart cities). They are generally developed to secure IoT-based environments and could be generally applied to smart ‘anything’ (homes, manufacturing, hospitals, etc.),
‘Generic’ security standards from the IT field. They can either partially or completely assist in guiding security in smart buildings, and
Standards from the industrial automation sector. They have more in common with the smart ‘anything’ operations than IT-specific standards. IoT security, however, would have more attack surface in general since it adds the consumer interaction part. On the other hand, an OT system would have more constraints on performance, safety, or resilience especially when it supports mission-critical operations

‍

**62443 application to smart buildings**

The above also shows that the requirements can be divided by the roles involved in running the environment; operators, integrators, and manufacturers:

Operator: a key requirement for an operator is commonly the implementation of an ISMS (Information Security Management System) in compliance with ISO 27001. For non-IT parts of the network, the ISMS is defined in 62443 part 2-1.
Integrator: the same applies to system integrators and service providers. An ISO 27001-compliant ISMS is also commonly required. Indeed, the protection of the integrator's own IT infrastructure is a prerequisite for the installation and maintenance of secure solutions for the operator. Security requirements of smart/connected subsystems, on the other hand, are found in 62443 part 3-3, while the design and deployment requirements are described in 62443 part 2-4.
Manufacturer: the product manufacturer has to protect its own infrastructure too, so ISO 27001 also applies. The components and functions implemented within the smart/connected components should follow both 62443 part 3-3 and 62443 part 4-2. The requirements could also be more specific, e.g., if a more specialized standard exists, such as in the case of smart grids (e.g., IEC 62351)^6.
‍

Threat modeling - Why does it matter?

IoT devices used in smart buildings are highly susceptible to cyberattacks. According to security vendor Kaspersky, the first half of 2021 has seen a 100% increase in attacks on smart devices reaching 1.5 billion, with attackers looking to steal data, mine cryptocurrency, or build botnets⁷. Sectrio's recent global threat landscape report showed an 81% increase in the number of high-value breaches and a 190% increase in published instances of ransom payment in 2021, over 2020⁸. The report also showed that the number of incidents and the cost of ransomware had continued their upward trajectory for the third consecutive year. These attacks will likely continue to rise over the next few years as the IoT/OT sector is still struggling with insecure systems and lack of compliance.

Following relevant standards is becoming more and more critical to prevent cyber intrusions and protect both the users' data and IP. Security hardening will not only protect the end user. In a recent report on IoT security⁹, 96% of technology decision-makers believed that securing products and environments will also make a positive impact on their bottom line. However, there is still low confidence in the current security posture, as only 12% of respondents consider the measures for protection from hackers to be sufficient¹⁰. We believe there is a need to shift left and build security early on, using threat modeling, and following relevant standards for a defense-in-depth approach.

Whether based on a specific standard, best practices, or contextual threat intelligence, threat modeling will identify security threats and areas of potential risk in a system's architecture, and what countermeasures are necessary to fix them early on in the design stage. Smart systems are most in need of threat modeling since they are usually wide open to the entire world and represent bigger security risks and larger attack surfaces. Table 1. Presents some of the most common threat scenarios seen in the wild that a threat model will identify, along with available controls described in the IEC 62443 standard series.

Table 1. Smart buildings threat scenarios and controls.

Conclusion

When it comes to the security of smart ‘anything’, including smart buildings, complying with cybersecurity standards might need a customized strategy to protect all involved systems and equipment. Three standard families, and specific key cybersecurity standards, were mentioned in this article; IEC 62443, NIST 800-82, and ISO 27001. Indeed, many parties are involved and make up crucial parts of those systems, and each one might have specific security needs.

For smart and connected subsystems, the IEC 62443 is a perfect fit to address the security needs of these infrastructures and it ideally complements the IT ISMS. In fact, while initially designed for ICT/OT environments, it has already gained wide acceptance in non-industrial systems and applications that automate (and remotely control/monitor) all types of IoT assets. IriusRisk is uniquely positioned to help you assess your system security against the IEC 62443 standards and provide the countermeasures that will improve your security and reduce your risk and attack surface.

References:

‍