As illustrated in Figure 1 (see elements in clockwise direction), security is a never ending process consisting of:

Security Risk Assessment Methodology Using IntelliGrid Environments 1. Security Risk Assessment Concepts 1.1 Security Assessment Process As illustrated in Figure 1 (see elements in clockwise direction), security is a never ending process consisting of: Security Requirements Analysis Security Policy Creation and Update Implementation of the security policies and procedures Monitoring for successful and unsuccessful security attacks Analyzing the effectiveness of the installed security mechanisms in regards to changes in technology, regulation, security threats, or monitored events. Re-assessing the Security Requirements based on this analysis Abstract Model for the Security Assessment Process Security Requirements Analysis Security Analysis of Effectiveness of Countermeasures Security Policy Creation Security Expenditures Security Monitoring for Attacks Security Countermeasures Implementation Figure 1: Security Assessment Process As can be seen from the figure, all steps in the process are related to the costs: the Security Expenditures. This is especially important during the Security Requirements analysis, which entails Security Risk Assessment. The costs of implementing security measures must be weighed IEEE P1649 Draft ver 1 1 October 2005

against the costs (financial, safety, social, and legal) if a security attack is successful. If significant costs could be incurred due to an attack, then significant expenditures are warranted to try to prevent such an attack. If the costs due to a successful attack are limited, then the expenditures for implementing the security measures should also be limited. 1.2 Components of Security Requirements Analysis This paper addresses the first element: Security Requirements Analysis. The process of security requirements analysis is an ongoing and iterative process. Business climate, regulations, or global events can all have a direct impact on security requirements. The iterative nature of continuously assessing the security requirements typically requires revision of previously developed requirements. In general the requirements process needs to perform requirements assessments in regards to the following issues: 1. Prevention: This is an analysis of the steps required to protect a given asset, or utility, from a set of known threats. It involves the development of preventative countermeasures, such as passwords, encryption, role -based access methods, locks, data validation, intrusion detection, and other security measures. 2. Security Breach Tolerance: This is an analysis to understand the impact of a successful security attack and the generation of methods to continue business within a given time period. It involves the development of ameliorating or coping countermeasures to minimize the impact of an attack, such as backup systems, backup sources of data, and alternate paths for accessing data. 3. Impact: This is an analysis that determines the results of business operation disruption if a security breach occurs and its impact on customers and other business functions. It involves the assessment of the costs, safety, and collateral damage during an attack and as a direct result of the attack. 4. Resolution: Policies and procedures need to be generated in regards to how to determine how to detect and recover from successful attacks. It involves the equipment, staffing, training, and other procedures to recover from the attack. 5. Prosecution: A security process needs to include an analysis of the type of information and audit procedures needed in order to successfully discover, investigate, and ultimately prosecute an attacker. It involves the implementation of logs, records, and audit trails. These costs associated with these security components need to be calculated and compared: the costs incurred due to a successful attack should be compared to the costs incurred to implement security measures. IEEE P1649 Draft ver 1 2 October 2005

