16.08.2013 Views

Cyber Security of SCADA Systems test bed - Senior Design - Iowa ...

Cyber Security of SCADA Systems test bed - Senior Design - Iowa ...

Cyber Security of SCADA Systems test bed - Senior Design - Iowa ...

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

12/6/2010<br />

SDMAY11-11 CYBER SECURITY OF <strong>SCADA</strong> SYSTEMS TEST BED<br />

<strong>Design</strong> Document<br />

Team Members: Tony Gedwillo – James Parrott – David Ryan<br />

Faculty Advisor: Dr. Manimaran Govindarasu<br />

<strong>Design</strong> Document | Tony Gedwillo – James Parrott – David Ryan


Table <strong>of</strong> Contents<br />

List <strong>of</strong> Figures ................................................................................................................................................ 3<br />

Executive Summary ....................................................................................................................................... 4<br />

Acknowledgement ........................................................................................................................................ 4<br />

Problem Statement ....................................................................................................................................... 4<br />

General Problem Statement ..................................................................................................................... 4<br />

General Solution Approach ....................................................................................................................... 5<br />

Operating Environment ................................................................................................................................ 6<br />

Intended Users and Uses .............................................................................................................................. 6<br />

Intended Users .......................................................................................................................................... 6<br />

Intended Uses ........................................................................................................................................... 6<br />

Assumptions and Limitations ........................................................................................................................ 6<br />

Assumptions List ....................................................................................................................................... 6<br />

Limitations List .......................................................................................................................................... 6<br />

Expected End Product and Other Deliverables ............................................................................................. 6<br />

Approach Used .............................................................................................................................................. 7<br />

<strong>Design</strong> objectives ...................................................................................................................................... 7<br />

Functional Requirements .......................................................................................................................... 7<br />

Virtualization ......................................................................................................................................... 7<br />

Power System Simulation and Integration ........................................................................................... 7<br />

<strong>Cyber</strong> <strong>Security</strong> Assessment ................................................................................................................... 8<br />

<strong>Design</strong> Constraints .................................................................................................................................... 8<br />

Technical approach considerations and results ........................................................................................ 9<br />

Virtualization Approach ........................................................................................................................ 9<br />

Power System Simulation and Integration Approach ......................................................................... 11<br />

<strong>Cyber</strong> Attack/<strong>Security</strong> Approach ......................................................................................................... 11<br />

Testing approach considerations ............................................................................................................ 13<br />

Virtualization Testing .......................................................................................................................... 13<br />

Power System Simulation and Integration Testing ............................................................................. 14<br />

<strong>Cyber</strong> <strong>Security</strong> Testing......................................................................................................................... 14<br />

Recommendations regarding project continuation or modification ...................................................... 15<br />

Detailed <strong>Design</strong> ........................................................................................................................................... 15<br />

SDMAY11-11 1


Virtualization: .......................................................................................................................................... 15<br />

Overview ............................................................................................................................................. 15<br />

Power Flow Simulation and Integration ................................................................................................. 16<br />

<strong>Cyber</strong> <strong>Security</strong> Vulnerability Assessment ................................................................................................ 19<br />

Project Team Information ........................................................................................................................... 21<br />

Faculty Advisor Information .................................................................................................................... 21<br />

Team Information ................................................................................................................................... 21<br />

Closing Summary ......................................................................................................................................... 21<br />

SDMAY11-11 2


List <strong>of</strong> Figures<br />

Figure 1: <strong>Design</strong> Cycle Diagram ..................................................................................................................... 5<br />

Figure 2: Sample Nessus Workstation Report ............................................................................................ 12<br />

Figure 3: Sample Nessus Vulnerability List ................................................................................................. 13<br />

Figure 4: System Diagram ........................................................................................................................... 16<br />

Figure 5: One-Line Diagram from PowerFactory ........................................................................................ 17<br />

Figure 6: Using Spectrum Power TG to close a relay .................................................................................. 18<br />

Figure 7: Conceptualization <strong>of</strong> our <strong>test</strong><strong>bed</strong>'s s<strong>of</strong>tware communicaiton .................................................... 19<br />

SDMAY11-11 3


Executive Summary<br />

Supervisory Control and Data Acquisition (<strong>SCADA</strong>) systems are the nervous systems for the body <strong>of</strong> our<br />

country’s infrastructure. This body includes many systems that are vital to the function <strong>of</strong> our society:<br />

power, water, natural gas, oil, and road traffic systems—among many others. However, the nervous<br />

systems (<strong>SCADA</strong> systems) that control our infrastructure are currently vulnerable to cyber-attack. “Since<br />

the mid-1990’s, security experts have become increasingly concerned about the threat <strong>of</strong> malicious<br />

