white paper on industrial automation security in fieldbus and

1WHITE PAPER ON INDUSTRIAL AUTOMATIONSECURITY IN FIELDBUS AND FIELD DEVICELEVELAuthors:Magnus Sundell, Vacon Plc, magnus.sundell{at}vacon.comJanne Kuivalainen, Vacon Plc, janne.kuivalainen{at}vacon.comJuhani Mäkelä, Nixu Ltd, juhani.makela{at}nixu.comArthur Gervais, Nixu Ltd, arthur.gervais{at}nixu.comJouko Orava, Vacon Plc, jouko.orava{at}vacon.comMikko H. Hyppönen, F-Secure Corporation, mikko.hypponen{at}f-secure.com

2AbstractThere has been a lot of discussion about malware and security in industrial automation systems afterStuxnet. This <strong>white</strong> <strong>paper</strong> is based on material from the public domain and focuses on presenting ageneric overview about security in industrial automation on the fieldbus and device level.The level of standardization in the information security field is presented, comparing the status of ICTsystems’ security standardization to that of industrial automation.Security aspects of traditional fieldbuses, Ethernet-based networks and wireless communicationtechnologies are presented. Challenges regarding data security in the field of industrial automation arediscussed. The properties of industrial automation devices are described with a focus on security,tampering possibilities, and risk mitigation methods.Index terms – security, industrial automation, fieldbus, industrial Ethernet, wireless communication,embedded devices, standardization, Stuxnet

3Table of Contents1 Introduction and scope ..................................................................................................................... 61.1 Industrial automation systems overview ................................................................................... 61.2 Types of malware ..................................................................................................................... 61.3 Current malware status concerning the industrial automation sector .......................................... 71.4 Standardization and related organizations ................................................................................. 81.4.1 ICT security standards ...................................................................................................... 81.4.2 Industrial automation standards ........................................................................................ 91.4.3 Other industrial automation security related organizations and standards ......................... 111.4.4 Standardization summary ............................................................................................... 112 Generic security considerations ...................................................................................................... 112.1 Attacks and scenarios ............................................................................................................. 122.2 Security program .................................................................................................................... 123 Security in communication between devices .................................................................................. 133.1 Purpose of communication ..................................................................................................... 133.2 Security threats and issues ...................................................................................................... 143.2.1 Reconnaissance activity .................................................................................................. 153.2.2 Attacks on communication ............................................................................................. 163.3 Traditional fieldbuses ............................................................................................................. 173.3.1 Modbus RTU.................................................................................................................. 183.3.2 PROFIBUS DP............................................................................................................... 193.3.3 CANopen ....................................................................................................................... 223.3.4 DeviceNet ...................................................................................................................... 233.4 Ethernet networks .................................................................................................................. 233.4.1 Ethernet physical layer ................................................................................................... 233.4.2 Ethernet data link layer ................................................................................................... 24

43.4.3 Internet Protocol ............................................................................................................. 243.4.4 Transport layer ............................................................................................................... 253.4.5 Network configuration .................................................................................................... 253.4.6 Network topology ........................................................................................................... 263.4.7 Industrial Ethernet protocols ........................................................................................... 273.5 Recommendations for enhancing security ............................................................................... 314 Security in field devices ................................................................................................................. 324.1 Security threats and issues ...................................................................................................... 324.1.1 Information leakage ........................................................................................................ 324.1.2 Tampering risks .............................................................................................................. 324.2 Simple field devices ............................................................................................................... 334.3 Embedded devices with real-time operating systems ............................................................... 334.4 Embedded devices with general-purpose operating systems .................................................... 344.4.1 Operating system vulnerabilities ..................................................................................... 344.4.2 Open-source systems ...................................................................................................... 344.4.3 General-purpose operating systems ................................................................................. 344.5 Recommendations for enhancing security in devices .............................................................. 354.5.1 Debugging interfaces ...................................................................................................... 354.5.2 Communication interfaces .............................................................................................. 354.5.3 Firmware protection ....................................................................................................... 364.5.4 Device parameters and configuration .............................................................................. 374.5.5 Firmware updating ......................................................................................................... 374.5.6 Superfluous information ................................................................................................. 375 Security in wireless communications.............................................................................................. 385.1 Security of wireless technology .............................................................................................. 385.1.1 IEEE 802.15.4 ................................................................................................................ 395.1.2 Wireless LAN ................................................................................................................ 39

55.1.3 Bluetooth........................................................................................................................ 395.2 Recommendations for improving wireless network security.................................................... 406 Summary ....................................................................................................................................... 417 References ..................................................................................................................................... 42

7however they quite often consume bandwidthand cause harm due to increased network traffichindering important information exchange.Worms with payload (i.e. code designed toperform actions on the infected system) cancause damage to the infected machine and itssystem.Viruses are also designed to self-replicate andspread to new machines. The F-Secureterminology [1] mentions a key characteristic ofviruses being the replication mechanism. Theterminology further notes that viruses commonlyinfect certain files, such as EXE or COM files onPC systems, or the Master Boot Record of harddrives and similar.Trojan horses are, according to the F-Secureterminology [1] a program which appears toperform some action which may be desired bythe user, but in reality performs some other(often undesired) action without the userknowing. Essentially, the function of theprogram is to make the user allow it inside thesafe boundaries of the system, before silentlybeginning to execute malicious actions.1.3 Current malware statusconcerning the industrialautomation sectorFor more than 25 years malware has targeted theIT world. In the beginning, malware was easy todetect since it modified the visible content of thescreen. Nowadays, malware tries to hide itself asmuch as possible which makes it difficult todetect. Furthermore, financially motivatedcybercriminals are exploiting hundreds ofthousands of PC’s in order to make money. Untilrecently the industrial automation sector has notbeen touched by malware.Stuxnet, probably created in 2009, has shownlike no other former malware that security issuesdo not only reside in the regular IT-world, butalso in the industrial automation sector. Sincegeneral purpose operating systems like Windowsare used in the scope of SCADA, vulnerabilitiesaffecting the latter operating systems can alsoaffect the industrial automation sector.Stuxnet is a worm which is capable of spreadingvia USB-Sticks from Windows machine toWindows machine. Therefore, an infectedmachine does not necessarily need to beconnected to the Internet. Stuxnet is using zerodayvulnerabilities (vulnerabilities which havenot been known) and therefore, it is verydifficult to protect against Stuxnet infectionseven with an up-to-date and patched Windowssystem.Once Stuxnet has successfully installed itself ona Windows machine, it is capable of searchingfor automation systems. Moreover, it is lookingfor Siemens’ Simatic factory systems, the socalled SCADA systems. If Stuxnet cannot findany SCADA systems, it will remain silent anddoes not pursue any activity. On the other hand,if an automation system is found and morespecifically high-frequency converter drives,Stuxnet tries to alter its functioning.The reason why Stuxnet is so special is that it isvery complex software and seems to be part of atargeted attack. Simply the size of the binary, 1.5Mb, is unusually big for malware. Furthermore,it employs 5 exploits, 4 of them being zero-dayvulnerabilities. A single zero-day vulnerabilitycosts about $50 000 to $500 000, which makesStuxnet a very expensive malware. Finally, inorder to operate as silently as possible, Stuxnethas been signed with a stolen certificate.All these three facts already make it clear thatthis malware has been created by a highlysophisticated attacker with a considerableamount of resources. Stuxnet was found in June2010 and according to different sources it wascreated during 2009. This means those

8professional attackers are able to target industrialautomation systems and remain undetected formore than one year. Furthermore, Stuxnet hasbeen installed on many computers worldwide.Would have been a targeted malware installedon 15 computers be detected anytime?On October 18 th of 2011 a new malware calledDuqu which is very similar to Stuxnet wasdiscovered. Compile times of this new malwarecould indicate that it has been created in thebeginning of 2010. Duqu’s intention is not toalter any functioning of industrial automationsystems, but rather to collect sensitiveinformation and send it to a remote server.Therefore, it can be considered more as a kind ofTrojan Spy.Although the maturity of malware and the rate ofoccurrence in the industrial automation sectorare still quite low it is foreseeable that attacksmay become more frequent and severe in thefuture. Potential scenarios might includevandalism or sabotaging of industrial plants,municipal services or critical infrastructure justfor fun (by everyday hackers) or possibly thehijacking and/or blackmailing of entire plants.In conclusion, there exist highly sophisticatedand financially well-established malwarecreators targeting industrial automation systems.Nevertheless, there are signs that vandalismcases are occurring in the industrial automationsector, with similarities to vandalism caused byhackers in the ICT sector. Therefore it is crucialto analyze the risks and create appropriatedefenses.1.4 Standardization and relatedorganizationsGenerally, standardization aims to providecommonly approved methods and practices toenable transparency in defined areas. With thehelp of standardization people can do e.g.internet banking safely and securely or use theirmobile phones. Also industrial standardsfacilitate global trade, protect human life (safety)and lately to drive more and more so called"green values". ICT has met the challenges ofsecurity for a relatively long period. This canalso be seen when standardization activities insecurity sector are briefly introduced.1.4.1 ICT security standardsInternational telecommunication union (ITU)has group “ITU-T Study Group 17 – Security”which operates and covers a wide spectrum ofapplication areas for security. It has publishedover seventy standards (ITU-TRecommendations) focusing on security. Onekey reference is X.509 which has enabledelectronic authentication over public networksbeing an enabler for the rise of e-business. SG17 is active in standard development and incoordination between applications specificgroups (e.g. SmartGrid security) and otherorganizations. ITU standards are typically anunderlying technology in industrial automationsecurity or are linked to industry requirementsvia other organizations. [2]Standardization work in IT security is also doneby the International Organization forStandardization (ISO). Committee ISO/IEC JTC1/SC 6 Telecommunications and InformationExchange Between Systems is developingtelecommunication standardization for theexchange of information between open systems.This standardization includes both the lowerlayers that, as well as the upper layers thatsupport the application protocols and services. [3]Responsible technical committee for the securityis JTC 1/SC 27 IT Security techniques. Thereare 98 published standards and all of them areISO/IEC versions. The corresponding technicalcommittee in IEC organization is ISO/IEC JTC1/SC 27 IT security techniques.

9The first standard has been published as early as1998. The focus is on protection of informationand ICT. This includes generic methods,techniques and guidelines to address bothsecurity and privacy aspects. [4]1.4.2 Industrial automationstandardsIndustrial security standardization work underthe International Electrotechnical Commission(IEC) is a relatively new area, when compared toIT activities under ISO. Usage of standard ITtechnologies and open systems in processcontrol has increased the risk of security threatsin the industry. Connectivity to business/ITnetworks is also more and more common today.Also cyber attacks are more and more advancedtoday. This all means that there is a clear needfor industry specific standards/ specificationsand references.Technical committee IEC/TC65 [5] and its foursub-committees prepare standards for industrialautomation as well as process industry specificstandards including security aspects. TC65 haspublished four generic security standards to thisday and there are six standards underconstruction work. The focus of these standardsis on the network and system level.

