Towards Anomaly Detection in SCADA Networks using Connection ...

Towards Anomaly Detection in SCADA Networks usingConnection PatternsErik PleijsierUniversity of TwenteP.O. Box 217, 7500AE EnschedeThe Netherlandsf.k.pleijsier@student.utwente.nlABSTRACTA vital part of modern infrastructure is controlled by SupervisoryControl And Data Acquisition (SCADA) networks.Because SCADA systems are increasingly connectedto the Internet, they become more exposed to securitythreats. Therefore it is even more important toinvestigate possible security measures to prevent attacksfrom happening. In [3] some metrics are proposed to classifyhost behavior. These metrics are proven to be stableover time on real network traffic that is collected on atranspacific link of the internet. SCADA systems sharemuch of the network technology with traditional networksand therefore these metrics might also be applicable onSCADA networks. Because anomaly detection relies onmodeling normal behavior and the host behavior is provento be stable over time under normal circumstances, themetrics might be used to aid anomaly detection. This paperprovides an analysis of the behavior of these metricsin SCADA networks and their applicability for anomalydetection in such networks.Keywordshost classification, SCADA, anomaly detection1. INTRODUCTIONA vital part of modern infrastructure is controlled by SupervisoryControl And Data Acquisition (SCADA) networks.SCADA systems are computer systems that areused to gather and analyze real-time data from sensors.Those systems can, for instance, be found in environmentssuch as traffic control, chemical industry, water treatmentand electricity companies. The critical nature of these infrastructuresmakes securing it against attacks especiallyimportant. The consequences of insufficient security measurescould be catastrophic. Traditionally these networkswere believed to be secure, but more recently SCADA networkshave been proved to be vulnerable to cyber attacks.One of the main reasons that the SCADA systems werebelieved to be secure is that they were isolated networks.In addition, SCADA networks used proprietary protocolsfor communication. Over the years the use of standardizedprotocols such as Ethernet and TCP/IP increased and soPermission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copiesare not made or distributed for profit or commercial advantage and thatcopies bear this notice and the full citation on the first page. To copy otherwise,or republish, to post on servers or to redistribute to lists, requiresprior specific permission and/or a fee.18 th Twente Student Conference on IT January 25 th , 2013, Enschede,The Netherlands.Copyright 2013, University of Twente, Faculty of Electrical Engineering,Mathematics and Computer Science.did the interconnectivity between SCADA networks andthe corporate networks. Currently, SCADA systems areoften directly or indirectly connected to the internet, sothey might be attacked from a remote location and thereforebe exposed to more threats. One example is the Maroochywater breach in 2000 (see [6]). An other exampleis the more recent stuxnet malware targeting SCADA infrastructure[4].Clearly, there is an increasing need forsecurity measures for this type of network.A particular field of network security is intrusion detection.Intrusion detection refers to detection of maliciousactivity in a computer system or network. Anomaly detectioncan be used for this purpose. Anomaly detectionrefers to the problem of finding patterns in data that donot conform to the expected behavior[2]. This approachcontrast with the signature based detection, that relies onknown malicious behavior to detect anomalies. One of theadvantages of anomaly based detection is being able todetect attacks that are not known beforehand.One of the main problems with Intrusion detection systems(IDS)based on anomaly detection is that they oftenreport on traffic that is unusual, but not malicious.The reason for this is that network traffic is generallyvery dynamic. But because SCADA networks are morepredictable, anomaly detection might work better in aSCADA environment.A central part of anomaly detection is defining what normalbehavior is for a certain entity. In a network, there areseveral ways to achieve this, for instance one could list allvalid messages on a network and use this as normal behavior.The approach taken in this research is using metricsto define normal behavior. The analysis of normal behaviorcan be done either host-based, where informationis gathered from software that is installed on each host,or network-based, where the information is gathered at aplace in the network infrastructure. In this research thenetwork-based approach is taken. One of the advantagesof network-based analysis is that analysis is also possiblewhen it is not possible to install software on all hosts.Because SCADA networks adopted common network technologyand protocols, security measures for traditionalnetworks might be applicable to SCADA networks. Howeverdespite the many similarities between SCADA networksand other computer networks, there are also a coupleof key differences. The communication in SCADAnetworks, for example, tends to be periodical and hencepredictable because control systems poll data at constantintervals. One other difference is that in a SCADA environmentit is not always possible or allowed to install softwareon the PLC’s, so host-based detection is not alwayspossible in a SCADA environment. Due to the differencesbetween traditional networks and SCADA networks, secu-