cyber-attacks on the vital supervisory control and data acquisition (<strong>SCADA</strong>) systems used to monitor and<br />

manage our energy systems. Most <strong>SCADA</strong> system designs did not anticipate the security threats posed<br />

by today’s reliance on common s<strong>of</strong>tware and operating systems, public telecommunication networks,<br />

and the Internet.”<br />

With the critical infrastructure <strong>of</strong> the <strong>SCADA</strong> systems and the security threats on these systems, it is<br />

important to research ways to correct potential security vulnerabilities. A <strong>SCADA</strong> <strong>test</strong> <strong>bed</strong> will be used<br />

for this research. This project will expand on the initial <strong>test</strong> <strong>bed</strong> created last year and make it more<br />

suitable for real-life scenarios and cyber security attacks.<br />

The previous senior design team created the initial <strong>SCADA</strong> <strong>test</strong> <strong>bed</strong>. This <strong>test</strong> <strong>bed</strong> included 2 Control<br />

Centers, 2 RTUs, 2 Relays, 3 SCALANCEs for encrypted communication, a web server, a DTS, and a light<br />

board for demonstrating when a relay trips or is closed. The previous team also <strong>test</strong>ed basic cyberattacks<br />

against the system. They were able to demonstrate a basic man-in-the-middle attack that would<br />

disrupt commands sent by the control center. The initial <strong>test</strong> <strong>bed</strong> was a great start and this year’s senior<br />

design team will improve on the <strong>test</strong> <strong>bed</strong>.<br />

The goals <strong>of</strong> this year’s senior design team are to expand the <strong>test</strong> <strong>bed</strong> to more nodes, integrate power<br />

flow analysis and <strong>test</strong> more advanced attacks. The basic approach for these goals is to use virtualization<br />

s<strong>of</strong>tware to expand the <strong>test</strong> <strong>bed</strong>’s nodes, use power flow s<strong>of</strong>tware for the analysis and use advanced<br />

vulnerability assessment tools for <strong>test</strong>ing cyber-attacks. This approach will create a more thorough <strong>test</strong><br />

<strong>bed</strong> that is similar to real-world systems, allow for power flow analysis and create cyber-attacks that will<br />

show vulnerabilities <strong>of</strong> the system.<br />

Acknowledgement<br />

Technical expertise <strong>of</strong> the <strong>test</strong> <strong>bed</strong> has been provided by <strong>Iowa</strong> State University graduate students Adam<br />

Hahn, Aditya Ashok and Siddharth Sridhar. DigSilent expertise has been provided by <strong>Iowa</strong> State<br />

University graduate student Jie Yan.<br />

Problem Statement<br />

General Problem Statement<br />

Our goal is to improve the cyber security <strong>of</strong> <strong>SCADA</strong> systems by making our own <strong>SCADA</strong> <strong>test</strong> <strong>bed</strong>, where<br />

we can simulate power systems and the communication protocols they use, and attempt cyber-attacks<br />

on our systems. Through this process, we can <strong>test</strong> vulnerabilities <strong>of</strong> commercial <strong>SCADA</strong> protection<br />

products report their vulnerabilities. We can also demonstrate the effects a <strong>SCADA</strong> cyber-attack can<br />

SDMAY11-11 4


have on a power system. We will be improving the <strong>test</strong> <strong>bed</strong> created by the previous year’s team. We will<br />

be expanding the <strong>test</strong> <strong>bed</strong>’s number <strong>of</strong> nodes, adding power flow analysis, and creating more advanced<br />

cyber-attacks.<br />

<strong>SCADA</strong><br />

System with<br />

Poor <strong>Security</strong><br />

Attack<br />

Scenario<br />

Improvement<br />

Cycle<br />

System<br />

Configuration<br />

and<br />

Improvement<br />

Figure 1: <strong>Design</strong> Cycle Diagram<br />

Vulnerability<br />

Assessment<br />

<strong>SCADA</strong><br />

System with<br />

Improved<br />

<strong>Security</strong><br />

General Solution Approach<br />

The three main tasks, as descri<strong>bed</strong> in our problem statement, are to expand the <strong>test</strong> <strong>bed</strong> by having more<br />

nodes, add power flow analysis functionality and create and <strong>test</strong> more advanced cyber-attacks. In order<br />

to expand the <strong>test</strong> <strong>bed</strong>, we will use virtualization to create more nodes without the need for hardware<br />

for each node. This will include virtualization <strong>of</strong> the relay and RTU. To add power flow analysis to the<br />

<strong>test</strong> <strong>bed</strong>, we will use s<strong>of</strong>tware that can connect to the <strong>test</strong> <strong>bed</strong> and provide analysis along with providing<br />