2. Security Risk Assessment Steps The steps to performing security risk assessment and risk mitigation are the following, and are illustrated in Figure 2-1: 1. Describe the Function as a narrative and basic steps, along with drawings to help identify the locations of data and the flows of information. These descriptions do not need to be detailed, but should cover the function from end to end. This should be done by Domain Experts : people who understand the functions and the equipment, but do not necessarily need to understand security technologies. 2. Identify the Information Assets that must be secured: covering software (databases and applications), information exchanges, and hardware. This should be done by Domain Experts. 3. Determine the Configuration and Performance Constraints of these information assets by using the Configuration and Performance Questions. This should be done by Domain Experts. 4. Assess the Security Requirements of Confidentiality, Integrity, Availability, and Non-Repudiation by using the Security Questions for each of the information assets. This should be done by Domain Experts. 5. Identify the IntelliGrid Environments that most closely match the Configuration and Performance Constraints. Using the Configuration and Performance questions, identify the most appropriate IntelliGrid Environments (see http://www.intelligrid.info ). This should be done by Communications Experts : people who understand communications, including security, but do not necessarily understand the function. However, interaction with the Domain Experts is vital to ensuring that the function is truly understood and the correct Environments selected. 6. Develop IntelliGrid sub-environments based on Configuration, Performance, and Security Requirements. Using the IntelliGrid Environments identified as the most relevant to the function, determine the appropriate security domains. This matching may not be exact, but can provide significant support to ascertaining what security services are needed. Ultimately, these combinations of Configuration, Performance, and Security requirements can be used to categorize sub-environments. This should be done by Communications Experts. 7. Identify Security Technologies and Techniques based on these sub-intelligrid Environment recommendations and modified by the Security Questions which identified which security requirements must be met. This should be done by Communications Experts. 8. Select Actual Security Products and Procedures. Company security policies and existing security products should be used to determine what actual security products and procedures should be implemented. This should be done by Utility Communications Experts. IEEE P1649 Draft ver 1 3 October 2005

Security Risk Assessment and Mitigation Process Domain Experts Communications Experts 1 Describe the Function as a narrative and basic steps, along with drawings to help identify the locations of data and the flows of information. 2 Identify the Information Assets that must be secured, specifically databases, data exchanges, applications, and hardware. 3 Determine Configuration and Performance Constraints of these information assets by using the Configuration and Performance Questions. 4 Assess the Security Requirements Of Confidentiality, Integrity, Availability, and Non- Repudiation by using the Security Questions for each of the key information assets. Identify the IntelliGrid Environments (see http://intelligrid.info) that most closely match the Configuration and Performance Constraints. Develop IntelliGrid Sub-Environments By Combining Configuration, Performance, and Security Requirements. This matching may not be exact, but can provide significant support to ascertaining what security services are needed. 5 6 Identify Security Technologies and Techniques based on IntelliGrid Environment / Security Domain recommendations and modified by the Security Questions 7 Select Actual Security Products and Procedures. Company security policies and existing security products should be used to determine what actual security products and procedures should be implemented. 8 Figure 2-1: Security Risk Assessment and Mitigation Process 2.1 Describe the Function Domain Experts should describe the function in narrative form, as well as developing a set of steps that show the sequence of information flows. These descriptions do not need to be detailed, but should focus on the data storage and data flows rather than application algorithms. Drawings are particularly useful to understand the different elements, and will be helpful in subsequent steps of the security risk assessment and mitigation process. 2.2 Identify the Information Assets as Focus of Security Risk Assessment It is clear from the previous discussion that different functions and systems can have very different security requirements, which may change over time or within different locations. Although many of the countermeasures are similar conceptually (e.g. authentication is required as a basic security service), many different technologies and techniques can (or must) be used for different situations (e.g. users can have passwords while applications generally should use certificates). The configuration of a function (e.g. data exchanges take place only within a IEEE P1649 Draft ver 1 4 October 2005

protected environment or are dispersed across large regions) and the performance of the function (e.g. 4 msec response times or contractually mandated time window for data to be available) also impact the types of security measures that could be used. Therefore, a Security Risk Assessme nt method must be used to assess the security risks and to determine what security countermeasures are feasible for each type of asset. Three different classifications of information assets are used, as shown below: 1. Databases and software applications assets, consisting of the data stored within databases, the software application programs, and other software resources within automation systems Assets Requiring Security Risk Assessment Hardware Asset Software Applications 2. Information exchange assets, consisting of the information flows across interfaces between systems and between applications within systems 3. Hardware assets, consisting of power system equipment, automation equipment, computer systems, and communication media and equipment Different types of information assets are associated with different business processes. For instance the EMS monitoring and control function contains the following types of information assets: Device data in the field as it is monitored or calculated Data flows across the communications network Communication network management data (e.g. status of each comm. line) Real-time database in the EMS Control commands across the communications network Control commands at the field devices Data within Database Information Exchanges Figure 2-2: Classification of Assets for Security Assessment These basic types might be further refined based on size or importance of the field device, size and importance of the substation, status vs analog data, etc. However, this refinement should be counterbalanced by the fact that the most crucial data asset will drive the security requirements. For instance, if control of breakers in a substation is the most important information asset, then the security solutions must provide the maximum degree of security needed by that asset; associated assets, such as monitoring of analog values, will most likely just use that same security solution. IEEE P1649 Draft ver 1 5 October 2005

2.3 Determine the Configuration and Performance Constraints of Assets via Questionnaires Configuration and performance questions, based on those developed for the IntelliGrid Architecture, can be used to identify the issues and constraints that will affect the security measures that should or could be deployed. These questions focus primarily on those configuration and performance issues that could influence the security technologies and techniques that would be effective without impacting the tasks that the function is performing. 2.4 Assess Sensitivity of Assets to Security Threats via Questionnaires Since all assets are different, depending upon their intrinsic nature, as well as where they are located and what their function is, the most effective method for assessing their sensitivity to security threats is to ask leading questions of the users and maintainers of the assets. The questions need to approach the security risk sensitivity through basic cost assessment. Although no precise costs are usually necessary for most security assessments, the rough costs associated with a security breach must be estimated and balanced against the costs of prevention or mitigation of a security breach, along with the risk that a security breach might occur. Therefore, three aspects must be considered to arrive at the resulting decision of what types of security measures should be applied: 1. Security Breach Costs. This assesses the cost associated with a successful attack due to failures of the security requirements. All the costs associated the attack should be included, including during the actual attack, recovery from the attack, and any legal or regulatory repercussions from the attack. These security breach costs should be separately assessed for the four security requirements: Confidentiality no unauthorized disclosure of information Integrity no unauthorized modification of information Availability no denial of authorized access Non-Repudiation no repudiation of a transaction The security breach costs for each of these security requirements can further be categorized as follows: a. Direct Impact of a Security Breach: The cost of loss of information, cost of lack of control, cost of loss of power, cost of coping during the breach, safety costs, political and social costs b. Recovery from a Security Breach: The cost of replacing or upgrading compromised equipment, recovering data, and retraining personnel c. Resulting Fallout from a Security Breach: The additional costs stemming from the fallout of having had a security breach in financial, political, regulatory, and legal terms IEEE P1649 Draft ver 1 6 October 2005

d. Prosecution: The cost for audit trails, tracking down the perpetrators, lawyers to prosecute, and lawyers to defend 2. Prevention/Mitigation Costs. The cost of putting in security measures, the hassle of using the security measures, and the need to monitor and enforce security measures. 3. Risk (Probability) That a Security Breach Will Occur. Balancing security breach costs against prevention/mitigation costs requires the assessment of the probability/risk that a security breach will occur. This probability/risk should be assessed based on the following criteria: a. Attractiveness of an asset to an attacker this assesses the likelihood that an attack will be attempted Financial gain for the attacker? Political gain for the attacker? Symbolic results makes the attacker feel good? b. Vulnerability of the asset to attack this assesses the likelihood that an attack will be successful In an enclosed environment with locks on the door? Directly or indirectly connected to the Internet? Are passwords changed from the default? Careless attitudes? Are possible hardware failures adequately taken into account? Are possible software malfunctions adequate ly taken into account? Are possible input or procedural errors adequately taken into account? The assessments can be based on expert judgments to arrive at rough estimates of the sensitivity of each asset to attack. The best method to capture these expert judgments is through a series of questionnaires. Security risk assessment is more of an art than a pure science. Most risk assessments must rely on judgment calls, since risk is, by definition, the probability of an attack, not absolute knowledge. Vulnerabilities of any specific asset are just the thin end of the wedge: if exploited, some seemingly minor vulnerabilities can end up disrupting one or more business processes, potentially causing severe operational or economic damage on TVA or the wider community. Therefore, TVA will need to rely on experience, deductive skills, and imagination to balance security risks against the costs of security measures. 2.5 Identify IntelliGrid Environments That Best Match Each Asset s Configuration and Performance Constraints EPRI s IntelliGrid Architecture analyzed power system operations in great detail, and identified 20 IntelliGrid Environments (see http://www.intelligrid.info) that categorize different aspects of the power industry. In particular, these IntelliGrid Environments were categorized based primarily on configuration issues, performance (quality of service) constraints, and security issues. IEEE P1649 Draft ver 1 7 October 2005

The assets identified in the previous steps can be allocated to these different IntelliGrid Environments, using the configuration and performance questions. For instance, some assets (e.g. protective relays) might be within a substation, while others (e.g. a Wide Area Network) transport data between a substation and a control center. For a given function, the number of IntelliGrid Environments could be one or could be six or ten, depending on the nature of the function. The identification of IntelliGrid Environments should be done by Communications Experts : people who understand communications, including security, but do not necessarily understand the function. However, interaction with the Domain Experts is vital to ensuring that the function is truly understood and the correct IntelliGrid Environments selected. 2.6 Develop IntelliGrid sub-environments based on Configuration, Performance, and Security Requirements The IntelliGrid Environments can be used as a first approximation to match the functions security domain requirements. (Security domains are equivalent to NERC s electronic perimeters.) These approximations are then modified by the answers to the Security Questions (see step 4). These combinations of Configuration, Performance, and Security requirements can then be used to categorize IntelliGrid sub-environments. Using the concept of security domains, information assets can also be classified according to their security requirements. Security domains are a construct (i.e. abstract tool) that can be used to simplify security risk assessment and, in turn, the design of security measures used to mitigate security risks. Assets with common security requirements are grouped together in the same domain, although the common thread(s) may be open to selection. Within that domain, appropriate security measures can be applied to satisfy the common security requirements. Different domains can represent different security requirements or scenarios. What remains is to identify and apply security measures between domains, as required by their security relationships and the risk mitigation goals. Note that security domains can even overlap and/or be nested within one other. When used creatively, this tool can lead to the application of insightful security solutions. The following examples illustrate different kinds of security domains: 1. A physical area, such as a substation. 2. A collection of devices of the same type, such as protection devices or power quality monitoring devices 3. A cyber area, perhaps containing all the assets required for collection of field data: substation devices, the communications network between substations and the control center, and the SCADA system within the control center As another example, one security domain could consist of all the protection devices within a substation, while a second security domain could encompass the entire substation. Security requirements within the Protection Security Domain would only include those needed for protection devices to perform their functions. However, all interactions between the Protection Security Domain and the Substation Security Domain might entail different security measures. IEEE P1649 Draft ver 1 8 October 2005

2.7 Identify Possible Security Technologies and Techniques for Each IntelliGrid Sub-Environment Each IntelliGrid Environment also identifies what security services are most likely to be pertinent. These can be reviewed to determine which are the most appropriate for the relevant IntelliGrid sub-environment. This list, and the descriptions of the security services in the Technical Assessment portion of the IntelliGrid Architecture report and web site, can be used to guide the assessment of possible security technologies and techniques. However, no system can be assessed in isolation, so the IntelliGrid Environments should be viewed as guidelines to be used to ensure the key elements are all covered. 2.8 Select Actual Security Products and Procedures. The final step in the security risk assessment and mitigation process must be performed with complete understanding of other communication requirements, company security policies, and existing security products in order to determine exactly what security products and procedures should be implemented. This should be done by Utility Communications Experts. IEEE P1649 Draft ver 1 9 October 2005

3. Questions Related to Configuration and Performance Constraints Either select (and possibly adapt) one of the IntelliGrid Environments (see http://intelligrid.info/intelligrid_architecture/environments/environments.htm) or fill out the tables below: 3.1 Configuration Constraints The following Table 3-1 provides questions related to performance constraints. Table 3-1: Configuration Constraints Questionnaire Questions Related to Communications Configuration of Asset Needed to assess the vulnerability and the possible security solutions) Select one from each category Connection configuration: Consists of point-to-point interactions between two entities (no networks: includes direct cables, dial-up, point-to-point wireless) Supports networked interactions (e.g. over a LAN or WAN) Single or broadcast configuration: Provides for single source and destination per message (e.g. two -party interactions) Provides multi-cast or broadcast capabilities (e.g. multi-party interactions such as protection devices issuing status or alarm data, or load control signals sent to groups of customer load control devices) Client-Server configuration: Provides interactions between a few "servers" and many "clients" (e.g. central web server with many users accessing it) Provides interactions between a few "clients" and many "servers" (e.g. master station polls many RTUs) Provides interactions between a few clients and a very large number of servers (e.g. automatic meter reading of millions of customers) Internal-External configuration: Provides interactions within a contained environment (e.g. within a substation or control center) Provides interactions across widely distributed sites (e.g. links between a control center and field locations) IEEE P1649 Draft ver 1 10 October 2005

Questions Related to Communications Configuration of Asset Needed to assess the vulnerability and the possible security solutions) Select one from each category Media configuration: Uses fixed communications (e.g. wire, fiber optic cables, fixed wireless systems) Requires mobile communications (e.g. wireless systems, cell phones, mobile radio system) Equipment constraints: No equipment or media constraints Compute-constrained equipment (e.g. meters, limited capability equipment controllers) Media-constrained communications (e.g. power line carrier for bits per second, Bluetooth for distance) Moves and changes: Infrequent changes of equipment or communications Frequent change of configuration and/or location of end devices or sites (e.g. corporate LAN with many moves and changes) IEEE P1649 Draft ver 1 11 October 2005

3.2 Performance Constraints The following Table 3-2 provides questions related to performance constraints. Table 3-2: Performance Constraints Questionnaire Questions Related to Performance Requirements of Asset - Needed to assess the vulnerability and the possible security solutions) Select one from each category Messaging speed: Requires ultra high speed messaging (short latency) of less than 4 milliseconds (e.g. protective relaying messaging) Requires very high speed messaging of less than 10 milliseconds (e.g. sequence of events resolution) Requires high speed messaging of less than 1 second (e.g. typical SCADA data retrieval, most data requested by users) Requires medium speed messaging on the order of 10 seconds or more (e.g. automated data retrieval not necessary for real-time actions) Availability: Requires ultra high availability of information flows of 99.9999+ (~1/2 second per year) Requires extremely high availability of information flows of 99.999+ (~5 minutes per year) Requires very high availability of information flows of 99.99+ (~1 hour per year) Requires high availability of information flows of 99.9+ (~9 hours per year) Requires medium availability of information flows of 99.0+ (~3.5 days per year or more) Time criticality: Timeliness of data acquisition is not very important Requires contractual timeliness (due to operational requirements, regulations or contracts, data must be available at a specific time or within a specific window of time) Time synchronization: Time synchronization is not very important Requires time synchronization of data for age and time-skew information IEEE P1649 Draft ver 1 12 October 2005

Questions Related to Performance Requirements of Asset - Needed to assess the vulnerability and the possible security solutions) Select one from each category Data traffic patterns: Low traffic levels the majority of the time (e.g. less than 20% traffic loading) Requires high frequency of relatively steady data exchanges (e.g. data retrieval every second, or peer-to-peer exchange of status every 4 milliseconds) Requires ability to handle bursty traffic (e.g. bursts of data during power system emergencies, or many users retrieving data on the hour) IEEE P1649 Draft ver 1 13 October 2005