ity measures designed for the one type of network shouldalways be validated against the other before applying it.In this work, the metrics in [3] that are defined to classifyhost behavior on the internet will be analyzed against realSCADA network data. These metrics rely only on headerinformation and can therefore be used without knowledgeof the payload of the packets. As part of that study the authorsproved that these metrics are stable over a large periodof time on real network traffic collected on a transpacificlink of the internet. They also showed that thesemetrics are influenced by some malicious traffic, for examplethe metrics are influenced by the effects of the sasservirus. Because these metrics tend to stay stable over timeand change on some malicious traffic, it is proposed tosee whether they can be used for anomaly detection inSCADA networks.The remainder of this paper is organized as follows. In thenext section the SCADA network data that is used in theresearch is presented. In section 3 the research methodologyand the nine investigated metrics are presented. Insection 4 the results will be discussed. In section 5 relatedwork is discussed. And finally in section 6 the conclusionsare presented.2. DATASETIn this research, network packet traces from a real worldSCADA environment are used. The data is collected in awater treatment facility in the Netherlands. The structureof this network is displayed in Figure 1. In the network,different subnetworks are present to limit connectivity betweenthe different subnetworks. Two subnetworks arepresent: field and control.The field network consist of the programmable logic controllers(PLCs) that directly supervise sensors and actuators.The control network consist of servers that performdifferent tasks, such as authentication, accounting and savinghistorical information; and Human Machine Interfaces(HMI) that are controlled by human operators. Communicationbetween the field and control networks shouldgo through a node termed “SCADA server”. All importantmachines for the infrastructure such as the “SCADAserver” are duplicated, so if one machine fails, the otherwill take over. Two datasets are captured simultaneously,one in the field network, and one in the control network.The corporate network consist of regular network devices,such as employee computers, printers and servers; and isconnected to the control network via a firewall. This subnetworkis not included in this research because it is notconsidered part of the SCADA infrastructure and is notessentially different from other corporate networks.3. METHODOLOGYThe behavior of the nine metrics from [3] is analyzedagainst a real world SCADA network traffic dataset that isdescribed in the previous section. The data is first aggregatedby source IP address, so that characterization canbe done on host-level. After that, time series techniquesare applied to aid the analysis of the data. The aggregateddata is then split into different time slots. Several sizes ofthe time slots are used in the time series, ranging from oneminute to one hour. The operators of this SCADA networkassume a period of one minute for periodic traffic,therefore we are not interested in patterns that occur inintervals smaller then one minute. When the data is splitinto the different time slots, the value for the metrics iscalculated in each time slot. Then the the last time slotis discarded because the data is not always aligned with amultiple of the time slot size. After that the data is plottedin graphs. Two types of graphs are used: graphs withthe time slots plotted against the metric value and graphswith histograms that show the distribution of values overthe time slots. And finally the metrics are analyzed to seehow they behave and how stable they are in the SCADAenvironment.The metrics under investigation are described in the nextsections and are divided into three categories: networkconnectivity, connection dispersion and traffic content.3.1 Network connectivity1. Number of peers2. Number of source ports3. Number of destination portsNetwork connectivity metrics are used to characterize therole of a host in a network, for example if the host is aclient, a server or a combination of both(e.g. as occurs inpeer to peer traffic). Our assumption is that if a host isbehaving normal, the role of this host in a network doesnot change and that there are malicious scenario’s that doinfluence the role of a host. For example when a host isbehaving as a client for a time and then suddenly showssigns of server behavior, that host might be compromised.3.2 Connection dispersion4. Ratio of shannon entropies of the second and fourthbytes of destination IP : S(IP2)/S(IP4)5. Ratio of shannon entropies of the third and fourthbytes of destination IP : S(IP3)/S(IP4)The connection dispersion metrics are used to quantifythe spreading in the list of destination addresses of a host.The entropy is not taken directly over the whole IP address,but on different bytes of the IP address. This isbecause IP addresses are not distributed randomly, but inan organized manner.According to [3], the entropies over different bytes of theIP address are quite similar under normal circumstancesand large differences in these entropies might expose scanning.While this is proven to work on a transpacific linkof the internet, it might not be applicable to SCADA networks.Because SCADA networks are closed in a sensethat they are not directly connected to the Internet andshould only communicate to a few other subnetworks, thesecond and third bytes should vary in a small interval (representingthe subnets) and the entropy should be fairlyconstant. So these metrics are expected to be stable, butwe do not expect them to be useful in the security context.3.3 Traffic content6. Mean number of packets per flow7. Percentage of small-size packets8. Percentage of large-size packets9. Entropy of the distribution of medium sized packetsThe traffic content metrics aid in the analysis of the transmittedtraffic. For example, the mean number of packets