real world scenarios for the <strong>test</strong> <strong>bed</strong>. With regards to the cyber-attacks, we will use vulnerability <strong>test</strong>ing<br />

tools to scan for vulnerabilities and then try attacks against the vulnerabilities.<br />

SDMAY11-11 5


Operating Environment<br />

The operating environment for the <strong>test</strong> <strong>bed</strong> is a lab in Coover Hall. The conditions in the lab are normal<br />

operating conditions for the <strong>test</strong> <strong>bed</strong> equipment.<br />

Intended Users and Uses<br />

Intended Users<br />

The primary users <strong>of</strong> this system will be graduate and undergraduate students in computer engineering<br />

or electrical engineering who are researching the cyber security <strong>of</strong> <strong>SCADA</strong> systems. Other users <strong>of</strong> this<br />

system might be researchers or companies interested in learning more about the <strong>test</strong> <strong>bed</strong> and its<br />

functionality.<br />

Intended Uses<br />

The primary uses <strong>of</strong> this system will be the creating and <strong>test</strong>ing <strong>of</strong> cyber-attacks and researching the<br />

effects that a cyber-attack could have on a <strong>SCADA</strong> system, especially in regards to power flow. Another<br />

use <strong>of</strong> this system might be showing people the basics <strong>of</strong> how a <strong>SCADA</strong> system works.<br />

Assumptions and Limitations<br />

Assumptions List<br />

All <strong>test</strong> equipment will function correctly<br />

The <strong>test</strong> <strong>bed</strong> is similar to a real-world <strong>SCADA</strong> system<br />

o 15 substations in the <strong>test</strong> <strong>bed</strong> will be enough to create real-world scenarios<br />

A pfSense firewall solution will be able to function like a SCALANCE device.<br />

The <strong>test</strong> <strong>bed</strong> will demonstrated to those interested in <strong>SCADA</strong> systems and cyber-security.<br />

Industry might be interested in vulnerabilities found through the <strong>test</strong> <strong>bed</strong>.<br />

The <strong>test</strong> <strong>bed</strong> will be used in the next years for continuation <strong>of</strong> cyber-security attacks on a <strong>SCADA</strong><br />

system.<br />

Limitations List<br />

We have two semesters to complete the project<br />

Only 120V will be used by the relays instead <strong>of</strong> higher voltages in the real-world such as 330KV.<br />

Only 2 physical relays will be used due to financial limitations<br />

Expected End Product and Other Deliverables<br />

At the end <strong>of</strong> the project period we expect to have a <strong>test</strong> <strong>bed</strong> that can be used both for demonstrations<br />

and for development <strong>of</strong> cyber security attacks. This <strong>test</strong> <strong>bed</strong> will have over 15 nodes, mostly virtual, with<br />

some physical. It will also have the ability to have power flow analysis so it can be used to track the<br />

effects a cyber-attack has had on the system. We will also have created cyber-attacks that can be used<br />

on the system and demonstrate vulnerabilities.<br />

SDMAY11-11 6


Approach Used<br />

<strong>Design</strong> objectives<br />

Create a <strong>SCADA</strong> Test<strong>bed</strong> that can be used to simulate cyber attacks<br />

o This <strong>test</strong><strong>bed</strong> will allow us to mimic real-world power systems and demonstrate the<br />

effects <strong>of</strong> a cyber-attack on a <strong>SCADA</strong> system.<br />

Develop a method to plan, execute, and analyze cyber-attacks on our system<br />

o We want to be methodical in our approach to <strong>test</strong>ing our finished system. It is<br />

important that we have a consistent system that we can use to report our findings.<br />

Functional Requirements<br />

Virtualization<br />

Create a virtualized platform that allows network stack inspection.<br />

o Creating a virtualized platform will be the basis <strong>of</strong> adding more substations to the<br />

current <strong>test</strong> <strong>bed</strong>. Since we are limited on financial resources, we are unable to purchase<br />

more SIPROTEC Relays and SCALANCE devices. We need a virtualized platform that will<br />

allow virtual substations that can connect to the physical <strong>test</strong> <strong>bed</strong>. We also need this<br />

platform to have the ability <strong>of</strong> network stack inspection in order for us to <strong>test</strong> cyberattack<br />

scenarios.<br />

Create virtualized images for RTUs, Control Center, firewalls and Relays<br />

o In order to fully virtualize a substation, we will need to create virtual images for each<br />

segment <strong>of</strong> the substation. Creating a virtualized image for the RTU should be<br />

somewhat basic since it is a s<strong>of</strong>tware application that runs on Windows. Creating a<br />

virtualized relay will be more difficult since it will require finding a relay simulator that<br />