4. Questions Related to Security Requirements The following tables ask questions related to security issues. 4.1 Questions Related to Confidentiality The following Table 4-1 contains questions related to the security requirement of confidentiality. Table 4-1: Questionnaire on Confidentiality Requirements Confidentiality Threat: Unauthorized Access to Information Questions that could be used to help identify the need for Confidentiality for the Asset Could your utility suffer significant direct financial losses from the data being seen by unauthorized entities? For instance, could there be revenue losses due to power operations? Could there be revenue losses due to market operations? Could contract negotiations between your utility and other entities be compromised? Could lawsuits be brought successfully against the utility? Could your utility suffer from social or regulatory impacts from the data being seen by unauthorized entities? For instance, compromise of privacy, embarrassment, prestige, exposure of competitive plans? Could your utility experience significant decrease in safety of employees, customers, or the public from the data being seen by unauthorized entities? For example, information that could be used disgruntled employees or terrorists to compromise safe power system operations? Could customers suffer significant direct financial losses from the data being seen by unauthorized entities? For instance, could competing customers use the data against them? Could their participation in market operations be compromised? Could another entity benefit financially from seeing the data? For instance, market participants? Competing utilities? Competing corporations? Contract negotiators? Could any entity benefit socially or politically from seeing the data? For instance, embarrassing a corporation? Disrupting power operations? Social unrest? Maximum Confidentiality Rating Rating (0-3): 0 = not relevant; 1=somewhat important; 2=important; 3=very important IEEE P1649 Draft ver 1 14 October 2005

