OPC Security WP2

8/3/2019 OPC Security WP2

1/39

intrinsica lly sec ure

po bo x 178

# 5 7217 Lantzville rd

lantzville, bc

c ana da v0r 2h0

office 250.390.1333

fa x 250.390.3899

www.byressecurity.com

Digital Bond

suite 130

1580 sawg rass c orp pkwy

sunrise, FL 33323

office 954.315.4633

www.digitalbond.com

OPC Security White Paper #2

OPC Exp osed

PREPARED BY:

Digital BondBritish Columb ia Institute of Tec hno logy

Byres Research

Novemb er 13, 2007OPC Sec urity WP 2 (Version 1-3c ).doc


2/39

OPC Sec urity WP 2 (Version 1-3c ).do c ii Novem ber 2007

Revision History

Revision Date Autho rs Details

0.7 May 15, 2006 E. Byres, M Franz, Draft inte rnal review ve rsion

1.0 May 31, 2006 E. Byres, J. Carter, MFranz

Dra ft for co ntrolled pub lic review

1.1 Aug ust 31, 2006 E. Byres, M. Franz 2nd Dra ft for co ntrolled publicreview

1.2 Februa ry 9, 2007 E. Byres, D. Peterson 3rd Dra ft for co ntrolled pub licreview

1.3 May 16, 2007 E. Byres, D. Pete rson Pub lic Relea se Version

1.3a June 8, 2007 Typo fixed in Sec tion 2.5.4 andadded required vulnerability

1.3b Aug ust 27, 2007 Minor gramm atica l errorscorrected

1.3c Novem be r 13, 2007 Gram ma tica l error c orrec ted in

Acknowledgements

The Group for Adva nc ed Informa tion Tec hno log y (GAIT) a t the BritishCo lumb ia Institute of Tec hno logy (BCIT), Dig ital Bond , and Byres Researc hwould like to thank all the vendors and end users that generously supportedour efforts through numerous interviews and by providing us with documentsthat could only be described as extremely sensitive. Unfortunately we cannot name you fo r ob vious sec urity rea sons, but we a pprec ia te yo ur time, trustand encourag ement.

Seve ra l peop le stoo d out in their c ontributions and advic e fo r this doc ume nttha t we w ould like to ac know led ge. First a re Bill Co tter of MSMUG a nd ChipLee of ISA - we tha nk you fo r all your help in ma king the user surveys possible.We would also like to thank Ralph Langner for providing the four examplesc ena rios for this rep ort and lots of useful info rmation on OPC vulnerabilities.

Finally we would like to thank Evan Hand, formerly of Kraft Foods Limited, forhis vision and support. Without him, this project never would have beenpossible.

Disclaimer

Deployment or ap p lic a tion of a ny of the op inions, sugg estions orc onfigura tion included in this rep ort a re the sole responsibility of the rea derand are offered without w arrantee o f any kind by the a uthors.


3/39

OPC Sec urity WP 2 (Version 1-3c ).do c iii Novem ber 2007

Table of Contents

Executive Sum mary................................................................................................. 1

1 Introduc tion ....................................................................................................... 3

1.1 The Issues........................................................................................................ 31.2 Organiza tion of OPC White Paper Series.................................................. 51.3 Study Methodology......................................................................................51.4 Limita tions of th is Study ................................................................................ 6

2 Threats & Vulnerabilities for OPC Host Systems.............................................. 8

2.1 Und erlying System Vulnerab ilities on OPC Hosts...................................... 92.1.1 Unnec essary Syste m Servic es..............................................................92.1.2 Syste m Enumeration and Profiling .................................................... 102.1.3 Password Vulnerab ilities.....................................................................132.1.4 Ina dequa te Logging ..........................................................................14

2.1.5 Pa tc hing and Upda te s.......................................................................142.1.6 Use of Wea k Authe ntic a tion Mec ha nisms...................................... 142.1.7 Remote Reg istry Browsing ..................................................................152.1.8 Loc a l Vulne rab ilities............................................................................15

2.2 OPC Relate d Vulne rabilities...................................................................... 152.2.1 Use of Histo rica lly Insec ure Transport................................................ 152.2.2 Lac k of Authentica tion in OPC Server Browser ..............................162.2.3 Overly Permissive Authoriza tion Polic y on OPC Serve r Browser... 162.2.4 OPC Server and OPC Server Brow ser Assigne d ExcessivePrivileges..............................................................................................................172.2.5 Unnec essa ry Protoc ol Sup port for OPC Serve r Browser................172.2.6 Lac k of Integrity of OPC Communic a tions..................................... 172.2.7 Lac k of Confid entiality of OPC Traffic .............................................. 172.2.8 COM Internet Services Relianc e on IIS.............................................182.2.9 OPC Sec urity Co nfiguration Lac ks Fine Grained Ac c ess Co ntrol18

2.3 Sec urity Co nsidera tions for Spec ific OPC Spec ific a tions.....................182.3.1 Sec urity Considerat ions fo r OPC-DA ................................................182.3.2 Sec urity Considerat ions fo r OPC A&E..............................................182.3.3 Sec urity Considerat ions fo r OPC-HDA .............................................192.3.4 Sec urity Considerat ions fo r OPC-DX ................................................192.3.5 Sec urity Considerat ions fo r OPC XML-DA........................................ 19

2.4 A Very Brief OPC Threa t Ana lysis.............................................................. 192.4.1 Attac ker Ob jec tives............................................................................ 192.4.2 Attac ker Tools and Tec hniques.........................................................20

2.5 Four Possible OPC Risk Sc ena rios .............................................................202.5.1 Risk # 1: Collatera l Damage by OPC-Una ware Ma lwa re ............. 202.5.2 Risk # 2: Ac c ide nta l Shutdown of Co ntrol System by User ............212.5.3 Risk # 3: Opportunistic OPC Denia l of Service At ta c k.................... 22


4/39

OPC Sec urity WP 2 (Version 1-3c ).do c iv Novem ber 2007

2.5.4 Risk # 4: Intelligent, Ag gressive At ta c k aga inst OPC Hosts............23

3 Analysis of Com mon OPC Configurations and Guida nce ......................... 25

3.1 User Guidanc e Docum enta tion...............................................................253.1.1 OPC Founda tion Guid elines..............................................................253.1.2 CERN Sec urity Guid elines...................................................................26

3.2 Default Configuration Param eters for OPC Serve rs.............................. 27

4 Conc lusions..................................................................................................... 29

Glossary .................................................................................................................. 31


5/39

OPC Sec urity WP 2 (Version 1-3c ).do c 1 Novem ber 2007

Executive Summary

In rec ent yea rs, Sup ervisory Control and Data Ac quisition (SCADA), proc esscontrol and industrial manufacturing systems have increasingly relied onc ommercial Info rma tion Tec hnolog ies (IT) suc h as Etherne t, Transmission

Co ntrol Protoc ol/ Inte rnet Protoc ol (TCP/ IP) and Wind ow s for bo th c ritica land non-critica l c om munic a tions. This ha s made the interfac ing of industria lcontrol equipment much easier, but has resulted in significantly less isolationfrom the outside world, resulting in the increased risk of cyber-based attacksimp ac ting industria l p rod uc tion a nd hum an sa fety.

Nowhere is this benefit/risk combination more pronounced than the wide-spread adoption of OLE for Process Control (OPC). OPC is increasingly beingused to interconnect Human Machine Interface (HMI) workstations, datahistorians and other hosts on the control network with enterprise databases,Enterprise Resource Planning (ERP) systems and other business oriented

software. Unfortunately, securely deploying OPC applications has proven tobe a challenge for most engineers and technicians. While OPC is an openprotocol with the specifications freely available, engineers must wadethrough a large amount of very detailed information to answer even themost b asic OPC sec urity q uestions.

To a ddress this need for sec urity guidanc e o n OPC d ep loym ent, a jointresearc h te am with sta ff from BCIT, Byres Resea rc h a nd Dig ital Bond werecommissioned by Kraft Foods Inc. to investigate current practices for OPCsec urity. The results of this stud y were the n used to c rea te three white papersthat:

1. Provide an overview of OPC Tec hnology and how it is ac tua llydeployed in industry

2. Outline the risks and vulnerabilities incurred in deploying OPC in ac ontrol environm ent

3. Summa rizes c urrent g oo d prac tice s for sec uring OPC a pp lica tionsrunning on Window s-ba sed hosts.

The w hite p aper you a re no w read ing is the sec ond of the three . In it wedeta il the vulnerab ilities typ ica lly found in OPC hosts, ba sed on OPC s c urrentarc hitec ture (suc h as the use o f DCOM) and the typ ic a l underlying op eratingsystem. We also investigated common misconfiguration vulnerabilities foundin OPC server or client computers both at the operating system and OPCapplication level. Finally, using the vulnerabilities uncovered, we discuss fourpossible risk sc ena rios for OPC-b ased a tta c ks.

This small samp le o f sc ena rios sug gests seve ra l interesting c onc lusions. First,they highlight the fact that attacking OPC deployments does not requirespecial skills or esoteric process controls knowledge. All the tools and


6/39


information needed to carry out attacks can be downloaded from theInternet.

The sec ond c onc lusion is tha t tw o c ore vulnerabilities, name ly exc essive lyopen firewalls and overly permissive DCOM access rights, lay at the heart ofma ny sc enarios. If either vulnerab ility is addressed , then the c ha nc e of thesescenarios occurring is significantly reduced. What is especially interesting isthat these vulnerabilities could be considered within the control of theknowledgea b le OPC end user.

Fina lly, since the typ ica l OPC host c onfigura tion is strongly influenc ed by theguidance provided by the software vendor, we discuss the quality ofinsta lla tion utilities and guidanc e provide d to end -users by the OPC vend orcommunity. In general we find that the guidance from vendors on OPCsecurity could be significantly improved.