can communicate with the RTU. We can use an open source firewall solution to simulate<br />

the SCALANCE firewalls.<br />

Virtualized system should be scalable to provide more realistic scenarios.<br />

o We want this system to be scalable to upwards <strong>of</strong> 30, if not more, substations. To be<br />

able to do this, we will first need to purchase and install a physical virtual host server<br />

with properly allocated physical resources. The substations should be deployed from the<br />

server.<br />

Power System Simulation and Integration<br />

Integrate DIgSILENT PowerFactory with <strong>SCADA</strong> <strong>test</strong> <strong>bed</strong><br />

o DIgSILENT PowerFactory has the power flow simulation capabilities that we need for our<br />

system. We can set breakers and other components on a PowerFactory schematic to<br />

correspond to data points stored on our SICAM terminals. We will link PowerFactory<br />

and our SICAM RTU’s together via OPC protocol.<br />

Power Simulation should represent real world scenarios<br />

SDMAY11-11 7


o We want to integration between the Power Flow Simulation <strong>of</strong> PowerFactory and the<br />

<strong>test</strong> <strong>bed</strong> to be able to represent real world scenarios. This will make the <strong>test</strong> <strong>bed</strong> more<br />

realistic and applicable to the world’s <strong>SCADA</strong> systems.<br />

<strong>Cyber</strong> <strong>Security</strong> Assessment<br />

Produce report detailing security vulnerabilities <strong>of</strong> the system<br />

o The report will detail each vulnerability found during the assessment, what the possible<br />

impact an attack would be if carried out using a particular vulnerability, as well as<br />

possible countermeasures to mitigate the effect <strong>of</strong> each attack.<br />

Shall implement attacks discovered during the vulnerability assessment<br />

o We will think <strong>of</strong> scenarios where an attacker could use a particular vulnerability to<br />

attack the system, try to implement that attack, and attempt to get the attack to work<br />

on a consistent basis.<br />

<strong>Design</strong> Constraints<br />

We have a few minor requirements that we have deemed “non-functional”:<br />

Minimal configuration on virtual image deployment<br />

o We want our system to be easy to set up and analyze. We don’t want to have to<br />

configure each <strong>of</strong> our virtual images individually.<br />

Images should have backups to prevent loss<br />

o We are currently using one external hard drive to accomplish this task, but we are<br />

looking into other solutions.<br />

Attack scenarios can be demonstrated without requiring detailed information on attack<br />

functionality<br />

o The simpler we make our system to operate, the easier it will be to demonstrate it to<br />

the <strong>Senior</strong> <strong>Design</strong> Review Board and others who wish to see a demonstration. We will<br />

document how to perform each attack, and if possible, create shell scripts or batch files<br />

to automate the attack.<br />

Assessment shall function as comprehensive documentation on the security state <strong>of</strong> the system<br />

o This assessment will attempt to be as comprehensive as possible during the information<br />

gathering phase, and will thoroughly document any progress made or failures<br />

encountered. This will help any future project teams build upon it the work<br />

accomplished this year, and hopefully let them avoid repeating any work that has<br />

already been accomplished.<br />

All <strong>test</strong> equipment should function correctly<br />

Power system should be represented in a manner that is easy to understand<br />

o This will help observers quickly and easily understand the implications <strong>of</strong> a cybersecurity<br />

attack. We are considering using a projector to project our system’s one-line<br />

diagram onto a wall. However, we would prefer to create an easy to understand<br />

display— other than a one-line diagram— to represent our system. This could be a<br />

simple program that we create that reads data points <strong>of</strong>f our OPC server and represents<br />

SDMAY11-11 8


them in an aesthetically pleasing and easily understandable manner. This display would<br />

make our <strong>SCADA</strong> system very easy to conceptualize, and it will make our system look<br />

more attractive and functional to observers.<br />

Technical approach considerations and results<br />

Virtualization Approach<br />

S<strong>of</strong>tware Options for a Virtual Hypervisor<br />

o VmWare Server<br />

Advantages<br />

Can get a free license<br />

Can have multiple virtual machines on 1 computer<br />

Disadvantages<br />

Minimal functionality<br />

It runs on top <strong>of</strong> an operating system so the resources used by the<br />

operating system will hinder its performance<br />

o VmWare ESX<br />

Advantages<br />

Is the operating system for the computer, minimal resource usage and<br />

overhead.<br />

Can get a free license from the university<br />

Can have multiple virtual machines on 1 computer<br />

Already familiar with this s<strong>of</strong>tware<br />

S<strong>of</strong>tware is easily installed on non-server class hardware<br />

Disadvantages<br />

License only lasts 1 year.<br />

o Citrix XenServer<br />

Advantages<br />