4.2 Questions Related to Integrity The following Table 4-2 contains questions related to the security requirement of integrity. Table 4-2: Questionnaire on Integrity Requirements Integrity Threat: Unauthorized Modification or Theft of Information Questions that could be used to help identify the need for Integrity for the Asset Could your utility suffer significant direct financial losses from the data being modified, deleted, or stolen by unauthorized entities? For instance, could there be revenue losses due to power operations? Could there be revenue losses due to market operations? Could contract negotiations between your utility and other entities be compromised? Could lawsuits be brought successfully against the utility? Could your utility suffer from social or regulatory impacts from the data being modified, deleted, or stolen by unauthorized entities? For instance, compromise of privacy, embarrassment, prestige, exposure of competitive plans? Could your utility experience significant decrease in safety of employees, customers, or the public from the data being modified, deleted, or stolen by unauthorized entities? For example, information that could be used disgruntled employees or terrorists to compromise safe power system operations? Could customers suffer significant direct financial losses from the data being modified, deleted, or stolen by unauthorized entities? For instance, could competing customers use the data against them? Could their participation in market operations be compromised? Could another entity benefit financially from modifying, deleting, or stealing the data? For instance, market participants? Competing utilities? Competing corporations? Contract negotiators? Could any entity benefit socially or politically from modifying, deleting, or stealing the data? For instance, embarrassing a corporation? Disrupting power operations? Social unrest? Maximum Integrity Rating Rating (0-3): 0 = not relevant; 1=somewhat important; 2=important; 3=very important IEEE P1649 Draft ver 1 15 October 2005