The g oo d new s is tha t there a re op erating system hardening p rac tic es tha t

are w ell p rove n in the IT sec urity c ommunity whic h we believe c an beadopted by the controls community to significantly reduce these risks. Inadd ition the re a re a numb er of DCOM spec ific sec urity settings tha t c an a lsobe a pp lied by the know led gea b le e nd -user. We will disc uss these solutions indetail in our final report in this series, OPC Sec urity White Paper # 3 Hardening Guidelines for OPC Hosts.


7/39


1 Introduction

This rep ort is the sec ond of three white p apers outlining the find ings from astudy on OPC security conducted by Byres Research, Digital Bond and theBritish C olumbia Institute of Tec hno logy (BCIT). The ob jec tive of this stud y was

to create a series of simple, authoritative white papers that summarizedcurrent good practices for securing OPC client and server applicationsrunning on Wind ows-ba sed hosts. The full stud y is d ivided into three Go odPrac tice G uides for Sec uring OPC as follows:

OPC Security White Paper #1 Understanding OPC and How it is Used:An introduction to what OPC is, what are its basic components andhow is it ac tua lly dep loyed in the rea l wo rld .

OPC Sec urity White Paper #2 OPC Exposed : What are the risks andvulnerabilities incurred in dep loying O PC in a c ontrol environme nt?

OPC Security White Paper #3 Hardening Guidelines for OPC Hosts:

How can a server or workstation running OPC be secured in a simpleand effec tive manner?

All three white papers are intended to be read and understood by ITadministrators and control systems technicians who have no formalbac kground in either Wind ow s prog ramm ing or sec urity ana lysis.

1.1 The IssuesIn rec ent yea rs, Sup ervisory Control and Data Ac quisition (SCADA), proc ess

control and industrial manufacturing systems have increasingly relied onc ommerc ia l informa tion te c hno log ies (IT) suc h a s Ethe rnet, TCP/ IP andWindow s for bo th c ritic a l and non-critic a l c om munica tions. The use o f thesecommon protocols and operating systems has made the interfacing ofindustrial control equipment much easier, but there is now significantly lessisolation from the outside world. Unless the controls engineer takes specificsteps to secure the control system, network security problems from theEnterprise Network (EN) and the world at large will be passed onto theSCADA a nd Proc ess Co ntrol Netw ork (PCN), put ting industria l prod uc tion a ndhuman sa fety at risk.

The wide-sprea d adop tion o f OLE for Proc ess Co ntrol (OPC) sta ndards forinterfacing systems on both the plant floor and the business network is ac lassic examp le o f both the bene fits and risks of a dop ting IT tec hno log ies inthe control world. OPC is an industrial standard based on the MicrosoftDistributed Comp onent Ob jec t Model (DCOM) interfac e o f the RPC (Rem oteProcedure Call) service. Due to its perceived vendor-neutral position in theindustrial controls market, OPC is being increasingly used to interconnect


8/39


Human Machine Interface (HMI) workstations, data historians and otherservers on the control network with enterprise databases, ERP systems andother business-oriented software. Furthermore, since most vendors supportOPC, it is often thought of as the one of the few universal protocols in theindustria l co ntrols wo rld , ad d ing to its widesp rea d appea l.

Many readers will be aware that the OPC Foundation is developing a newversion of O PC (c a lled OPC Unified Architec ture or OPC-UA) tha t is based onprotocols other than DCOM1. This is in conjunc tion with Mic rosoft's goa l ofret iring DCOM in fa vour of the mo re sec ure .NET and servic e-orientedarc hitec tures. Onc e mo st OPC app lic a tions do ma ke this migra tion from theDCOM -ba sed a rc hitec ture to NET-ba sed arc hitec ture, industry will have theop portunity for fa r bette r sec urity whe n it co me s to OPC, but a lso a new setof risks.

Unfortunately, based on our experience in the industry, it may be a numberof yea rs befo re many com panies ac tua lly co nvert their system s. So sinc eDCOM-based OPC is wha t is on the p lant floo r tod ay and will c ontinue to seeuse for years to come, we focused our investigation on how to secure thistype of OPC.

Our initial research showed two main areas of security concern for OPCdep loym ents. The first (and mo st o ften quoted in the pop ula r p ress) is tha t theunderlying protocols DCOM and RPC can be very vulnerable to attack. Infac t, viruses and wo rms from the IT world ma y be inc rea sing ly foc using on theunderlying RPC/DCOM protocols used by OPC, as noted in this attack trendsd isc ussion:

Over the past few months, the two attack vectors that we saw involume were against the Windows DCOM (Distributed Component

Object Model) interface of the RPC (remote procedure call) service

and against the Windows LSASS (Local Security Authority Subsystem

Servic e). These see m to be the c urrent favorites for virus and worm

writers, and we expec t this trend to c ontinue.2

At the same time, new s of the vulnerab ilities in OPC are sta rting to rea c h themainstream press, as seen in the March 2007 eWeek article entitled HoleFound in Protocol Handling Vital National Infrastructure 3. Thus, the use ofOPC connectivity in control systems and servers leads to the possibility of

DCOM -ba sed p rotoc ol attac ks, d isrup ting c ontrol systems op erations.

1 See Whitep ap er #1, Sec tion 5.7: OPC Unified Architec turefor more informa tion on O PC-UA.2 Bruc e Sc hneier, Atta c k Trends QUEUE Ma gazine, Assoc iation o f Comp uting M ac hinery,June 20053 Lisa Va as, Hole Found in Protoc ol Hand ling Vita l Nat iona l Infrastructu re eWee k,http://www.eweek.com/article2/0,1759,2107265,00.asp , Ma rch 23, 2007


9/39


Desp ite a ll the se c onc erns, it is our belief tha t the most serious issue for OPC isthat configuring OPC applications securely has proven to be a majorc ha lleng e for most engineers and tec hnic ians. Even thoug h OPC is an openprotocol with the specifications freely available, users must wade through alarge amount of very detailed information to answer even basic security

questions. There is little d irec t g uida nc e on sec uring OPC, a nd our resea rc hindicates that much of what is available may actually be ineffective ormisguided.

All things considered, there is little doubt that some clear advice would bevery useful for the control engineer on how best to secure currentlydep loye d, COM/ DCOM-based OPC system s. This series of white papers a imsto help fill tha t g ap for the end -user.

1.2 Orga nization of OPC White Paper SeriesAs noted ea rlier, this is the sec ond of three white papers outlining the find ingsand rec om me ndations from a study on OPC sec urity. In White Paper # 1 wereview ed the OPC spec ific a tions, foc using on d eta ils tha t a re relevant from asec urity point o f view and might b e useful to users wishing to und erstand therisks of OPC deployments. We then described the real-world operation ofOPC applications, identifying components that need to be understood toharden hosts running OPC client and server applications. In White Paper #3,our fina l white p aper, we w ill use this informa tion to g ive the OPC e nd-user aseries of practical recommendations they can draw on to secure their OPChost ma c hines.

Before one c an p rovide sec urity rec om me nda tions, it is imp ortant to c lea rlydefine the sec urity risks fac ed when dep loying OPC. Thus in this sec ond whitepaper we define a set of vulnerabilities and possible threats to OPC hosts,based on OPCs current architecture (i.e. the use of DCOM). We also look atcommon misconfiguration vulnerabilities found in OPC server or clientcomputers both at the operating system and OPC application level. Finally,since the typical OPC host configuration is strongly influenced by theguidance provided by the software vendor, we looked at the quality ofconfiguration utilities and guidance provided to end-users by the OPCvendor c ommunity.

1.3Study Methodology

Developing the findings and recommendations for all three of the whitepapers req uired the follow ing four-phase a pproa c h to the study:

1. Data Ga thering

Conducting user surveys and collecting information on OPCde ployments in order to get a rep resenta tive samp le o f how ac tual


10/39


OPC deployments were configured in the field by our targetaudience.

Reviewing OPC Found ation and vend or configura tion guide lines.

Conducting a literature search for OPC-related papers andguidelines.

2. Asc erta ining potential threa ts and vulnerab ilities in O PC systems

Identifying what operating system configuration issues exist intypica l OPC d ep loyments.

Identifying what OPC, RPC and DCOM issues exist in typical OPCdeployments.

3. Creating recommendations for mitigating potential threats andvulnerabilities

Determining what could be done to secure the underlyingop eration system without impa c ting the O PC func tiona lity.

Determining what could be done to secure RPC/DCOMc om pone nts in a n OPC ho st.

Dete rmining OPC-spec ific c lient and server sec urity c onfigura tions.

4. Testing the sec urity rec om me nda tions

Lab testing a ll rec om mendations in a typica l OPC e nvironm ent a ndmodifying our rec omm end a tions ac c ord ingly.

1.4 Limitations of this StudyIt is important to understand that this report is not intended to be a formalsecurity analysis of OPC or DCOM, but instead is a set of observations andprac tices that w ill help end -users sec ure their OPC systems. As well, this reportis focused only on securing the host computers that are running OPC.

Sec uring the network OPC operate s ove r is an interesting and imp ortant a reaof research, but is beyond the scope of this report. A follow-on study isplanned to investigate these network security aspects and consider solutionsfor OPC/DCOM in the network infrastructure, including firewall rule-sets andana lysis of third party OPC tunnelling solutions.

Fina lly, we c annot gua rantee tha t fo llow ing our rec om mendations will resultin a completely secure configuration. Nor can we guarantee that these


11/39


recommendations will work in all situations; some modifications may berequired for individual OPC client and server applications or MicrosoftWindow s netw ork dep loyments. How eve r, we are c onfident tha t using theseguidelines will result in more secure systems as compared to the typicaldefault application and operating system settings we have seen in our

investigations.


12/39


2 Threats & Vulnerabilities for OPC Host Systems

