INTRODUCTION Purpose and Scope The Advanced Metering Infrastructure (AMI) Common Alarms and Events document is intended to provide a foundation on which AMI vendors and asset owners can develop a standard for AMI alarms and events. The standard will address electric utilities’ need for greater interoperability and standardization of security events and enable Security Information and Event Management (SIEM) vendors to provide better situational awareness and cyber event detection in their products. The scope of this document includes only alarms and events generated by the meter and not the supporting AMI components such as the collection engine, technician service tool, or other AMI equipment at the head end. Additionally, while this document attempts to begin codifying the meaning of alarms and events, it does not attempt to codify their interpretation. EPRI AMI Incident Response Project The goal of the EPRI AMI Incident Response Project is to address several challenges that confront utilities when they are designing systems for detecting and responding to AMI incidents: Lack of a standard set of alarms and events across AMI vendors How to design a scalable Intrusion Detection System (IDS) Guidelines for responding to AMI incidents If a utility deploys meters from multiple vendors, the different data formats and naming conventions for alarms and events can make it challenging and expensive to integrate the AMI systems into the utility's SIEM. A set of common security information objects is needed to standardize the AMI alarms and events across vendors. Codifying security information objects will reduce the resources necessary for a utility to deploy multiple AMI vendors and also reduce the customization that each AMI vendor must do for a specific utility. In the long run, this will also make it easier for third-party security appliance manufacturers to apply their technology to the AMI domain, helping utilities better manage their security. The effective design of an IDS in a utility's AMI environment has several characteristics that differentiate it from the traditional Information Technology (IT) environment. For example, simply deploying a perimeter IDS may not provide the coverage necessary for an AMI system. Since there tends to be mesh networks in addition to IP-based backhaul networks, positioning an IDS at the AMI head-end system could miss malicious activity in the mesh network. Additionally, there can be scalability issues as some utilities deploy millions of meters in their service territory. In addition to the challenges of integrating AMI systems into utility backend systems, it is also unclear what the best practices are for responding to AMI incidents. There is a need for clear
The AMI System Security Requirements topics that are not applicable to alarms and events consist of the following: Confidentiality and Privacy (FCP) Availability (FAV) Identification (FID) Authorization (FAZ) Non-Repudiation (FNR) Boundary Services (FBS) Resource Management Services (FRS) Trust and Certificate Services (FTS) Development Rigor (ADR) Organizational Rigor (AOR) Handling/Operating Rigor (AHR) Accountability (AAY) Access Control (AAC) In cases where an alarm, or event traces to multiple items in AMI System Security Requirements, the following convention is used: ABC.1,2,..,N where ABC denotes the AMI System Security Requirements category code and 1-N denotes the specific requirement in the category. In cases where multiple categories are referenced, a semicolon (;) is used to separate the category (e.g., ABC.1,2; DEF.1.3). The NISTIR 7628 categories that are applicable to alarm and event consist of the following: Access Control (SG.AC) Audit and Accountability (SG.AU) Identification and Authentication (SG.IA) Communication Protection (SG.SC) Information Integrity (SG.SI) In cases where an alarm, or event traces to multiple items in NISTIR 7628, the following convention is used: AB.CD-1,2,..,N where AB.CD denotes the category code and 1-N denotes the specific requirement in the category. In cases where multiple categories are referenced, a semicolon (;) is used to separate the category (e.g., AB.CD-1,2; EF.GH-1.3). This section also includes material related to the Security Profile for AMI. If applicable, these relationships are indicated along with the section of that document referenced. Authentication This section describes alarms, and events related to authentication.
Usage Data Alarms and status events related to the integrity of customer-specific usage data are included in Table 3. Table 3 Usage Data Alarms and Events Event Type ID Name Description Type Traces To USG.1 Usage Data Cleared This event occurs when usage data is cleared from the device. E FAC.23 USG.2 C12.19 Energy Usage Data Table Modified This event occurs when the C12.19 usage data tables are modified on the device. E FAC.23 USG.3 Usage Data Configuration Change This event occurs when there is a usage data configuration change on the device. Types of usage data configurations may include consumption units and multipliers. E FAC.23 Meter Configuration Alarms and status events related to the configuration of the AMI meter are included in Table 4. Table 4 Meter Configuration Alarms and Events Event Type ID Name Description Type Traces To CFG.1 C12.19 Device Configuration Change This event occurs when a device's configuration is changed in the meter’s C12.19 tables. E SG.CM-3, 4, 5 Controls The section describes the alarms and events as it relates to the accountability of control functions on the meter. Meter Disconnect Switch The meter disconnect switch enables the utility to send a signal to the AMI electric meter to disconnect a customer’s power if they are moving, have not paid their electric bills, or for safety purposes. Alarms and events related to triggering must be in place to detect malicious activity. Alarms and status events related to the meter disconnect switch are included in Table 5.
Figure 1: Percentages of IDS vendors for different technologies and environments. Source: publicly available information from top 15 smart grid security solution vendors. 4 Figure 2: Characteristics of a scalable and comprehensive intrusion detection system for AMI 9 Figure 3: AMI Network Diagram Instrumented with IDS Components (Courtesy Justin Searle, UtiliSec)
operations security policy and application configurations head-end Stateless Specification-based Monitoring Inconsistent traffic origin or destination Checking of packet header against security policy and network configuration Collectors and/or head-end 3-4 Integrity of communication traffic Checking of packet payload against protocol specifications Collectors and/or head-end 3-7 Illegitimate use of credentials Checking of system logs against security policy Head-end 5-7 Integrity of node software or hardware Operating system, application, and file integrity checking Meters, collectors, and head-end Host Unresponsive nodes Checking of protocol operations against security policy and application configuration Collectors 2-7 Anomaly-based Monitoring High bandwidth usage Traffic monitoring against normal statistical profiles Meters and/or collectors 3-4 High signal power level Checking of wireless signal against normal statistical profiles Meters and/or collectors 1-2 Monitoring Architecture Components, Topology, and Communications Following guidance on intrusion detection systems from [14], a monitoring architecture for AMI can be decomposed into the following components: Sensors: software or hardware components to capture and analyze network or system activity. In the case of an AMI, sensors should be deployed at the head-end, collectors and meters. Head-end sensors would process a large volume of traffic, while sensors in meters should have minimum computing requirements. Management server: information generated by sensors should be sent to one or several management servers. The roles of the management server are 1) to store events in a database, and 2) to run a correlation and aggregation process to detect intrusions that could not be identified locally. Database server: repository for event information recorded by sensors and management servers. The combination of the management server and the database server is often called a Security Information and Event Management (SIEM). A SIEM can log security events from other sensors than the ones deployed in the AMI. Console: interface that security administrators can use 1) to configure the intrusion detection systems, 2) to monitor the security state of the AMI, 3) to visualize and explore alerts, and 4) to conduct forensics activity. Figure 9 presents the topology of the monitoring architecture with the locations of the various components in the AMI. Figure 9: AMI Network Diagram Instrumented with IDS Components (Courtesy Justin Searle, UtiliSec)
Incident Scenarios [9 – SG.IR-8] This section provides guidance on how to identify specific AMI incidents. The following fields in Table 20 are used to describe each of the incident scenarios listed in the sections below. After the incident scenario has been determined, the incident classification field in Table 25 is used to determine the appropriate remediation strategy to employ. Table 20 – Incident Scenario Description ID Identifier for the incident scenario Incident Scenario Description of the incident scenario Alarms and Events Alarms and events associated with the incident scenario Situation Awareness Data Evidence to support that the incident has occurred Incident Classification Classification of the incident to allow the incident response team to determine an appropriate remediation strategy to employ Physical The following incident scenarios occur as a result of a physical action being taken upon the meter. Table 21 – Physical Incident Scenarios ID Incident Scenario Alarms and Events Situational Awareness Data Incident Classification PHY.1 Attacker installs bypass device to steal electricity Removal Tamper A physical bypass device has been installed. Theft of Energy PHY.2 Attacker tampers with meter to steal electricity Removal Tamper Tamper seals on the meter have been broken. Signs of hardware modification present (e.g., wires or headers soldered onto board) Theft of Energy PHY.3 Attacker vandalizes meter to steal electricity Removal Tamper Communications Lost Signs of physical damage to the meter. Theft of Energy PHY.4 A natural event (e.g., earthquake, fire, or flood) causes the meter to lose power. Device Outage Communications Lost Weather or news reports may indicate that a natural event has occurred. Power Outage PHY.5 Attacker removes meter and inserts it backwards into the Removal Tamper Physical inspection reveals meter is inserted backwards. Theft of Energy
meter housing to steal electricity Reverse Rotation Authentication The following incident scenarios occur as a result of an attacker attempting to bypass authentication controls on the meter. Table 22 – Authentication Incident Scenarios ID Incident Scenario Alarms and Events Situational Awareness Data Incident Classification AUTH.1 Attacker attempts to guess the login credentials to the C12.18 optical port interface C12.18 Failed Login C12.18 Successful Login Event occurs in the absence of any known maintenance activity Theft of C12.18 Logon Credentials AUTH.2 Attacker attempts to bypass the meter’s security controls by injecting C12.22 messages with invalid credentials C12.22 Failed Authentication Inspection of packet captures to detect maliciously modified packets Bypass of Meter Security Controls Communications The following incident scenarios occur as a result of a disruption of communications between the meter and the head end. Table 23 – Communications Incident Scenarios ID Incident Scenario Alarms and Events Situational Awareness Data Incident Classification COM.1 Poor communications between the AMI meter and the head end causes integrity check failures Failed Communications Integrity Check Failed communications integrity checks occur sporadically without any discernible pattern (e.g., types of messages failing integrity checks). Poor Communications Link COM.2 Attacker injects fuzzed packets on the communications link in order to bypass security controls Failed Communications Integrity Check Malformed PDU Events occur with a discernible pattern (e.g., types of messages failing, period in which events occur) Bypass of Security Controls
COM.3 Attacker injects malformed packets in an attempt to spoof the meter’s energy usage Failed Integrity Check Events occur with a discernible pattern related to billing or metering functions. Theft of Electricity COM.4 Attacker employs an active RF jamming attack to disrupt meter communications Communications Lost A number of meters in the same physical locality report a loss of communications Denial of Service COM.5 Attacker floods the communications channel with traffic in order to disrupt meter communications Communications Lost Failed Communications Integrity Check Malformed PDU Meter traffic flow monitoring tools report an abnormally large volume of traffic Denial of Service COM.6 Attacker exploits a meter vulnerability to cause a permanent denial of service Communications Lost Event occurs in the absence of any additional situational awareness data (e.g., natural event, tamper events) Denial of Service Software The following incident scenarios occur as a result of a software error on the meter. Table 24 – Software Incident Scenarios ID Incident Scenario Alarms and Events Situational Awareness Data Incident Classification LOG.1 Attacker injects malicious code in order to bypass security controls on the meter Software Error Malformed PDU Additional signs of suspicious behavior (e.g., unauthorized remote disconnects) Bypass of Security Controls LOG.2 Meter software flaw causes software errors to occur Software Error Incident occurs under specific circumstances in similarly configured meters Meter Malfunction Incident Remediation The next step in the incident management process is remediation. Remediation of AMI incident involves identifying the appropriate remediation strategy to employ. In most circumstances, Remediation of AMI incidents should be performed after the AMI incident scenario and incident classification has been identified. The following best practices have been identified for the remediation of AMI incidents.