operations security policy and application configurations head-end Stateless Specification-based Monitoring Inconsistent traffic Checking of packet header against security Collectors and/or 3-4 origin or destination policy and network configuration head-end Integrity of Checking of packet payload against protocol Collectors and/or communication 3-7 specifications head-end traffic Illegitimate use of Checking of system logs against security policy Head-end 5-7 credentials Integrity of node Operating system, application, and file integrity Meters, collectors, software or Host checking and head-end hardware Checking of protocol operations against security Unresponsive nodes Collectors 2-7 policy and application configuration Anomaly-based Monitoring High bandwidth Traffic monitoring against normal statistical Meters and/or 3-4 usage profiles collectors High signal power Checking of wireless signal against normal Meters and/or level statistical profiles 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)
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)
EPRI_AMI_Incident_Response_20120810.docx