To assess the sec urity risks in d ep loying OPC, it is imp orta nt to define the set o finherent vulnerabilities, the threats that may exploit them and the possibleimpact of compromised software components. Only when we understand

these threa ts c an we beg in to determine w hat a re reasona ble me thod s forde fending a ga inst them.

For the purpose of this study, we defined a vulnerability as a design,implementation or configuration flaw that could result in the loss ofconfidentiality, integrity or availability of either the OPC application or theund erlying op erat ing system. Vulnerab ilities ma y oc c ur a t a ll layers of thesystem, starting with the operating system and progressing upwards to theac tual co nfigura tion o f the OPC a pp lica tion.

Closely related to vulnerab ilities, we define threatsas exploits, too ls, or human

agents that could compromise the security of an OPC application or theunderlying op erating system. In te rms of impac t we foc us on the effec ts of ac om prom ise, includ ing imp ac ts suc h a s denia l of servic e (DoS), una utho rizedalteration of data and possible negative effects on the physical processbe ing c ontrolled .

In this stud y we foc used on two d istinct types of vulnerab ilities:

High risk op era ting system vulnerab ilities- c ommon p latform orop erat ing system vulnerab ilities tha t could a dversely a ffec t thesec urity of the OPC a pp lica tion. Since this is suc h a broa d topic, wewill further foc us on a subset of the op erating system threa ts and

vulnerabilities tha t a re mo st c ritic a l to the sec urity of the OPCservers.

Inherent OPC vulnerab ilities- wea knesses due to the d esign of theprotoc ols und erlying the c urrent O PC spec ific a tions as well asimp lem enta tion c hoice s ma de b y vend ors, suc h as DCOMc onfigura tion set tings.

Sinc e OPC sec urity (p articularly a uthentica tion a nd autho riza tion) is so tightlybound to operating system security, this division may seem somewhatawkward. In many cases, both the problems and solutions are related.

However, by approaching the problem from two different angles in otherwords, by considering the ways that a poorly configured OPC applicationcould adversely affect the security of the underlying operating system andvic e-versa we no t only make the p rob lem more m anag ea ble, but it a llow sea sier and mo re log ic a l selec tion of c ounte rme asures.


13/39


2.1 Underlying System Vulnerab ilities on OPC HostsTo da te, the m ost c om mo n threa ts to c ontrol systems have been ind irec t,targeting the underlying operating system or network infrastructure ratherthan the control system devices and protocols themselves. Generally, control

system applications or devices have suffered more as collateral damagefrom malware rather than from directed attacks. In other words,compromising the host computers operating system and its relatedapp lic a tions is the c om mo n atta c k pa th for an atta c ker to ta ke and will likelyc ontinue to b e in the foreseeab le future.

Thus we sta rt our list o f OPC Host Vulnerab ilities by d esc ribing the mostcritical operating system exposures that need to be addressed by OPCadministrators. Since OPC is a lmost exclusive ly run on a Wind ows p lat formsome of these vulnerabilities will be Windows specific, but many apply toother operating systems as well. Finally, since Microsoft has significantly

improved the overall security posture of its operating system in recentrelea ses (XP SP2 and Serve r 2003 in pa rtic ular), many o f these vulnerab ilitiesare more c ritica l for older OPC systems running on Windows 2000 or NT4.

Most o f these p rob lem s are well known a mo ng IT administra tors, but lessunderstood in the control system world. Furthermore, due to their potentialimpact, these issues are important enough for us to revisit within the contextof OPC Host sec urity.

For each of the following vulnerabilities, we describe the root cause, theconsequences of exploitation, and in some cases, introduce high levelrem ed ia tion tec hnique s. Spec ific guida nc e to a dd ress ea c h of these issues isprovide d in White Paper #3.

2.1.1 Unnecessary System Servic es

One of the basic security principles is that a single-purpose device with alimited set of tightly controlled functions is far easier to secure than amultipurpo se system. This is no t o nly bec ause the multipurpo se systemprovides mo re servic es tha t c an b e p otentia lly exploited , but a lso b ec ause itis a single p oint o f fa ilure.

Since in mo st c ases OPC servers will d irec tly monitor and c ontrol proc essda ta , it follow s tha t the c om puter co nta ining the OPC server should not a lsobe used as a file, p rint, or we b server. For examp le, if a web server is need edto allow employee access to OPC data, it is far better to have a separateweb server host that retrieves data from the OPC server host (via amec ha nism suc h a s ODBC o r OPC-XML). Using a web server tha t is inte gra tedinto the same OPC host that has direct access to controllers or I/O devices isasking for troub le.


14/39


Older versions of Wind ows NT/ 2000 Server ena b led many unnec essaryservices by default, but Windows XP/2003 does a much better job ofreducing these potential vectors for attacks. As noted in White Paper #1,OPC servers and DCOM have surprisingly few dependencies on otherWindows services, so there is little need for many of the default Windows

services suc h a s File and Print Sha ring or NetBIOS ove r TCP. Thus these servicesshould be disabled unless there is a pressing need for them in the controlstrategy.

Althoug h the prac tic e is not widesp rea d , som e IT app lic a tion vend ors notonly ensure that their application exposes the smallest possible attacksurface, but also disable unnecessary functionality and tighten accessc ontrols during the insta lla tion p roc ess. We would like to see a ll OPC vendorsand autom ation software ve ndors c onsider ad d ing hardening sc rip ts to the irp rod uc ts. This will minimize unnec essa ry system services ena b led a fter asuccessful installation.

2.1.2 System Enumeration and Profiling

Regardless of whether the threat agent is a human or an automated pieceof ma lwa re, targets must be d isc ove red before they c an be a ttac ked. Unlessprior know led ge of the system is ava ilab le to the a ttac ker, rec onna issanc e istypically the first step in any attack sequence. Most reconnaissance effortsconsist of active probes of the targeted network or system to gaininforma tion about its identity, c apabilities and potentia l weaknesses. Systemprofiling takes advantage of the fact that, by default, most applications andservices provide excessive information to unauthenticated parties. Windows

and OPC a re no exc ep tion.There a re a number of well known tools or too ls suites tha t a llow the a tta c kerto collect this useful information. We will describe some of the most commonbelow.

2.1.2.1 Traffic Sniff ing

Onc e a n atta c ker has identified a g iven d evice , c omputer or an "interesting"process control network, it is possible to gather information about the victimbased on passive or indirect means that are unlikely to be detected on theta rgeted system eve n if monitoring and log g ing is in p lac e. This is typ ica lly

accomplished through simple traffic capture tools that can analyze thenature o f traffic to a nd from a target devic e.

Window s netw orks are p a rtic ula rly chatty and d ivulge information a bout endhosts through broadcast traffic that is visible to all members of the LAN. Anyinforma tion sent in NetBIOS name servic e broa dc asts c an b e c aptured andharvested for atta c ks.


15/39


2.1.2.2 Dom a in Name System (DNS) Que ries

Informa tiona l ga thering m ethod s using DNS are c om mo nly consideredattacks originating from the Internet, but similar information can be retrievedby querying internal DNS servers if systems do not deploy a "split DNS."

Sinc e it is a c om mo n prac tice to inc lude func tiona l informa tion, op eratingsystem typ e, o r the owner's na me in DNS address rec ords, DNS queries c anbe a valuable source of information. By either using tools to resolve a rangeof host IP add resses or by d irec tly querying a DNS serve r with a zone transfer,an a ttac ker c an o ften q uic kly identify c ritic a l node s suc h a s an OPC server.

If name resolution is enabled then the names of internal systems can beobtained by simply conducting a ping sweep of the network. While this mayseem innocent enough, it can often be used for highly inappropriatepurposes. For example, recently one of the authors used this techniqueduring a site sec urity a ssessment to quickly ide ntify the Ethe rnet-Seria l

Ga tewa ys and IP video c ame ras used in a physic a l sec urity system by notingthe presenc e o f "sec urity" in the ir host na me . For a rea l a tta c ker a simp le nextstep might have been to launch a denial of service attack against thesedevic es in o rder to d isab le the site s video surveillanc e c apab ilities.

2.1.2.3 Ac tive Direc tory/ LDAP Que ries

Depending on the c onfiguration, authorized doma in memb ers ma y be ab leto extrac t a signific ant a mount of informa tion a bo ut other dom ain membe rsby send ing Lightweight Direc tory Ac c ess Protoc ol (LDAP) queries to a dom a inc ontroller. If the Gue st user is ena b led (a req uirem ent for leg ac y NT4services) even unauthenticated users may be able to gain access to this

information.

2.1.2.4 TCP/ UDP Sc anning

Following passive information gathering techniques, attackers typically beginac tively prob ing a device s TCP or User Datagram Protoc ol (UDP) services todetermine whe ther c om mo n app lica tions are running . This is typ ic a lly knownas port sc anning and c an be extrem ely effec tive in loc a ting b asic servic es.For example, a standard port scan allows one to determine the probablepresenc e o f DCOM by chec king whether TCP Port 135 is op en and listening.Sinc e this doe s not p rovide any informa tion a bout OPC o r eve n whe ther an

OPC server is present on a given host, attackers may also send validme ssages to the a pp lica tion layer to identify spec ific servic es.

2.1.2.5 NetBIOS Enum era tion - Domains and Workgroup s

There a re a number of b uilt-in tools on any Wind ow s system tha t w ill allow anattacker to determine which domains or workgroups are present on a givennetwork or host. In Figure 2-1, we notice that the administrators username


16/39


(OPCADMIN) and the workgroup name (OPCGROUP) are revealed by aNetwork Basic Inp ut Outp ut System (NetBIOS) Name Service sc an.

If NetBIOS c annot b e d isab led , turning o ff the A lerter and Messeng er servic escan prevent disclosure of this information (Note: starting with Windows XPServic e Pac k 2, bo th o f these servic es a re set to Disab led by d efa ult).