10Table 1. A list of published IEC standards on industrial automation security (status 11/2011).StandardIEC/TS 62443-1-1 Ed1.0 (2009-07-30)Industrial communication networks -Network and system security - Part 1-1:Terminology, concepts and modelsIEC 62443-2-1 Ed1.0 (2010-11-10)Industrial communication networks -Network and system security - Part 2-1:Establishing an industrial automation andcontrol system security programIEC/PAS 62443-3 Ed1.0 (2008-01-22)Security for industrial processmeasurement and control - Network andsystem securityIEC/TR 62443-3-1 Ed1.0 (2009-07-30)Industrial communication networks -Network and system security - Part 3-1:Security technologies for industrialautomation and control systemsIEC/TR 62541-2 Ed1.0 (2010-02) OPCUnified Architecture – Part 2: SecurityModelNotesTechnical specification defines according to its namedefinitions around the topicStandard has a concept for a cyber-security managementsystem (CSMS) for industrial automation and controlsystems (IACS) including risk analysis, addressing riskswith CSMS and monitoring and improving CSMS.ISO/IEC 17799 and ISO/IEC 27001 are correspondingstandards for business/information technology systems.This standard has focus in specialties in IACS as failurescan have impacts on health, safety and environment (HSE)This part is published as a publicly available specification/pre-standard for industrial control system (ICS) securitypolicy.ICS requirements for plant operation can differ frombusiness/IT systems (e.g. response times) and theseaspects are taken into account when setting specificationsfor industry.Technical report IEC/TR 62443-3-1 helps to evaluatetechnologies and countermeasures to build security forIACS. Topic is divided into categories: authentication,access control, data encryption & validation, management,IACS SW and physical security. Different measures areintroduced, evaluated and recommended for each category.This standard also includes recommendations for devicelevel.OPC Unified Architecture (OPC UA) security model focuson securing the data exchange between applications.Security model describes the security threats of thephysical, hardware and software environments for OPCUA use.