Is the operating system for the computer, minimal resource usage and<br />

overhead.<br />

Can have multiple virtual machines on 1 computer<br />

Disadvantages<br />

No free license available, would need to pay for one.<br />

Not as familiar with this s<strong>of</strong>tware.<br />

o Micros<strong>of</strong>t HypverV<br />

Advantages<br />

Can get a free license from the university<br />

Can have multiple virtual machines on 1 computer<br />

Is the operating system for the computer<br />

Disadvantages<br />

Not familiar with this s<strong>of</strong>tware.<br />

SDMAY11-11 9


S<strong>of</strong>tware Selection for a Virtual Hypervisor<br />

We chose to use VmWare ESX as our virtualization hypervisor. A team member was<br />

familiar with the s<strong>of</strong>tware and has used it before. The university also gives us a 1 year license to<br />

the s<strong>of</strong>tware so there was no need to spend money on the s<strong>of</strong>tware. It was also easy to install<br />

on a PC even though it usually recommends server-class hardware be used. This s<strong>of</strong>tware also<br />

allows for virtual machine templates to be used so it would be easier for use to deploy multiple<br />

substations.<br />

S<strong>of</strong>tware Options for a S<strong>of</strong>tware Relay Simulator<br />

o Delphin-Informatika IEC 61850 Simulator<br />

Advantages<br />

Was developed with use for SICAM PAS and Siemens Relays<br />

Connected and worked with SICAM PAS<br />

Disadvantages<br />

Only 30 day trial, expensive to purchase<br />

Trial did not include full functionality<br />

Based out <strong>of</strong> Russia, little amount <strong>of</strong> support.<br />

o SISCO AX-S4 MMS<br />

Advantages<br />

Free educational license<br />

Provides a network stack for communication<br />

Disadvantages<br />

More complex than the other solutions<br />

o SystemCORP IEC61850 DLL<br />

Advantages<br />

Free<br />

Disadvantages<br />

Poor documentation<br />

Did not connect well to our system.<br />

No Support<br />

S<strong>of</strong>tware Selection for a S<strong>of</strong>tware Relay Simulator<br />

We chose to use the SISCO AX-S4 MMS as the s<strong>of</strong>tware for simulating relays. At first we thought<br />

the Delphin-Informatika IEC 61850 Simulator would be our selection. It worked well with our system and<br />

was developed for the same hardware and s<strong>of</strong>tware that we are using. The draw backs to the Delphin-<br />

Informatika simulator is that the trial only lasted 30 days with basic functionality and that the full license<br />

would be too expensive. We did some more research and found the SISCO simulator. The SISCO AX-S4<br />

MMS provides much functionality as a simulator and SISCO provides a free educational license. Even<br />

though the SISCO product is more complex and will take longer to learn, it was the best option.<br />

SDMAY11-11 10


Power System Simulation and Integration Approach<br />

S<strong>of</strong>tware Options<br />

o Siemens Spectrum Power TG DTS (Dispatcher Training Simulation)<br />

Advantages<br />

S<strong>of</strong>tware already installed in our lab<br />

S<strong>of</strong>tware designed to interact with the our system<br />

Disadvantages<br />

Poor documentation<br />

Hard to set up<br />

Technical support period had expired<br />

o DIgSILENT PowerFactory<br />

Advantages<br />

Has OPC communication capabilities<br />

Easy to use<br />

Extensive documentation<br />

Many people in ECpE department use this s<strong>of</strong>tware<br />

Disadvantages<br />

Requires advanced license<br />

S<strong>of</strong>tware Selection<br />

We chose to use DIgSILENT PowerFactory for our power system simulation. It was<br />

becoming apparent that we required technical support from Siemens if we were going to use<br />

Spectrum Power TG DTS. The manuals were not helpful, and they did not contain the<br />

information we needed. This support costs around $20,000 per year—a price clearly out <strong>of</strong> our<br />

budget. We found that there was a graduate student here at ISU doing something very similar<br />

to our project. He was using an OPC server to control breakers in DIgSILENT PowerFactory.<br />

Since this was exactly what we wanted to do, and we knew it could be implemented, we<br />

decided to go with that. The use <strong>of</strong> PowerFactory’s OPC capabilities requires an advanced<br />

license that costs around $2,000. Since this was way less than the Siemens support cost, that<br />

was only going to last a year anyway, we decided it would be better to obtain a license that the<br />

whole department could use.<br />

<strong>Cyber</strong> Attack/<strong>Security</strong> Approach<br />

S<strong>of</strong>tware Options<br />

o Nessus <strong>Security</strong> Scanner<br />

Advantages<br />

Remote Vulnerability Scanning<br />

Combined the “Document Running Services” and”Document wellknown<br />