Figure 2-1: NetBIOS Name Servic e Sc an

2.1.2.6 SMB Enumera tion Using Anonym ous Log in

Built into the Common Interne t File System (CIFS)/ Server Message Bloc k (SMB)protocol are APIs that allow extensive information about servers to bed isc overed , even to una uthentica ted users. Since Wind ow s NT/ 2000 a llow sanonymous connections by default (but not XP/2003, unless it is enabled),these older operating systems are particularly susceptible to thisrec onna issanc e a ttac k. The fo llow ing is som e of the informa tion tha t c an b eharvested using this tec hnique :

Account Information: Using the anonymous log in an a ttac ker c anma ke queries to ide ntify userid , username , ac c ount desc ription,log in a nd password ac tivity using op erat ing system utilities and freesec urity tools. Based on this informa tion, atta c kers c an then b eg inthe sea rc h for weak pa sswords.

Polic y Settings: Besides ac c ount informa tion, policy at tributes c anbe de termined that a llow a n atta c ker to d isc over when a givenac c ount requires a strong passwo rd or has ac c ount loc koutenabled.

File Shares: Arme d with a list of a c c essible sha res, an a tta c ker c anbeg in to b row se the file system and a ttemp t to retrieve inte resting

# nbtscan -v 192.168.68.60

Doing NBT name scan for addresses from

192.168.68.60

NetBIOS Name Table for Host 192.168.68.60:

Name Service Type

----------------------------------------

CLEANW2KSP4 UNIQUE

CLEANW2KSP4 UNIQUEOPCGROUP GROUP

OPCGROUP GROUP

CLEANW2KSP4 UNIQUE

OPCADMIN UNIQUE


17/39


files and use writea b le d irec tories to up loa d too ls and ga ininte rac tive system ac c ess. Dep end ing on the permissions, it maya lso be possib le to mo d ify OPC c onfigura tion files.

Domain Trust Relationships: Althoug h OPC is mo st c om mo nly used

within a single d om a in, unauthentica ted users c an identify dom aintrust rela tionships tha t no t only c an b e used to identify ad d itiona la tta c k vec tors aga inst the OPC server, but a lso to a llow theattac ker to launc h atta c ks from a c om prom ised server to othe rsystems.

2.1.2.7 RPC Endpoint Discovery

Informa tion about RPC e ndpoints is ava ilab le by d efault. How eve r, ba sed onour testing, Windows or Linux RPC scanning tools could not identify thepresenc e of the OPC Prog ram IDs. This situa tion may be c hang ing rapidly asa num ber of OPC sc an too ls have b een noted on the Internet in the p ast fewmonths.

2.1.2.8 Network Ma nag eme nt Applic ations

The Simple Netw ork Mana gem ent Protoc ol (SNMP) is a c om mo nly usedmethod for ma nag ing and monitoring a variety of ne twork devic es inc ludingswitches, routers, servers, and even some PLCs. Although SNMP is notena b led by defa ult on most Window s server insta lla tions, if it is ena b led and apredictable community string is in place, the Microsoft MIB (ManagementInforma tion Base) e xposes a significant a mo unt o f information tha t c ould beused to c om prom ise the c onfidentia lity (and possib ly the integ rity) of a n OPC

Server.

The informa tion tha t c an be g a ined by brow sing the SNMP MIB inc lud es:running services, file share names and paths, usernames, domain names,hardware information, and more. All of this could provide useful informationto exp loit an O PC Server or the opera ting system. Besides SNMP, othe r systemma na gem ent softw are, suc h as Microsoft Terminal servic es, if not a deq ua telysec ured , may result in a dd itiona l expo sures to OPC servers.

2.1.3 Password Vulnerabilities

Given OPC's reliance on Microsoft authentication mechanisms, weak

passwo rds a re amo ng the mo st c ritic a l vulnerab ilities tha t c an und ermine thesec urity of an OPC server. The poor selec tion o f passwords is the tipp ing p ointfor the sec urity of a ny a pp lic a tion, op erating system , or device . This isespecially true for OPC/DCOM authentication which uses local ordom a in/ Ac tive Direc tory c red entials for authentica tion.

For ea se o f administra tion, it may ma ke sense to use the term OPC as pa rtof the username or group name, but OPC, the organization, vendor, or


18/39


product name, or process control information should never be used in theactual passwords. Having strong, difficult to guess passwords are especiallyc ritica l sinc e sec urity tec hniques tha t limit p asswo rd guessing a tta c ks (suc h a saccount lockout based on failed authentication attempts) may beina pprop riate for the ind ustria l c ontrols env ironme nt. Further guida nc e on

pa sswo rd selec tion and m anag ement can be ob tained from p ap ers such asthe pap er "Password Mem orab ility and Sec urity: Emp irica l Results"4

2.1.4 Inadequate Logging

By default, Windows 2000/XP auditing settings do not record DCOMc onnec tion req uests, SMB log ins, or a ttempts to ac c ess system o b jec ts. Unlessthese settings are enabled, it is impossible to determine whether accessviolations have oc c urred , or the source o f the intrusion. In White Pap er #3 wedefine a Windows audit configuration for OPC servers designed to mitigatethis vulnerability.

2.1.5 Patc hing and Updates

The p ast several yea rs ha ve m ade users and vendors keenly aware o f thenee d to p a tc h op erating system s and app lic a tions. This top ic is only inc lud edfor the sake of completeness, and we assume that most OPC users andvendors have developed effective patching procedures. For those readerswho d o not c urrently have a goo d pa tch m ana gem ent proc ess in plac e w esuggest contacting your control system vendor or referencing the GAOreport Informa tion Sec urity: Age nc ies Fac e Cha llenges in Implem ent ingEffec tive Softw are Patc h Manage me nt Proc esses 5, and the Edison ElectricInstitute s Patc h manage me nt Stra teg ies for the Elec tric Sec tor .6

2.1.6 Use of Weak Authentication Mec hanisms

Although NT4 Service Pac k 4 (SP4) and Wind ows 2000/ XP p rovide robustauthentication and authorization mechanisms, for compatibility reasonsinsecure authentication mechanisms are still supported by clients and serveras a defa ult sett ing . Window s 2000 still ac c ep ts LanMa n (LM) a nd NT LanMa n(NTLM) a uthentica tion mec hanisms, bo th o f whic h ha ve we ll-knownwe aknesses and are susc ep tible to q uick offline a tta c ks.

For example, a rogue server or other client-side attacks can exploit thedefault support of weak hashes to capture authentication credentials of

4 Jeff Yan, Ala n, Ross, Alasda ir. "Password Memorab ility a nd Security: Empirica l Results," IEEESec urity a nd Privac y, vol.02, no.5, pp . 25-31, Sep tem ber-Oc tob er 20045 Informa tion Sec urity: Ag enc ies Fac e Cha lleng es in Imp leme nting Effec tive Softw a re Pa tc hMa nage me nt Proc esses , GAO Rep ort GAO -04-816T, US Ge neral Ac counting O ffic e, June02, 20046 Pat ch mana gem ent Strateg ies for the Elec tric Sec to r , White Paper, Ed ison Elec tricInstitute IT Sec urity Working Group , Ma rch 2004


19/39


otherwise sec ure ma c hines. In th is type of a tta c k, ma licious HyperTextMa rkup Lang ua ge (HTML)/ Uniform Resource Loc a tor (URL) is sent throug hem a il or a c om prom ised web site c an red irec t a user to the rog ue SMB serverwhich is configured to support only weak hashes and can be used to gatherc red entials. For this rea son w e rec om me nd tha t NTLMv2 authentica tion be

required for all OPC communications.

2.1.7 Remote Reg istry Browsing

As the storehouse of configuration information, the Windows registry is a likelytarget of any attack, whether local or remote. Remote read-only access tothe registry can divulge a significant amount of information that is useful foran a ttac ker. In the c ase o f OPC, it would a llow an atta c ker to identify ac tiveOPC servers and othe r COM ob jec ts tha t a re insta lled . This info rmation w ill bed isc losed even if ano nymous log ins a re d isab led .

Early versions of Windows 2000 allowed remote registry browsing by default.

Furthermo re, p rior to the relea se of the OPC Server Brow ser, the registry wa sa lwa ys queried by OPC Clients to determine w hich servers were p resent . Thesub sequent relea se o f both Windo ws XP and OPC Serve r Brow ser means tha tthis risk c an be now reasonab ly mitiga ted .

2.1.8 Local Vulnerabilities

Althoug h our p rima ry foc us is rem ote threa ts and vulnerabilities, if an a tta c kercan gain access to a local domain, it provides a stepping stone toc ompromise OPC rela ted files and proc esses. This is pa rticularly importa ntsince the default DCOM and file system permissions are far too permissive,

often a llowing a c c ess to any user or the EVERYONE group on a system.In orde r to c ond uc t these a ttac ks, INTERAC TIVE ac c ess is usua lly required ,which is the default for DCOM servers including OPC. In White Paper #3 wewill identify a more appropriate set of object permissions to provide multiplelayers of defense, including removing the OPC server process from theINTERACTIVE group .

2.2 OPC Related VulnerabilitiesBuilding on the vulnerabilities found in the underlying operating system, wenow discuss specific flaws in OPC servers and clients. Many of the inherent

vulnerab ilities in OPC from both a rc hitec ture a nd the ve ndor imp lem enta tionare sins of omission rathe r than kno wn d esign errors.

2.2.1 Use of Historically Insec ure Transport