4.3 Questions Related to Availability The following Table 4-3 contains questions related to the security requirement of availability. Table 4-3: Questionnaire on Availability Requirements Availability Threat: Denial of Service or Prevention of Authorized Access Questions that could be used to help identify the need for Availability for the Asset Could your utility suffer significant direct financial losses from the data being unavailable within the required time window? For instance, could there be revenue losses due to power operations? Could there be revenue losses due to market operations? Could contract negotiations between your utility and other entities be compromised? Could lawsuits be brought successfully against the utility? Could your utility suffer from social or regulatory impacts from the data being unavailable within the required time window? For instance, compromise of privacy, embarrassment, prestige, exposure of competitive plans? Could your utility experience significant decrease in safety of employees, customers, or the public from the data being unavailable within the required time window? For example, information that could be used disgruntled employees or terrorists to compromise safe power system operations? Could customers suffer significant direct financial losses from the data being unavailable within the required time window? For instance, could competing customers use the data against them? Could their participation in market operations be compromised? Could another entity benefit financially from the data being unavailable within the required time window? For instance, market participants? Competing utilities? Competing corporations? Contract negotiators? Could any entity benefit socially or politically from the data being unavailable within the required time window? For instance, embarrassing a corporation? Disrupting power operations? Social unrest? Maximum Availability Rating Rating (0-3): 0 = not relevant; 1=somewhat important; 2=important; 3=very important IEEE P1649 Draft ver 1 16 October 2005