s<strong>of</strong>tware vulnerabilities” phases into one scan<br />

Free License available<br />

Disadvantages<br />

SDMAY11-11 11


Is limited by the plugins that have been created<br />

o Various Open Source Tools<br />

Advantages<br />

Usually free<br />

Disadvantages<br />

Not necessarily well documented or supported<br />

S<strong>of</strong>tware Selection<br />

The first piece <strong>of</strong> s<strong>of</strong>tware used in performing the vulnerability assessment will be Nessus <strong>Security</strong><br />

Scanner from Tenable <strong>Security</strong>. Nessus remotely scans computers for vulnerabilities, both client-side<br />

and server side, through <strong>test</strong>s that are specified via the s<strong>of</strong>tware’s plugin architecture. Nessus generates<br />

a report for each computer which contains a list <strong>of</strong> any vulnerabilities it discovered during the scan, each<br />

categorized by port number and severity level, as well as reports generated by the <strong>test</strong> plugin itself.<br />

These reports can be viewed directly on the Nessus Server via a web interface, or exported as an HTML<br />

file.<br />

Figure 2: Sample Nessus Workstation Report<br />

SDMAY11-11 12


Figure 3: Sample Nessus Vulnerability List<br />

It is difficult to predict what s<strong>of</strong>tware will be used to implement the attacks, as the appropriate s<strong>of</strong>tware<br />

will vary depending on the type <strong>of</strong> vulnerability. Most, if not all tools will be free and open source,<br />

though we will not exclude commercial s<strong>of</strong>tware if it will prove useful. An excellent compilation <strong>of</strong><br />

common security tools is the Linux distribution called Backtrack 4, which is available for free from its<br />

website.<br />

Testing approach considerations<br />

Virtualization Testing<br />

How and where will <strong>test</strong>ing be performed?<br />

Testing will be performed in the <strong>SCADA</strong> lab. We will need to verify the virtual server is<br />

running and communications are working.<br />

Exactly what will be <strong>test</strong>ed?<br />

Communications between virtual RTUs and virtual relays<br />

Communications between virtual RTUs and physical command center<br />

How will <strong>test</strong>ing accuracy be determined?<br />

We will check the RTU operations screen and if it shows that both virtual relay and<br />

command center are connected than it is working correctly<br />

What information will be recorded on the forms that will be used to record <strong>test</strong> results?<br />

We will record what virtual RTUs and virtual relays are not working and record any<br />

errors associated with them.<br />

SDMAY11-11 13


Who will be doing <strong>test</strong>ing and how will it be verified?<br />

Most likely James Parrott will complete <strong>test</strong>s. Graduate students will also help in the<br />

<strong>test</strong>ing.<br />

Power System Simulation and Integration Testing<br />

How and where will <strong>test</strong>ing be performed?<br />

Testing will be performed in our <strong>SCADA</strong> lab. We will need to verify that our <strong>SCADA</strong><br />

<strong>test</strong><strong>bed</strong> is interacting with and controlling our power flow s<strong>of</strong>tware.<br />

Exactly what will be <strong>test</strong>ed?<br />

We will need to <strong>test</strong> each component on our power flow simulation that is linked to our<br />

OPC server and controlled by our <strong>SCADA</strong> system. These components will mainly be<br />

relays.<br />

How will <strong>test</strong>ing accuracy be determined?<br />

Our <strong>test</strong>ing will be very objective, since the components that we are <strong>test</strong>ing—virtualized<br />

relays—only exist in two states: on and <strong>of</strong>f. Our operator will be sitting at our control<br />

terminal, and he will toggle the status <strong>of</strong> a relay. If the change is reflected on our<br />

PowerFactory display, and the power flow solution is adjusted accordingly, we know<br />

that the <strong>test</strong>ed component is functional.<br />

What information will be recorded on the forms that will be used to record <strong>test</strong> results?<br />

Date/Time, name <strong>of</strong> component <strong>test</strong>ed, location on OPC server, <strong>test</strong> failed/successful,<br />

comments<br />

Who will be doing <strong>test</strong>ing and how will it be verified?<br />

Most likely Tony Gedwillo will be performing these <strong>test</strong>s. Our cooperating grad students<br />

will help to verify these results by attempting to operate the system.<br />

<strong>Cyber</strong> <strong>Security</strong> Testing<br />

How and where will <strong>test</strong>ing be performed?<br />

o In the lab, on the physical substations.<br />

Exactly what will be <strong>test</strong>ed?<br />

o We will <strong>test</strong> the overall security configuration <strong>of</strong> the system and attempt to<br />

implement any promising vulnerabilities that are discovered.<br />

How will <strong>test</strong>ing accuracy be determined?<br />