SCADAField network Control network Corporate networkPLCPLCHMIHMIPLCSCADA serverFirewallPLCPLCServerFigure 1. Conceptual network overviewpeers2.01.51.00.50.00 50 100 150 200 250hours from start of captureFigure 2. number of peers for atypical PLCpeers4.03.53.02.52.01.51.00.50.00 50 100 150 200hours from start of capture250Figure 3. number of peers for atypical HMIsrc_ports109876543210 50 100 150 200hours from start of capture250Figure 4. number of source portsfor a typical HMIper flow indicates how many packets a host sends on averageto each of its peers. Small values for this metricmight indicate attacks or scans, because not much data istransferred during a scan.The percentage of small-size packets can be used to measurethe percentage of signaling traffic in the total traffic,while the percentage of large size packets can be used tomeasure the percentage of packets that are used for dataexchange, such as downloads.The entropy of the distribution of medium sized packets isused to indicate web or interactive traffic, because it turnsout that these types of traffic have a higher variability inpacket sizes. In a SCADA environment it might be usefulfor distinction between protocols with highly variablepacket sizes and traffic with less variation in packet size.An attack is likely to change this value. A port scan for examplemight send lots of packets with almost no variationin packet size.4. RESULTSOne general observation during the analysis of the metricsis that using a slot size of one minute did not reveal significantdifferent results from analysis using a time slot sizeof one hour. Therefore the results are discussed based ongraphs that resulted from the analysis with time slot sizeset to one hour.4.1 Network connectivityThe number of peers for a PLC is displayed in Figure 2. Inthis figure it is seen that this PLC host only has one peerduring each time slot, with the exception of one time slotwhere it has two peers. Due to the fact that all networktraffic from and to the PLC’s is supposed to be handled viaone “SCADA server” (as discussed in Section 2) the PLC’sshould always communicate with just one single peer (theSCADA server).When further investigating the time slot where this PLC’swas communicating with two peers, we observe a machineinside the control network connecting directly to a PLCbypassing the SCADA server. This should not happenand it is, therefore, an indication that this metric can beuseful in anomaly detection. Because all PLC hosts showa similar behavior only one is displayed.On the control network all nodes also connect to the“SCADA server” for communication with the nodes insidethe field network, but on the control network there is alsosome direct communication between different hosts insidethe control network. Therefore a little more time slots areseen where the number of peers is higher than one (seeFigure 3).The number of source ports and the number of destinationports for a typical HMI machine are respectively shownin Figures 4 and 5. In these figures a stable value of twosource ports and two destination ports is seen with someexceptions to other values. The exceptions coincide withthe change in number of peers as seen in Figure 3. OtherHMI machines show similar behavior, showing a quite stableand equal value for the number of source ports andthe number of destination ports, although the exact numbervaries between different HMI machines, it is alwaysbetween two and five. The analysis shows that HMI machinesbehave in a stable way.In Figure 6 the number of destination ports is shown. Thisfigure reveals a stable value between 170 and 175 for numberof destination ports with one higher value. This highervalue coincides with the already discussed event where the

