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