Throug hout their history, RPC imp lem enta tions have ha d a poo r sec urityrec ord o n both Window s and non-Wind ow s p la tforms a like. Sinc e thec urrently dep loyed versions of OPC a re based on DCOM (whic h is based on


20/39


RPC), the OPC host w ill be vulnerab le to a ll pre-authentica tion flaws in RPC,suc h as tho se exploited by the Blaster worm in 20037. These in turn could resultin the compromise of services, execution of arbitrary code, or denial ofservic e a tta c ks aga inst the OPC ho st. Only aggressive pa tc hing of OPC ho stsor b loc king of a ll OPC tra ffic through firew a lls c an m itiga te this risk.

Adding to the problem is the fact that the default (and most common)configuration for RPC uses dynamic ports, which makes it more difficult towrite e ffec tive firewa ll rules. As we w ill d isc uss in White Paper # 3, this issue c anbe a ddressed , but the solution d oe s add a dd itiona l c onfigura tion c om plexityfor the system a dministrato r.

In the future, the importance of these RPC issues should fade as Webservices-based OPC implementations (i.e. OPC-UA) are built using type safeprogramming languages (such as C# and Java) with code access security.Unfortunately at the present time almost all OPC users must still deal with thevulnerab ilities inherent in RPC a nd DCOM.

2.2.2 Lack of Authentication in OPC Server Browser

Configuration g uidanc e from ma ny vend ors, as we ll as the OPC Found ation sc onfigura tion g uidanc e for XP-SP28, recommends allowing remoteAnonymo us Log in so OPCEnum will work when DCOM Authe ntica tion is sentto None. If a buffer overflow of some type were discovered in the OPCServer Brow ser code, the c onseq uenc es c ould b e a rb itra ry cod e exec utionor denia l of servic e aga inst a ny c om puter running the OPC Server Brow ser.Fortunate ly we a re una ware o f any suc h buffer overflow in the OPC ServerBrow ser c od e a t this time.

Certa in OPC c lients rely on OPCenum.exe to get the CLSID of the OPCserver. If OPCEnum will not function in these servers, the OPC client will beunab le to dete rmine the servers CLSID and therefore b e una b le to c onnec tto the OPC server. Several resea rc hers have dem onstra ted tec hnique s toremotely disable OPCEnum, indicating that this could be used as a possibledenial of servic e a ttac k vec tor.

2.2.3 Overly Permissive Autho rization Polic y on OPC Server Browser

Ma ny doc uments, includ ing the OPC Found ation s XP SP2 Guida nc e9,rec ommend that the Everyone group b e ad de d to the OPC p ermissions.

7 http://www.microsoft.com/security/encyclopedia/details.aspx?name=Win32%2fMsblast8OPC Foundation, Using OPC via DCOM with Microsoft Windows XP Service Pack 2, Version1.1, http :// ww w.op c foundation.org/ Dow nloa dFile.aspx/Using OPC via DCOM w ith XP SP2v1.10.pdf?RI=3269To its c red it, the OPC Found at ion do cume nt d oes include a note stat ing it is oft en

desirable to add these permissions to a smaller subset of users. While w e w ould havepreferred to see this sugg estion be inc luded as the m a in text of the doc ument, it is be tterthan ma ny of vendo r do c uments we inspe cte d.


21/39


This violates the basic p rinc iple of lea st p rivileg e. If a loc a l Gue st user exists,then b y allow ing the Everyone g roup to a c c ess (and perhaps launch) OPCservers, a guest user without any password would be able to launch OPCservers and ac c ess them.

2.2.4 OPC Server and OPC Server Browser Assigned Excessive PrivilegesMost o f the OPC Servers we a na lyzed in our stud y ha d defa ult insta lla tionstha t ran with SYSTEM level p rivileg es, the m ost p owerful ac c ount in Wind ows.This is a highly risky setting tha t o ffers little adva nta ge to the user. In WhitePaper # 3 we will disc uss a lternatives to this situation.

2.2.5 Unnecessary Protocol Support for OPC Server Browser

Defa ult protoc ols transports for OPCEnum.exe inc lude not only TCP/IP, butSeq uenc ed Pac ket Excha nge (SPX), NetBIOS Extend ed User Inte rfac e(NetBEUI), and Co nnec tion Oriented NetBIOS over InterNetwork pa c ket

Excha nge (IPX). Som e ve ndors even g o so fa r as to rec om me nd ena b lingCOM Internet Services, an HTTP transport for DCO M.

The fac t is tha t new vulnerab ilities in overloo ked p rotoc ols or ap p lica tions arefreq uently d isc overed . Since there is little rea son to support the other leg ac yprotoc ols a t this time, they should be d isab led and only TCP/ IP a llow ed . Forexample, there is an interesting note in Matrikon documentation10 on howthe use of datagram-based protocols may expose the servers to memoryleaks. It turns out that there is a memory leak problem with older Windowssystems that use UDP for DCOM11. Since fe w systems rea lly need to sup portthis p rotoc ol, it is fa r be tte r if d isab led .

2.2.6 Lac k o f Integrity of OPC Comm unica tions

The d efa ult DCOM set tings do no t p rovide message integ rity c hec king . If theunderlying network infrastructure is compromised and the attacker can sniffand injec t tra ffic , it is likely tha t rog ue m essages c ould b e injec ted onc e theclient and server have authenticated during the initial connectionestab lishment. A numb er of SMB ma n in the m idd le too ls and tec hniquesare available and it is likely that these could be modified or enhanced toconduct man in the middle attacks against OPC communication. For thesereasons we recommend that if at all possible, Packet Integrity should beena b led as d isc ussed in White Paper #3.

2.2.7 Lack o f Confidentiality of OPC Traffic

Althoug h DCOM supports message e nc ryption, none of the OPC vend ors wereviewe d rec omme nded ena b ling Pac ket Privac y for their OPC Server or the

10 MODBUS/ TCP OPC Server, Ma trikonOPC Inc .11 http://support.microsoft.com/kb/294710/en-us


22/39


OPC Server Browser. However, some vendors rec ommend VPN tunne lling a sa means of providing sec ure off-site ac c ess. The p rima ry issue w ith Pac ketPrivacy is that for some applications, the encryption may be too processorintensive unless hardware acceleration cards are installed to offloadcryptographic tasks. In most configurations that we investigated in the lab,

enc ryption d id not c ause a signific ant d eg rad ation of pe rforma nc e.

2.2.8 COM Internet Services Reliance on IIS

To overc ome known issues with DCOM a nd firew a lls, HTTP c an b e used as atransport a lterna tive to tunne lling DCOM over a sing le TCP port. While a fewc om panies rep orted using this tec hnique , it is relatively ra re a nd we g enerallydo not rec om me nd it. The COM Internet Servic es req uires the dep loyment ofMic rosoft Interne t Info rmation Server (IIS) and thus introd uc es add itiona loverhead and potentially a different set of vulnerabilities. Although thenetwork sec urity p osture of IIS has imp roved , we believe tha t most o f the

benefits of this method are outweighed by the difficulty of hardening thisc om plex, fea ture-ric h app lica tion tha t itself has had numerous vulnerabilities.

2.2.9 OPC Sec urity Configuration Lac ks Fine Grained Ac cess Control

Unfortunately there is no standardized method of having per-item accessc ontrol for rea d -only versus rea d write ac c ess. Som e OPC server vend orsimplement item-based security; however most only implement server-levelpermissions i.e. they may have a server that only allows read-only access,and a d ifferent server tha t a llow s both read ing and writing to tags.

2.3 Security Considerations for Specific OPC Specifications2.3.1 Sec urity Considerations for OPC-DA

OPC-DA provides an attacker with the ability to not only gain unauthorizedread access to process control data, but to also modify data points ondevices. Apart from providing erroneous values, attackers could injectmessages into the client application and conceivably launch more subtleattacks by manipulating time stamps and quality metrics. Depending onrequirements of the OPC client application, OPC-DA servers may beespecially susceptible to denial of service attacks at multiple layers of theprotocol stack.

2.3.2 Sec urity Considerations for OPC A&E

OPC-AE will typically provide an attacker with less ability to directly controlthe physical process. However it provides direct access to another weak link,namely the human operator. If an attacker can degrade the operatorsability to view, respond, and acknowledge critical system events, otherattacks may go unnoticed, or worse, the operator may take inappropriateaction that negatively impacts the physical process. For example,


23/39


overloa d ing an operato r with a la rms ma y und ermine his trust in the system. Itis also likely that the complexity of OPC A&E servers, given their use ofcallbacks and state machines, could make them more prone toimp lem enta tion flaws tha n o ther OPC servers.

2.3.3 Sec urity Considerations for OPC-HDAThe c om prom ise of an OPC-HDA server will not likely have the imm ed ia tec onseq uenc es of imp ac ts on other OPC a pp lica tions. How ever there still existrisks such as the disclosure of sensitive business information or themo dific a tion o f da ta tha t is req uired for c omp lianc e p urposes.

2.3.4 Sec urity Considerations for OPC-DX

As OPC-DX communication is used for OPC server to server data exchange,and is ofte n used to p rov ide multi-vend or c ont rol system interop erab ility. Thesensitivity of this da ta excha nge c an vary greatly ba sed on w hether the d a ta

is used to ma ke c ont rol dec isions.

2.3.5 Sec urity Considerations for OPC XML-DA

Since OPC XML-DA does not use DCOM it has a d ifferent set of sec urityc onc erns. The spec ific a tion doe s not p rovide any a pp lic a tion-layer sec uritymec ha nisms, and c urrent imp lementa tions must rely on HTTP/ HTTPS sec uritymechanisms (i.e. basic authentication and/or transport layer security). OPCXML-DA d oes no t ut ilize the Web Servic es Sec urity sta nd ards suc h a s WS-Sec urity.

2.4 A Very Brief OPC Threa t Ana lysisAlthough a formal threat analysis was out of scope for this study, it makessense to b riefly consider the ob jec tives and me thod s tha t an a ttac ker c oulduse to c om prom ise an OPC server. The follow ing sec tion b riefly d esc ribespossib le a ttac ker ob jec tives, atta c ker too ls and tec hniques.

2.4.1 Attac ker Objec tives

A threa t ana lysis me thodolog y we ha ve suc c essfully used in p rev ious projec tsis to develop a set of high level attacker objectives. For OPC these are likelyto be:

Reconnaissance- Identify OPC server

Confidentiality- Ga in una uthorized rea d ac c ess to OPC server da ta

Availability- Denial o f OPC server service

Integrity- Alte r OPC server da ta


24/39


Integrity Crea te rog ue O PC server

2.4.2 Attac ker Too ls and Tec hniques

To a c hieve the a bove o b jec tives, an atta c ker has a va riety of tec hniques a ttheir disposal:

Use of Free ly Ava ilab le OS Rec onna issanc e and Attac k Too ls Toolslike nma p, netc a t and ma ny others a re free ly ava ilab le to exploitany und erlying system vulnerab ilities tha t may be p resent on poo rlyc onfigured OPC hosts. These typ ic a lly a re d esigned for rem otedeployment.

Use of Freely Ava ilab le OPC Browsers- Typ ica lly the se tools requirethe a ttac ker to b e p art of the same do ma in or workgroup in orderto easily browse a nd a lter the OPC ob jec ts.

Custom OPC At ta c k Too ls- to c ond uc t a mo re fully automa tedatta c k, a sop histic ated a ttac ker c ould develop c ustom sec uritytools or exp loit a p oo rly configured server or imp lem enta tion flaw .These tools a re a lso b ec om ing inc rea sing ly ava ilab le for downloa don the Internet.12

2.5 Four Possib le OPC Risk Scenarios13All the above vulnerability and threat analysis details may leave the readerwondering So what d oes a ll this rea lly mea n to the sec urity o f my c ontrolsystem? To answer this, we p rovide four possible risk sc ena rios below . This is

only a small sub set of possible sc enarios since, as no ted ea rlier in this report, afull analysis was beyond the scope of the project (Additional OPC risksc ena rios c an be found in papers by Langne r14 and Mora.15).

2.5.1 Risk #1: Collateral Damage by OPC-Unaware Malware

In this first sc ena rio, gene ra l purpose m a lwa re inad vertently imp ac ts an OPCclient or server running in a control environment. For this to occur, thec om bined req uired vulnerab ilities inc lude:

1. The c ontrol system firewa lls (or othe r EN/PCN perime ter sec uritymeasures) are configured to allow a significant number of open ports

12 For exam ple, the OPC Server Inte rface Vulnerab ility Assessme nt Too lca n be downloadedfrom http:// ww w.neutralbit.co m/13 Spec ial thanks to Ra lph Langner for providing the four examp le sc ena rios for this rep ort.14 Ralph Langner; OPC Exposed Part II, S4 Co nferenc e, Digital Bond Press, Miami, FL,January 200715 Lluis Mo ra; OPC: Interface Implementation Vulnerabilities , S4 Con ferenc e, Digita l BondPress, Miami, FL, January 2007


25/39


to and from the OPC server platform because data is needed byapp lica tions in the b usiness network (This c ould a lso b e the result oflac k of a ttention to sec urity);

2. The DCOM ac c ess rights tha t a re very p ermissive due to the insta lla tionsc rip t p rovided b y the OPC vendor;

3. An OPC server running on a host platform running either an outdatedopera ting system (suc h a s Wind ows-NT, SP4) OR a c urrent o pera tingsystem with c ritic a l pa tc hes not a pp lied (suc h a s Wind ows-XP SP2).

Based on the OPC End -user survey no ted in White Paper # 1, vulnerab ilities # 2and #3 are extremely common, occurring in a majority of end userdeployments 51% and 53% of the time, respectively. As we will discuss inSec tion 3 of this rep ort, we have go od rea son to believe tha t vulnerab ly # 1 isa lso c om mon in ma ny rea l wo rld OPC d ep loyments.

The threa t in this sc ena rio is an a verage worm tha t exploits well-know n

RPC/ DCOM vulnerab ilities suc h a s the MSBlaste r worm d id in 2003. Thepossible impact starts with the worm entering the organization via a businessuser on the enterprise network, traversing through the c ontrol system firew a ll,infecting systems with OPC servers and then spreading onto other systems inthe automa tion network.

Ac c ording to sta tistics ob ta ined from the Ind ustria l Sec urity Inc identDatabase (ISID), the Blaster wo rm inc ident c aused a t least 6 sep ara teproc ess sec urity inc idents in 2003 by following this general sc ena rio. Using ISIDextrapolation techniques, this translates into a conservative estimate ofbetween 60 and 120 incidents in the North American control market in 2003.

Typ ica lly, inc ide nts of th is typ e have resulted in loss of produc tion in over 40%of the c ases.

2.5.2 Risk #2: Accidental Shutdown of Control System by User

In this sc enario, a bene vo lent b ut ill-informed c orpo ra te user is experime ntingwith OPC client applications or tools. By chance he/she connects to aSCADA system tha t ha s an integ ra ted OPC server and a possible overloa dflaw. For this to result in an impact, the required combined vulnerabilitiesinclude:

1. The c ontrol system firewa lls (or othe r EN/PCN perime ter sec uritymeasures) are configured to allow a significant number of open portsto and from the OPC server platform because data is needed byapp lic a tions in the business network;



26/39


3. A SCADA system with integ ra ted OPC server tha t ha s a very largevariable p oo l;

4. An OPC software vulnerability where a server browse results in crash ofc ontrol system w ith large va riab le p oo ls.

For the reasons noted previously, vulnerabilities #1 and #2 are common. AsOPC g row s in pop ula rity and dep loyment sc op e, # 3 is bec oming inc rea sing lycommon.

Vulnerability #4 may seem unlikely, but the fact is that an OPC item browseuses a lot of memory and has been shown to cause system crashes in thepast. In one case an accidental OPC item browse on a system withapproximately 40,000 variables resulted in the complete shut down of ama jor food p roc essing p lant. This particular system ha d a very la rge a mo untof p roc essing pow er and me mo ry - estima tes by OPC expert Ra lph Langne rindica te tha t one c an e xpe c t server brea kdo wns on a verage PC ha rdwa re

with a va riab le poo l in e xce ss of 20,000 variab les.The imp ac t from this sc enario sta rts when the user b rowses the OPC server onthe SCADA system from enterprise netwo rk and as a result c rashes both theOPC server and the integra ted SCADA system. Prod uc tion is shut d ow n a ndthe root cause is unknown to the company. According to the survey resultsreported in White Pap er # 1, loss of OPC a t this leve l will result in a loss ofprod uc tion in the ma jority of OPC d ep loyments 54% of the time .16

2.5.3 Risk #3: Opportunistic OPC Denial of Service Attack

In this sc ena rio, OPC-spec ific ma lwa re infec ts a c om pany control system and

causes shutdown of process operations. For this to result in an impact, thec om bined vulnerab ilities req uired inc lude:



3. An OPC software vulnerability that can be exploited to cause a denial

of servic e in the OPC a pp lic a tion and possib ly in the c omputer hostingthe OPC server;

4. A malwa re p ac kag e tha t spec ific a lly exploits OPC is ava ilab le.

16 OPC Sec urity Whitepa pe r #1 - Understanding OPC a nd How it is Dep loyed , ByresResea rc h a nd Dig ital Bond, Ap ril 2007, p. 12


27/39


Once again, vulnerabilities #1 and #2 are common place in the deployedOPC systems we surveyed . Acc ording to tests rep orted a t the S4 co nferenc ein January 2007, of the 75 different OPC servers tested using freely availabletools, 33% of these serve rs were vulnerab le to basic Do S a tta c ks17. This verylimited research shows that many deployed OPC servers have vulnerability

#3, and the number of vulnerable systems and variety of vulnerabilities islikely to grow as mo re sec urity resea rc h is performe d .

To d ate, vulnerab ility # 4 has neve r been rep orted , but papers by bo thprivate experts and government security bodies indicate that narrowfocus,custom-built malware has become increasingly common in the past twoyears1819. The te c hnology to c rea te suc h a wo rm is rea d ily ava ilab le.

The steps to imp ac t for this sc enario a re tha t the OPC m alwa re e nters thecompany via another vector (such as email) and begins to search for OPCtargets. It detects any OPC servers on the control system from enterprisenetwork and then attacks any vulnerable applications using the OPCvulnerab ilities listed in CERT/ CC vulnerability notes (for example see C ERT/ CCVulnerab ility ID: VU# 404833) or a zero-d ay vulnerab ility.

Once this scenario occurs, the OPC server will be unavailable and mayrequire anything from a simple reboot to complete software re-installationand c onfiguration to reco ver. The impa c t on produc tion w ill be based onhow the OPC server is used and if other critical control applications are onthe same c om puter as the OPC server ap p lic a tion.

2.5.4 Risk #4: Intelligent, Aggressive Attack against OPC Hosts

In this scenario, a skilled and aggressive attacker deliberately targets OPCsoftware running on his target companys control system and causes aserious proc ess up set using a man-in-the-midd le (MITM) tec hnique. For this toresult in a n impac t, the c om bined vulnerab ilities req uired inc lude:



17 Lluis Mo ra ; O PC: Inte rfac e Imp leme nta tion Vulnerab ilities , S4 Conferenc e, Digita l BondPress, Miami, FL, January 200718 Al Berg, "Seve n trend s to expe c t from virus and worm autho rs in 2006," Threat Mo nitor,January 4, 2006(http://searchsecurity.techtarget.com/tip/1,289483,sid14_gci1155150,00.html)19 NISCC Briefing : Ta rgeted Trojan Ema il Attac ks,National Infrastructure SecurityCo ordina tion Cent re, Lond on, UK, June 2005


28/39


3. Administrative rights allowing write access to ADMIN$, the registry andthe Window s servic e c ontrol ma nage r on the vic tim mac hine.

Onc e aga in vulnerab ilities # 1 and # 2 are c om mo n. The third vulnerab ility ismore d emanding, but is not unrea sona ble to a ssume tha t anybod y ca pa bleof c arrying o ut a M ITM a ttac k as desc ribed below w ill be a b le to ge tadministrative rights using standard rootkit software or by other means. Finallysom e me ans of a c c ess into the enterprise network is req uired .

The step s to imp lement the a ttac k are:

The a tta c ker wo uld first ga in ac c ess to the enterp rise ne twork and thengain the required access privileges into the control system by takingad vanta ge s of the two vulnerab ilities noted abo ve.

The a tta c ker would then remo tely insta ll a stea lth OPC server on avictim machine using DCOM, rename the registry entry for victim OPCserver to point to the stealth OPC server and remotely install and

execute utility program for killing the original OPC server.

Finally the attacker would use the stealth OPC server to deliberatelysend misleading information to the operators to induce them to takeinappropriate actions (this is known as operator spoofing). If desiredthe attacker could also de-install and delete utility program to wipeout trac es of th is ac tivity.

Figure 2-2: OPC Ma n-in-the-Midd le A ttack (c ourtesy of Ralph Lang ner)

The result would b e m a levo lent p roc ess ma nipula tion without b eing no tic ed

by c ontrol roo m sta ff (if p rop erly d isguised ). Attac ks of this type aga inst OPCsystems have not been reported to date, but have been demonstrated bysecurity researchers. As well, a similar, but non-OPC attack was beenreported in 2002 against the ship loading facilities of a major oil companyduring a general strike. In this case the attackers used knowledge of theMODBUS protoc ol to rem otely destroy a ll the PLC prog rams req uired fortanker loa d ing, effec tively shutting d ow n the p ort for a day.

Normal Operation

Attack Stage #1 -Insert Stealth OPC Server

Attack Stage #2 -Stealth Server Controls AllTraffic in Both Directions

OPCClients

(e.g. HMI)

OPCServer

SCADA/ControlSystem

OPCClients

(e.g. HMI)

SCADA/ControlSystem

OriginalOPC

Server

StealthOPC

Server

OPCClients

(e.g. HMI)

SCADA/ControlSystem

OriginalOPC

Server

StealthOPC

Server


29/39


3 Analysis of Common OPC Configurations and

Guidance

In this section we investigate system defaults and vendor guidancedoc ume nts for OPC insta lla tions in terms of the ir imp ac t o n sec urity.

For the most part, the security of any OPC installation largely rests upon howthe end-user configures their OPC hosts. While software flaws andvulnerabilities can impact overall system security, incorrectly appliedpermissions or inappropriate accounts can do far more damage.Furthermo re, the typ ic a l OPC host c onfigura tion is strong ly influenc ed by theguidance provided by the software vendor - most end-users are likely to stickwith the default vendor configuration unless there are very convincingrea sons to do otherwise. Thus we believe tha t the OPC vend or has signific antresponsibility for helping users create secure OPC systems.

3.1 User Guida nce DocumentationFor this portion of the analysis we requested OPC/DCOM host hardeningrecommendations from a large number of vendors. Unfortunately we failedto receive any documents that explicitly focused on OPC security, althoughwe understand that such documents may be under development in someorganizations. In the end we were left with what we could obtain fromvendor web sites or from organizations such as the OPC Foundation andCERN.

As we reviewed many of these OPC documents, we were struck by the

impression that many authors believe security isnt really a majorconsideration for applications not directly on the Internet. For example, theOPC Foundations XP SP2 Configuration guide20 states that the Windowsfirewall could be disabled if the OPC server is safely behind a corporatefirewall. Unfortunately we believe that this is a very antiquated andmisguided viewpoint numerous studies have shown that permeability ofmost network architectures with a single security perimeter control isinadequate and untenable21. Below we will summarize two documents thatprovide d the mo st foc used guidance, one from the OPC Founda tion a nd theother from CERN.

3.1.1 OPC Foundation Guidelines

Due to the extensive sec urity imp rovements in Wind ows XP SP2, the OPCFound ation released a doc ument d esc rib ing settings nec essa ry to ge t OPC

20 Karl-Heinz Deiretsbac her, Jim Luth & Rashesh Mo dy; Using O PC v ia DCOM with Mic rosoftWind ows XP Service Pac k 2, OPC Foundation, 200421 Avisha i Wool, "A quantitat ive stud y o f firew a ll configuration errors" IEEE Co mp uterMagazine, IEEE Co mputer Soc iety, June 2004, Pages 62-67


30/39


working if SP2 wa s insta lled on a host. Since the primary func tion o f theWind ows XP SP2 relea se w as improved sec urity, the rec ommendations in thisdoc ument have a signific ant impac t on O PC sec urity. Tab le 4-1 shows asumm ary of these rec om mendations.

Host Firewall Add DCOM (TCP port 135) and OPCEnum excep tions tofirew a ll. Rec om mends for vendors to use the Microsoft API toautom ate firew a ll c onfiguration during the insta ll.

DCOM Settings Add a nonym ous login to OPCEnum.exe. Although the sc reenshot show s add ing Everyone a nd Anonymo us log in as theusers, they recom me nd c rea ting an opc user's group .

Network

Considerations

Ma y be a c c ep tab le to pe rma nently disable the firew a ll if

be hind a c orporate firew all.

Tab le 3-1: Summa ry of OPC Found ation Sec urity Co nfiguration Guide lines

Unfortunately, while these guidelines offer several useful tips, the overall

effec t may be to dec rea se ra ther than inc rea se the sec urity of OPC systemsby imp lying tha t ve ry p ermissive sett ings are req uired on the Window s firew a llfor OPC to operate22. In particular, the suggestion that it might beacceptable to disable the host firewall if the system was safely behind ac orpora te firew a ll wa s troub ling . While this ma y have b een ac c ep tab le whenthe document was written in 2004, we believe this to be ill advised in mostind ustria l sett ings today. Thus we enc ourage the O PC Founda tion to ha vethe d oc ument revised .

3.1.2 CERN Sec urity Guidelines

Conseil Europen Recherche Nucleaire (CERN) released a well writtendoc ument desc ribing the ir p rac tice s for Wind ow s XP SP2 de p loym ents ofOPC Servers and Clients23. This doc ume nt provided go od qua lityrecommendations from a security perspective, and we have therefore builtupon their suggestions for our hardening recommendations in White Paper# 3. Tab le 3-2 shows a summa ry of these rec om me nd ations.

22 In fairness to the OPC Found ation, the p urpose o f the w hitep ape r wa s to e xplain how toconfigure the Wind ow s firew a ll to a llow OPC traffic p ass through it. This in turn would helpd isc ourag e users from shutting o ff the firew a ll a ltogether.23 Jean-Pierre Puget , Rena ud Ba rillere, Ma rk Beha rrell; IT-CO rec om me nded DCOM sett ingsfor OPC , Europea n Lab oratory for Particle Physics, 7 July 2005http:// itc ofe.web.ce rn.c h/itco fe/ Service s/ OPC/ GettingStarted / DCOM/ Related Docum ents/ ITCODCOM Settings.pd f


31/39


Host Firewall Recommends disabling the built-in firewall during installationand re-ena b ling it la ter. Excep tions a re a dded for DCO M (TCP

port 135) and for all c lient and server ap p lica tions.

Accounts Rec om me nds c rea ting a loc a l group for a ll users tha t should b eab le to ac c ess the OPC server.

DCOM Settings For the OPC Server: (Ap p lic a tion: Connec t, Identity:CERN\ opc admin, Launc h Permissions, Ac c ess Permissions)

OPC Server Browser (Authentica tion Level: Co nnec t)

Table 3-2: Summ ary of CERN Sec urity Configuration Guidelines

3.2 Default Configuration Parameters for OPC ServersOne of the a rea s where Microsoft ha s ma de signific ant improve ments in thepast few years is in making applications, processes and the entire Windowsoperating system more secure out of the box. Although a tough default

security posture with restrictive access control and fewer enabled servicesmay make an application more difficult to initially configure, in the long runthis ma y be the best sec urity solution. On the othe r hand, making the defa ulttoo restrictive may cause the user to configure the application to the mostinsecure (permissive) status just to get it operational. Consequently, aba lanc e o f sec urity and usab ility is req uired .

As we investigated the range of DCOM configuration guidance, our goalwa s not to be exhaustive (or even p resent b est p rac tic es) but to understandthe range of likely configurations. In most cases, our assessment was basedon free ly ava ilab le d oc umenta tion a nd OPC servers.

One of the first things we noticed was that the majority of vendors did nottighten down the access permissions for DCOM objects after the installationprocess was complete. In fact, as OPC security expert Ralph Langner pointsout in his paper OPC Exposed Part II 24, a number of major vendors maderecommendations that left the end users OPC security configuration wideopen. For example, Langer offered the following sample from a major PLCma nufac turers OPC d oc umenta tion 25:

As of Servic e Pac k 2 for Windows XP, com munications of OPC a lso

req uires the follow ing permissions to be set up :

Local and remote launch for the Anonymous Logon in

Launc h Permission

24 Ralph Langner; OPC Exposed Pa rt II, S4 Co nferenc e , Digital Bond Press, Miami, FL,January 200725 After ca reful consideration the identity of this vend or has be en removed to a voidsub jec ting the users of this p roduc t to unnecessa ry risk.


32/39


Local and remote activation for the Anonymous Logon in

Launc h Permission

Loc a l and remote ac c ess for the Ano nymous Log on in Acc ess

Permission

These set tings a re made automatica lly when you insta ll the XXXX NETCD.

These set tings basic a lly a llow any individua l with ne twork ac c ess to bothlaunch and access arbitrary OPC services across the network. Even worse,Mr. Langner notes tha t som e vend ors even suggest tha t the user rec onfigurestandard DCOM access rights for the entire host and not just theirapp lic a tion. Sinc e ma ny users do not fully understand the imp ac t o f theseconfiguration suggestions, we feel that this type of vendor guidance isirresponsible and will result in settings that violate most corporations securitypolicies.

In c om parison, ma ny IT app lic a tions have exec utab le hardening sc rip ts forinsta lla tion. These sc ripts ma y initially red uc e the sec urity o f the system toexpedite the actual installation of an application, but they thenautomatically correct this at the end of the installation process. We suggestthat control system vendors using OPC start adopting this technique tored uc e the post insta lla tion c onfigura tion burden up on the end -user.

Honeywe ll and Matrikon p rovide two go od vendor prac tic es that c an m akesec uring OPC easier. Hone ywe ll not only extend ed OPC to p rov ide increa sedsecurity, but provided very specific configuration recommendations,especially on user accounts and permissions. Although we did not examine

as ma ny live OPC Servers as we wo uld ha ve liked , Matrikon wa s the onlyvendor of those we examined that changed DCOM permissions at thecompletion of the installation process, showing what can and should bedo ne b y vendors.

In summary, the focus of most user documentation is on initial configurationand the steps necessary to ensure proper functioning of the applications.Unfortunately, this is typically done by strongly downgrading the securityposture of the applications and offering no guidance on how to upgrade itaga in at the c om p let ion o f insta lla tion. The sec urity of most OPC systemswould be greatly improved if vendors improved the quality of configuration

guidance to include improving security settings and provided easy to usehardening sc rip ts to autom atica lly enab le mo re rea sona b le sec urity settingsafter installation.


33/39


4 Conclusions

In this report we looked at the possible vulnerabilities present in OPC systemsas they are d ep loyed to day. We then used this da ta to c rea te four sc ena riostha t represent some o f the possibilities for OPC-ba sed a tta c ks. These fo ur

point us to several interesting conclusions. First, they highlight the fact thata tta c king OPC d ep loym ents doe s not require spec ia l skills or esoteric controlsknow led ge . All the too ls and informa tion nee ded to c arry them out c an b edo wnloa de d from the Internet.

The sec ond c onc lusion we c an d raw is tha t two c ore vulnerab ilities, namelyexcessively open firewalls and overly permissive DCOM access rights, lay atthe heart of many scenarios. If either vulnerability is addressed, then thechance of these scenarios occurring is significantly reduced. What isespec ially inte resting is the fac t tha t these vulnerabilities could be c onsideredthe responsibility of and within the control of the knowledgeable OPC end

user.

In other words, while there are a significant number of high profilevulnerabilities that are due to the design of both DCOM and the OPCstandard, the misconfiguration of either the underlying operating system orDCOM c onfiguration settings app ea r to o ffer a muc h more a ttrac tive a ttac ksurface for the average attacker. OPC security (particularly authenticationand authorization) is tightly bound to operating system security, so a poorlyconfigured OPC application can adversely affect the security of theund erlying o perating system a nd vice -versa .

Given Microsoft's large market share and early design decisions, there aresignificant vulnerabilities in OPC systems simply as a result of the underlyingop erating system. There is a rich lib rary of a tta c k tec hnique s and too ls tha tnovice (or automated) attackers can use to easily identify OPC servers on anetwork and then extract useful information. Due to the weak configurationof many of the OPC deployments active today, these attacks can beextrem ely effec tive. The OPC end user ca n ha ve a d irec t influenc e o nred uc ing this a ttac k surfac e.

At the same time, the OPC vendor community also needs to bear someresponsibility for improving OPC sec urity. The poor qua lity (from a sec urity

point of view) of most OPC user documentation is resulting in deploymentswith an unnecessarily weak security. We strongly believe that the security ofmost OPC systems would be greatly enhanced if vendors improved thequa lity of c onfigura tion guidance to include rec ommend ed sec urity settingsand provided easy to use hardening scripts to automatically enable morereasonable security setting after installation. A few vendors have moved inthis d irec tion, but the vast ma jority have no t.


34/39


The g ood new s is tha t the ha rdening p rac tic es for the Window s op eratingsystem are well known b y the IT sec urity co mm unity and c an be adop ted bythe controls community to significantly reduce these risks. In other words,OPCs reliance upon the Microsoft platform is both a curse and a blessing -while Windows has flaws, there are a wealth of practices for hardening

Windows servers that can be easily applied to OPC clients and servers. Inadd ition the re a re a numb er of DCOM spec ific sec urity settings tha t c an a lsobe a pp lied by the know led gea b le e nd -user. We will disc uss these solutions indetail in our final report in this series, OPC Sec urity White Paper # 3 Hardening Guidelines for OPC Hosts.


35/39


Glossary

ACL - Access Control List: List of rules in a router or firewall specifying accessprivileges to network resources.

API - Application Programming Interface: The spec ifica tion of the interfac ean app lic a tion m ust invoke to use c erta in system fea tures.

CATID - Ca tegory Identifier: Spec ifies the ac tive OPC spec ific a tions.

CCM - Component Category Manager: A utility that creates categories,places components in specified categories, and retrieves information aboutcategories.

CERN - Conseil Europeen Recherche Nucleaire: European Laboratory forPartic le Physics.

CIFS - Common Internet File System: Upda ted version of Server Me ssage

Block application-level protocol used for file management between nodeson a LAN.

CIP - Common Industrial Protocol: CIP is an open standard for industrialnetwork technologies. It is supported by an organization called OpenDeviceNet Vendor Association (ODVA).

COM Component Object Model: Microsofts architecture for softwarecomponents. It is used for interprocess and interapplication communications.It lets c om ponents built by different vend ors be c ombined in an a pp lic a tion.

CLSID - Class Identifier: An identifier for COM o b jec ts.

CORBA - Common Object Request Broker Architecture: Architecture thatenables objects, to communicate with one another regardless of theprogram ming langua ge and op erating system be ing used .

CSP - Client Server Protocol: An Allen-Brad ley p roto c ol used to c om munica teto PLCs over TCP/ IP.

DDE Dynamic Data Exchange: A mechanism to exchange data on aMic rosoft Wind ows system.

DCOM Distributed Component Object Model: This is an extension to theComponent Object Model to support communication among objects

loc a ted on d ifferent c om puters ac ross a netw ork.DCS Distributed Control System: A Distribute d Co ntrol System a llows forremote human monitoring and control of field devices from one or moreop eration cente rs.

DDE - Dynamic Data Exchange: An interprocess communication system builtinto Windows systems. DDE enables two running applications to share thecommon data.


36/39


DLL - Dynamic Link Libraries: A fi le containing executable code and databound to a prog ram a t the a pp lic a tion s loa d or run time , ra ther than linkingduring the c ompilation of the ap p lic ations c od e.

DMZ - Demilitarized Zone: A small network inserted as a "neutral zone"betw een a trusted priva te ne two rk and the outside untrusted netw ork.

DNP3 - Distributed Network Protoc ol 3: A p rotoc ol used betw een c omp onentsin SCADA systems (prima rily in the power and water industries).

DNS Domain Name System: A distributed database system for resolvinghuma n read ab le names to Internet Proto c ol addresses.

EN - Enterprise Network: The c orpo ra tion-wide b usiness c om munica tionnetwo rk of a firm.

ERP - Ente rprise Resourc e Planning : Set of activities a business uses toma na ge its key resourc es.

GUI - Graphical User Interfac e: Graphic a l, as op posed to textua l, interfac e toa c omputer.

GUID - Globally Unique Identifier: A unique 128-bit number that is producedby the Windows operating system and applications to identify a particularc om pone nt, app lica tion, file, da tabase entry or user.

HMI - Human Machine Interface: A software o r hardwa re system tha t ena b lesthe interac tion of m an a nd m ac hine.

HTML - Hypertext Markup Lang uag e: The a utho ring softw are lang uage usedon the Inte rnet's World Wide Web.

HTTP - HyperText Transfer Protocol: The protoc ol used to transfer Webdoc uments from a server to a brow ser.

HTTPS - HyperText Transfer Protocol over SSL: A secure protocol used totransfer Web doc uments from a server to a b row ser.

IIS - Internet Informa tion Serve r: Microsofts web server application.

IDL - Interfac e Definition Langua ge : Language for describing the interface ofa software c omp onent.

IDS - Intrusion Detec tion System : A system to detect suspicious patterns of

network tra ffic .IPX - Internetwork Packet Exchange: A networking protocol used by theNovell Inc orporated .

IPSEC Internet Protocol SECurity: An Internet standard providing security atthe netw ork layer.

IP - Internet Protocol: The standard proto c ol used on the Internet that definesthe d a tag ram format a nd a best effort p ac ket de livery servic e.


37/39


I/O - Input/ Output: An interface for the input and outp ut of informa tion.

ISA - Instrumentation, Automation and Systems Society: ISA is a nonprofitorganization that helps automation and control professionals to solvetec hnic a l instrumenta tion p rob lems.

IT - Information Tec hnology: The d evelop me nt, insta lla tion a ndimp lem enta tion o f app lic a tions on c om puter system s.

LAN - Loc al Area Network: A c om puter netw ork tha t cove rs a sma ll a rea .

LM - LAN Manager: A now obsolete Microsoft Windows networking systemand authentic ation p rotoc ol.

LDAP - Lightweight Directory Access Protocol: A protocol for accessingd irec tory services.

MBSA - Microsoft Baseline Security Analyzer: A tool from Microsoft used totest a system to see if Microsoft b est p rac tice s are b eing used .

MIB - Management Information Base: The da tabase tha t a system running anSNMP agent mainta ins.

MODBUS - A communications protocol

Documents

OPC Security WP2