dst_ports3.02.52.01.51.00 50 100 150 200 250hours from start of captureFigure 5. number of destinationports for a typical HMImean #packets per flow200180160140120100800 50 100 150 200 250minutes from start of captureFigure 8. mean number of packetsper flow for a typical PLCdst_ports2001901801701601500 50 100 150 200 250hours from start of captureFigure 6. number of destinationports for a typical PLCnumber of bins161412108642080 100 120 140 160 180mean #packets per flow200Figure 9. Histogram of meannumber of packets per flowentropy ip3/ip42.01.51.00.50.00.51.00 50 100 150 200 250hours from start of captureFigure 7. ratio of shannon entropies:S(IP3)/S(IP4)probability0.350.300.250.200.150.100.050.000 200 400 600 800 1000 1200 1400 1600packetsize (bytes)Figure 10. Packet-size distributionof the SCADA networkSCADA server was bypassed. The number of source portsfor PLC’s is not shown, because for all PLC’s this numberturned out to be fixed to either one or two dependingon the services provided. Analysis of number of sourceports and the number of destination ports reveal that thePLC devices are acting as servers in the network, the lownumber of source ports correspond to the services providedand the high number of destination ports is explained bythe fact that clients just pick an available port to communicatewith the PLC. It also reveals that this behavioris very stable under normal conditions and is sensitive toanomalous events.The first conclusion that can be drawn by looking at thenetwork connectivity metrics is that the metrics do staystable in a SCADA environment. The second conclusionis that at least some anomalous behavior can be detectedby using them. A third observation is that the metrics canbe used to distinct between PLC’s and HMI devices, butall devices within either group showed similar behavior. Afinal observation is that PLC’s behave a little more stablethen the HMI machines.4.2 Connection dispersionIn Figure 7 the ratio of shannon entropies of the third andfourth bytes of destination IP is shown. This figure showsa stable value of zero with one exception with a value ofone. This is explainable by the way the SCADA networkis arranged. Because each host is normally only communicatingwith the SCADA server, the entropy on the firstthree bytes of the destination IP address is always zero.When the earlier described SCADA bypass event occurredthe entropy over the third byte of the entropy did changeto one because the host that was directly communicatingwith the PLC’s was in an other subnetwork (the fieldnetwork).The Ratio of shannon entropies of the second and fourthbytes of destination IP is not shown because this value waswithout exception fixed to zero. The reason for this is thatno direct communication with hosts outside the SCADAnetwork occurred.The connection dispersion metrics are very stable, butthey are not very informative. We argue that this is truenot only for this particular SCADA network, but in general.Because SCADA networks are in general arranged ina way that prevent direct communication with hosts outsidesome subnetworks the entropy over the first two bytesof the IP will in this cases never change to a value otherthan zero.If however events occur where the entropy over the firstbytes of the IP change, this should be handled with extremecaution because this represent highly unwanted traffic.It should be noted that there are simpler methods todetect this events, for example: in SCADA, networks communicationis allowed between a small number of subnetworks.One could list all subnetworks that are allowed tocommunicate with and check if the source and destinationIP addresses are all within these subnetworks.4.3 Traffic contentIn Figure 8 the mean number of packets per flow is shown.This figure reveals the first metric that is not stable. Tomake more clear how the different values are distributedover the time slots a histogram of the same data is shownin Figure 9. In this figure it is seen that values around170,185 and 200 of mean number of packets per flow occurclearly more than other values. It is not clear why thishappens.To determine the Percentage of small-size packets, thePercentage of large-size packets and the Entropy of thedistribution of medium sized packets it is necessary to definewhat the packet size limit for small packets and theminimum packet size for large packets are. In [3], thethresholds for small and large packets are respectively definedas 144 bytes and 1392 bytes. When these thresholds

% small size pkt(

[1] R. R. R. Barbosa, R. Sadre, and A. Pras. Towardsperiodicity based anomaly detection in scadanetworks. In IEEE 17th Conference on EmergingTechnologies & Factory Automation, ETFA 2012,Kraków, Poland, USA, September 2012. IEEEIndustrial Electronics Society.[2] V. Chandola, A. Banerjee, and V. Kumar. Anomalydetection: A survey. ACM Computing Surveys(CSUR), 41(3):15, 2009.[3] G. Dewaele, Y. Himura, P. Borgnat, K. Fukuda,P. Abry, O. Michel, R. Fontugne, K. Cho, andH. Esaki. Unsupervised host behavior classificationfrom connection patterns. International Journal ofNetwork Management, 20(5):317–337, 2010.[4] N. Falliere, L. Murchu, and E. Chien. W32. stuxnetdossier. White paper, Symantec Corp., SecurityResponse, 2011.[5] U. Premaratne, J. Samarabandu, T. Sidhu,R. Beresh, and J. Tan. An intrusion detection systemfor iec61850 automated substations. Power Delivery,IEEE Transactions on, 25(4):2376–2383, 2010.[6] J. Slay and M. Miller. Lessons learned from themaroochy water breach. International Federation forInformation Processing, 253:73, 2008.[7] A. Valdes and S. Cheung. Communication patternanomaly detection in process control systems. InTechnologies for Homeland Security, 2009. HST’09.IEEE Conference on, pages 22–29. IEEE, 2009.