SDMAY11-11 14


o If an attack works properly, then it was accurate to call examine that<br />

vulnerability<br />

What information will be recorded on the forms that will be used to record <strong>test</strong> results?<br />

The configuration <strong>of</strong> each device, as well as whether particular attacks<br />

were effective.<br />

Who will be doing <strong>test</strong>ing and how will it be verified?<br />

o David Ryan will be doing this section <strong>of</strong> <strong>test</strong>ing in cooperation with Adam Hahn.<br />

Recommendations regarding project continuation or modification<br />

At this point, we recommend that we continue the project as planned. It appears that we will be able to<br />

satisfy our functional requirements in the allotted time. We will be able to virtualize RTU’s and relays,<br />

connect our power flow s<strong>of</strong>tware to the <strong>test</strong><strong>bed</strong> via OPC protocol, and execute cyber-attacks on the<br />

system. There is no reason to abandon the project, since there was a large initial investment in the<br />

equipment used in the lab and we have the time and ability to complete the project as planned.<br />

Detailed <strong>Design</strong><br />

Virtualization:<br />

Overview<br />

This part <strong>of</strong> the project requires us to install a virtualized hypervisor, install virtual RTUs and virtual<br />

relays on the server and have them connect to the current <strong>test</strong> <strong>bed</strong>. As stated in the s<strong>of</strong>tware selections,<br />

we will be using VmWare ESX for the virtual hypervisor and SISCO AX-S4 MMS as the relay simulator.<br />

Below is a figure the shows what our <strong>test</strong> <strong>bed</strong> with virtualized substations will look like.<br />

SDMAY11-11 15


Figure 4: System Diagram<br />

Power Flow Simulation and Integration<br />

Relevant s<strong>of</strong>tware and equipment<br />

o DIgSILENT PowerFactory<br />

This is the s<strong>of</strong>tware we will use to simulate our power system and solve<br />

its power flow. The substations (busses), generators, loads, and relays<br />

that we want to reflect real world scenarios will be modeled through<br />

this s<strong>of</strong>tware. These components will be represented on a “one line<br />

diagram” (See Figure 1). The relays modeled in this s<strong>of</strong>tware will be<br />

controlled by our <strong>SCADA</strong> system via OPC connectivity. This s<strong>of</strong>tware will<br />

function as our OPC client. With this s<strong>of</strong>tware, we can show the effects<br />

<strong>of</strong> a cyber-attack on a power system.<br />

SDMAY11-11 16


Figure 5: One-Line Diagram from PowerFactory<br />

o Siemens Spectrum Power TG<br />

This s<strong>of</strong>tware will be used to manually control the statuses <strong>of</strong> the relays<br />

in our system. Here, we can manipulate our power system. This<br />

s<strong>of</strong>tware functions as a Human Machine Interface, or an HMI.<br />

SDMAY11-11 17


Figure 6: Using Spectrum Power TG to close a relay<br />

o Siemens SICAM PAS<br />

Our virtualized RTU’s will use SICAM PAS s<strong>of</strong>tware. This s<strong>of</strong>tware will<br />

provide the OPC server needed to facilitate communications between<br />

Spectrum Power TG and PowerFactory. After connections are<br />

established between SICAM, PowerFactory, and Spectrum Power TG,<br />

SICAM s<strong>of</strong>tware will mainly be a background system. During an attack<br />

simulation, users will not directly use SICAM s<strong>of</strong>tware, and observers<br />

will not be aware <strong>of</strong> its operation. It simply serves as a communications<br />

point.<br />

SDMAY11-11 18


Figure 7: Conceptualization <strong>of</strong> our <strong>test</strong><strong>bed</strong>'s s<strong>of</strong>tware communicaiton<br />

<strong>Cyber</strong> <strong>Security</strong> Vulnerability Assessment<br />

This will be a white-box vulnerability assessment. We have complete access to a fully operational <strong>test</strong><br />

<strong>bed</strong> with no danger <strong>of</strong> causing any harm if we disrupt normal operations. This provides an excellent<br />

opportunity to research and <strong>test</strong> any vulnerabilities that might disrupt normal operations in a functional<br />

real-world system.<br />

This assessment will concentrate on the assessing the physical substations because they have a wellestablished<br />

that will likely change very little in the near future. Any work assessing the physical<br />

substations should carry over into the Virtualization and Power Flow Simulation portions <strong>of</strong> this project.<br />

The virtualization component will attempt to emulate the physical substations, and the power-flow<br />

simulation should interact the same way with physical or virtual substations.<br />

The <strong>test</strong>ing procedure is as follows:<br />

SDMAY11-11 19


Validate the System<br />

The initial step will be to do a network survey to validate the network, and eliminate any<br />

