...
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
...
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 getty 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.