11Preparation of industrial automation securityIEC62443-standards is done based on theInternational Society of Automation (ISA) work.ISA99 committee “Industrial Automation andControl Systems Security” has originally startedthis activity, which is now utilized by IEC. [6]A brief idea in this standardization is to divideprocess or plant in security zones connected byconduits and determine security by securityassurance levels (SAL’s) (alike with safetyintegrity levels in functional safety). Detaileddefinition work based on this approach for thesecurity system is ongoing.1.4.3 Other industrial automationsecurity related organizationsand standardsIEC technical committee TC 57 Power systemsmanagement and associated informationexchange is responsible for internationalstandards for power systems control equipmentand related systems and associated informationexchange. TC 57 launched the first standardabout data and communication security in 2003and there is a new series IEC 62351-1…8 for“Power systems management and associatedinformation exchange - Data andcommunications security” available. Theavailability of electric power systems is vital fortoday’s infrastructure and as control of thesesystems is based on digital communicationstoday and they are geographically wide systems,the security challenge is addressed with industryspecific standard. Communications protocols forsubstation automation like IEC 61850 areincluded.ISO/IEC joint technical committee JTC 1 SC37is preparing standardization of generic biometrictechnologies pertaining to human beings tosupport interoperability and data interchangeamong applications and systems. Personalidentification & ID cards with biometrics andbiometric data protections techniques, biometricsecurity testing are excluded.The Internet Engineering Task Force (IETF,http://www.ietf.org) is a large open internationalcommunity of network designers, operators,vendors, and researchers concerned with theevolution of the Internet architecture and thesmooth operation of the Internet. One of theoperating areas is security, which has multipleworking groups around different topics.1.4.4 Standardization summaryStandardization and related activities has strongposition in ICT security. Nature ofstandardization fits well in security as it offerstransparent and open platform for development.Technical solutions are reviewed by expertsglobally and the results are available in thepublic domain for use in industry. Security ofautomation is newer topic. However, there hasbeen active work by society and wider IECstandardization is ongoing. Industry shouldadopt present automation securitystandardization and prepare for the forthcomingoutcome. There are proven security methodsavailable; it’s more an industry task to applythem in proper and relevant extent. Somelimitations will apply in security realization dueto historical reasons, but the current IECstandardization approach gives a good startingpoint towards better automation security.2 Generic securityconsiderationsGenerally known, the three most importantelements of information security areconfidentiality, integrity, and availability (CIA).In the scope of automation systems the CIA triadmay shift to AIC, availability being the mostimportant characteristic of an industrialautomation system.

12Information needs to be available if requested.Denials of Service attacks for instance areattacks against the availability of information.Especially in industrial automation systems it iscrucial that the machines are working and thatinformation can be retrieved from them.Availability can be achieved by creating robustsystems with multiple layers of redundancy.Protection against Denial of Service attacks haveto be put into place.Integrity refers to protecting information againstunauthorized modification. It is necessary to beable to detect if the given information isqualitatively valuable or not. If an attacker isable to alter information this represents animportant threat which can be, depending on thecase, even worse than deletion of information.Integrity therefore guarantees that if theinformation has been altered, then this can bedetected. Different approaches can achieveintegrity, depending on the need. A simple hashfunction can be used to calculate the hash overinformation. In other cases asymmetriccryptography might be employed in order to signdata with a private key. In both cases thelegitimate receiver will have the certainty thatthe information has or has not been alteredduring transit.Confidentiality means that information shouldbe protected against unauthorized access. Thiscan for instance be achieved by encrypting theinformation. An attacker who is able to receivethe encrypted information is not able to disclosethe content of the information (if properlyencrypted and the secret keys are kept secret).Therefore the confidentiality is guaranteed.A further concept which could be added to theCIA triad is called accountability. The intentionof accountability is to be able to attribute a givenaction to a known actor. Furthermore, it mightbe necessary to know the time and activityperformed by the actor.2.1 Attacks and scenariosConcerning industrial automation systems,essentially two types of attacks seem to be themost important: Information leaking attacks andtampering attacks. First, information leaking canhave an important impact on advantages forcompetitors and may also affect the trust of thecustomers. Second, tampering can directly affecta customer and therefore represents an equallycritical threat. If an attacker is able tosuccessfully alter an industrial automationsystem, the consequences will inevitably damagethe manufacturer. Sections 3.2 and 4.1 of this<strong>white</strong><strong>paper</strong> will explain the detailedconsequences.2.2 Security programUnless a security program already exists in anorganization, it is of high importance that one isestablished. A security program commonlydefines the objectives, policies, and guidelinesregarding information security, and is alsoconcerned with the practices used to analyze,implement, and maintain security in anorganization and its systems. The securityprogram should concern IT systems, industrialcontrol systems, as well as the links betweenthese two.The security objectives, policies, and guidelinesare important tools for employees and partnercompanies for understanding why informationsecurity is important and how security isachieved in the organization. By helping peopleto understand their role in creating informationsecurity, it is easier for them to act securely intheir daily tasks.A crucial aspect of the security program is thecontinuous assessment of threats and risks,prevention and countermeasures, and constantmonitoring and improvement. The securityprogram must be viewed as a continuous process

13which maintains the information security in theorganization at the required level.In the field of industrial systems, the IEC 62443standard presents terminology, models, andguidelines for establishing a security program.3 Security in communicationbetween devicesThis section of the <strong>white</strong> <strong>paper</strong> describessecurity issues in the communication betweendevices, e.g. SCADA to PLC or field device,PLC to field device, or between field devices.3.1 Purpose of communicationCommunication between devices in an industrialcontrol system enables real-time monitoring andcontrol of the target system and devices.Additionally, auxiliary functions such asparameterization and configuration, assetmanagement, and potentially firmwareupgrading may take place in the communication.Higher level systems such as SCADA can beconsidered to have more of a “coordinating” role,acquiring data from the PLC and field devicelevel and utilizing this information to supervise,control and optimize the overall functionality ofthe system. Basic, non-real-time controlexecuted by the SCADA might include changingor overriding setpoint values. Acquired data isoften illustrated in a graphical user interface.When discussing communication protocols andlinks, the OSI reference model is commonlyused to represent the layers of abstractionprovided by different protocols. The figurebelow illustrates the OSI model, in which acommunication relationship between devices Aand B is viewed as consisting of multiple layers.The application layer on top has the highest levelof abstraction, providing functionality which isrelated to the main functionality of the device.It is interesting to note that in the OSI model,which was introduced in the late 1970s and early1980s, no layer explicitly considers the need forany security. Although this can be (and is)implemented inside layers in different protocols,the below illustration as commonly presenteddoes not detail the need for security functionality.If, in some systems, intermittent layers do notaddress security specifically, then thiscommonly has to be implemented in theapplication layer.Figure 2 The OSI seven-layer reference model.

14Depending on the communication link, not alllayers specified in the model are used. However,the purpose of the model is to illustrate that thelayering of protocols creates a kind oftransparency; the layering of protocols meansthat communication follows the path of the bluedashed arrow, but to the application layer itseems like it is communicating directly to theapplication layer of another device, as illustratedby the orange dashed arrow.3.2 Security threats and issuesThe use of communication networks has allowedinstallations to reduce the amount of cablingrequired, compared to e.g. wired I/O control andmonitoring. The reduced cabling results inreduced costs and generally also a moremanageable installation. Communication alsobetter utilizes the capabilities of modernelectronics. However, the available digitalcommunication interfaces in both systems anddevices pose security risks unless they arecorrectly addressed.The word ‘attack’ commonly means thedeliberate realization of a threat against a system,with the purpose of evading or circumventingsecurity measures and violating security policies.Attacks may be directed from outside anorganization or plant, but they may also beinitiated from within. It is also possible thatattacks are initiated due to a suitable opportunityarising, perhaps without significant planningeffort. There are also attacks which are highlydeliberate and thoroughly planned, perhaps withsuch an important goal that large amounts ofmoney, resources and time are used inimplementing the attack. Furthermore, securitythreats and issues may be associated with eitherintentional or unintentional actions of people, e.g.deliberate incorrect operation of equipment vs.incorrect operation due to ignorance or lack ofunderstanding of security policies.When viewing communication between devices,the security threats can essentially be viewed totarget either one or both of the devices, or thecommunication link and data. Before attacks areexecuted, it is common that the attackerperforms some surveillance of the target system.Device ADevice BLayer 7Layer 1Application layerPresentation layerSession layerTransport layerNetwork layerData link layerPhysical layerApplication layerPresentation layerSession layerTransport layerNetwork layerData link layerPhysical layerFigure 3. An illustration of the effects of one layer in theOSI model being compromised.

15Considering the OSI reference model, the threatsto a communication link may exist at any layerwhich is used. As an example, if the informationof a message is attacked on the data link layer,and the attacker succeeds in e.g. modifying thesource address of a message such that it passesthrough security defenses, then the layers on topof the data link layer are also compromised. Thelayers above the data link layer assume that theframe checking on the data link layer is reliableand has indicated a positive match, meaning thatthe encapsulated data shall be processed by thenext higher layer.It is not uncommon that an organization or itsemployees needs to have remote access toinformation and systems, commonly in the formof VPNs (Virtual Private Network). Thisfunctionality is enabled by tunneling protocolsusing cryptography to communicate informationsecurely over an untrusted network. Often it iswrongly believed either by an organization or itsemployees that the VPN system is immune tointrusion or attacks. However, it is well-knownthat VPNs are commonly used forcommunicating sensitive information, and inmany cases a VPN allows access to anorganization’s IT networks and applications. Inother words, VPN connections form an attractivetarget for attackers, and therefore emphasisneeds to be placed on analyzing the security ofremote connections.Threats to the security of VPN solutions are notmerely technology-based, but are sometimesalso due to human ignorance or error. As anexample, even if the technical security issues ofa VPN system are resolved, an employee maymistakenly or intentionally leak a username andpassword to a third party, effectivelycompromising the security of the entire system.If sent in plain-text using e.g. unencrypted email,it is possible for a hacker performing trafficsniffing to detect this information.Over the last years, the use of remoteconnections for accessing industrial controlsystems has increased. The connections aremade either to a SCADA or DCS system,however sometimes such connections areestablished directly to PLCs or even to fielddevices. It is essential to acknowledge that inconnecting these devices to a network withinternet access, the industrial control system andits devices are automatically exposed to threats.3.2.1 Reconnaissance activityLearning to know the target which is to beattacked is commonly the first step in the plan.This prestudy may involve physically visitingthe target if possible, obtaining information byobserving and potentially stealing information.For determining the structure or topology of thecommunication network(s) in the targetedsystem, various approaches can be considered.Information obtained through physical presence,as mentioned above, may includeschematics/blueprints or documentation on thestructure of an electrical system. Alternatively,configuration or project files used in controlsystems such as PLCs or SCADA systems mayprovide significant information regarding thelayout and operation of a system. It is importantto recognize risks such as this kind of documentleaking during the commissioning phase of aplant, e.g. in the interaction with suppliers andsubcontractors.If access to a communication bus can beobtained, it may be possible for an intruder tolisten to the communication activity in theconcerned bus or network. Apart from thecommunication which occurs frequently (e.g.monitoring and control commands in the case ofan industrial communication bus); infrequentlyor irregularly communicated information may beof interest to an intruder. Such information mayinclude passwords or other sensitive information,but also e.g. proprietary protocols may be

16observed with the purpose of reverseengineering. It may also be possible to determinesome structure of the bus or network based onthe activity log.The way in which the targeted devices arephysically installed or located in the plant affectsthe possibilities to study the communicationsystem and/or gain access to it. If the devices arelocated inside cabinets or electrical rooms, mostlikely there is only a communication cableentering and exiting the enclosure. On the otherhand, if the devices are distributed across theplant in the vicinity of the equipment or processcontrolled, this kind of enclosure need not bepresent which means that the device may bemore exposed to a potential intruder.If an attacker is successful in determining thetype of devices in a system, additionalinformation about individual devices may oftenbe found online. Such information includes usermanuals and data sheets, and in the terms ofindustrial communication often devicedescription files and examples on the kinds ofmessages to use for interacting with the device.3.2.2 Attacks on communicationThe communication between devices can beattacked in different ways.An example of an attack on a communicationbus is a man-in-the-middle attack, in which e.g.a gateway, switch or server is compromised. Inthis case, the information which is intended toflow through the intermediate component maybe read, modified and/or forwarded to a thirdpartybefore it is sent to its original destination.This behavior may occur silently, avoidingdetection while gathering information about thesystem. Theoretically, an intrusive device mightprovide incorrect commands or data to thelegitimate devices, causing behavior whichdiffers from that which is intended and expectedof the system. Depending on the system andcircumstances, this may cause harm to thesystem, the equipment or the process which iscontrolled.Another approach to compromising acommunication bus is by overloading the bus,essentially equivalent to a denial-of-service(DoS) attack. This kind of attack will likely bedetected once it is executed. Overloading of thebus or exhaustion of resources in the bus orsome device connected to it, may prevent thesystem from performing the functions that areexpected of it. The inability to executefunctionality may mean that services are deniede.g. due to certificates or authorization not beingcommunicated properly, which may prevent anoperator of the system from exercising control.Also the inability to control setpoint and/ormonitor actual values might cause the processcontrol to malfunction, potentially leading toequipment damage, risk of personal injury,and/or financial loss.Additionally the spoofing of information such assource or destination addresses forms anotherkind of attack. Protocols and systems which arenot able to authenticate the source or destinationaddress are vulnerable to spoofing, and wouldgenerally need precautions to be taken by e.g.the application layer to authenticate source anddestination devices. This spoofing may beutilized to make intruding devices act likelegitimate masters and attempt to control slavedevices in a potentially harmful way.It is important to protect the master devices inthe communication buses or networks of thecontrol system, regardless of which protocol orbus/network is in question. If a master devicegets compromised, the attacker can issuecommands appearing “legitimate” to the slaves.It is important to note that if functional-safetyrelateddata is communicated over fieldbusesusing the various functional-safety extensions to

17protocols, then e.g. man-in-the-middle attacksmay compromise the safety of the process. Sucha situation may pose a significant risk to humansafety and also carries financial risk. This isespecially true in systems where functionalsafety is entirely implemented by the automationsystem.3.3 Traditional fieldbusesIn this <strong>white</strong> <strong>paper</strong>, the term “traditional fieldbus”is used to refer to fieldbuses using a non-Ethernet medium, for example (but not limitedto) CAN- or EIA485-based fieldbuses.Communication protocols used in industrial andbuilding automation systems include e.g.Modbus RTU, PROFIBUS DP, CANopen,DeviceNet, BACnet MS/TP and LON.Many of these field buses are based on a masterslaveinteraction in which a master devicecommands and issues requests to the slavedevices. Such commands and informationreturned by the slave devices is generallycommunicated cyclically at an update rateranging from a matter of milliseconds to seconds.In many field buses, the master device isresponsible for handling the start of the system,configuring the slave devices and ensuring thatthe system is operating correctly. A slave is notallowed to send messages to the bus unlessrequested by the master device, or if the slavehas the token in a “token-passing” system.diagnostics use, otherwise the intruder wouldneed to connect such a stub. Obtaining accessthrough an existing device likely involveshijacking or manipulation of the firmware in abus node.Another factor possibly limiting theattractiveness of targeting a traditional fieldbusmay be the restricted openness and familiarity ofthe bus protocols. Although information aboutthe protocols can be obtained with sufficienteffort, specifications about IP-based protocols(e.g. UDP, TCP and FTP) are easily accessed.However, this “security by obscurity” cannot beviewed to increase system security considerably,because these legacy protocols are increasinglybeing replaced by standardized, welldocumentedprotocols. Additionally, an attackermay cause problems even by disrupting thephysical layer (electrical signals) and need notknow the communication protocols used in thesystem.Logging and analysis of the communication on atraditional fieldbus requires an access point tothe bus, as well as a tool for capturing the framesbeing communicated. As mentioned earlier, thiskind of eavesdropping or monitoring wouldrequire a direct access point with an intrusivedevice, or obtaining this information through anexisting device e.g. by hijacking or using othermethods.One beneficial factor of traditional fieldbuses ascompared to Ethernet networks is the restrictedaccess to the bus. When a plant is commissioned,a specific set of devices are usually connected tothe bus. For an attacker to gain access to thefieldbus, this would require either attaching anunfamiliar device to the bus, or obtaining accessthrough an existing device.Connecting a new device to the bus likelyrequires a physical presence at the bus; theremay be a bus stub available for e.g. servicing or

18Table 2. An overview of a few fieldbus protocols and their properties.Modbus RTU PROFIBUS DP CANopen DeviceNetSpeed9,6 – 19,2 kbit/s, orhigherup to 12 Mbit/s up to 1 Mbit/s 125, 250 and 500kbit/sCommunicationschemeMaster-SlaveMaster-Slave(multiple Masterpossible)Master-Slave,Client-Server andProducer-ConsumerMaster-Slave(multiple Masterpossible) or Peerto-PeerAuthenticationof devices?No authentication Device number Optional, e.g.vendor IDOptional, e.g.vendor IDSpoofing of datapacketspossible?Yes Yes Yes YesRemarksMaster node has nospecific address Slave devicescannot know theidentity of themaster node.Implementation isdone preferably inHardware.Implements a class2 Master which isused for e.g.diagnosticspurposes.In conclusion, only some buses use deviceauthentication, which is not especially spoofresistant.Once a malicious attacker is able to getaccess to the different buses, he can conductDenial of Service attacks and modify requests.3.3.1 Modbus RTUModbus RTU is a mapping of the Modbusapplication layer protocol on the EIA-485 serialline. This protocol is a master-slavecommunication bus featuring a single master. Interms of communication, the master co-ordinatesall transactions by issuing a request and thenawaiting a response from the correct slave. Themandatory supported bitrates are 9600 and19200 bits per second but others may also besupported. The response timeout, i.e. the time inwhich a slave must respond to a request by themaster, may be several seconds and isapplication-dependent.In the Modbus frames which are communicated,the master node has no specific device address;only slave devices are assigned an address.Additionally, the master can also use the address0 for broadcast messages, which are processedby all slave nodes.Because a Modbus request frame does notcontain a master address, the slave devicescannot verify whether the device issuing the

19request is the legitimate master, or an intrudingdevice. If the frame is valid and the slave is in asuitable state, the request may very likely beprocessed.The Modbus over serial line specification doesnot specify any mandatory requirement for themaster node to indicate whether it has detectede.g. the presence of a second master on thecommunication bus. Essentially, when a masternode in a Modbus-over-serial-line system is inthe idle state, it does not receive any data fromthe bus. It might be the situation that the busreceiver electronics is disabled. In this case, itneed not hear that another device is acting as amaster node.Since the bitrate of the system can be low, andthe response timeout of the system is relativelylong, an intruder does not need advancedhardware to access the bus. Commonly, thebitrates in a Modbus RTU bus are compatiblewith those of a PC serial port, meaning that aperson with a portable computer and suitableEIA-485 hardware and software can easilyconnect to the bus and possibly enter thecommunication loop.An intrusive device which has access to the buscan perform a denial-of-service attack e.g. byplacing its transmitter in the “active” state, asopposed to the “inactive” state which allows thebus to be idle. Thus this rogue device couldreserve the bus without releasing it, effectivelypreventing other devices from communicatingnormally. The intruding device could alsoactivate its transmitter intermittently, resulting inwhat might seem like random errors in thecommunication on the bus.3.3.2 PROFIBUS DPPROFIBUS DP is a master-slavecommunication bus which supports the presenceof multiple masters in the network. The mastersshare the EIA-485 medium using a specialtelegram, in which one master passes the tokento another master. Only the node which has thetoken can communicate. The PROFIBUS DPsystem can be configured to operate at up to 12Mbit per second. The PROFIBUS DP protocolfeatures a watchdog functionality, which is usedby DP slaves to monitor that the master devicesends updated I/O data frequently. Thewatchdog time is determined in the master setupand can be configured from a few millisecondsup to several minutes, or it can be completelydisabled.It is very common that the PROFIBUS DPprotocol of a device is implemented in hardware,either by using a single-chip solution whichincludes the protocol and an MCU core in thesame IC, or by using a separate MCU and aseparate ASIC which handles the DP protocol. Itis also possible to implement PROFIBUS DP insoftware but it is rather uncommon. Due to thehigh bitrates and thus tight timings of theprotocol, a potential attacker likely needs topurchase suitable hardware for accessing the bus.There are two classes of masters in thePROFIBUS DP system; class 1 which iscyclically commanding a number of slaves, andclass 2 which is e.g. a laptop or programmingconsole which can be used for configuration,maintenance or diagnostics. A class 2 master cancommunicate with other masters and their slaves;however it may only briefly perform actual I/Ocontrol. This is a managed feature which firstrequires stopping the data exchange with theprimary master.In each PROFIBUS DP message, two fields arereserved for the addresses of the sending andreceiving devices. A PROFIBUS DP slavedevice remembers the address number of themaster which initialized it; thus an attackerneeds to detect the address of the mastercontrolling a slave, in order to attempt tocommand the slave using a spoofed address.

20When the bus system starts, masters whichperform cyclical data exchange initialize theslaves which are assigned to them. Thisinitialization consists of a parameterization and aconfiguration step, in which the PROFIBUS DPparameters as well as possible vendor- ordevice-specific parameters are set in the slave.Additionally, the device number is verifiedagainst that which the master expects, to ensurethat the correct type of device exists at thecorrect address. In the configuration step, thelength and structure of the periodicallytransmitted I/O data is set, as defined in themaster setup. Both the parameterization andconfiguration procedures can be accepted orrejected by the slave. Each slave keeps track ofwhich master address configured them for dataexchange.To avoid the conflicting situation in whichdifferent masters try to command the same slave,it is possible to lock slaves to a single class 1master (the master which performs theinitialization procedure described above). It is,however, also possible that a slave is not locked,which would mean that a slave could be claimedby different masters. This is nevertheless morean issue of network management, i.e. ensuringthat slaves are locked to their primary master.to read the Identification & Maintenance (I&M)information from bus devices. The I&M is astructure of device identification informationwhich at a minimum includes the I&M0information, but optionally also other I&Mfields (see the table below) This kind ofinformation about a device (which can beidentified using its slave number in the bus) canreveal what the device is doing, the device typeand give clues as to how its behavior could becompromised. The I&M information may bechangeable by the owner or operator of a device,so in case this information is not write-protected,an intruder may attempt to change theinformation, e.g. change the text describingfunction, task, location or installation date sothat identification of the device istampered.Table 3. The I&M information inPROFIBUS and PROFINET devices.The PROFIBUS DP-V1 extension specifies anacyclic communication which can be used asneeded to e.g. read or write variables orparameters of a device, if it implements somedevice profile such as PROFIdrive or encoderprofile. A master class 2 can perform read and/orwrite operations targeted at a PROFIBUS DPslave device independent of the slave’srelationship to its primary master. This presentsrisk in case the master class 2 can modifyparameters which affect the operation of thedevice.If a device gains access to the bus, and is able toperform DP-V1 functionality, then it can attempt

21I&M Field Information DescriptionI&M0 Manufacturer IDOrder IDSerial NumberHardware RevisionSoftware RevisionRevision CounterProfile IDProfile-specific typeI&M versionI&Ms supportedNumber codeText stringText stringVersion NumberVersion NumberNumberNumberNumberVersion NumberBitmaskReveals the device vendor.Reveals the order number of the device.Reveals the serial number of the device.Reveals the hardware revision of the device.Reveals the software revision of the device.Change counter.Reveals implemented device profile.Possible profile-specific code.Reveals implemented I&M version.Reveals which I&Ms are supported.I&M1 Function TagLocation TagText stringText stringDescribes the function of the device.Describes the location of the device.I&M2 Installation Date Text string Reveals the installation date of the device.I&M3 Descriptor Text string Freely assignable comment/annotation.I&M4 Signature Text string Can be used as signature for tools.

22As with e.g. Modbus RTU, an intruding devicecould issue a denial-of-service attack on thePROFIBUS DP bus by transmitting data eitherin bursts or continuously. This wouldcompromise the normal communication in thesystem resulting in partial or complete loss offunctionality.3.3.3 CANopenCANopen is a higher-layer protocol which isbased on the CAN data link layer protocol.CANopen supports bitrates up to 1 Mbit persecond. The network is managed by a singleNMT master that controls the devices on thenetwork. Different types of communication aredefined as “protocols” in CANopen, e.g. ProcessData Object (PDO), Service Data Object (SDO)and Network Management (NMT) whichprovide different sets of functionality to thesystem.The PDO protocol can be configured to transmitin either synchronous or asynchronous mode. Inthe synchronous mode, devices communicatetheir input/output data within a specified timewindow of receiving a special SYNC commandfrom a synchronizing application. Asynchronousdata is transmitted without any relation to aSYNC command. The triggering of messagescan be event-driven, timer-driven or remotelyrequested. The asynchronous PDO protocol isvulnerable to an intruding device sending data tothe bus e.g. with spoofed addresses.The CANopen protocol supports a nodeguarding protocol, using which the NMT mastermonitors that slaves respond to a guardingrequest within a specified time window. If suchtimely responses are not provided by a slave, orits NMT communication status changes then theNMT master should react on this event. Lifeguarding is essentially allows the slave tomonitor the guarding performed by the master,and allowing the slave to react to not beingguarded in a timely manner. Additionally,CANopen features a heartbeat mechanism inwhich a heartbeat producer cyclically transmits amessage to heartbeat consumers. Missingheartbeats indicate that a slave has gone offlineand allows for reaction. It is mandatory toimplement either guarding or heartbeat.The CAN messages is shared by means of anarbitration of the CAN message priority. Thepriority is determined based on a bit field whichis mandatory in all CAN frames. The hardwareof every CAN device is required and able todetect when another device is transmitting amessage with a higher priority. In this case, the“losing” device backs off and cancels itstransmission, instead listening to the “winning”device.A device which gains access to the bus cansilently monitor the bus and observe thecommunication. Additionally, a denial-ofserviceattack could be launched utilizing theautomatic, hardware-based arbitration of theCAN frame. If an intrusive device repeatedlytransmits messages with the highest of priorities,no “normal” CAN frames will be communicatedon the bus as these will losing the priorityarbitration. Effectively, the bus is overloadedand system functionality which relies uponcommunication will suffer. Guarding orheartbeat protocols will trigger events after aspecified time, but communication is notpossible as long as the attack proceeds.In CANopen, the highest priority CAN frame isan NMT message for network management. TheNMT message contains one octet of data whichindicates the requested state of the targeted node,and another octet which specifies the nodewhich should change its state when receiving theNMT message. If the node number is 0, allnodes receiving the message shall change theirstate. Thus, an intrusive device could control thestate of the CANopen devices on the bus.

23It is also possible that an intrusive device whichhas access to the bus can transmit either valid orinvalid data to the bus, corrupting some of thenormal communication in the system. In the caseof transmitting valid data, the intruding devicecan act as a master, commanding slave devicesas it desires.CANopen specifies mandatory objects whichidentify the devices on the bus. An example isthe 1000h “Device Type” object, which containsthe device profile number which is implementedby the device. Another mandatory object is the1018h “Identity” object containing informationsuch as the vendor ID (mandatory) and possiblethe product code and revision number. Thisreadily available information may allow anintruder to study the device configuration in thenetwork, learning which kinds of devices (basedon device profiles) and whose devices (vendorinformation) are present.CAN-in-Automation (CiA), which is the userorganization for CANopen, has initiated aworking group on the topic of communicationsecurity in CANopen and the reliable encryptionand decryption of CAN frames.3.3.4 DeviceNetDeviceNet is a connection-based networkprotocol which is based on the CAN data linklayer. The DeviceNet protocol supports threebitrates; 125, 250 and 500 kbit/s. Master-slaveand peer-to-peer communication is supported byDeviceNet, still the majority of installationsfollow the master-slave scheme. There may bemultiple masters on the same network.Like many other protocols, DeviceNet specifiesa mandatory “Identity” object which containsinformation such as vendor ID, device type,product code, product name and revisioninformation. This information can provide anintruder with clues regarding the devices whichare installed in the system.The master in a DeviceNet bus may scan thenetwork at startup with the purpose of verifyingthat the actual network corresponds to thatwhich is configured. It can use information suchas the Identity object for checking vendor IDnumbers and product codes. DeviceNet featuresan optional heartbeat functionality which is usedto monitor the status of devices on the bus. Theheartbeat interval can be configured to an integernumber of seconds, defining the intervals atwhich the slave device sends a heartbeatmessage to the master. If the heartbeat from aslave stops, the master interprets this as a slavegoing offline and can react on this event.The DeviceNet data link layer is the same asused in e.g. CANopen or other CAN-basedprotocols, using priority arbitration in hardware.Because of this similarity, these protocols are allvulnerable to the same kinds of attacks whichare targeted at the CAN data link layer or thephysical layer. An intruding device may monitorthe bus, learning how the primary master opensconnections to its slaves. The intruder mayimpersonate the primary master and sendincorrect commands to the slave devices.3.4 Ethernet networksEthernet is a de facto standard medium incommunication, with a multitude ofcommunication protocols and applications. TheEthernet specification itself covers the twolowest layers of the OSI reference model(Physical Layer and Data Link Layer), while theInternet Protocol (IP) suite and its core protocolsprovide Transport Layer (e.g. TCP, UDP) andApplication Layer (e.g. HTTP, FTP or TLS/SSL)functionality.3.4.1 Ethernet physical layerExcept for the lowest layers in the OSI referencemodel, an increased level of abstraction asprovided by higher layers also invites to agreater risk for intrusion, vulnerabilities and

24malicious activity. The Physical Layer isconcerned with issues such as electricalcharacteristics and the encoding of data in themedium, and in general does not implement anysecurity features.3.4.2 Ethernet data link layerOn the next layer is presented the concept of theEthernet frame (of which there exist a fewdifferent types) containing amongst other thingsthe “MAC addresses” of the source anddestination device. These six-octet MACaddresses were intended to be a permanent andglobally unique numerical identifier for eachnetwork device. However, in most modernhardware it is possible to change the MACaddress, which may be maliciously used in e.g.MAC spoofing. An example of a MAC addressis 00:21:99:00:2D:A9.In an Ethernet MAC address, the first threeoctets form an OUI (Organizationally UniqueIdentifier) which is purchased by a devicevendor from the IEEE registration authority.These first three octets can be used to determinethe vendor of the device which is the sender orreceiver of an Ethernet frame. In other words, anattack which is intended to target the equipmentof a specific vendor theoretically only needs theMAC address OUI to detect potential targets.The MAC address identifies a single device,meaning that a receiver cannot determine fromthe MAC address of an incoming frame whetherthe sender is installed on the same networksegment (link) or on another segment which isbridged to the receiving device’s segment. Inother words, MAC address filtering cannot beused to create security barriers based on networktopology.MAC address filtering can be used to preventaccess to a network or prevent processing of aframe, but it can be circumvented by an intruderwho knows how to spoof his or her MACaddress. If the intruder is able to find a MACaddress which is not filtered, it is possible thatthe intruder gains access to a network(depending on whether other protectivemeasures are in place) or that the frame isprocessed by the receiving device.3.4.3 Internet ProtocolInside an Ethernet frame, there may beenveloped an Internet Protocol (IP) datagram.Currently the IPv4 standard is most widely usedbut IPv6 is in deployment. The IP protocol is aconnectionless protocol, meaning that messagescan be sent from one device on the network toanother without requiring any priorarrangements e.g. handshaking. The sendermight believe that the receiver is on the networkand capable of receiving data, when in fact it isnot. The IP protocol does not guarantee deliverysuccess or order of delivery, nor can it guaranteethat a transmitted message will be received onlyonce by the recipient, as network conditions maycause loss, duplication or out-of-order deliveryof IP packets. This kind of reliability andsecurity requirements are enabled by the use ofhigher-layer protocols e.g. TCP.The IP protocol makes use of IP addresses (inIPv4 these are four-octet addresses) and subnetmasks which allow the subdivision of a networkinto subnetworks. An example of an IP addressis 192.168.1.0, with a subnet mask of255.255.255.0. This example means that thesubnetwork has the network prefix “192.168.1”and the last eight bits of the IP address is usedfor identifying individual devices in thatsubnetwork.The Address Resolution Protocol (ARP) isdesigned with the purpose of providing a wayfor devices and networking equipment to resolvethe MAC address corresponding to an IP address(i.e. learning the device identification number ofa specific network device). Sometimes there isalso the need for the opposite conversion, i.e.

25learning the IP address for a specific MACaddress. One protocol intended for that use is theDynamic Host Configuration Protocol (DHCP).IP filtering is the process of allowing certain IPdatagrams access to a network, or allowingframes to be processed in a device. Differentfields of the datagram may be subject to filtering,e.g. protocol type, datagram type, the source ordestination IP address. If the filter rejects aframe based on its IP datagram, the frame isdiscarded as if it had never been received.If an intruder is able to configure the contents ofan IP datagram suitably, so that it passes thesecurity settings of a network device, it ispossible that he or she gains access to a networkor that a frame is processed by a receivingdevice.3.4.4 Transport layerThe Transport layer builds upon the services ofe.g. the Internet Protocol. This layer enables thedetection of missing or out-of-order frames, orretransmission of frames which have not beenacknowledged by the receiver. Additionally, thetransport layer may provide a concept ofconnections between network devices, so that ahandshaking is performed before data exchangecan commence between two devices. In theInternet Protocol suite, typical transport layerprotocols include the User Datagram Protocol(UDP) and the Transmission Control Protocol(TCP).In addition to the aforementioned improvements,the transport layer protocols TCP and UDPintroduce the use of ports in communicationendpoints. Ports are associated with a networkdevice IP address so that the two in combinationform the complete source or destination addressfor a communication connection. Some portnumbers are predefined for commonly usedservices, while some port numbers may be usedfor custom purposes. As an example, theModbus protocol over TCP uses the port number502.Firewalls are commonly configured to check theport numbers in Ethernet frames and allow ordisallow certain traffic into or out of a network.This functionality is referred to as portforwarding. An example of the use of portforwarding could be allowing computers on theInternet to perform an HTTP access to a webserver within a private LAN, by allowingconnections on the port 80 (which is reserved forHTTP traffic).When preparing for an attack, an intruder maytry to connect to a range of ports in sequence ona specific network device. This activity iscommonly referred to as port scanning, thepurpose of which is to detect any open portswhich may be used as an entry point into thedevice. Another type of scanning is calledportsweep, in which connection attempts to aspecific port number is made to multiplenetwork devices.3.4.5 Network configurationThe networking equipment must be correctlyconfigured and appropriate security featuresmust be enabled. Because different equipmentsupports different options for configuration, it isdifficult to provide a comprehensive list ofthings to address. At a minimum, however, thedefault username and password foradministration of the settings must always bechanged, so that it is not trivial to change thesettings of equipment. Passwords forconfiguring network equipment must be selectedwith good strength, i.e. having different kinds ofcharacters (numbers, upper- and lower-casecharacters, special characters) and withsufficient length.IP address filtering in networking equipmentmay prevent attackers with basic skills fromaccessing the network. Similarly, MAC address

26filtering is another barrier for preventing simpleattacks. URL filtering may be applied in order toprevent persons inside the safe network zonesfrom accessing known, insecure content in theInternet. Application-level firewalls or onessupporting stateful packet inspection (SPI) canbe used to further increase the level of security.Firewalls shall be configured in such a way thatonly the required functionality is open andenabled. Firewalls shall be used where needed,e.g. as required by the network security zoneswhich are setup for an organization. Firewallsfrom different vendors may be used in order toprovide some security due to diversification.Appropriate encryptions need to be used e.g. forwireless connections. As an example, manyWireless LAN (WLAN) routers support WEP,WPA and WPA2 encryptions. Of thesealternatives, WEP should not be used, WPA canbe used but WPA2 provides the best level ofsecurity. Furthermore, in order to increase thelevel of security, WPA should be used in theenterprise mode (known as WPA-Enterprise orWPA-802.1X mode).Manufacturers’ recommendations regardingwhich equipment works well together should befollowed. This is especially true if therecommendation is based on securityfunctionality.3.4.6 Network topologyIt is important to consider how the Ethernetnetwork is constructed, in terms of topology.The bridging between networks of differentsecurity, e.g. between an Industrial Ethernetnetwork and an office- or IT-network, should becarefully considered and configured.There is also a risk regarding physical security ifthere are unused ports in Ethernet equipmentwhich can be used by an intruder to gain accessto the network. Sometimes, unused ports innetworking equipment are used for portforwarding, which means that the traffic throughe.g. a switch or similar piece of equipment isforwarded to a certain, unused port. This portcan be used for logging and traffic analysispurposes by e.g. connecting a computer withsuitable capture software.Because Ethernet has become more popular indifferent automation systems, there have alsoappeared a number of gateways and bridgeswhich allows connection of Ethernet totraditional fieldbuses. These devices present anaccess point from an Ethernet network to fieldbuses, which were originally designed to beclosed networks. The features of such gatewaysand bridges, such as integrated web interfacesfor configuration or monitoring with the purposeof allowing simple configuration possibly fromremote locations, may encourage the looseningof security configurations. As an example, thebrowsing of a web interface generally requiresthe port 80, which is reserved for HTTPcommunications, to be open. However, access tothe web server in a device from outside meansthat the HTTP port is also exposed to nonintendedusers, which may target attacks on it.Although this kind of web interface iscommonly protected by a username-passwordcombination, the default value is often listed inthe device manual which is available online.Although the password may be changed, it is notuncommon that the new password has poorstrength, due to user/operator ignorance and/orinadequate instructions to choose the passwordcleverly. It is worth mentioning, that if anintruder manages to determine the password fora gateway (or some other networking device) itmay be possible for the intruder to change thepassword, security settings or other functionalityrelated to the system.

273.4.6.1 Ethernet hubAn Ethernet hub is a layer 1 (physical layer)device which does not examine or manage thetraffic through it, mainly rebroadcasting enteringpackets to all the other ports. Because hubs aregenerally not concerned or even aware of framesor packets, they tend to operate mostly on rawdata. A consequence of this is that hubs do notintegrate any security functionality and thusshould not be used in industrial automationnetworks.3.4.7 Industrial Ethernet protocolsThere exist a large number of communicationprotocols which are based on the Ethernetmedium; some examples of industrial protocolsinclude PROFINET IO, EtherCAT, ModbusTCP, and EtherNet/IP. Other areas ofautomation include BACnet/IP in buildingautomation or GOOSE messaging as defined byIEC 61850 in power systems communication.3.4.6.2 Ethernet switchBy an Ethernet switch it is generally meant alayer 2 (data link layer) device which routes databased on MAC addresses; however there arealso switches in higher layers. There aregenerally two kinds of switches; unmanagedones which have no configuration interface oroptions, and managed ones which can beconfigured by the user.A switch discovers the devices which areconnected to its ports and maintains a list ofsuch devices and their addresses. When anEthernet frame enters to the switch, the switchchecks its table to determine which port (if any)contains the device with a MAC addressmatching that of the frame. If a match is found,the frame is forwarded only to the concernedport.3.4.6.3 Ethernet routerAn Ethernet router is a layer 3 (network layer)device which routes data based on IP addresses,thus enabling the construction of subnets. Itchecks the incoming frames for their addressinformation and determines how to forward theframe, based on a routing table or routing policy.The routing table can be dynamically achievedusing e.g. routing protocols; however anoperator may also configured static routing rulesmanually.

28Table 4. An overview of a few industrial Ethernet protocols and their properties.Modbus TCPPROFINET IO EtherCAT EtherNet/IPModbus UDPCommunicationschemeMaster-SlaveMaster-Slave (multipleMaster possible)Master-SlaveMaster-Slave(multipleMasterpossible) orPeer-to-PeerAuthentication ofdevices?NoauthenticationInitialization, vendorID and device IDOptional, e.g. vendorID, product code,revision number, serialnumberOptional, e.g.vendor IDSpoofing of datapackets possible?YesYes. If an existingdevice cannot becompromised,specialized hardware isneededYes. If an existingdevice cannot becompromised,specialized hardwareis neededYesRemarksSometimesimplemented inhardware, especially inthe class IsochronousReal-TimeHardwareimplementation inslaves3.4.7.1 Modbus TCP and UDPModbus TCP is a mapping of the Modbusapplication layer protocol onto the TCP/IPtransport layer protocol. Another variant isModbus UDP which maps the same applicationlayer protocol onto the UDP protocol. Thesemappings permit the use of Modbus on theEthernet medium.In Modbus TCP/UDP, the IP addresses are usedto identify devices. A Modbus TCP/UDP devicemay include functionality for both slave andmaster modes. The message framescommunicated in this network do not separatelyidentify a device as a master, which is analogousto the master not having its own address in theModbus RTU protocol. Devices cannotauthenticate a device as a “legitimate” master.The difference between using TCP and UDP liesmainly in the consideration that Modbus on TCPensures that messages are reliably delivered, inorder, while potentially reducing the timelinessof delivery. Using UDP, there is no guaranteethat messages are delivered in the correct order(or delivered at all), but the logic of missingrequests/responses and retry is moved to theModbus application layer. Thus, timingconsiderations are different from the TCP casein which retransmissions are handled by thetransport layer. Data such as setpoint and/oractual values are relevant only for a short spanof time after “sampling”, thus there is little sensein trying to retransmit these packets numerous

29times just because TCP says so. When usingUDP, retransmission of old data can be avoidedin case one cycle of data is missed; the nextcycle with up-to-date data is sent instead.The bridging between Modbus TCP or ModbusUDP into the serial line variants, e.g. ModbusRTU, has become more common as IndustrialEthernet also increases in popularity.3.4.7.2 PROFINET IOPROFINET IO is an Ethernet-based protocoldesigned for real-time communication. Theexperience gained from the PROFIBUS fieldbuswas integrated with the Industrial Ethernettechnology to create PROFINET. The masterdevice in a PROFINET IO system is called the“Controller”, while slaves are referred to as“Devices”. Cyclic data exchange in PROFINETIO takes place directly in the Ethernet layer 2,not involving any transport protocols such asUDP or TCP; the messages are addressed usingthe MAC addresses of the PROFINET IOdevices. Acyclic data is exchanged using theUDP protocol.The cyclic data exchange connections aremonitored using a watchdog time, which isconfigured as a multiple of the update (cycle)time of the network. As an example, if theupdate time is 8 milliseconds and the watchdogtime multiplier is 3, then the watchdog time willbe 24 milliseconds. If the communication is idlefor longer than this period of time, the devicemonitoring the watchdog will detect this eventand execute some reaction; however this isdevice- or user-specific.Because the PROFINET IO real-time dataexchange frames are communicated in theEthernet layer 2, these frames contain only MACaddresses. This means that the real-time framescannot be communicated outside a subnet whichis delimited by a router, because routers formsubnets based on IP addresses as defined in layer3.A hardware implementation is required for themost deterministic class of PROFINET IOdevices, known as IRT (Isochronous Real Time).This is commonly an ASIC with integratedswitch and other functionality needed for thePROFINET IO IRT protocol.A PROFINET IO Controller always needs toconnect to a PROFINET IO Device using anexplicit “Connect” message. After this theController downloads startup parameters to thedevice, following a handshake verifying that thestartup is successful and complete. An intruderwishing to establish a connection to a device, i.e.to act as a second master, has to know how thedevice is structured and how to initialize itproperly at startup. Based on vendor ID anddevice ID it may be possible to find the GSDMLdescription file for the device, however if thedevice is modular then knowing the trueconfiguration likely requires physical access ordocumentation about the system.The PROFINET IO protocol furthermorerequires the same I&M functionality asdescribed for PROFIBUS DP earlier.PROFINET IO devices thus expose the sameinformation to anyone who can access it.At startup the PROFINET IO controller providesthe vendor ID and product ID that is configuredfor the targeted IO device. The device checks themaster’s expected information against its owndata and aborts the connection request if amismatch occurs.Two potential methods of attacking thecommunication in a PROFINET IO system aredescribed in [7]. The authors propose that it maybe possible to modify the outputs of aPROFINET IO Device without being detectedby either the Device or the Controller.

303.4.7.3 EtherCATEtherCAT is a real-time Ethernet-based protocolin which the Ethernet frame moves similar to atrain along rails from the master, through allslave devices and back to the master devicewithout stopping. Slave devices process theEthernet frame “on-the-fly”, causing only a tinydelay in each slave device. Devices take datafrom and put data to different sections of theEtherCAT frame, depending on how theEtherCAT master has configured the slaves atstartup. The “on-the-fly” processing requires aspecialized hardware in the slave devices, whilethe master implementation can utilize virtuallyany Ethernet network interface such as PCnetworking cards. As a result, compromisedslaves could spoof at least data in the parts of theEtherCAT frame which they are configured toprocess. A compromised master, or one which isthe subject of a man-in-the-middle attack, couldresult in spoofed data and altered configurationof the slaves.Depending on the implementation, theEtherCAT master can be configured to checkvarious aspects of the slave device, e.g. vendorID, product code, revision numbers and serialnumber at startup. These features are commonlyoptional and can be disabled.EtherCAT supports different subprotocols whichare tunneled in EtherCAT frames; examples ofsuch are CAN-over-EtherCAT (CoE) andEthernet-over-EtherCAT (EoE). The CoEprotocol is an integral part of EtherCAT and isused to identify, configure and control the slaves.The EoE protocol is optional and allows non-EtherCAT devices to be added to the systemusing switchports, which “de-tunnel” theEthernet frames from the EtherCAT frames. It ispossible to tunnel Ethernet frames through themaster PLC if such a feature is implemented andenabled.Logging of the EtherCAT traffic may bepossible in case there is a switch in the networkwhich is configured to forward messages to anunused port. If the switch is not a real-timeswitch, the real-time attributes of the EtherCATcommunication may not be evident from the log.It may also be possible to log the EtherCATcommunication via the EtherCAT master, whichmay e.g. be PC-based running Windows.The EtherCAT protocol diagnoses the networkand provides indications regarding e.g. networkor slave problems. Additionally, the protocolsupports redundancy such that if the network isconstructed like a ring, a broken or disconnectedcable or node somewhere in the ring does notprevent the operation of other nodes.Furthermore, EtherCAT features timesynchronization between master and slaves.It is possible that an intruding device whichgains access to the network transmits messagesinto the network, which easily disrupts theEtherCAT communication. This will interferewith both control and monitoring of the processand equipment, as data exchange is hindered andfurthermore time synchronization-dependentfunctionality is disrupted.3.4.7.4 EtherNet/IPEtherNet/IP is an Ethernet-based protocol whichimplements the Common Industrial Protocol(CIP) which is also used in DeviceNet.EtherNet/IP uses the UDP and TCP protocols forcommunication. EtherNet/IP follows the masterslaveand peer-to-peer communication models ascommon in other protocols.The EtherNet/IP protocol presents the same“Identity” object as DeviceNet, thus thisinformation can be used for detection and studyof EtherNet/IP devices. An EtherNet/IP mastermay check the information of a device, e.g.vendor ID and product ID, in order toauthenticate the device. Another similarity to

31DeviceNet is the heartbeat mechanism by whichthe network device states are monitored.EtherNet/IP devices are subject to the genericthreats which face essentially all Ethernet-baseddevices, e.g. espionage by logging of thenetwork communication, denial-of-serviceattacks, potential man-in-the-middle attacks, orattacks on a specific layer in the OSI model.3.5 Recommendations forenhancing securityA large number of recommendations forenhancing the security in communicationsbetween devices can be identified, but it is notpractical nor is it the purpose of this document toexhaustively list these. It must be rememberedthat no system is 100 % secure so that it couldnot be broken, given enough resources, time andmotivation; this also holds true forcommunication networks in industrial controlsystems. The set of feasible improvements tothis kind of security depends largely on theindividual characteristics of a system, and themodeled threats, tolerated risk and derivedpriority for addressing vulnerabilities shall guidethe implementation of security improvements.Physical security can be considered of keyimportance concerning access to thecommunication networks, especially in the caseof traditional fieldbuses, in which physicalaccess to the bus is necessary for maliciousbehavior. This is an important aspect also forEthernet-based networks, although attentionmust be paid in these networks also to remoteaccess. In terms of the security at the plant, oneitem to consider includes the cabling of the bus;the possibilities for an intruder to trace thecabling and document the system could bereduced. Also, locking devices inside cabinets orelectrical rooms discloses fewer clues about theiruse, connections and configurations, comparedto devices which are not enclosed. The accessrights to physical locations in which criticalsystems are operating should be assessed and, ifdeemed necessary based on vulnerability andtolerated risk, restricted appropriately. It is alsopossible to implement critical communicationlinks using optical fiber, which are not easilyintercepted.Unused Ethernet ports in e.g. network equipment(switches, hubs) or in field devices (withintegrated switch functionality) can be protectedfrom unauthorized use e.g. with plug guards,which are physically plugged into the port. Theplug guard requires a key to be removed, thuspreventing anyone not possessing the key fromconnecting to the network.Functionality which is password-protected couldattempt to ensure that the factory-defaultpassword is changed to some other password.More importantly, such password-protectionshould require that the selected password fulfillscertain requirements regarding strength, such asrequiring a mix of letters, numbers and specialcharacters, and having a minimum length of e.g.six or eight characters.Care should be taken to improve security also atthe lowest layers in the OSI model. As anexample, if the data link layer is compromisedfor instance by a falsified source address ortampered data, the layers above in the OSImodel are also affected although they might notbe aware of the situation.When selecting communication protocols for theprocess control network, but also e.g. for remoteconnections, attention should be paid to thesecurity features which are provided by theprotocols. As examples can be mentioned thestrength of encryption or the protection againstreplay attacks using sequence numbering and theease of circumventing these mechanisms. Also,when procuring equipment for networks, thesecurity functionality offered by different

32devices should be assessed, preferring deviceswith advanced security options. A look at theuser’s manual, which is commonly available fordownload from the Internet without cost, canprovide an impression of how mature thesecurity of a device is.The threats against a communication network ina plant shall be assessed and modeled, either byan internal or external assessment team. In thisanalysis, it is crucial that the participatingpersonnel think as an attacker. A list ofvulnerabilities and possible exploits shall beestablished, against which a list of securitymeasures shall be constructed. Highest priorityshould be assigned to implementing themeasures which remedy the vulnerabilities withhighest risk, followed by the remedies which areeasiest and quickest to implement. This is not tosay, that low-risk vulnerabilities and hard-toimplementsecurity measures can be ignored oravoided, but they may be assigned to a laterphase in order to quickly raise security.4 Security in field devicesThis section of the <strong>white</strong> <strong>paper</strong> discussessecurity aspects of field devices. By this ismeant the sensors and actuators at the lowestlayer of the automation pyramid, which interactwith, control and monitor the actual process andequipment in a system. These devices arecommonly based on embedded firmware withfunctionality to allow customization to suit theapplication needs.4.1 Security threats and issuesThere are mainly two threats against fielddevices which should be taken care of:Information leakage and tampering of thedevices.4.1.1 Information leakageDepending on where the field device isemployed, information leakage can occurthrough mainly three channels: Through an ITleak, human leak, or physical leak. At themanufacturer side, an IT leak could happenwhere the field devices are programmed andconfigured. If responsible computers are infectedwith a Trojan horse, an attacker could easilyobtain configuration files and access keys.Social engineering attacks should not beunderestimated and can give an attacker thepossibility to access confidential informationabout field devices through a human leak.The physical leak could happen on themanufacturer side, but is more probable whenthe device is employed in the field. If amalicious attacker is able to obtain a field devicehe is able to analyze it extensively. Reverseengineering can be conducted on the analyzedhard- and software.4.1.2 Tampering risksField devices can be manipulated in general intwo different ways: The attacker can insertspoofed firmware updates or change deviceparameters through the PC software controllingthe device, or using the device’s integrated userinterface such as a keypad and display.If an attacker is able to control the PC,configuring the devices at the manufacturer, hecan alter configuration parameters and theinstalled firmware. An attacker will alter devicefirmware with either one of the following twomotivations: First in order to provokedysfunction of the device, or second to improvethe performance of the device.A malfunctioning device can create damagewherever the field device is employed.Furthermore, not only the field device will beaffected, the entire production chain in which thefield device works will be influenced.

33Tampering with a field device in order toachieve better performance can be driven byfinancial benefits. If an attacker can successfullyand significantly improve the performance of afield device, he can buy cheaper devices, tunethem, and sell them consequently as moreexpensive devices. Usually firmware updates areencrypted with a symmetric key which is storedon the field device. Furthermore, the encryptedfirmware updates can usually be retrieved fromthe Internet. Therefore, in order to modify afirmware update, the attacker would first need toobtain the encryption key, decrypt the firmware,modify it, and finally encrypt it again. Since theencryption key is stored on the field devices, amalicious attacker needs to search in memoryfor the key.4.2 Simple field devicesBy “simple” field device is herein referred to asa device which does not employ a full-scaleoperating system, but possibly some kind ofscheduler mechanism. These schedulermechanisms may be developed completelyvendor-specifically, thus there may be noinformation publically available on theirworkings. Commonly, the design decision to usea scheduler instead of an operating system maybe related to the low complexity of the device,limited resources such as memory, or otherconstraints.As scheduler-based devices consist of embeddedfirmware, the reverse engineering and themodification or tampering is non-trivial.However, if an attacker is able to obtain thebinary code from the device, it may be possibleto analyze its behavior and, with sufficient effort,identify vulnerabilities. Nevertheless, dependingon the device, if its functionality and role withindifferent systems is not significant enough, anattacker’s motivation may not be sufficient to gothrough this reverse-engineering effort.If the device provides a user interface, it ispossible that an attacker targets this interfaceand tries to alter the behavior of the device. E.g.buttons or switches can easily be used by aperson who has physical access to the device.The wiring and connections of a device may alsobe the target of tampering, if they are accessible.4.3 Embedded devices with realtimeoperating systemsMost embedded field devices utilize some realtimeoperating system (RTOS), of which thereexist a large number of differentimplementations. The operating systems enablemulti-tasking and necessary support functions tothe device firmware. Documentation on thedifferent systems may be available in varyingamounts; however the generic operating systemtheory applies to virtually all systems.Because these operating systems are part of theembedded firmware, the direct modification ofthe device binary is not an easy task. However,if one succeeds in e.g. reading the binary code ofthe device, it may be possible to detect textstrings stored in the code which contain clues asto which operating system is used. Other textstrings may also disclose software componentswhich are used or version numbers.Similar threats relate to the RTOS-based devicesas simple field devices, however these slightlymore advanced systems may be of higherimportance in a control system and thereby themotivation to attack these devices with RTOSsmay be higher.It is common that some methods of diagnosticsor debugging are left enabled in the devices, forthe purpose of e.g. field troubleshooting. Theseinterfaces present a possible way for studyingthe device and its functionality.

344.4 Embedded devices withgeneral-purpose operatingsystems4.4.1 Operating systemvulnerabilitiesDue to the complex nature of operating systemsand the software environment executed on top,vulnerabilities do and will continue to exist.Sometimes the vulnerabilities are found in theoperating system kernel itself, however in manycases the vulnerability is caused by the differentservices and applications which are executedusing the services of the operating system.By the word “vulnerability” is meant an error(e.g. due to misspecification, incorrectimplementation or simply a human mistake)which can be used by an attacker to performmalicious activity on a system or network.Different kinds of activity may be possible, forexample executing code or commands, accessingrestricted data without proper authorization, orconducting denial-of-service attacks.It is common knowledge that general-purposeoperating systems (such as Microsoft Windowsor Linux-distributions) are targeted by malware.One reason for targeting these systems is theirpopularity; if a malware can be targeted at awidely used system, the potential impact andassociated achievable notoriety for the creator ishigher. Also operating systems intended e.g. formobile phones and smartphones, such asSymbian or Android, have been targeted bymalware.4.4.2 Open-source systemsOpen-source systems may, from one perspective,be considered at risk as the source code isreadily available to anyone, including malwarecreators. Thus, with proper analysis it is possibleto detect vulnerabilities based on the source codeanalysis and modeling of different scenarios.Furthermore, online issue and vulnerabilitytracking systems may highlight the detectedissues, sometimes also presenting which versionof the system includes the problem and when ithas been corrected.This information can be helpful in tracking thehistory of security issues in a system; howeverthis kind of log can also be used by malwarecreators to make the malicious software adaptitself based on the installed version of anoperating system. Nevertheless, nowadays it isvery common for exploit researchers to makebinary differences e.g. between patched andunpatched Windows drivers. Therefore, it isequally possible to reconstruct vulnerabilityunder Windows as under Linux.On the other hand, the open-source communityprovides a wealth of competence and resourceswhich review documentation and source-code,while also actively contributing to thedevelopment including correction of identifiedissues. The open-source nature of a systemshould thus not be viewed as a puredisadvantage, as long as the backing communityof developers and stakeholders is competent andcapable of maintaining it.4.4.3 General-purpose operatingsystemsThe experience from desktop operating systemshas shown that all kinds of operating systemshave vulnerabilities regardless of open source orclosed source. Microsoft Windows for instancehas been improved by Microsoft throughconstant and serious effort, because it has beenshown to not be secure enough. CurrentMicrosoft Windows versions have asignificantly superior level of security comparedto older versions. Linux implemented earlyimportant security features like division ofprivileges, whereas under Windows until

35recently the default user administrator privilegeshad. Because of the threats, things have beenimproved on both sides, and it is difficult to statethat Linux is more secure than Windows or viceversa.Both, Windows and Linux are implemented inembedded devices. Knowing that is relativelyeasy to update desktop operating systems, thismight not be true for embedded operatingsystems. An update would be very difficult if theconcerned device is running in a productionenvironment and cannot be rebooted withoutinterrupting an entire factory. Moreover, notevery field device has a permanent Internet ornetwork connection. A manual update procedurewould be necessary and depending on thenumber of affected devices this requires aconsiderable amount of time.Vulnerabilities are provided to the operatingsystem vendors from a lot of different sources ona weekly basis. General-purpose operatingsystems do provide a lot of advantages, but if anattacker is able to find a single vulnerability in it,he may exploit every device running the specificsystem. Therefore, somebody needs to take care,that field devices employing a general purposeoperating system are constantly kept up-to-date.To not use a general purpose operating systemand write from scratch a custom operatingsystem might, depending on the complexity,result in fact in a far less secure system (alsocalled security by obscurity).When the operating system of a device isupdated, the device usually needs to be rebooted.But in some cases updates can create conflictswith former software employed in the device.Therefore, extensive testing needs to be appliedbefore updating productive systems in order tokeep the negative effect of the downtime assmall as possible.4.5 Recommendations forenhancing security in devicesIn general it is very difficult to protect a device,once the attacker is able to gain physical accessto it. If possible the disassembly of the deviceshould be made more difficult, nevertheless if anattacker has sufficient time and equipment thisdoes not hinder him from analyzing anobfuscated device.In the design of devices, security needs to beaddressed at all levels and in different scenarios.Using an attacker’s perspective, enhancingsecurity in the device should be a continuousprocess about identifying weakest links andstrengthening them. Threats to a product orproduct family should be modeled andappropriate measures to correct these determinedand implemented.4.5.1 Debugging interfacesInterfaces for debugging and manufacturing (e.g.JTAG or similar, serial ports for text output)shall not be utilizable in the production versionof a device. The interfaces may be rendereddisabled either by not assembling electricalcomponents (e.g. zero-ohm jumpers) or bysecurity functionality in the ICs in the product.A debugging interface which needs to beenabled in a field-installed device could e.g. beprotected using cryptography, so thatauthentication using a key is needed before theinterface opens. Authentication keys need to bestored securely, protected from the attacker.4.5.2 Communication interfacesMany devices feature one or morecommunication interfaces. All such interfacesneed to be appropriately protected againstmalformed or bad messages, preventing issuessuch as buffer overflows or crashes fromoccurring. Communication protocols which are

36not intended for the end-user shall not beenabled in a device.Detailed information about the device, orinformation revealing the technicalimplementation of the device, shall not becommunicated outside the device unlessabsolutely necessary. Secret or criticalinformation, which needs to be communicatedoutside the device, must be encrypted with astrong algorithm and a good key. Such keysneed to be stored securely so that they cannot beaccessed by the attacker.Communication interfaces to a PC program maybe targeted by an attacker, either by monitoringthe traffic on a serial, USB or Ethernet link, orby reverse engineering the PC program itself. Bystudying the program or the communication, theattacker may detect commands which are hiddenfrom the user interface of the PC program, ormay apply existing commands in new ways.Monitoring e.g. the serial port communication iseasy using available PC programs. It is alsopossible that the user records the communicationand replays select portions in order to decipherthe functionality of the device.If the communication interfaces of a deviceintegrate some security features (e.g. reminiscentof a firewall in Ethernet applications), then thedefault configuration should be that all access tothe device is prevented. The purpose is that onlythe smallest required number of changes to thesecurity configuration is made in order to allowthe system to work as expected.4.5.3 Firmware protectionThe binary firmware of a product can beprotected from being extracted e.g. byencrypting the non-volatile memory in which thefirmware is stored. This approach presents somechallenges in terms of decrypting the firmwaresecurely at start-up, and storing the keys so thatthey cannot be extracted from the device. Byprotecting the contents of e.g. a flash memoryfrom being extracted, attempts to reverseengineera device are no longer trivial.Sometimes there may be a need to prevent thecopying of binary firmware from one product toanother. Since it is not uncommon for differentproducts belonging to the same product familyto use a single piece of hardware, with featuresbeing disabled in software, the copying of binaryfrom a feature-rich product to a low-cost productcan be motivated by financial gain, or enablingfeatures which have been disabled from theentire product family.Another approach to preventing firmware fromexecuting in an unauthorized device is toimplement a kind of license management. Thiscould e.g. be design so that a device needs anunforgeable serial number which corresponds toauthorizing a certain firmware to execute in thedevice. This mechanism needs protection againsttampering using cryptography and securemanagement of the cryptography keys, serialnumbers and firmware packages.There are different ways to prevent this copying,such as the above mentioned encryption offirmware and license management methods.Creating different hardware is another option;perhaps the most effective way is to implementthe feature-restricted product using a binaryincompatibleprocessor or microcontroller. Thus,the feature-rich binary cannot be copied to thefeature-restricted product; as the binary isincompatible it will not execute.If a product does not have encrypted firmwarestorage, but it is introduced to the nextgeneration of the product, this likely alsoconstitutes a kind of hardware differentiation, asthe security keys needed for encryption mayneed a different model of processor,microcontroller or memory to be used.

374.5.4 Device parameters andconfigurationThe parameters and configuration of a devicecan be protected against modification e.g. bydefining user access levels with passwordprotection.Such mechanisms shall require thatthe password configured for the different userlevels have sufficient strength. As the devicemost likely contains a default password, thedevice shall encourage (possibly even require)the user to change the default password. It isespecially important is that passwords are nothardcoded into the device.Only proper user and software authenticationcan really create a level of security forautomation field devices. The Stuxnet case hasshown that default passwords undermine manysecurity measures, therefore the field devicesshould not be possible to be configured withdefault passwords.The storage of the passwords should beprotected, potentially using encryption so thatplaintext is not present. If the passwords need tobe communicated between ICs, the passwordsshould be communicated in ciphered mode.4.5.5 Firmware updatingThe updating of firmware in the device needs tobe secure. A major security issue arises if anattacker is able to insert a modified firmwareinto a field device; it would be possible tocontrol how the device is functioning. Severaltechniques to mitigate this risk can beconsidered.The device should detect if firmware has beenmodified, e.g. using error checking algorithms ina bootloader; in this case the system should go toa safe state and not execute the incorrectfirmware.and therefore it is nearly unfeasible to alter it. Inthis case, the secret key of the field deviceshould be stored securely and to the possibleextent changed regularly. Therefore, encryptionsolely cannot be seen as a sufficient securitymeasure. If possible, proper key management isneeded. Key management provides functionalityto exchange existing keys and also revoke keyswhich gets compromised. Moreover, whenencryption is used no Master key should beemployed. Basically, this means that everydevice should have its own key, thus limiting thedamage from disclosure of a single key.If possible, firmware updates should be digitallysigned with a private key. The correspondingpublic key can be stored in the field device (forinstance in a read-only memory, ROM) and usedin order to verify legitimate firmware updates.No “Master Tool” should be available, whichwould allow modification and tuning of the fielddevice, without proper authentication.Furthermore, if a field device is modified by theresponsible controlling software, this softwareshould be able to log this activity. Additionallythe logging should not be done exclusively onthe local machine, but should be sent to a centralserver which keeps track of all modifications.4.5.6 Superfluous informationThere is often a lot of extra data related to aproduct or device which is needed e.g. onlyduring the development stage. There is a riskthat this kind of information is left in theproduction version of a product, even though itis not needed for the principal functionality ofthe device. This presents a risk in terms ofinformation leakage, which may further lead torisk of tampering. It is therefore essential thatthe amount of information, which is not relatedto functionality, is minimized in the device.The firmware needs to be encrypted. An attackerwould not be able to read an encrypted firmware

385 Security in wirelesscommunicationsIn computer networking, wirelesscommunication such as WLAN has been usedfor many years. For close-range wirelesscommunication, technologies such as Bluetoothor Zigbee are popular choices. Wirelesstechnology is also entering the industrialautomation market, with technologies forWireless HART, Ethernet or PROFIBUS.The International Telecommunication Union(ITU) has reserved special frequency bands forindustrial, scientific and medical usage,commonly known as ISM bands. Many currentwireless approaches to industrial automation relyon IEEE 802.15.4 “Low rate WPAN”technology, or on Bluetooth technology, whichare capable of operating at one or more ISMbands. Bluetooth and 802.15.4 technologies areboth capable of operating in the 2.4 GHz ISMband, however 802.15.4 can also operate in the902-928 MHz ISM band. Wireless LAN, basedon IEEE 802.11, can also operate in the 2.4 GHzISM band, although higher frequencies are alsoavailable for this communication.IEEE 802.15.4 and Bluetooth are designed forshort range communications with ranges around10-20 meters. IEEE 802.11, depending on theprotocol used, offers ranges in excess of 50meters indoor and over 100 meters outdoors.The data rates of the technologies differ, as doesthe transmission range, due to design objectivessuch as low power consumption and low datarate. 802.15.4-based devices have very lowpower consumption, reducing the achievabledata rate and transmission range, while the highdata rate and long range of 802.11-based devicestranslates into high power consumption.5.1 Security of wireless technologyBecause it is not necessary to have physicalaccess to a wire or network, wireless systems arevulnerable targets to eavesdropping and possiblyalso tampering. Additionally, some networks areso-called ad hoc networks in which nodesparticipate in routing and data forwarding, andthus cannot rely on fixed devices acting asrouters. Thus, connections may need to beestablished to unfamiliar devices. Because insome cases, it is desirable to reducecomputational capacity and thus powerconsumption, the feasibility of cryptographicalgorithms and protocols may in someapplications be limited.Wireless links can be targeted by jammingattacks in the form of a device transmitting at avery high power, with the target of disruptingauthorized communication in a system. Byjamming is commonly meant that a devicedeliberately transmits different kinds of signalsinto a busy medium, decreasing the signal-tonoiseratio of the on-going communication. Thiscorresponds to a denial-of-service attack. Thepossibility to succeed with this kind of attackdepends on the network, the used technologyand devices, the jamming device and the overallenvironment. Some wireless technologiesimplement features to improve the networkperformance in case the medium contains a lotof interference; as an example, IEEE 802.15.4provides dynamic channel selection whichallows the device to select the best availablechannel for operation .A device attempting toovercome this flexibility of the network needs tobe able to jam over a wide spectrum, whichcontributes to cost and complexity in the jammer.However, given enough resources andmotivation, this can also be achieved.

395.1.1 IEEE 802.15.4The IEEE 802.15.4 standard is the basis of somecommonly used communication protocols suchas WirelessHART, Zigbee and 6LoWPAN. TheMAC layer of the IEEE 802.15.4 specifies asecurity mechanism which allows encryptionand decryption of the messages which arecommunicated between devices; however thissecurity feature is optional. The securitymechanism is designed to be flexible, allowingthe application of the cryptography only onrequired frames, or with certain nodes in thenetwork. This allows the extra overhead ofsecurity to be avoided in such cases where it isnot deemed necessary. The firmware in theapplication layer of a device specifies the levelof security required by setting controlparameters in the stack; per default no security isenabled.The WIrelessHART protocol uses the 128-bitAES encryption which is provided by the802.15.4 compliant devices and does not allow itto be disabled. Apart from protecting the datacontents of the message, it also protects thenetwork/transport layer information of packetsso that the routing of packets is correct.The Zigbee protocol specifies additional securityservices at the network and application layers,using symmetric cryptography to protect theframes and authorize devices. Keys are managedby a central device and are either pre-installedinto devices, transported using securecommunication, or established without beingdirectly transported between devices.5.1.2 Wireless LANThe security of Wireless LAN (WLAN)networks is a key consideration in IT systemsmanagement, however as it is becomingincreasingly common to have Industrial Ethernetnetworks connected to WLAN stations. Unlesssecurity is properly addressed also in theseconfigurations, the industrial communicationnetwork and control system is left highlyvulnerable.Sometimes, WLANs are configured with no orpoor security measures. Additionally, thephysical security around the WLAN, and thepossibility to access the WLAN from outside e.g.the building in which it is setup, increases therisk of intrusion. Furthermore, employeeschanging the network configuration or setting upweakly protected access points poses further risk.Insufficient security measures, such as weakencryption standards or reliance on poor filtering,leave holes in the security which may provide afalse sense of security; while only deter hackerswith basic knowledge, it enables advancedattackers to access the system.5.1.3 BluetoothBluetooth devices must be paired beforeconnections can be made; this is a basicrequirement for protecting private data. Once apair of devices has been authorized to connect,they can be configured to do so without futureuser intervention. Basic protection which can beconfigured by the user includes making thedevice non-discoverable, preventing the devicefrom showing up on a Bluetooth device scan. Anon-discoverable device can theoretically bedetected using brute-force methods; howeverthis will generally require too much time to bepractical. Some devices can also be configuredas “non-connectable”, meaning that not evenpaired devices can establish a connection to thisdevice.The Bluetooth specification addresses theproblem with passive eavesdropping and manin-the-middleattacks by specifying “SecureSimple Pairing” of devices, which is mandatoryin devices with Bluetooth version 2.1 or higher.The cryptography of the pairing procedure isenhanced, without affecting the user interventionwhich is needed. This improvement reduces the

40possibilities for a device sniffing the Bluetoothcommunication to be able to determine thecredentials used by a device to establish apairing.User ignorance, typically in the case of mobilephones or PDAs, presents a significant securityrisk in that devices may be left in discoverablemode. Users may also be the subject of a “socialengineering” attack, such as proposed in [8], inwhich they unsuspectingly accept an incomingpairing request. This could expose their sensitivedata or put them at risk for sabotage.Additionally, numerous security issues in theform of Bluetooth viruses or worms, andoperating system or application vulnerabilitieshave been identified. The exploitability of thesevulnerabilities varies, however the exploits maycause slow operation or application or devicecrashes. The effect of such an error in anindustrial control system can be considerable.5.2 Recommendations forimproving wireless networksecurityDue to the broadcasting nature of wirelesscommunications, physical access to thecommunication network is no longer a necessity.If an attacker is within range of the wireless link,it is possible to start an attack from outside theboundaries of physical access. Therefore,security measures shall focus on configuration ofthe network and devices so that an attackercannot exploit vulnerabilities, and to ensure thatthere are multiple security barriers protecting thesystem. Thus, even if the attacker breaks someof the barriers, he or she does not easily gainaccess to the network.This is not to say that physical security andaccess can be ignored. Both wired and wirelessnetworking equipment must be protected, so thatan intruder cannot easily access the networkfrom inside the building or premises. Unusedports in networking equipment shall be locked toprevent unauthorized connection to these.It should be a priority to ensure that employeesor other persons with access to the organizationdo not affect the network configuration, eitherby modifying existing devices or by connectingand setting up new networking equipment. Thereexists a risk that new networking equipmentintroduced to the network has less stringentsecurity configuration, thus exposing a weaklink to potential attackers.From a management perspective, it is imperativethat the organization defines security guidelines,policies, arranges training for staff and thirdparties, and establishes a security “culture”. Thisculture shall include continuous assessment,feedback and actions to maintain security in theorganization. It is essential to recognize thepeople in this process, and to ensure that theycan voice their concerns and that theirunderstanding of security is aligned to thesecurity policies and guidelines as necessary.It is important to configure the wireless networkcorrectly. As has been outlined above, the firststep is to ensure that security modes are enabled,if they are not by default. Where used,passwords must be selected so that they havegood strength. Where the encryption modes areselectable, and there is a reason not to use thebest available encryption (e.g. reducing powerconsumption in wireless nodes) the ease ofcracking the encryptions must be weighedagainst the tolerated risk. Then, the appropriateencryption is taken into use.In applications where Bluetooth is used as thewireless protocol, the devices should beconfigured with the lowest possible amount ofvisibility to non-familiar devices. Preferably,devices should be non-discoverable if they neednot be paired with new devices.

416 SummaryThis <strong>paper</strong> has provided an overall introductioninto the information security of industrialautomation. The current state of standardizationhas been reviewed and compared to the level ofinformation security standardization in the ICTfield. Additionally, the security issues in interdevicecommunication and in field devices alonehave been discussed, followed by a briefoverview of the security issues in wirelessinterfaces.Security in industrial automation has got muchmore attention after the Stuxnet case. Measuresto improve and implement security have beenstarted before Stuxnet, but thoughts and attitudeshave now changed. It has been shown in this<strong>paper</strong> that traditional fieldbuses are missingsecurity aspects in many ways. There are nostandardized rules and requirements for fielddevices against security threats like tampering,hacking and similar activities. This means that itwill be difficult to implement security measuresin lower automation levels by retrofitting or reengineeringcurrent communication standards inthe short term.operator staff needs to follow proper proceduresin order to ensure that the security of customeroperations is not at risk.Field level communication developers and fielddevices manufacturers need to place more focuson security in future development. There areeasier and more difficult areas to handle, but asthis Pandora’s box is once opened there is noturning back. Transparent and quantitativemethods are required and on-goingstandardization work needs strong support fromall sides. The automation business has creditablehistory solving challenges e.g. in safety, EMCand functional safety – it’s time for security now.Therefore, it is essential that end-users andowners/operators apply feasible cyber securityprograms in their processes and plants to getprotection against attacks via upper automationlevels and to restrict physical access in affectedzones. Existing practices of ICT business andalready published industrial standards andguidelines can be used as a foundation for thiswork.A security program shall be a de facto –requirement for new installations and plants.Risks shall be identified and preventivemeasures shall be applied through the deliverychain from customer requirements to systemintegrators and device vendors. Also installation,commissioning, maintenance, service and

427 References[1] F-Secure Corporation Terminology.http://www.f-secure.com/en/web/labs_global/terminology[2] ITU, ITU-T Study Group 17 – Security.http://www.itu.int/ITU-T/studygroups/com17/index.asp[3] ISO, Telecommunication standardization committee.http://isotc.iso.org/livelink/livelink/open/jtc1sc6[4] ISO, Technical committee: Security.http://isotc.iso.org/livelink/livelink/open/jtc1_bp[5] IEC Technical Committee 65.http://www.iec.ch/dyn/www/f?p=103:7:0::::FSP_ORG_ID:1250[6] ISA, ISA99, Industrial Automation and Control Systems Security.http://www.isa.org/MSTemplate.cfm?MicrositeID=988&CommitteeID=6821[7] Åkerberg, J. & Björkman, M. (2009). Exploring Security in PROFINET IO.33 rd Annual IEEE International Computer Software and Applications Conference.[8] Symantec Bluetooth Security Review.http://www.symantec.com/connect/articles/bluetooth-security-review-part-1

43BiographiesArthur Gervais is a Junior Security Consultant at Nixu. Currently finishing his double degree as Masterof Science in IT-Security, he has experience especially in network security. In 2011 he was awarded theBest Student Award from the German Federal Office for Information Security (BSI).Mikko Hyppönen is Chief Research Officer at F-Secure Corporation. He has studied thousands of viruscases during the last 20 years. He has published texts on his research findings in several internationalpublications, including Scientific American, The New York Times and CNN.com.Janne Kuivalainen is Director, Control Platform and Products at Vacon Plc. He has been working over10 years with embedded device related R&D and in power plant engineering in the 90's. He is member ofSESKO/SK65 - national electrotechnical standardization committee for industrial-process measurement,control and automation in Finland.Juhani Mäkelä is a lead developer in the Development and Nixu Open divisions of Nixu. He has a longexperience of working with embedded systems in the telecommunication and commercial areas. The lastfour years he has been developing a mobile security platform for Linux-based smartphones.Jouko Orava is Manager, Control Platform and Architecture at Vacon Plc. He has almost 20 years experienceof frequency converter development in areas of embedded software and fieldbuses. The last years he has beendeveloping embedded systems and architectures for frequency converters.Magnus Sundell is a Development Engineer at Vacon Plc. He holds a M.Sc. degree in Computer Science andhas long experience developing embedded systems for industrial communication. His main tasks are softwarearchitecture and requirements management in industrial connectivity.