The topic of IT security is becoming increasingly relevant in modern auto- mated industrial plants. Modern au- tomation systems provide high levels of inter-connectivity. Implementations are based on commercial IT plat- forms, many of which are known to be vulnerable to electronic attacks. This article is part 1 of a three part tutorial on IT security for industrial systems. Industrial information system security Part 1 66 ABB Review 2/2005 Tutorial IT security in industrial plants - an introduction Martin Naedele, Dacfey Dzung Security objectives are explained, at- tack types are illustrated, and avail- able and suggested countermeasures and general good practices are briefly described. Part 2 of this series will address best practices in protecting against certain types of attacks, and Part 3 will survey emerging standards for automation system security.
Transcript
The topic of IT security is becomingincreasingly relevant in modern auto-mated industrial plants. Modern au-tomation systems provide high levelsof inter-connectivity. Implementationsare based on commercial IT plat-forms, many of which are known to bevulnerable to electronic attacks. Thisarticle is part 1 of a three part tutorialon IT security for industrial systems.
Industrial informationsystem security Part 1
66 ABB Review 2/2005
Tutorial
IT security in industrial plants - an introductionMartin Naedele, Dacfey Dzung
Security objectives are explained, at-tack types are illustrated, and avail-able and suggested countermeasuresand general good practices are brieflydescribed. Part 2 of this series willaddress best practices in protectingagainst certain types of attacks, andPart 3 will survey emerging standardsfor automation system security.
67ABB Review 2/2005
Industrial information system security
In the past, industrial automation sys-tems were not linked to each otherand were not connected to public net-works like the Internet. Today, the sit-uation is somewhat different: becausethe market puts pressure on compa-nies to make fast and cost efficientdecisions, accurate and up-to-date in-formation about the plant and theprocess status must be available notonly on the plant floor, but also at themanagement level and even for sup-ply chain partners [1]. This results ingreater inter-connectivity between dif-ferent automation systems and be-tween automation and office systems.Modern industrial automation systemsare, to a large extent, based on com-mercial operating systems, protocolimplementations, and communicationapplications originally developed forthe office IT environment. Many ofthese systems and implementationsare known to be vulnerable to attacks,and with open and standardized Inter-net-technologies, expertise andknowledge of such vulnerabilities iseasily available to potential attackers.By connecting industrial plants to theInternet or to other public networksthese vulnerabilities are exposed.Thus, IT security issues must also beaddressed in industrial automationsystems.
What is IT security?For many people, IT security is con-sidered a synonym for encryption andfor others, the foremost IT security is-sue concerns protection against com-puter viruses. In reality however, ITsecurity has a much wider scope. Thefollowing eight security objectives area suitable framework for structuringsecurity requirements and propertiesof a system:
Confidentiality: The confidentialityobjective deals with preventing thedisclosure of information to unautho-rized persons or systems. For automa-tion systems, this is relevant both withrespect to process specific informa-tion, such as product recipes or plantperformance and planning data, andto the secrets specific to the securitymechanisms themselves, such as pass-words and encryption keys.
Integrity: The integrity objective dealswith ensuring that modifications
made by unauthorized persons or sys-tems to specific information are de-tected. For automation systems, thisapplies to information such as prod-uct recipes, sensor values or controlcommands. Violation of integrity maycause safety issues, ie, equipment, theenvironment, or even people may beharmed.
Modern industrialautomation systems are,to a large extent, basedon commercial operatingsystems, protocol imple-mentations, and commu-nication applicationsoriginally developed forthe office IT environment.
Availability: Availability means ensur-ing unauthorized persons or systemscannot deny access/use to authorizedusers. For automation systems, thisrefers to all elements of the plant like:control systems; safety systems; opera-tor workstations; engineering worksta-tions; manufacturing execution sys-tems; and the communication systemsbetween these elements and to theoutside world. Violation of availabili-ty, also known as denial-of-service(DoS), may not only cause economicdamages but also safety issues as op-erators may lose the ability to monitorand control the process.
Authentication: Authentication is con-cerned with determining the trueidentity of a system user and mappingthis identity to a system-internal prin-cipal (eg, valid user account) underwhich this user is known to the sys-tem. Most other security objectives,most notably authorization, distin-guish between legitimate and illegiti-mate users based on authentication.
Authorization: The authorization ob-jective – also known as access control– is concerned with preventing peo-ple (or systems) who do not havepermission from accessing the system.In the wider sense, authorizationrefers to the mechanism that distin-guishes between legitimate and ille-gitimate users for all other security
objectives, eg, confidentiality, integri-ty, etc. In the narrower sense of ac-cess control, it refers to restricting theability to issue different types of com-mands to the plant control system.Violation of authorization may createsafety issues.
Auditability: Auditability is concernedwith being able to reconstruct thecomplete system behavior historyfrom records of all (relevant) actionsexecuted on it. This security objectiveis mostly concerned with discoveringand finding reasons for malfunctionsin the system and to establish thescope of the malfunction or the con-sequences a security incident. Notethat auditability without authenticationmay serve diagnostic purposes, butdoes not provide accountability.
Non-repudiability: The non-repudia-bility objective means being able toprovide irrefutable proof to a third-party of who initiated a certain actionin the system, even if this actor is notcooperating. This security objective isrelevant in establishing accountabilityand liability. In the context of automa-tion systems, this is most importantwith regard to regulatory require-ments, eg, US Food and Drug Admin-istration (FDA) approval. Violation ofthis security objective may have legal
Tutorial
Security mechanisms used between control system and external networks as reported in [3]. Note that 5 % of systemsare not secured in any war.
and commercial consequences, but nosafety implications.
Third party protection: A successfullyattacked and subverted automationsystem could be used for various at-tacks on the IT systems, data or usersof external third parties using, for ex-ample, distributed denial-of-service(DDoS) or worm attacks. The thirdparty protection objective deals withpreventing this type of damage fromoccurring.
The importance of each security ob-jective depends on the system, specif-ically its purpose and its assets. Inautomation systems, for example,confidentiality is important for pro-duction and performance data, whileintegrity and authorization is mostrelevant for operator commands, pa-rameters, and control functions. Foreach system and installation, a secu-rity policy, stating the security objec-tives and specific system constraintsmust be in place before the securityarchitecture for any system can bedesigned.
At this point it may be worth pointingout the difference between the con-cepts of security and safety as appliedto an automation system or plant. Al-though no undisputed definitions forthese terms exist, they tend to beused in the following way: security isconcerned with the prevention of in-tentional malicious attacks whereassafety is concerned with the preven-tion of damage caused by a predomi-nantly unintentional or random loss of
integrity and availability of plant com-ponents, or by user error.
What types of attacks are there?An attack is a violation of one ormore security objectives and can beinitiated either inside or outside theplant. Attacks may target a specificsystem or type of system, or theymay, for example, in the form ofviruses and worms simply victimizeany vunerable system they encounter.
For each system andinstallation, a securitypolicy, stating the securityobjectives and specificsystem constraints mustbe in place before thesecurity architecture for any system can bedesigned.
A computer may be attacked for ex-ample to: obtain specific data storedon the computer (eg, production da-ta); to abuse the processing or storageresources of this computer (eg, tostore and distribute pirated software);to use applications installed on thecomputer to manipulate data or othersystems (eg, a production plant con-trolled by the computer); or to pre-vent usage of this computer for its in-tended purpose.
A data transmission link is anotherpossible target and may be attacked:
to eavesdrop on transmitted informa-tion; to falsify the information sent tothe recipient of the transmission; or toprevent the legitimate use of thetransmission link by, for example,flooding it with messages.
Do such attacks really happen?January 1998: External attackers tookover the central control center for theGazprom pipeline system. For an un-known period of time they were ableto control the flow in the wholeGazprom pipeline network1).
March 2000: A disgruntled formercontractor gained access to the con-trol system of a sewage treatmentplant in Maroochy Shire in Queens-land/Australia. He flooded the sur-rounding environment with millionsof litres of untreated sewage2).
December 2000: Attackers compro-mised the computer network of anunnamed power utility in the US viaan unsecured data exchange protocol.They used the compromised hosts toplay networked computer games.Their usage of computing resourcesand network bandwidth severelyimpedeed the utility’s electricity trad-ing3).
January 2003: The safety monitoringsystem of the Davis-Besse nuclearpower plant in the US was infectedwith the “Slammer” worm. The wormbypassed the plant’s firewalls via acontractor’s laptop - which was con-nected to the power plant network atthe same time - and via a modem tothe infected enterprise network of thecontractor company4).
August 2003: At CSX Transportation, aUS railway company, a worm infectedthe communication network used forsignalling, bringing all trains to a haltfor half a day5).
Tutorial
Table 1: Which security mechanism for which security objective?
challenge-response protocolsAuthorization Hardened operating systems (no insecure or unused services, user
accounts; tightly defines access control lists (ACLs) on resources, etc.), firewalls, personal firewalls, application level message filters, Virtual LAN (VLAN)
Auditability Intrusion Detection System (IDS), logsNon-repudiation Digital signature3rd party protection Firewall (egress filtering), malware scanner (for outgoing data)
May 2004: The “Sasser” worm infect-ed the signalling and control systemof the Australian railway company,RailCorp. 300,000 commuters in andaround Sydney had no transportationon this day6).
These examples show that electronicattacks on industrial control systemsreally do happen. In addition, it canbe safely assumed that a large numberof attacks have not been reported inthe press. Canadian researchers main-taining a confidential database of ITsecurity incidents in industrial installa-tions have observed an increase in in-cidents and a shift from internal to ex-ternal attacks [2]. It is worth mention-ing, however, as far as details aboutthe above mentioned incidents areknown, they were all possible onlybecause suggested practices weredisregarded. A survey conducted byARC in 2004 indicates that a signifi-cant number of control systems con-nected to external networks have nosecurity mechanisms .
Which security mechanisms should be used?A risk of an attack exists if there is anexposed vulnerability and a threat.The vulnerability of an information
1
system may be caused by a logicaldesign flaw (eg, a wrongly designedprotocol), an implementation mistake(eg, allowing a buffer overflow), or afundamental weakness (eg, passwordsand cryptographic keys that are guess-able by trying out all possible permu-tations).
Threats to a system are the potentialgoals of attackers, for example, to dis-rupt production for a certain period of time. Threats may also be realizedby an incidental, non-intentional ex-ploitation of a vulnerability.
The risk of a given attack is deter-mined by the likelihood of a success-ful attack and the severity of the dam-age it may cause. For a given system,a threat analysis must be performedduring which risks are evaluated andranked in importance. This analysisforms the basis for the security policy,where the relevant security objectivesare specified. This finally determinesthe security mechanisms to be de-ployed. Security mechanisms reducethe risk to a system by making the ex-ploitation of vulnerabilities less likelyor by limiting the damage. illus-trates the interrelations between theIT security terms used in threat andvulnerability analysis.
Table 1 shows which security mecha-nisms are commonly used to reducethe risk of certain types of securityobjective violations:
2
Suggested best practicesSecuring a system is difficult as it isnecessary to spread effort and budgetto efficiently and effectively prevent awide variety of attacks. Based on ex-periences that have been made in thisfield over the last few decades, thefollowing best practices should betaken into account when deployingtechnical security measures or imple-menting procedural controls:
Avoid a weak link: The effort spent onprotecting the various interdependentsecurity objectives required for a sys-tem has to be distributed so that allmechanisms facing an attacker are ofcomparable strength. Otherwise, anattacker could bypass a strong mecha-nism by breaking a weak one. In se-curity systems humans are often theweakest link, the effect of whichplaces greater importance on proce-dures and training.
There is no “security by obscurity”:It used to be argued that automationsystems were secure because very fewpeople had sufficient detailed knowl-edge about their operations and pro-tocols to attack them. Unfortunatelythis is no longer the case. Many au-tomation experts exist in all parts ofthe world, and automation systemsare largely based on well-documentedopen standards.
Least privilege: By only giving usersthe minimum permission necessary to
Tutorial
Footnotes:
6) http://news.com.au/common/story_page/
0,4057,9455677%255E15306,00.html
IT security threat analysis terms and their interrelations.2
Target system characteristics
Goal
Threat Attack
Threat agent/
attackerVulnerability
Assets
Damage
RiskSecurity
mechanisms/controls
DetermineDetermine Determine
Creates
Motivates
Is realized by
Is goal of
Executes
Violation causes
Violates
Refer to
Is exposed to
Exploits
Deters
Affects
Contributes to
Reduces severity of impacts
Justifies
Reduces likelihood of occurences
Securityobjectives
Contributes to
70 ABB Review 2/2005
Industrial information system security
do their job, the risk of insider attacksor the abuse of compromised useridentities is reduced.
Important secure system designprinciplesTwo design principles should be con-sidered when architecting a securesystem:Defense-in-depth: There are two com-monly used basic approaches for se-curing physical and information sys-tems: hard perimeter and defense-in-depth. The idea behind the hardperimeter approach is to put a singleimpenetrable wall around the systemand to disregard all security issues in-side. In the defense-in-depth ap-proach several zones are placedaround the object to be protected.Different types of mechanisms for de-tecting and delaying an attacker areused concurrently inside and aroundeach zone. The outer zones containless valuable targets. Properly imple-mented defense-in-depth security ar-chitectures are more resistant to at-
tacks than hard perimeter architec-tures.
Security is a process, not a product:Due to changes in the operating envi-ronment and the availability of newattacks, no security system even if it isimplemented flawlessly, will be ableto fulfill its purpose forever withoutmaintenance. Maintenance includesreviewing access control rules andupdating installed software. Thesereviews compare actual state with thedefined state of the system. In addi-tion, they assess whether the definedstate is still appropriate in the face ofa changing business and risk environ-ment. The need for maintenancemeans that continuous financial andstaffing resources are needed to keepa system secure.
Where do we stand?Even though reports about spreadingworms and a general increase in net-work based attacks seem to dominatethe news in IT related publications,
this is not really a reason to foregothe enormous benefits that full verti-cal and horizontal integration basedon network interconnections canbring to an enterprise. As long aswell-known good practices are re-spected in implementing and operat-ing network connectivity between thecontrol system and other networks, anadequate level of security can beachieved for any application. That se-curity level then represents the resid-ual risk that is regarded as acceptableafter a thorough threat and risk analy-sis for the particular installation.
Part 2 of this tutorial will explain howan automation system may be protect-ed against damages from worms andviruses. Part 3 will show what indus-try standards are emerging in the fieldand how they can be used to reducethe effort to secure a plant against tar-geted and untargeted attacks.
“Security” is not a fixed target. Contin-uous efforts are necessary to keep anysystem secure. In the case of controlsystems, both the plant operating en-terprise and the automation vendorhave to be involved in these efforts.
[1] Leffler, N. , Terwiesch, P.: Aspects of Productivi-
ty, ABB Review 2/2004.
[2] Byres, E. , Lowe, J.: The Myths and Facts behind
Cyber Security Risks for Industrial Control Sys-
tems, VDE Kongress 2004.
[3] Forbes, H.: Plant Floor Network Practices in
Today’s Factories and Plants, ARC insight 2004-
53EMHLP, December 2004.
Further reading:
M. Naedele: IT Security for Automation Systems, in:
R. Zurawski [Editor]: Industrial Information Tech-
nology Handbook. CRC Press, January 2005,
ISBN 0-8493-1985-4.
M. Naedele: IT Security for Automation Systems -
Motivations and Mechanisms, atp international, Vol 1
(1), 11/2003, and atp, Vol 45 (5), 5/2003.
R. Anderson: Security Engineering, Wiley, 2001.
Tutorial
Glossary
Cryptographic Checksum Check-bits calculated from the content of a document or messageand a secret key, such that any unauthorized changes in the document can be detected.
Challenge-Response A sends a challenge to B: a question whose answer can only be given if a common secret (password) is known. If B responds correctly, it has proven its identity to A, without having sent a password. (Sending a password is vulnerable to eavesdropping.)
Public Key Cryptography Encryption method using a pair of keys: Encryption with the public key results in data which can only be decrypted by the receiver using the matching private key. The private key must be kept secret.
Digital Signature Check-bits appended to a document or message, calculated from the document and a secret known only by the sender. Used to prove that the document originates from the claimed sender.
Digital Certificate Digital “passport”, attests that a public key belongs to the claimed owner. Issued (signed) by a trusted certification authority.
Virtual Private Network Private network running over encrypted tunnels through (VPN) the public Internet.Firewall Device or program which inspects all incoming (ingress) or
outgoing (egress) messages. Messages are filtered (blocked or forwarded) based on source/destination addresses or application level contents.
Intrusion Detection Devices observing traffic in a network, in order to detect electronic System (IDS) intrusions and raise alarms. Detection is based on attack signa-
tures or anomalies in the traffic patterns.Secure Socket Layer Security protocol widely used to authenticate Web servers and to (SSL) establish encrypted communication between Web browsers and
servers. Uses digital certificates.
Industrial informationsystem security Part 2
Malware protection for industrial automation systemsMartin Naedele, Rolf Vahldieck
Tutorial
74 ABB Review 3/2005
The previous part of this three-part tutorial on information system security inindustrial networks introduced the basic terminology and explained the needfor security measures. This need was, in part, motivated by a number of report-ed incidents where worms infected automation systems. There is no doubt thatworm infections pose a real threat for networked automation systems today.
This part of the tutorial explains the different types of malware and suggestshow an automation system can be defended against them. A case study is pre-sented where some of the suggested mechanisms are applied in a real-worldautomation system.
Tutorial
75ABB Review 3/2005
Industrial information system security
Protecting their networked automa-tion systems against viruses, worms,
and related threats (so-called malware)is one of the foremost security con-cerns many enterprises must deal with.As the incidents discussed in the firstpart of this tutorial [1] have shown, thisis indeed a serious issue. Damagecaused by malware may include:
The obstruction of communicationbetween hosts on the LAN becauseof high loads on the network.Host operating system crashes andforced shutdowns.Permanent damage to applicationand data files stored on the harddisks of those hosts. Malware can also send out informa-tion from the system to outside des-tinations or open a backdoor intothe system, allowing remote controlof this host by an attacker.
Any of these symptoms of a malwareinfection are unacceptable in a manu-facturing and process control environ-ment.
This article looks at different strate-gies that can be used on technical andprocedural levels to defend againstsuch threats.
What types of malware are there? And how do they infect a system?There are four main types of malware,though actual implementations mayhave characteristics of multiple types[2].
A virus is a program that infects ahost as part of a legitimate data trans-fer, and is generally attached to anoth-er message or file. In the pre-networkdays of computing, hosts were infect-ed with viruses via floppy disks. Inparticular, the virus was often situatedin the part of a disk that is read andexecuted whenever the computer wasstarted (so called boot sector viruses).Nowadays, viruses spread mostly viaexecutables or documents containingso-called active content (macros,scripts) sent over the network, forexample as attachments to emails,instant messaging, or as part of webpages. Infections via portable storagemedia do happen, but more rarely.
The action a virus executes when it isinvoked is called its payload. A virus
payload may display a message on thescreen or it may completely take overand manipulate the display. It maychange or delete random files or eventhe entire file system, or it may crashthe system. Its most characteristic ac-tion is that, in addition to other mali-cious actions, it spreads by attachingitself to other programs and docu-ments on the host.
A virus relies on one or even multipleuser actions, ie, starting a program,surfing to the web page or inserting aportable storage medium to be propa-gated and/or activated. Of course, inmost cases the user is not aware thatsuch actions will activate the virus.
A worm is very similar to a virus butthe major difference is that it does notrequire a user action for propagation.A worm can be regarded as a self-propagating virus, copying itself fromhost to host via the network. Typicalworms use the e-mail system to prop-agate – they mail themselves from theinfected host to recipients taken fromthe user’s e-mail address book, orthey directly scan other hosts on theLAN or network addresses on theInternet for potential entry points andthen open a connection to completethe transfer.
As worms are not activated by useractions they are often located in thehost’s memory and can be removedby rebooting. To date, few wormshave had a payload that has causedpermanent damage to the infectedhosts, though, of course, this is not aguarantee that future worms will notbe destructive. Worms often overloadthe networks around the infected hostas they spread to other destinations and .
A Trojan (like the proverbial horse) isan application that camouflages itselfas a harmless piece of software but infact has an additional malicious func-tionality. A Trojan can be regarded asa virus without a propagation compo-nent. A typical function of a Trojan isto provide a backdoor into a systemfor remote control by an external at-tacker. For this purpose, the Trojanwants to remain undetected for longperiods and therefore has no interest
Table 1
1
Name First seen Means of propagation Size of epidemic
and damage type
Sasser 30 April 2004 Vulnerability in Windows >= 1,000,000 hosts infected LSA service (repeated shutdown/reboot)
Blaster 11 August 2003 Vulnerability in Windows >= 500,000 hosts infected DCOM
Slammer 25 January 2003 Buffer overflow >= 75,000 hosts infectedin SQL Server (network saturation)
CodeRed 19 July 2001 Buffer overflow in IIS >= 350,000 hosts infected (network congestion)
ILOVEYOU 4 May 2000 VB script attachment >> 10,000,000 hosts infectedprocessed by Outlook
Melissa 26 March 1999 Mail attachment; >= 100,000 hosts infectedon opening sending itself to Outlook addressbook entries
Major worm/virus epidemics in recent years [4]Table 1
The geographical spread of Slammer within30 minutes of its release. The diameter of each circle is a function of the logarithmof the number of infected machines, solarge circles visually under-represent thenumber of infected cases in order to minimize overlap with adjacent locations.For some machines, we can determine onlythe country of origin rather than a specificcity. [Figure and caption taken from [3]].
1
Sat Jan 25 06:00:00 2003 (UTC) Number of hosts infected with Slammer: 74,855
76 ABB Review 3/2005
Industrial information system security
in causing obvious malicious effectsnoticeable by a user.
In fact certain Trojans, so called rootkits, modify significant parts of theoperating system to prevent detection.They may replace, for example, oper-ating system utilities that list files onthe hard disk or show open networkconnections by versions that hide theTrojan activity.
A special kind of Trojan is spyware.Spyware applications are active in thebackground and transmit certain infor-mation from the infected host, such assoftware applications installed on thehost, or web pages visited, to outsiderecipients. Like Trojans, spyware triesto stay undetected over extendedperiods of time.
How to prevent an infection?Generically speaking, malware infec-tions can be prevented by limitingtheir means for propagation and com-munication.
To prevent virus infections, the differ-ent ways a virus infected file entersthe system must be controlled. Fortu-nately for automation systems, it ispossible to eliminate most of theseattack paths [5]:
E-mail or instant messaging (IM/IRC) attachments: there should be no incoming e-mail orIM/IRC traffic to hosts on the automa-tion system network. This can be en-forced by not installing any e-mail orIM client applications on the comput-ers, or disabling those that are part ofthe operating system. Additionally thecorresponding protocols should beblocked at the firewall(s) between theautomation network and outside net-works should be blocked. If there areoperational reasons for receiving e-mail and using IM facilities in thecontrol room, a separate computercan be used which is not connectedto the automation network but direct-ly to the enterprise intranet. This com-puter may also have access to outsidecommunication networks, for instancevia dial-up modem or ADSL. Also onthis computer the e-mail or IM clientapplications should be configured soas not to execute any active content.In addition filtering applications
should be used to remove attach-ments, scripts and other dangerous in-gredients from any incoming message.
Web browsing: like incoming e-mail, web browsing toarbitrary sites on the Internet fromany host in the automation networkshould be prohibited. As de-installinga web browser is often not seen as arealistic option, filtering at the firewalland VPN setup can be used to ensureonly a small number of pre-approvedwebsites – such as reference docu-mentation on the enterprise intranetor a vendor support site – can bereached. This also mitigates the threatthat users will work around the emailclient restrictions mentioned in theprevious section by using web basedemail clients. Again, the use of sepa-rate hosts not connected to the au-tomation network is suggested forweb access. All downloaded contentshould be filtered for active and po-tentially malicious elements. Ideally,only pure HTML should reach theclient application.
Malware infections can beprevented by limiting theirmeans for propagationand communication.
Drive sharing: drive sharing between hosts insideand outside of the automation net-works should generally be prohibited.This can be enforced by firewalls.More secure protocols exist for trans-porting data in and out of the automa-tion network .
Portable media (CD, DVD, disk, memorystick, etc.): processes, procedures, and supportingphysical means (eg, drive locks) inthe plant should ensure that allportable media are scanned for mal-ware with up-to-date scanning en-gines and signatures before they arebrought into contact with a host onthe control network. Extra protectionmight be provided by multiple scansusing different anti-virus products. Ofcourse the host used for malwarescanning should not be connected tothe control network.
2
Data transfer applications (FTP, PC Anywhere, etc): direct transfer of files into the controlsystem by any of those means shouldbe restricted to a minimum. An inter-mediate staging server should be usedto scan all incoming data for malware.Digital signatures can help verify thatthe file really originates from the as-sumed, and trusted sender, and that itwasn’t modified between the virus scanand import into the control system.
Portable computers: every portable computer should havethe most up-to-date operating systempatches installed as well as a currentmalware scanner running. Recently,several security vendors have startedto offer solutions to verify a computerfulfills certain requirements before itcan connect to the network.
Externally accessible service: every host should be “hardened”. Thismeans that unrequired services anduser accounts should be removed/dis-abled, and user access rights and poli-cies are set such that every user (in-cluding system accounts) only has theminimum level of privileges necessaryfor operations.
The dataflow architecture of the sys-tem should ideally be designed insuch a way that no requests are need-ed from external PC clients to thecontrol network. In this case the fire-wall can be configured to block allconnections from the outside, includ-ing worm scans. If ports must beopened, there are several options toprotect them against malware:
If the enterprise can enforce appli-cation settings on both the clientand the server hosts, ports can beconfigured differently than the well-known numbers targeted by worms. VPNs can restrict the set of permit-ted client hosts.Within the control network furtherfirewalls and personal firewalls canbe used to create containmentzones.Non-essential services with knownweaknesses should only be offeredon one of several redundant serversto reduce the effect of an infection.
An additional measure to avoid at-tacks through an externally accessible
Tutorial
77ABB Review 3/2005
Industrial information system security
continuously monitors these systemsand is trained and equipped withtools to respond immediately to con-tain the infection and recover from it.
How to recover from an infection?To plan and execute an appropriateresponse to an infection, certain infor-mation must be collected:
Which functions/hosts are neededmost urgently and have to be re-covered with highest priority?What down time is acceptable forthe different system functions?Which persons have to be alerted?How quickly are they available?Who may replace whom?
Based on information about functions,interdependencies, and data flows, itmay be possible to design the systemarchitecture such that it has prede-fined isolation points. If the networkis cut at those points, the remainingislands are at least partially functional.
Redundant functions can be distrib-uted over several of these contain-ment zones.
The following technical means sup-port the rapid recovery of plant con-trol:
A warm standby backup host isolat-ed from the network for functionsthat allow basically no outage.Recent and complete system back-ups on swappable and bootablehard disks for the immediate restartof infected systems after the infect-ed hard disk has been removed.
Recent and complete system back-ups on other media (“ghost im-ages”) for the immediate reinstalla-tion of affected hosts.Local, non networked backup con-trol mechanisms, such as manualvalves as well as procedures onhow to man and operate these. Communication means for emer-gency staff that are independent ofthe IT network, e.g. two-way radio.Internet access from a separate hostindependent of the enterprise net-work, eg, via ADSL or dial-up to adifferent provider, so that informa-tion and updates from the Internetcan be obtained even while themain network is down.
Once these technical measures are inplace, the following sequence of stepsshould be adhered to when an infec-tion occurs:
Isolate hosts that are known to beinfected. Separate the different containmentzones at the prepared isolationpoints.Identify and remove the vector ofthe infection (eg, connection to out-side network).Once the spread of malware isstopped, connect standby backuphosts that were kept offline untilthat point.Identify the malware.Restore the infected hosts accordingto the prepared strategy (hard disk,ghost image, rebuild from the origi-nal media, disinfection). Follow ex-pert guidance on how to remove the
Tutorial
service is to install all updates that re-move known security vulnerabilitiesin that service. This is not necessarilythe best method because it requires aconsiderable effort to install eachpatch. Also, it is advisable to defer in-stallation until the automation systemsupplier has tested and qualified thepatches. Despite vendor testing at areference installation, it can not beguaranteed that the patch will not in-terfere with a specific system. Mostimportantly, patching can not prevent“zero-day attacks”, ie, attacks via vul-nerabilities which are unknown untilthe attack occurs. Because of this, anyanti-malware policy should not relyon patching alone.
How to detect an infection?Even before it affects the proper func-tioning of the automation system, itmay be possible to discover the infec-tion and thus initiate countermeasuresbefore any damage is done. Availablemeans of doing this include host-based anti-virus tools, network andhost intrusion detection systems, gen-eral network health monitoring toolsthat are perhaps even integrated intothe control system HMI, [6], as wellas relatively recent technologies to de-tect specific worm activity in a net-work [7]. However, certain hosts, di-rectories, or applications may have tobe excluded from virus scanning andintrusion monitoring for performancereasons.
In any case, such mechanisms will on-ly be useful if there is somebody who
3
Prototype of a tool developed in ABB Corporate Research to alert theprocess control system operator to anomalies in network behavior,e.g. caused by a worm.
3Prototype of a tool developed in ABB Corporate Research for securely importing files into a control network.
2
78 ABB Review 3/2005
Industrial information system security
identified malware. If in doubt, it isbetter to rebuild the system – toensure that all pieces of the infec-tion are really removed – rather thanto rely on malware removal tools.Take backup hosts offline again.Reconnect restored hosts.Take measures, like changing cer-tain procedures, to prevent thereoccurrence of the same infection.Reconnect to the outside network.
Case studyThis case study describes the malwareprotection strategy for a slightly sim-plified version of a real ABB customerautomation system. The plant controlsystem consists of an HMI and a per-formance data collection and report-ing subsystem.
The customer wanted access to the re-porting server from PC clients in hisintranet, which is also connected tothe Internet. The main security con-cern for the customer is the threat ofworm infections, especially via thereporting service which must beexposed through the firewall.
The following description highlightssome of the more interesting technicalmalware protection mechanisms sug-gested for this situation . For brevi-ty, procedural and standard technicalmeasures are not described.
4
The operations part of the control sys-tem is isolated from the rest of thenetwork. Any files imported into thispart via portable media must first bescanned at the anti-virus station. Theanti-virus station is located in the con-trol room and is only connected tothe intranet. It has a personal firewalland can only “pull” updates from thenet into the anti-virus station. Thereporting system is connected to thecontroller network via its own server.The controller network uses a non-TCP/IP/Ethernet fieldbus and is there-fore unlikely to be a worm vector.
A firewall is used to block requestsfrom the intranet to all ports on thereporting server except those neededto obtain performance data. To fur-ther reduce the attack surface, only asubset of the PCs on the intranet –those that are supposed to run theperformance reporting client applica-tion – are allowed to send data to theopen ports in the firewall. This isachieved using an IPSec based VPNbetween these hosts and the firewall.In this case, the VPN is mainly used toensure host authentication, not dataconfidentiality.
SummaryProtection against malware is mostly a“people issue”. Clear policies explain-ing what is permitted, procedures to
ensure that permitted actions are exe-cuted correctly, and training to makeusers aware of policies, procedures,and the reasons behind them are im-portant factors that help protect a sys-tem against malware infections. A pol-icy with respect to data flows betweenthe automation system and the out-side, for example, should be definedsuch that many of the infection vec-tors previously mentioned are auto-matically disabled, even if this causessome inconvenience for users. Techni-cal means such as firewalls, virusscanners, content filters, and intrusiondetection systems are available to sup-port and enforce procedures.
[1] Naedele, M. , Dzung, D.: IT security in industrial
plants – an introduction, ABB Review 2/2005.
[2] T. Chen, J-M. Robert, "Worm epidemics in high-
speed networks," IEEE Computer, June 2004.
[3] M. Naedele: Sicherheitsstrategien für automa-
tisierte Produktionssysteme, in: D. Burgartz,
R. Röhrig [Eds.] Information Security Manage-
ment, TÜV Verlag, to be published in 2005.
[4] Naedele, M., Biderbost, O.: Human-Assisted
Intrusion Detection for Process Control Systems,
2nd Int. Conf. on Applied Cryptography and
Network Security (ACNS), Tunxi/Huangshan,
China, June 2004.
[5] Riordan, J., Zamboni, D.: Billy Goat Detects
Worms and Viruses, ERCIM News No. 56 January
2004, http://www.ercim.org/
publication/Ercim_News/enw56/riordan.html.
[6] N. Weaver, V. Paxson, S. Staniford and R. Cun-
ningham, A Taxonomy of Computer Worms, Proc.
ACM CCS Workshop on Rapid Malcode, October
2003.
[7] D. Moore, V. Paxson, S. Savage, C. Shannon,
S. Staniford and N. Weaver, Inside the Slammer
Worm, Security and Privacy, July/August 2003.
Further reading
Richard Harrison: The Antivirus Defense-in-Depth
Guide, Microsoft, 2004
Tutorial
Network diagram of a malware-protected automation system.4
Operations Control Performance reporting AV
HMI HMI
Control Server
Control Server
Performance data processing
Performance analysis
workstation
Firewall
VPN
Performance analysis
workstation
Removable storage
Fieldbus (non TCP/IP/Ethernet)
Controller Controller
InternetIntranet
AV station Personal firewall
Industrial informationsystem security Part 3
Standards for securing industrial automation systemsMartin Naedele, Dick Oyen
Part 2 of this three-part tutorial on information system security in industrial networksexplained the different types of malware and suggested how an automation systemcould be defended against them.
This final installment looks at various initiatives that have been started over the lastcouple of years by different groups to create standards and other forms of guidanceto secure industrial automation systems. An overview of a number of those initiativesand their work products is presented, and the approach taken by IEC TC65 WG10 toproduce technical blueprints for securing certain control system scenarios isexplained.
69ABB Review 4/2005
Tutorial
Currently there is a flood of infor-mation available on information
system security in general. On top ofthis, there are some automation ven-dor white papers that explain certainaspects of locking down their systems.However, there is a serious lack ofimpartial and easily accessible guid-ance on how to systematically secureautomation and control systemsagainst electronic attacks.
There is no doubt that standards inthis area would be very beneficial forboth automation users and automationvendors, thus enabling them to:
Estimate the effort required to im-plement, maintain, and operate se-curity mechanisms and processes.Specify the security objectives fortheir plant and the security func-tionalities and measures that haveto be provided by vendors and sys-tem integrators.Compare the threat coverage andcost of offered security solutions.Implement and operate cost effi-cient security mechanisms acrossmultiple plants and locations in theenterprise.Be sure that their defense againstIT-based threats corresponds tostate-of-the-art solutions.
Vendors and system integrators will beable to:
Anticipate security requirementsand develop corresponding func-tionality.Create security architectures thatmay be reused across multiple proj-ects and customers. This reducescosts in proposal writing, engineer-ing, and the purchasing of thirdparty security devices and applica-tions.
Major standardization initiativesThe following survey of industrial se-curity standardization initiatives isadapted from [1] and [2].
ISA S99 The intention of the ISA (Instrumenta-tion, Systems, and Automation Soci-ety) Committee SP99, “Manufacturingand Control Systems Security”1) is tocreate guidance documents and astandard (S99) on introducing IT secu-rity to existing industrial control andautomation systems.
ISA is entitled to produce standardsfor the process industry with nationalvalidity in the US. Many ISA standardsare used internationally as best prac-tices or, such as S88 and S95, adoptedas international standards.
Standards outlining howto systematically secureautomation and controlsystems against electronicattacks would be verybeneficial for bothautomation users andautomation vendors.
SP99 started its work in 2002. As a firststep, it produced two technical reportsthat were published in spring 2004. Thefirst report “Security Technologies forManufacturing and Control Systems” [3]is a comprehensive survey of what isstate-of-the-art in security technologiesand mechanisms, with comments ontheir applicability for the plant floor. Itcovers: authentication and authoriza-tion; filtering/blocking/access control;encryption and data validation; audit,measurement, monitoring, and detec-tion; operating systems and software;and physical security. Each technologyis evaluated with regard to the follow-ing questions: Addressed security vul-nerabilities; typical deployment; knownweaknesses; use in an automation envi-ronment; future directions; recommen-dations; and references.
The second report “Integrating Elec-tronic Security into the Manufacturingand Control Systems Environment” [4]presents recommendations for a secu-rity architecture and describes the ad-ministrative issues and processes forintroducing a security managementsystem in industrial plants. The ap-proach in this report is inspired byISO/IEC 17799 [5]. It contains sectionson developing a security program,policies, risk assessment, audits andtesting, developing, selecting, andprocuring, countermeasures, as wellas examples for policies and forms.
Since the summer of 2004 SP99 hasbeen working on the S99 standard.S99 focuses on:
Retrofitting security mechanisms inexisting plants with commerciallyavailable components without actual-ly prescribing a specific architecture. The processes to operate the under-lying management system and ad-ministrative processes.
The actual security architecture andprocesses will likely be customizedfor specific plants.
IAONAThe Industrial Automation Open Net-working Alliance (IAONA) is an inter-est group of industrial communicationsystem users and manufacturers. ItsJoint Technical Working Group Securi-ty2) has developed a Security DataSheet which is intended to serve as atemplate for automation system and
70 ABB Review 4/2005
Industrial information system security
Tutorial
CIDX (http://www.cidx.org/CyberSecurity/ )creates procedural security guidance for thechemical industry. Its work is aligned withISA SP99. CIDX is mostly active in NorthAmerica.NAMUR (http://www.namur.de/en/694.php)provides guidance on secure usage of net-working technology for the process indus-try. NAMUR is mostly active in Germany/Eu-rope.NERC (http://www.nerc.com/ ) is the NorthAmerican self-regulation authority for powerutilities. Compliance with NERC 1200 andsuccessor CIP 002…009 standards onsecurity management with their strongfocus on processes and documentation iscompulsory for North American power utili-ties.CIGRE (http://www.cigre.org), the Interna-tional Council on Large Electric Systemsaddresses IT security considerations in anumber of its working groups. PCSRF (http://www.isd.mel.nist.gov/proj-ects/processcontrol/ ), the Process ControlSecurity Requirements Forum, promotessecurity certification of future control systemcomponents according to ISO/IEC 15408(“Common Criteria”). It is driven by the USNational Institute of Standards and Technol-ogy, the US national ISO/IEC 15408 certifi-cation authority. PCSF (http://www.pcsforum.org/ ), theProcess Control System Forum, was estab-lished 2004 as a meta-initiative to promoteinformation sharing between all the otherinitiatives on the topic.
Secutity initiativesTable 1
71ABB Review 4/2005
Industrial information system security
Tutorial
device vendors to document the secu-rity and communication related fea-tures and requirements of their indi-vidual products. This information canserve as valuable input for the au-tomation security architect as he de-signs and configures the necessarysecurity mechanisms for the plant.The benefit of such a Security DataSheet is that it collects, at a singlelocation, concise security relevantinformation that is otherwise oftenhard to obtain from vendor literature.
IECIn early 2004 the IEC Technical Sub-Committee 65C (Digital Communica-tions), through its working groupWG13 (Cyber Security), started toaddress security issues - within theIEC 61784 standard – for field busesand other industrial communicationnetworks. These issues are outlined in a new part 4 entitled “Digital datacommunications for measurement andcontrol – Profiles for secure communi-cations in industrial networks”.
What became evident during thiswork was that security issues in theautomation system cannot be solvedby protecting communication aloneand by looking only at the field level.Instead, the working group started tospecify state-of-the-art secure realiza-tions of certain common automationnetworking scenarios, such as dial-upremote access. These descriptions,called requirement sets, contain aproduct independent specification oftechnical mechanisms in the contextof a best-practice security architecture,as well as guidance on the configura-tion and operation of these mecha-nisms. The approach is described ingreater detail below.
Consequently, the work of the groupwas moved to TC65 WG10 to alignthe actual and necessary work withthe IEC committee mandate. The com-pleted standard IEC 62443, entitled“Security for industrial process meas-urement and control – Network andsystem security” is expected in 2006.The final voting for international va-lidity will take place during the firsthalf of 2007.
Some other security initiatives arebriefly described in .Table 1
Security management on the plant flooraccording to ISA S99The ISA SP99 technical reportTR99.00.01 [3], “Security Technologiesfor Manufacturing and Control Sys-tems” provides guidance on the appli-cability of a broad and inclusive rangeof security technologies. Its advicecomes from the combined experienceof security experts from automationsystem vendors and users. As the in-formation presented is analytical in
nature, it is not a normative standardagainst which compliance can bemeasured. The reader determines theapplicability of the information to thespecific case. It is an excellent docu-ment for those starting to determinesecurity measures and those withexperience. TR99.00.01 continues tobe updated but its content will not becovered by the S99 standards.
As of October of this year, drafts oftwo of the four parts of the S99 stan-dard are almost ready for publicreview.
Part 1 defines terms and describes themodels used in discussing security inautomation systems. Part 2 adviseshow a cyber-security managementsystem (CSMS) can be established.There are 18 key elements in a CSMSwhich are structured in a life cyclethat is constantly repeated throughfour phases: Plan, Do, Check, andAct. The CSMS is provided by theChemical Industry Data Exchange(CiDX) [7], which adapts the fourphases of the British Standard BS7799-2:2002 [6] to automation systemsand defines the 18 key elements. TheCSMS and its elements are shown in
. Its cyclic nature is implicit in step18 in which the security program itselfis modified according to lessonslearned in the course of the precedingelements.
Plan phase:Security planning begins with makinga business case so that top manage-ment can set a clear top-level policythat mandates the security program.
Organizational Security is planned and this takes into account all of thedepartments and people that areinvolved with the control system. It identifies roles and establishesresponsibilities relative to security.
Security relates to people: those whohave assets to protect, those who areexpected to protect them, and thosewho might compromise those assets.Personnel Security defines personnelpolicies to estimate and maintain thetrustworthiness of those who are giv-en greater access to the assets. Physi-cal and Environmental Security mustalso be planned. Cyber security is
Classification, and Assessment8. Risk Management and
Implementation9. Incident Planning and
Response10. Communications, Operations,
and Change Management11. Access Control12. Information and Document
Management13. System Development and
Maintenance14. Staff Training and Security
Awareness15. Compliance
Check16. Business Continuity Plan17. Monitoring and
Reviewing CSMS
Act18. Maintaining and
Implementing Improvements
based on an assumption that there aresubstantial (not absolute) barriersagainst physical attack.
Security risks are identified, classified,and assessed in the planning phase.Detailed instructions about how to dothis is provided in S99 and the materi-al that it references.
Do phaseRisk assessment leads directly into theDo Phase. Using the risk assessment,security resources can be efficientlyapplied to real vulnerabilities.
Procedures are established that planthe response to potential incidents.Response planning must include whenit becomes necessary to notify govern-ment officials of a significant threat tothe community.
Overall management policies and pro-cedures are established to cover com-
munications, system operations, andchange management.
Access control defines the privilegesthat accompany specific roles. It alsodefines the procedures that limit peo-ple’s access to activities and informa-tion to which they are privileged.Authentication means are determinedwhich will ensure that a particularuser (person or software) has thenecessary access authorization.
Information and Document Manage-ment identifies the security classifica-tion of data and specifies safeguards.Security issues of developing andmaintaining the system are also han-dled by policies and procedures.
Staff must be trained in the relevantsecurity procedures and all personnelshould undertake regular refreshercourses on general security precautions.Compliance of departments and person-
nel to the security policies and proce-dures must be measured through con-tinuous monitoring, and periodically,through audits. Compliance must alsotake into account external requirementssuch as those of customers, contractualpartners, and regulatory agencies.
Check phaseThe Check Phase includes developinga Business Continuity Plan and fol-lowing it. This plan establishes howthe company will operate through in-cidents that result in serious damage,plant outage, and possibly communitycatastrophe. The lessons learned fromthe CSMS activities are reviewed inthe Check Phase.
Act phaseAs the CSMS is a cyclic process, thesecurity program is revised accordingto the review in the Check Phase. S99 Part 2 provides more details aswell as 19 steps for establishing a
72 ABB Review 4/2005
Industrial information system security
Tutorial
Modular security architecture. Each can be mapped to certain components of the automation system and its network.2
SED
Standalone device
IOC
CNH
Control center/HMI
Application servers
Remote control center(e.g. backup, or a different plant)
PEC
Service laptop
IRA
Remote access client(e.g. maintenance)
ECI
Semi-public network (e.g. enterprise network)
Control network (control center upper level)ULCC
ACI
automationcell
automationcell
LLCC
Control network (control center lower level)
Control servers
AFDcontroller controller
FC
Control network (field level)
PSMPublic network(e.g. Internet)
73ABB Review 4/2005
Industrial information system security
Tutorial
CSMS. Part 3 aims at providing guid-ance on how to operate the CSMS.
Technical security architecture based onIEC 62443IEC 62443 mainly addresses – on asystem level – technical aspects of thesecurity architecture, and thus compli-ments product oriented initiatives likeIAONA, and process guidance provid-ed by SP99 and NERC.
With the ongoing stan-dardization efforts forIndustrial IT securityprocesses and architec-tures, plant managershave a real chance to im-plement state-of-the-artand cost-efficient informa-tion system security.
The basic idea of the IEC approach isthat of a modular security architec-ture. Each module corresponds to acertain usage or communication sce-nario and can be mapped to certaincomponents of the automation systemand its network . Each module isrepresented by a requirement setspecified in the standard. Some of therequirements, as well as the physicalor logical components they refer to,are common to multiple modules.Security architecture modules can andshould be combined to suit the specif-ic usage and threat situation of anautomation system. The standard willprovide guidance on the priority ofmodules for situations where a com-plete implementation of the standardis not possible due to budget limita-tions for initial implementation andongoing maintenance.
The requirements will be formulatedin a way that can be used as the basisfor Requests for Proposals (RFPs) fordata communication standards, andoffers, as well as security audits. They
2
should, at the same time, allow fordifferent technical solutions. One goalis that it will be possible to meet therequirements of the standard usingproducts and technologies that arecommercially available today. The re-quirements can also be applied to cur-rent and legacy systems and they canbe scaled down for systems where ananalysis has indicated they represent alow risk for both the enterprise andsociety.
The working group foresees the fol-lowing modules:Enterprise – control net interconnect(ECI): ECI defines the security architec-ture for non-real-time dataflow be-tween a control network and an enter-prise network, preferably unidirec-tional out of the control network.Interactive remote access (IRA): IRA details the security architectureneeded so that parts of the controlsystem can be accessed remotely (ie,via telephone dialup or Internet) forperhaps engineering or expert diagno-sis. Inter control center connect (ICC):ICC describes how communicationsbetween fixed control centers overpublic networks can be secured.Stand-alone embedded device (SED):SED outlines the security requirementsfor an automation device that is notcontained in a security zone and forwhich a full-blown security perimeterwould not be cost efficient, eg, apole-top Intelligent Electronic Device(IED).Portable engineering computer (PEC): PEC details how a control system canbe protected against threats originat-ing from portable computers that maybe moved back and forth betweenpublic networks and the control sys-tem Portable storage media (PSM): An au-tomation system may be exposed tomalware infections through storagemedia like memory sticks or CDs. PSMexplains how this can be prevented.Automation cell interconnect (ACI): ACI outlines the security architecturerequired for protected communicationbetween automation cells within acontrol network.Upper Level Control center (ULCC): Part of a control network is connectedto operator workstations, “historians ”,application servers and connectivity
servers. ULCC datails network orient-ed security mechanisms specific tothis part. Lower Level Control center (LLCC): LLCC outlines network oriented secu-rity mechanisms in the part of thecontrol network connected to con-trollers and PLCs.Field Control (FC): FC outlines networkoriented security mechanisms in thepart of the control network connectedto field devices.Control network host (CNH): CNH ex-plains how automation workstationsand servers for operations and engi-neering can be secured against attacksfrom insiders and malware, for exam-ple.Automation field device (AFD): AFD ex-plains how field devices and embed-ded controllers can be secured.
Each module describes: a use case towhich it applies; threats that are ad-dressed or not addressed; the underly-ing assumptions; the requirements;and the party (automation vendor,system integrator, or plant owner) re-sponsible for meeting each of the re-quirements. The core part of eachmodule is the requirement set and itcontains between 20 and 50 require-ments, depending on the module.
Each requirement consists of a norma-tive statement, optionally includingscale-down alternatives, a rationale,and in many cases one or more appli-cation notes. The rationale is an es-sential element, as it enables the read-er to make an informed decisionabout the importance and applicabili-ty of the requirement. The applicationnotes provide technical guidance onhow the requirement could be real-ized.
The IEC 62443 standard describes the“what” and “why” of the security ar-chitecture, but the “how” is specific toan individual site and system and istherefore left to the engineering judg-ment of the plant experts and the au-tomation/IT integrator.
SummaryWith the ongoing standardization ef-forts for Industrial IT security process-es and architectures, specific to con-trol and automation systems, plantsmanagers now have a real chance to
implement state-of-the-art and cost-efficient information system security.
The standardization initiatives de-scribed above have so far been char-acterized by a general recognition thatpragmatic solutions are needed toserve the industry, as well as veryconstructive collaboration among au-tomation vendors and end users sothat this objective is achieved.
ABB is a major contributor to varioussecurity standardization initiatives.The company offers products and so-lutions that are compliant to evolvingstandards, and provides assistance toits customers in applying these stan-dards to specific plants and sites.
[1] Naedele, M.: Standardizing Industrial IT Security –
A First Look at the IEC approach, 10th IEEE Inter-
national Conference on Emerging Technologies
and Factory Automation (ETFA 05), Catania, Sep-
tember 2005
[2] Dzung, D., Naedele, M., von Hoff, T., Crevatin, M.:
Security for industrial communication systems,
Proceedings of the IEEE, Vol. 93 (6), June 2005,
pp 1152–1177
[3] ISA SP99: Security Technologies for Manufactur-
ing and Control Systems, Instrumentation, Sys-
tems, and Automation Society, ISA-TR99.00.01-
2004, March 2004,
[4] ISA SP99: Integrating Electronic Security into the
Manufacturing and Control Systems Environment,
Instrumentation, Systems, and Automation Soci-
ety, ISA-TR99.00.02-2004, April 2004,
[5] ISO: Information technology – Code of practice for
information security management, ISO/IEC
17799:2000, December 2000,
[6] British Standards Organization: Information secu-
rity management systems – Specification with
guidance for use, BS 7799-2:2002, September
2002
[7] Chemical Industry Data Exchange (CiDX): Guid-
ance for Addressing Cybersecurity in the Chemi-
cal Sector, Version 2.0, December 2004.
74 ABB Review 4/2005
Industrial information system security
Tutorial INDEX 2005
3/2005: Sustainability
Sustainability in ABB 6Healthy, safe and productive 10Emissions trading 14SF6 technology 20Energy efficiency 22Networking 28Not on my watch 31Leaner, fitter, smarter 36HVDC 42
Safety management in process industries: Part 1 47Part 2 51Energy efficiencyGreen shipping 54The ABB turbocharger 58Boosting supply 63Cut and dry 66
Unplugged but connected – Part 1. 70
Industrial information system security – Part 2 74
4/2005:Innovation – The DNA of business
Looking back to look forward 6Fruits of innovation 9Best innovations 2005 15Grid flexibility 21Light and invisible 25Convergence in the control room 30Powerful and stable 33High voltage assembly 36Breaking to the front 39Ironing out resonances 42Age is no issue 47The process “copper” 51Control loops: pleasure or plague? 55Stabilizing influence 60Live(ly) neighbours 64Unplugged but connectedPart 2 65
Industrial information system security – Part 3 69
3 / 2005
The corporate technical journal of the ABB Group
www.abb.com/abbreview
ABBReview
Sustainability
Sustainability is an essential part of ABB’s business
page 6
Beating the greenhouse effect withemissions trading
page 14
Safety management in process industries –the ABB approach
page 51
a
4 / 2005
The corporate technical journal of the ABB Group
www.abb.com/abbreview
ABBReview
Innovation –the DNA
of business
Best innovations 2005 page 15
Power lines that don’t spoil the landscapepage 25
The magnetic stabilizer that saves on zincpage 60
a
1 / 2005
The corporate technical journal of the ABB Group
www.abb.com/abbreview
ABBReview
Pioneering spirits
A revolution in high dc current measurementpage 6
Team-mates: MultiMove functionality heraldsa new era in robot applications
page 26
Best innovations 2004page 43
a
1/2005: Pioneering spirits
A revolution in high dc current measurement 6Form and Function 11The perfect cast 14DryQ – Dry and silent 17
PSGuard contributes to UCTE grid reconnection 22Team-mates 26Instant comfort 30
Satisfaction guaranteed 33Panoramic projection 37Digging into the archives 40Best innovations 2004 43
Don’t touch: ABB’s new passive voltage indicator 52Wireless Ad-hoc networks 54Autonomic computing 55
2/2005: University and industry cooperation
Closing the gap 6Welcome to our world 10The MIT experience 14Leaders of tomorrow 18University co-operation 22City of learning 29Let’s work together 32Looking ahead 35Value for money 39Root cause 44Predictable assembly 49Hot stuff 55Grids united 59Simulated reality 62Industrial information system security –Part 1 66
a
2 / 2005
The corporate technical journal of the ABB Group
www.abb.com/abbreview
ABBReview
University and industry co-
operation
Turning Europe into a dynamic and competitive knowledge-based economy
page 6
The importance of working together with industry: university viewpoints
