Introduction

For the purposes of this page the GEISA team consists of any individuals contributing to the specification via the GEISA project and processes and the implementer consists of any entities and/or individuals who are consuming, configuring and/or operating the GEISA specification: Security is a fundamental to the GEISA specification (the “specification”) and responsibilities will vary by entity. The following are the minimum criteria needed for this specification to be successful for GEISA and the implementer:

• Clear expectations must be illustrated outlining what responsibilities fall to the GEISA team vs. the entities or individuals implementing the specification. On this page this will be referred to as the, “Shared Responsibility Model” which is outlined below.

• The specification must afford an implementer the ability(ies) to comply with applicable standards, frameworks, certifications, etc. such as IEC 62443 without an undue amount of overhead.

GEISA Responsibilities Statement

To set expectations GEISA is focused on defining a secure-by-default Common Operating Environment (“COE”) that surfaces the levers needed by the implementer to tailor the COE to their own policy and risk management requirements. For example, out-of-the-box networking may be secure-by-default and deny all access and the implementer has the levers needed to open up networking access as they deem appropriate for an application to run.

Shared Responsibility Model [Refining]

For those who are unfamiliar with a formal Shared Responsibility Model definition major cloud providers provide some good references for their own which helps to understand the concepts at play:

• GCP

• AWS

• Azure

The purpose of defining a clear shared responsibility model in the context of security is to clearly outline responsibilities such that all parties can successfully achieve their security objectives

GEISA Responsibilities

It is important to note that GEISA can’t feasibly account for all implementer operational contexts, architectures, governance and policy requirements, processes, etc. and, as such, the below responsibilities have been identified given these circumstances.

Responsible for:

• Making available a baseline set of functionality that is intended to afford the implementer the ability to meet common security requirements based on an identified, well known, prevailing standard or framework such as IEC 62443.

• Identifying the minimum system requirements in order to run the GEISA specification and testing against those system requirements to prove out a reference implementation in support of implementers.

• Ongoing security assessment and analysis of any versioned required components (e.g. libraries, operating systems, etc.) to ensure that they are supported and current or free of major vulnerabilities or bugs and updating those over time.

• Implementing processes to ensure that contributions to the GEISA specification are properly vetted and carried out by individuals free of malicious intent.

• Defining and maintaining a baseline threat model to identify risks, and where deemed appropriate, altering system design to either mitigate those risks or allow for mitigation of those risks.

Implementer Responsibilities

You as the implementer are best suited, and equipped, to understand the architecture that you are implementing within, the parties involved, the policy requirements and risk appetites, etc. and, as such, the following responsibilities have been identified given these circumstances.

Responsible for:

• Identifying the applicable laws, regulations, required security controls or other security-oriented requirements that they must satisfy and assessing the GEISA specification for suitability to meet those requirements.

• Identifying the underlying hardware, choosing the compatible operating system they wish to use and at their discretion any additional software deemed necessary beyond what is defined in the GEISA specification.

• Once implemented keeping the operating system and any other software current with updates as they are released to fix published bugs, defects, vulnerabilities, etc.

• Defining their own shared responsibility model with any third parties that they may allow to access or provide components to the architecture they implement inclusive of the GEISA specification. For example, any application developers, system operators, etc.

• Defining and maintaining a threat model, which may take into account the GEISA baseline threat model, and identifying applicable risks as well as any appropriate action(s) to mitigate those risks.

• Ensuring achievement all implementer-specific control requirements spanning all relevant Security and Privacy domains.

The GEISA specification may assist the implementer with achieving certain implementer requirements but it is not responsible for the final design, implementation and/or operation of controls defined by the implementer and required to meet certain implementer requirements.

GEISA Baseline Threat Model

The GEISA Execution Environment inputs:

• HAN Interface

  • Gateways

  • Smart Inverters

• LAN Interface

• Environmental Sensors

  • Temperature

  • Humidity

  • Accelerometer

  • Location (GPS)

• Meter Register

• Metrology Sensor

• Provisioning Interfaces

  • Bluetooth

  • Thread

GEISA Execution Environment outputs:

• HAN Interface

• LAN Interface

• Local Storage

• Disconnect Switch(es)

Potential Threats and Causes

• Malicious Firmware & Apps

  • Supply Chain Attack

  • Unpatched Components

  • Compromised Vendor

  • Compromised Employee Workstation

  • Compromised Management System

• Vulnerable Network Interface

  • Poor Programming Practices

  • Inadequate Testing

  • Unpatched Components

  • Supply Chain Attack

• Broken Firmware

  • Poor Programming Practices

  • Incorrect Logic

  • Inadequate Testing

  • Unpatched Components

• Side Channel Attacks

• Malicious Inputs

  • Forged data from Smart Inverters

  • Forged data from EVSE

  • Attack on the Provisioning Interface

• Privilege Escalation

• Isolation Escape

  • Attacker is able to escape isolation mechanism and access core environment

• Direct Hardware Attack

  • Decap Chip

  • Access to programming interfaces

    • Replace Firmware

    • Retrieve and decompile firmware

  • Swap out the chip

• Resource Exhaustion

  • CPU

  • Memory

  • Storage

  • HAN Communications

  • LAN Communications

• Denial of Service

  • HAN Communications

  • LAN Communications

• Peer-to-Peer Attacks

Potential Attacker Objectives

• Access to the Utility Internal Network

• Controlling the Remote Service Switch (or other actuator)

• Attacking devices within the Home

• Coordinated attacks across Homes

  • Note: there are papers which demonstrate that coordinated attacks on as little as 1% of the load can cause grid instability.

• Manipulating readings (typically for theft)

• Steal data (privacy, spying on customers etc.)

• Obtaining Key material to impersonate the meter.

• Turn devices into a botnet (e.g. Mirai, etc.)

We need the GEISA APIs to have well defined rejection mechanisms that inform applications that they have violated policy and allow them to take action. Some Linux APIs will let a process know that it is getting close to it’s limit. Ideally applications could get details on their allocation. The simplest approach would be to (a) rely on existing API mechanisms and (b) share the policy limitations.