Intrusion Detection in Spire
Spire is an open-source SCADA system which provides intrusion-tolerance for the power grid. Spire has been designed to tolerate system level and network levels attacks and compromises. It provides this intrusion-tolerance fulfilling the timeliness criteria of power grid monitoring and control systems. More about spire can be found here.
Even thou Spire has been developed to tolerate intrusions very well, it is currently lacking in terms of detecting the intrusions. Hence, it is harder for system administrators (HMI) to identify malicious nodes or where the attacks are coming from. Network Intrusion Detection Systems (NIDS) have matured a lot over the years. One such popular NIDS is Snort which I have used in this project. There are even applications of NIDS in SCADA systems. However, combining NIDS and Intrusion Tolerance in interesting ways is yet an untapped area of research. There can be a lot of potential in this unity.
Goals
In this project, I am adding the capability of detecting malicious messages in Spire, and hence also detect malicious nodes. The assumption is that if a message is identified as malicious, then the sending node is probably malicious as well. The objective is to explore and open up a line of research in combining intrusion detection with intrusion tolerance for Spire and other SCADA systems. More specifically, the goals are:
- Detect malicious messages and malicious senders in Spire (replicas or PLC proxies or PLCs)
- Improve intrusion tolerance through detection
- Explore and open up a line of research in combining intrusion detection with intrusion tolerance for Spire and other SCADA systems
Approach
Given the limited time for the project (only a semester long length of time), here is the list of what was accomplished:
- Researched on existing Intrusion Detection Systems
- Familiarize with Spire in terms of implementation and testing
- Setup, compile and run Spire on 6 Virtual Machines
- Integrated Snort (IDS) in the Spine network to analyze traffic
- Performed testing: DOS, ARP Poisoning and Replay
Results and Discussions
The above grpah shows you the number of alerts produced by Snort for each of the attack scenarios and the normal running scenario (Control). DOS scenario actually produced a lot more alerts, but I capped it to 500. Here are some details and discussions about the results:
- The default snort rules produce a number of alerts for each of the attack scenarios and even in the nomal running scenario (Control)
- Snort flags all the alerts as from UDP protocol except in the DOS scenario, where most of the alerts are flagged as ICMP
- Currently the change in number of alerts tell us more about the change in traffic volume than actual attacks
- Since normal case traffic is regular, this can still indicate a problem
- We need to craft a set of rules in order for the normal case scenario to not throw any alert
- Snort should only throw alert when an attack is actually likely, then this information can be used to detect attacks
Detecting Attacks
After analyzing the results of this project, here are some ideas of how we can detect DOS, ARP Poisoing and Replay attacks:
- DOS attacks are easier to identify because you can easily isolate the source sending the large number of packets to overwhelm a target
- ARP Poisoning is harder to identify since the attacker can secretly stay as a MITM without disrupting services.We can detect it by cross checking MACs in packets with an accepted list
- Replay attacks are the hardest to identify since the attacker does not change anything in the packet and simply reintroduces them in the network. This can be prevented by using session keys that expires after certain amount of time
Next Steps
This semester long project is not to be concluded here, and we will continue to work on this. Here are some projected next steps for this project:
- Modify the default Snort rules and come up with our own set of rules so that alerts are only generated in abnormal running conditions
- Identify attacks likely to occur in Spire
- Come up with IDS rules which in combination with intrusion tolerance of Spire can defend against those attacks
Project Materials
The Box folder (from the link above) contains the images of the virtual machines that I setup for this project. They should already have all the networking setup between them. Please follow the Spire Readme in order to run the system in VMs names pc1, pc2, pc3, pc4, pc5, pc6. Use VM pc7 in order to run benchmark. Use VM snort1 in order to run Snort and monitor the network traffic. And finally, use VM atk1 in order to simulate attacks. I have tested all these VMs using just my laptop (i7 with 4 cores, hyperthreaded, SSD and 16GB of RAM) running VirtualBox to host the VMs. If you need assistance in setting this up or running it, then please contact me.