4.4 Questions Related to Non-Repudiation The following Table 4-4 contains questions related to the security requirement of nonrepudiation. Table 4-4: Questionnaire on Non-Repudiation Requirements Non-Repudiation Threat: Denial of action that took place, or claim of action that did not take place Questions that could be used to help identify the need for Non-Repudiation for the Asset Could your utility suffer significant direct financial losses from a transaction being repudiated or from lack of solid proof that a transaction did not take place? For instance, could there be revenue losses due to power operations? Could there be revenue losses due to market operations? Could contract negotiations between your utility and other entities be compromised? Could lawsuits be brought successfully against the utility? Could your utility suffer from social or regulatory impacts from the data being repudiated or from lack of solid proof that a transaction did not take place? For instance, compromise of privacy, embarrassment, prestige, exposure of competitive plans? Could your utility experience significant decrease in safety of employees, customers, or the public from the data being repudiated or from lack of solid proof that a transaction did not take place? For example, information that could be used disgruntled employees or terrorists to compromise safe power system operations? Could customers suffer significant direct financial losses from the data being repudiated or from lack of solid proof that a transaction did not take place? For instance, could competing customers use the data against them? Could their participation in market operations be compromised? Could another entity benefit financially from the data being repudiated or from lack of solid proof that a transaction did not take place? For instance, market participants? Competing utilities? Competing corporations? Contract negotiators? Could any entity benefit socially or politically from the data being repudiated or from lack of solid proof that a transaction did not take place? For instance, embarrassing a corporation? Disrupting power operations? Social unrest? Maximum Non-Repudiation Rating Rating (0-3): 0 = not relevant; 1=somewhat important; 2=important; 3=very important IEEE P1649 Draft ver 1 17 October 2005