incorrect assumptions from being made due to incorrect or outdated documentation. A<br />

reference spreadsheet will be created to record all available information about each device. We<br />

will then physically verify that all Ethernet connections are going to the proper place according<br />

to the network map. Last, we will record the host names and IP addresses <strong>of</strong> all machines in the<br />

lab, as well any s<strong>of</strong>tware applications that are installed on each machine.<br />

Document Running Services<br />

The next step will be to find out how many ports were exposed to the local network, and what<br />

services were running on each port. This step will be accomplished Nessus <strong>Security</strong> Scanner.<br />

Nessus will scan through each possible TCP and UDP ports on each computer or hardware<br />

device, detecting whether or not each port responds when queried with traffic. If the service<br />

isn’t directly identifiable to the port scanner, s<strong>of</strong>tware named Active Ports can be used to<br />

discover which executable opens which port. This information will then be recorded to use as a<br />

reference guide, in case we ever need to readily identify a particular port number or service.<br />

Document Well-Known S<strong>of</strong>tware Vulnerabilities<br />

During the port scan, it also runs numerous <strong>test</strong>s on each port to determine if each port is<br />

susceptible to a particular vulnerability <strong>of</strong> any severity level.<br />

The client side s<strong>of</strong>tware scan requires a credentialed scan using Nessus’s SMB logon capabilities.<br />

When Nessus is provided with the local Windows account credentials, the s<strong>of</strong>tware is able to<br />

check the patch levels <strong>of</strong> all s<strong>of</strong>tware on the computer, including Windows itself. Information<br />

about the OS patch level will be added to the reference spreadsheet.<br />

Search for Implementation Vulnerabilities<br />

The final step will be to search for vulnerabilities that are undocumented or specific to our lab<br />

implementation. This includes investigating the Siemens s<strong>of</strong>tware because Nessus does not have<br />

any <strong>test</strong>s to evaluate its security level, as well as searching for any weaknesses in<br />

communication or authentication protocols used by any devices or s<strong>of</strong>tware in the lab.<br />

Attack Implementation<br />

To evaluate the results <strong>of</strong> the vulnerability assessment, we will attempt to implement any<br />

promising vulnerabilities that are discovered. We will also attempt to make repeating these<br />

attacks as simple as possible by documenting the steps on how to perform the attack, and if<br />

possible, create shell scripts or batch files to run the attack commands.<br />

Produce Report<br />

We will produce a report detailing the existing vulnerabilities <strong>of</strong> the system, the possible impact<br />

if an attack were carried out using a particular vulnerability, as well as possible countermeasures<br />

to mitigate the effectiveness <strong>of</strong> a given attack.<br />

SDMAY11-11 20


Project Team Information<br />

Faculty Advisor Information<br />

Dr. Manimaran Govindarasu<br />

3227 Coover<br />

Ames, IA 50011-3060<br />

Phone: 515-294-9175<br />

Fax: 515-294-3637<br />

Email: gmani@iastate.edu<br />

Team Information<br />

James Parrott<br />

Computer Engineering<br />

2132 Sunset<br />

Ames, IA 50014<br />

Phone: 515-480-8149<br />

Email: jparrott@iastate.edu<br />

David Ryan<br />

Computer Engineering<br />

2304 Wallace Rambo<br />

Ames, IA 50012<br />

Phone: 563-380-1259<br />

Email: drryan50@iastate.edu<br />

Tony Gedwillo<br />

Electrical Engineering<br />

6212 Frederiksen Ct<br />

Ames, IA 50010<br />

Phone: 402-896-9046<br />

Email: gedwillo@iastate.edu<br />

Closing Summary<br />

The goal <strong>of</strong> our <strong>SCADA</strong> <strong>test</strong> <strong>bed</strong> is to mimic real world <strong>SCADA</strong> systems and to discover and document<br />

vulnerabilities that industrial <strong>SCADA</strong> systems may have. If industrial <strong>SCADA</strong> systems are compromised,<br />

money and lives can be lost, especially for large scale <strong>SCADA</strong> systems like electrical power transmission<br />

systems. We will use virtualized relays and substations (RTU’s) along with control system s<strong>of</strong>tware and<br />

power flow simulation s<strong>of</strong>tware to model a <strong>SCADA</strong> system. Once this system is set up, we can complete<br />

vulnerability assessments, conduct attack scenarios, and document the effects on our power system and<br />

the failures <strong>of</strong> our security measures. Our hope is that we can provide the power industry, along with<br />

any industry that utilizes <strong>SCADA</strong> systems, with reports on <strong>SCADA</strong> system vulnerabilities, so that<br />

preventative measures can be taken.<br />

SDMAY11-11 21

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!