Iam Opc Security Wp1

8/3/2019 Iam Opc Security Wp1

http://slidepdf.com/reader/full/iam-opc-security-wp1 1/39

intrinsica lly sec ure

po bo x 178

unit# 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 #1

Understanding OPC and How it isDeployed

PREPARED BY:

Digital Bond

British Co lumb ia Institute o f Tec hno logy

Byres Research

July 27, 2007

OPC Security WP 1 (Version 1-3b).doc



OPC Sec urity WP 1 (Version 1-3b).doc ii July 2007

Revision History

Revision Date Author Details

0.7 Ma y 15, 2006 E. Byres, J. Ca rter, M Franz,

W. Henning, J. Karsch

Dra ft inte rna l review version

1.0 Ma y 31, 2006 E. Byres, J. Ca rter, M Franz

W. Henning, J. Karsch

Dra ft for co ntrolled pub lic review

1.1 August 31,

2006

E. Byres, M. Franz 2nd Dra ft for co ntrolled pub lic

review

1.2 Feb ruary 9,

2007

E. Byres, D. Ped erson 3rd Dra ft for co ntrolled pub lic

review

1.3 Ap ril 3, 2007 Pub lic Relea se Version

1.3a June 27, 2007 Gram ma tica l errors c orrec ted

1.3b July 27, 2007 Gramm atica l errors c orrec ted

Acknowledgements

The Group for Advanc ed Information Tec hno logy (GAIT) a t the British

Co lumb ia Institute of Techno logy (BCIT), Dig ita l Bond , and Byres Research

would like to thank all the vend ors and end users tha t generously supported

our efforts throug h numerous interview s and by p roviding us with d oc uments

that could only be described as extremely sensitive. Unfortunately we can

not name you fo r obvious sec urity reasons, but we apprec ia te your time , trust

and encourag ement.

Two peop le stoo d out in their c ontributions and advice fo r this doc ume nt

tha t we wo uld like to acknowledge . These p eop le a re Bill Co tter and Chip

Lee . Thank you for a ll your help.

Finally we would like to thank Evan Hand, formerly of Kraft Foods Limited, for

his vision and support. Without him, this project never would have been

possible.

Disclaimer

Deployment o r app lica tion of a ny of the op inions, sugg estions or

configuration included in this report are the sole responsibility of the reader

and are offered without wa rrantee o f any kind b y the authors.

Downloaded from www.IAMechatronics.com



OPC Sec urity WP 1 (Version 1-3b).doc iii July 2007

Table of Contents

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

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

1.1 The Issue s........................................................................................................ 31.2 Organiza tion & Methodology of the Stud y ..............................................5

1.3 Limita tions of th is Study ................................................................................ 6

2 What is OPC?..................................................................................................... 7

3 How Ind ustry Uses OPC .................................................................................. 10

3.1 Key Find ings from the OPC Deploym ent Survey....................................10

3.1.1 Wha t do End -Users use OPC fo r?......................................................10

3.1.2 Wha t OPC Func tiona lity do End -Users Deploy? .............................11

3.1.3 Wha t is the Impac t if OPC Co mmunica tions a re Lost?.................12

3.2 Customer Referenc e Implem enta tions of OPC..................................... 13

3.2.1 Loca l OPC on Control/Supervisory Netw ork................................... 143.2.2 Loca l OPC on Co ntrol/Sup ervisory Network and Histo rian DMZ..15

3.2.3 Remote OPC betw een Plant Sites....................................................16

4 The OPC Arc hitec ture ..................................................................................... 18

4.1 The Rela tionship between OPC, CO M, DCOM and RPC ....................18

4.2 OPC Da ta Model........................................................................................ 19

5 OPC Standards & APIs.................................................................................... 21

5.1 OPC Data Access (3.0)..............................................................................21

5.1.1 Example of OPC-DA Usage ...............................................................22

5.2 OPC Ala rms & Events (1.10) ......................................................................22

5.2.1 Example of OPC A&E Usage .............................................................22

5.3 OPC Histo rica l Da ta Ac cess (1.20)...........................................................23

5.3.1 Example of OPC-HDA Usage ............................................................23

5.4 OPC Data Excha ng e (1.0) ........................................................................23

5.4.1 Example of OPC-DX Usage ...............................................................24

5.5 OPC Security (1.0).......................................................................................24

5.6 OPC XML-Data Ac cess (1.01) ................................................................... 24

5.6.1 Example of OPC XML-DA Usage.......................................................25

5.7 OPC Unified Arc hitec ture (RC 1.00)......................................................... 25

6 OPC Interna ls - Relevant OPC and Windows Components ....................... 27

6.1 Proxy/ Stub DLLs...........................................................................................27

6.2 OPC Server Browser....................................................................................28

6.3 Windows Components ..............................................................................28

6.4 A Simp le OPC Server..................................................................................29

7 Conc lusions..................................................................................................... 31

Glossary .................................................................................................................. 32




OPC Sec urity WP 1 (Version 1-3b).doc 1 July 2007

Executive Summary

In rec ent years, Supervisory Co ntrol and Data Ac quisition (SCADA), proc ess

control and industrial manufacturing systems have increasingly relied on

commerc ial Information Techno log ies (IT) suc h a s Ethe rnet™, Transmission

Control Protoc ol/ Internet Protoc ol (TCP/ IP) and Window s® for bo th c ritica land non-c ritica l comm unic ations. This has made the interfac ing o f industria l

control equipment much easier, but has resulted in significantly increased

connec tivity to the outside wo rld, which in turn results in an increase in the risk

of c yber-ba sed a ttac ks imp ac ting industrial p rod uc tion a nd human safety.

Nowhere is this benefit/risk combination more pronounced than the wide-

sprea d adop tion of Ob jec t Linking and Emb ed ding (OLE) for Proc ess Control

(OPC). OPC is increasingly being used to interconnect Human Machine

Interface (HMI) workstations, data historians and other hosts on the control

network with enterprise databases, Enterprise Resource Planning (ERP)

systems and other business oriented software. Unfortunately, securelydeploying OPC applications has proven to be a challenge for most

engineers and technicians. While OPC is an open protocol with the

spec ifica tions free ly ava ilab le, eng ineers must wa de through a la rge amo unt

of very detailed information to answer even the most basic OPC security

questions.

To address this need for sec urity guidance on OPC d ep loyment, a joint

research team with sta ff from BCIT, Byres Research and Digita l Bond were

commissioned by Kraft Foods Inc. to investigate current practices for OPC

sec urity. The results of this stud y we re then used to c rea te three white papers

that:

1. Provide an overview of OPC Tec hnology and how it is ac tua lly

dep loyed in industry

2. Outline the risks and vulnerabilities incurred in deploying OPC in a

control systems environment

3. Summ arizes current good prac tices for sec uring OPC app lica tions

running on Window s-ba sed hosts.

The w hite p aper you are now read ing is the first o f the three and explains

what OPC is and describes the results of a survey of OPC end-users on how

OPC is ac tua lly used in the field. It is intend ed to b e read and understoo d by

IT administrato rs and c ontrol systems engineers/ technic ians ra the r than OPC

prog ramm ing or sec urity experts

The results of the end -user survey ind ica te tha t OPC is not just used for da ta

ma nag ement p urpo ses on the plant floor, but instea d is a c ritical com ponent

of many production systems. Over quarter of the end-users reported that loss

of OPC communications would result in a loss of production. In addition,





approximately 20% of the companies reported deploying OPC over site

business networks, enterprise networks or corporate Intranets and

approximately 10% used OPC over the Internet itself. All these results highlight

the urgent need for better OPC sec urity.

The c ha llenges of sec uring OPC d ep loyme nts are a lso c lear. The inherent

architectural complexity of OPC, the default security posture of many OPC

servers, and the lack of unambiguous guidance with regard to security all

contribute to the d iffic ulties of sec uring OPC d ep loym ents. In a dd ition, OPC’ s

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 applied to OPC clients and servers. In the follow-on white

papers these solutions are discussed in detail.





1 Introduction

This report is the first o f three white p apers outlining the findings from a stud y

on OPC security conducted by Byres Research, Digital Bond and the British

Co lumbia Institute o f Tec hno logy. The ob jec tive of this stud y wa s to c rea te a

series of simple, authoritative white papers that summarized current goodpractices for securing OPC client and server applications running on

Window s-ba sed hosts. The full stud y is d ivided into three Good Prac tice

Guide s 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 and

how 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 and

vulnerab ilities incurred in de p loying OPC in a control environm ent?

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

How can a server or workstation running OPC be secured in a simple

and effective ma nner?

All three white papers are intended to be read and understood by IT

administrators and control systems technicians who have no formal

background in either Windows programming or security analysis.

1.1 The Issues

In rec ent years, Supervisory Co ntrol and Data Ac quisition (SCADA), proc ess

control and industrial manufacturing systems have increasingly relied oncom merc ia l informa tion tec hnolog ies (IT) suc h a s Ethernet™, TCP/ IP and

Window s® for bo th c ritic a l and non-c ritica l co mm unic ations. The use of these

common protocols and operating systems has made the interfacing of

industrial control equipment much easier, but there is now significantly less

isolation from the outside world. Unless the controls engineer takes specific

steps to secure the control system, network security problems from the

Enterprise Network (EN) and the world at large will be passed onto the

SCADA and Proc ess Control Network (PCN), put ting industria l p rod uc tion and

human sa fety a t risk.

The wide-sprea d adop tion o f OLE for Proc ess Control (OPC) standards forinterfacing systems on both the plant floor and the business network is a

c lassic example of both the b ene fits and risks of a dop ting IT techno logies in

the control world. OPC is an industrial standard based on the Microsoft

Distributed Component Object Model (DCOM) interface of the Remote

Procedure Call (RPC) service. Due to its perceived vendor-neutral position in

the industrial controls market, OPC is being increasingly used to interconnect





Human Machine Interface (HMI) workstations, data historians and other

servers on the control network with enterprise databases, ERP systems and

other business-oriented software. Furthermore, since most vendors support

OPC, it is often thought of as the one of the few universal protocols in the

industrial controls wo rld , ad d ing to its widesprea d appea l.

Unfortuna tely, viruses and wo rms from the IT wo rld m ay be increa singly

focusing on the underlying RPC/DCOM protocols used by OPC, as noted in

the fo llow ing d iscussion o f at tac k trends:

“Over the past few months, the two attack vectors that we saw in

volume were against the Windows DCOM (Distributed Component

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

and aga inst the Windo ws LSASS (Loc a l Sec urity Authority Sub system

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.” 1

At the same time, news of the vulnerabilities in OPC are starting to reach themainstream press, as seen in the M arc h 2007 eWeek a rtic le e ntitled “ Hole

Found in Protocol Handling Vital National Infrastructure” 2. Thus, the use of

OPC connectivity in control systems and servers leads to the possibility of

DCOM-based p roto col a ttacks d isrupting c ontrol system s op erations.

Comp lica ting matters even more is Microsoft's goa l of retiring DCOM in favor

of .NET and movem ent towa rds Service Oriented Architec tures. The g oo d

news is that most OPC applications will eventually be migrated from the

DCOM-based architec ture to a potentia lly more sec ure .NET-ba sed

architec ture (See Sec tion 5.7: OPC Unified Architec ture fo r more deta ils). The

bad news is that Microsoft’s desire to discontinue support for DCOM in thelong term may require some companies to use unsupported software with

serious vulnerabilities. Regardless, DCOM-based OPC is what is used on the

p lant floor and it will continue to b e used for many yea rs to com e. Thus, this

doc ument focuses a lmo st exc lusively on OPC o ver DCOM.

Desp ite a ll the se conc erns, it is our be lief tha t the most serious issue for OPC is

that sec urely dep loying OPC a pp lications has proven to be a challenge fo r

mo st eng ineers and technicians. While OPC is an open p roto col with the

spec ifica tions free ly ava ilab le, eng ineers must wa de through a la rge amo unt

of very de ta iled information to answer even basic sec urity questions. There is

little d irec t guida nce on sec uring OPC, and our resea rch ind ica tes tha t muc hof what is available may actually be ineffective or misguided. All things

1 Bruce Sc hne ier, “ Atta c k Trends” QUEUE Ma gazine, Assoc iation of C om puting

Machinery, June 2005

2 Lisa Va as, “ Hole Found in Protoc ol Hand ling Vita l Nat iona l Infrastruc ture” eWeek,

http :// ww w.ew ee k.c om / a rticle2/0,1759,2107265,00.asp , March 23, 2007





considered, there is little doubt that some clear advice for the control

eng ineer on how b est to sec ure OPC systems would be very useful.

1.2 Orga nization & Methodology of the Study

While researching this study we found few treatments of OPC that were

useful for rea ders who w ere not experienc ed software d eve lopers. Thus, we

begin this first white paper with a review of the OPC specifications, focusing

on details that are relevant from a security point of view and might be useful

to users wishing to understand the risks of OPC deployments. Following this

conceptual overview, we describe the real-world operation of OPC

ap p lications, ide ntifying c om po nents that nee d to be understood to harden

hosts running O PC c lient and server ap p lica tions.

In White Paper #2 we define a set of vulnerab ilities and likely threats based

on OPC’ s architec ture (such as the use o f DCOM, the reliance up on a n OPC

Server Brow ser, etc .) and com mon mis-configura tion vulnerab ilities found in

OPC servers.

In White Paper # 3 we use a ll this information, plus the results of the surveys, to

give the O PC end -user a series of p rac tica l rec om mendations they c an draw

on to sec ure their OPC host machines.

Creating these recommendations required the following four-phase

ap proac h to the study:

1. Data Ga thering

• Conducting user surveys and collecting information on OPC

de ployments in order to get a rep resenta tive sam ple of how ac tualOPC deployments were configured in the field by our target

audience.

• Reviewing OPC Found ation and vend or co nfiguration g uidelines.

• Conducting a literature search for OPC-related papers and

guidelines.

2. Ascerta ining potential threa ts and vulnerab ilities in OPC systems

• Identifying what operating system configuration issues exist intypical OPC deployments.

• Identifying w ha t OPC, RPC a nd DCOM issues exist in typ ica l OPC

deployments.

3. Creating recommendations for mitigating potential threats and

vulnerabilities





• Determining what could be done to secure the underlying

op eration system without impac ting the OPC func tionality.

• Determining what could be done to secure RPC/DCOM

com ponents in an OPC host.

• Dete rmining OPC-spec ific c lient a nd server sec urity co nfigurat ions.

4. Testing the Sec urity Rec om mend ations

• Lab testing a ll rec om mendations in a typica l OPC environm ent a nd

modifying our rec ommenda tions ac c ord ingly.

1.3 Limitations of this Study

It is important to understand that this report is not intended to be a formal

security analysis of OPC or DCOM, but instead is a set of observations andprac tices tha t w ill help end -users sec ure their OPC systems. As well, this report

is focused only on securing the host computers that are running OPC.

Sec uring the netw ork OPC op erates over is an interesting and important a rea

of research, but is beyond the scope of this report. A follow-on study is

p lanned to investiga te these netw ork sec urity aspec ts and consider solutions

for OPC/DCOM in the network infrastructure, including firewall rule-sets and

ana lysis of third p arty OPC tunne lling solutions.

As well, we cannot guarantee that following our recommendations will result

in a completely secure configuration. Nor can we guarantee that these

recommendations will work in all situations; some modifications may berequired for individual OPC client and server applications or Microsoft

Windows network deployments. However, we are confident that using these

guidelines will result in more secure systems as compared to the typical

default application and operating system settings we have seen in our

investigations.





2 What is OPC?

OLE for Process Control (OPC) is a software interface technology used to

facilitate the transfer of data between industrial control systems, Human

Machine Interfaces (HMI), supervisory systems and enterprise systems such as

historical databases. It was developed in response to the need for astandardized method for allowing different control systems to interface with

ea ch other. Tod ay it has grown to be the lead ing te chnology for integ ra ting

d ifferent co ntrol prod uc ts.

The p rima ry va lue o f OPC is tha t it p rovides a c om mo n interfac e for

communicating with diverse industrial control products, regardless of the

software or hardware used in the process. Before OPC, application

de velopers had to de velop spe c ific com munica tions drivers for eac h c ontrol

system they wished to interface with. For example, HMI vendors had to

develop hundreds of different drivers for the different Distributed Control

Systems (DCS) and Program mable Log ic Controllers (PLCs) on the m arket .

Using OPC, these application vendors no longer need to develop separate

drivers for each network or processor. Instead, they create a single optimized

OPC c lient and / or server for the ir p rod uc t. This OPC c lient would then

communicate with OPC servers designed and sold by the manufacturers of

the other networks and controllers.

It is important to understand that OPC does not eliminate the need for

drivers. Typica lly eac h manufac turer develop s an OPC server for their spec ific

product using whatever protocol their device needs, since they are best

suited to build a server that will take full advantage of their product.However, once an OPC server exists for a piece of equipment or an

application, it becomes much easier to integrate its data with other OPC

com pliant softwa re.

HMIApplication

DCS Driver 1

PLCBrand A

Driver 2

PLCBrand B

Driver 3

OPCPlatform

DCS OPC Srvr 1

PLCBrand A

OPC Srvr 2

PLCBrand B

OPC Srvr 3

HMIApplication

OPC Client

Before OPC After OPC

Figure 2-1: OPC Effic ienc y in Driver Developme nt





OPC is based on Microsoft’s Distributed Component Object Model (DCOM)

technology, which is the culmination of a number of other technologies

including Component Object Model (COM) and the Object Linking and

Embedding (OLE). Many people have heard of OLE and have used its

capabilities when adding a spreadsheet to a word processing document.

OLE allows the spreadsheet application to dynamically update theinformation in the word p roc essing doc ument. Typica lly the user isn’ t req uired

to d o even the slightest c onfigura tion beyond the c lic k of a mo use. The OLE

specification defines how the spreadsheet (in this case the OLE server) will

forma t a nd send da ta to the wo rd proc essor doc ument (the OLE c lient).3

OPC is based on a client-server architecture. An OPC server is a software

app lica tion tha t typ ica lly ga thers information from devices (such a s PLC, DCS

or SCADA c ontrollers) using these devic e’ s na tive protoc ols (suc h a s MODBUS

or PROFIBUS). The server then provides access to this da ta via CO M o b jec ts

and method calls, allowing multiple OPC clients to indirectly read and write

to the field device via the OPC server.

An OPC client is an application that accesses data held by OPC servers. For

example, an HMI package may contain an OPC client that allows it to

access data provided by an OPC server application resident on another

ma chine. The HMI package c ould a lso a c t as an OPC server, allow ing othe r

OPC clients to access the data it has aggregated either directly from field

controller or from other OPC servers.

To illustrate this c lien t-server architec ture, imagine a simp le system w ith three

basic com ponents designed for controlling the wa ter leve l in a ta nk:

• A MODBUS-ca pable PLC p erforming the ac tua l control,• An OPC platform that contains an OPC server and a MODBUS

protocol driver,

• A HMI for operato r ac cess to the control system .

Within the PLC, the data reg isters and d isc rete points might look like this:

Reg ister Nam e (Tag) Desc ription

40001 SP Wate r Leve l Setp oint

40002 CO Pump Control Outp ut

40003 PV Wate r Leve l Sensor

10001 LoAla rm Tank Dry Ala rm

10001 HiAlarm Tank Overflow Ala rm

Table 2-1: Example Data Points in the PLC

3 http:// msdn.microsoft.com /library/d efault.asp?url=/library/en-us/ dnd c om / html/m sdn_dc omte c .asp





The HMI will need to be a b le to w rite the set point in the c ontroller, rea d the

current water level, and monitor the controlled output (the pump) and

alarms. If the HMI needs to read a value from the PLC, it sends a request via

an OPC Application Programming Interface (API) call and the server

translates this into a MO DBUS message fo r communica tions to the PLC. When

the desired information is returned from the PLC to the OPC server it thentranslates tha t b ac k to OPC for transmission to the HMI.

Figure 2-2 shows a simp lified illustration of the communications in this system.

Figure 2-2: Example o f Possible OPC Client-Serve r Architec ture in Tank Level Control

l a t i g i d

PLC Platform with OPC

Server

HMI with

OPC Client

MODBUS OPC/DCOM

Level

Transmitter

Field I/O





3 How Industry Uses OPC

As part o f the resea rch e ffort in c rea ting this series of rep orts, a survey o f OPC

end-users was conducted by the study team and the Instrumentation,

Automation and Systems Soc iety (ISA) in the Winte r of 2006. The intent w as to

determine how end-user companies actually deploy OPC in their processand manufac turing environm ents. Sec urity rec om mendations deve lop ed in

this study were then tailored to meet the needs of the largest number of

ac tua l users, as identified by the survey.

The fo llowing two sec tions d isc uss the typ es of OPC c onfigurat ions users

rep orted as ac tua lly used in industry. We then illustra te three of the c om mo n

configurations involving OPC, that end-user companies reported using on

the ir sites. The intent of this sec tion is not to rec om mend or endorse these

dep loyments, but ra ther show how OPC is ac tua lly used in the rea l world .

3.1 Key Findings from the OPC Dep loyment Survey

The OPC User Survey was conduc ted in the winte r of 2006 using a we b survey

designed by study team a nd m anaged b y ISA. A tota l of 113 ind ividua ls

respond ed , the vast majority of them we re end users of c ontrol systems.

3.1.1 What do End-Users use OPC for?

The first question in the survey asked “ how does your c ompa ny typica lly use

OPC in its operations ”? Not surprisingly, OPC was always or often used for

data transfer to historians, data aggregation in HMIs and supervisory control

in the majority of the end users facilities. What was surprising was that 30% of

the end users rep orted em p loying OPC for data sharing to 3rd parties suc h asbusiness partners and sup p liers. Since it is likely tha t most 3rd parties are

loc ated rem ote ly from the users’ p rod uc tion fac ilities, this ind ica tes that O PC

is being used for da ta transfer fa r beyond the p lant floo r.

Always orOften Sometimes

Rarely orNever

Transfer to Historians 72% 16% 12%

Data Aggregation in HMIs 50% 20% 29%

Supervisory Control 50% 17% 33%

System Control Data 40% 21% 39%

Data Between Partners30% 11% 59%

System Interlocks 17% 13% 70%

Table 3-1: Question #1: How d oes your compa ny typ ically use OPC in its op erations?





T a n s f e

r t o H i s t o r i a

n s

D a t a A g

g r e g a t i o

n i n

. . .

S u p e

r v i s o r y C o n t r o l

S y s t e m

C o n t r o l D

a t a

D a t a

B e t w e

e n P a r t n

e r s

S y s t e m

I n t e

r l o c k s

Al w a y s o r O f t e n

S o m e t i m e s

R a r e l y o r N e v e r 0%

10%

20%

30%

40%

50%

60%

70%

80%

Figure 3-1: Question #1: How do es your comp any typ ically use OPC in its

operations?

3.1.2 What OPC Func tiona lity do End-Users Deploy?

The next question asked the respond ent to indica te w hat OPC func tionality

the ir com pany used . The results indica te tha t Data Ac cess (DA), Histo rica l

Data Access (HDA) and Alarms and Events (A&E) are the primary OPCspec ifica tions tha t a c tua lly ge t used on the p lant floor. The rema ining

spec ifica tions are o nly used in limited cases.

Always orOften Sometimes

Rarely orNever

Data Access (DA) 82% 13% 5%

Historical Data Access (HDA) 53% 15% 33%

Alarms and Events (A&E) 42% 18% 40%

Data eXchange (DX) 25% 15% 60%

XML Data Access (XML-DA) 23% 14% 63%

Web Services 19% 12% 69%

Batch 17% 18% 65%

Security 15% 15% 70%

Unified Architecture (UA) 10% 16% 74%

Tab le 3-2: Question #2: What OPC Func tiona lity Does Your Co mp any Use?





D a t a

A c c e s s

( D A )

H i s t o r i c a

l D a t a

A c . . .

A l a r m s a n

d E v

e n t s

. . .

D a t a

e X c

h a n g

e ( D X

)

X M L D

a t a A c

c e s s

. . .

W e b

S e r v i c

e s

B a t c h

S e c u r i t y

U n i f i e

d A r

c h i t e

c t u r e .

. .Al w a y s o r O f t e n

S o m e t i m e s

R a r e l y o r N e v e r

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

Figure 3-2: Question #2: What OPC Functionality Does Your Company Use?

3.1.3 What is the Impac t if OPC Communications are Lost?

The next question a sked the respond ent to ind ica te w hat types of impac t

would the loss of OPC have on their operations and what percent of the

OPC systems dep loyed w ould ha ve this impac t. What is interesting is tha t

over a quarter of the sites reported that loss of OPC would result in a loss of

production. Also interesting is that more systems would experience loss of

view by the op erato rs than no t.While some users remarked that they had deliberately structured their

systems to minimize safety and operational effects on loss of OPC-based

information, others sta ted the op posite; “We c ont rol the m oto r drives by OPC

with the DCS. If we lose the OPC we stop the prod uc tion!” Clearly OPC is not

just being used for data management purposes on the plant floor, but

instead is a c ritica l com ponent of m any prod uc tion systems. This highlights

the urgent need for better OPC sec urity.

Most (80%or more)

Some(60 -40%)

Few(20% or less)

Temporary loss of historical dataaccess 38% 28% 34%

Permanent loss of historical data 33% 18% 49%

Loss of view by operators 41% 23% 36%

Loss of production 27% 17% 57%

Other 16% 19% 65%

Table 3-3: Question #3: Perc ent of Systems with a Given Imp ac t if OPC is Lost





T e m

p o r a r y

l o s s

o f h .

. .

P e

r m a n

e n t l o

s s o f .

. .

L o s s o f

v i e w

b y o p e

. . .

L o s s o f

p r o d u

c t i o

n

O t h e

rM o s t ( 8 0 % o r m o r e )

S o m e ( 6 0 - 4 0 % )

F e w ( 2 0 % o r l e s s )0%

10%

20%

30%

40%

50%

60%

70%

Figure 3-3: Question #3: Perc ent of Systems with a Given Imp ac t if OPC is Lost

3.2 Customer Referenc e Imp lementa tions of OPC

The fina l question on OPC use wa s designe d to dete rmine w hich networks

OPC traffic is actually found on. In other words, is most OPC traffic restricted

to only the lowest levels of the control system or does it travel over upper

levels such as the enterprise network or even the Internet. Closely

corresponding to the response to question #1, OPC was used in about two-thirds of the sites for transfers in layers 1, 2 and 3 of the network (the layers

refe r to the ISA SP-99 General Refe renc e Model and not the OSI model). This

aligns with the response to Question #1 of the survey, which indicated that

data transfer to historians, data aggregation in HMIs and supervisory control

wa s a primary use in the majority of the end users fac ilities.

Also correlating with question #1 was the fact that approximately 20% of

companies reported deploying OPC over the site business network,

enterprise network or corporate Intranet and approximately 10% used OPC

ove r the Internet. Clearly, the c om mo n be lief that OPC is only found on the

control netw ork is bad ly m istaken.





Alwaysor Often Sometimes

Rarely orNever

Internal to OPC Server Only (No networktraffic) 43% 16% 40%

Control Network (Layer 1) 49% 15% 35%HMI/Supervisory Network (Layer 2) 67% 17% 17%

Site Operations/DH Network (Layer 3) 62% 18% 20%

Control System DMZ 30% 11% 59%

Business Network (Layer 4) 22% 16% 62%

Enterprise Network (Layer 5) 18% 12% 70%

Corporate Intranet 22% 8% 70%

Internet via VPN 12% 8% 80%

Internet 8% 4% 88%

Table 3-4: Question #4: What Networks is Your OPC Traffic Opera ting Ove r?

I n t e r n a l

t o O P C

S e r v

. .

C o n t r o l N e

t w o r k

( L a y .

.

H M I / S u

p e r v i s o r y

N . . .

S i t e

O p e

r a t i o

n s / D H .

. .

C o n t r o l S

y s t e m D

M Z

B u s i n

e s s N

e t w o

r k . . .

E n t e

r p r i s e

N e t w

o r k . . .

C o r p o r a t e I n t r a n

e t

I n t e r n e t

v i a

V P N

I n t e r n e t

Al w a y s o r O f t e n

S o m e t i m e s

R a r e l y o r N e v e r

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

Figure 3-4: Question #4: What Networks is Your OPC Traffic Op era ting Ove r?

Using these results as a starting point, we conducted interviews with a

number of end-users to understand the actual deployments that might

produc e these num be rs. We q uickly disc overed three com mon dep loyments

that accounted for the majority of all reported user architectures. We will

de sc ribe ea ch of these b elow.

3.2.1 Loc al OPC on Control/ Supervisory Network

This first dep loyment is typ ica l of ho w m any com panies use OPC fo r

connecting control and interlock traffic between different vendors’ control





systems. A vendor inte rfac e, suc h a s RSLinx, brings up data from PLCs on the

control layer into a HMI or OPC concentrator via a control protocol like

Co mmon Ind ustria l Protoc ol (CIP) or Client Server Protoc ol (CSP). It then sto res

this data in the OPC server for excha nge with o ther vend ors’ OPC c lients and

servers. All traffic is conta ined on the HMI layer and no OPC traffic c rosses the

firewall boundaries.

Figure 3-5: Loc al OPC on the Control/ Supervisory Network Only

3.2.2 Loc al OPC on Control/ Supervisory Network and Historian DMZ

The sec ond dep loyment is typ ica l of how c om panies use OPC to transfer

both real-time and historical traffic between different vendors control

systems. Aga in a vendor interfac e like RSLinx brings up da ta from the PLC’ s

via a control protocol into a HMI or OPC concentrator and then stores it in





the OPC server to make it available for the data historian. Alternatively, the

server ma y reside in the SCADA o r DCS system itself a nd use OPC DA, HDA or

A&E to transfer information. The historian c om puter ca n sit in a Demilitarized

Zone (DMZ) for shared control/enterprise data servers or up on the business

network, dep ending on the site. Typ ica lly the OPC tra ffic w ill cross a t least

one firew all or router with a n Access Control List (ACL).

Figure 3-6: Loc al OPC on Control/ Supervisory Network and Historian DMZ

3.2.3 Rem ote OPC between Plant Sites

The third dep loym ent is typica l of how som e c om panies use O PC to

aggregate data between related sites. Historical traffic between different





field sta tions or rem ote sites is transferred via OPC to a central da ta historian.

Aga in this historian c an sit in a DMZ or up on the business network, dep ending

on the site. Typ ica lly the traffic will c ross a t lea st two firew a ll interfac es.

Figure 3-7: Remote OPC between Plant Sites





4 The OPC Architec ture

4.1 The Rela tionship between OPC, COM, DCOM and RPC

One of the most important things to understand about OPC is that it is an

App lication Prog ramm ing Interfac e (API) and not a n “ on the wire” p rotocol.It is at a higher level of abstraction than communications protocols such as

Ethe rnet, TCP/IP or the even the MO DBUS Ap plica tion Protocol. For most

developers using the OPC API, the underlying network transport or data

enc od ing used by the API to exchange da ta is irrelevant.

Figure 4-1: OPC Laye ring

As Figure 4-1 shows, underlying OPC are three very critical communications

protoc ols; COM, DCOM and RPC.Component Object Model (COM) is a successor to Dynamic Link Libraries

(DLLs) and is a software architecture developed by Microsoft to build

component-based applications. It allows programmers to encapsulate

reusab le p iec es of c od e in such a wa y that other ap plica tions can use them

without having to worry about implementation details. In this way, COM

objects can be replaced by newer versions without having to rewrite the

app lica tions using them .

Distributed Component Object Model (DCOM) is a network-aware version of

COM . It tries to hide the d ifferenc e b etw een invoking loc a l (i.e. on the same

computer) and remote interfaces (i.e. two different computers) fromsoftware developers. In order to do this, all the parameters must be passed

by va lue a nd the returned va lue m ust a lso b e p assed by va lue. The p roc ess

of c onve rting the parame ters to d a ta to b e transferred ove r the w ire is ca lled

marshalling. Once marshalling is completed the data stream is serialized,

transmitted and fina lly restored to its original data ordering on the o ther end

of the connec tion.





DCOM uses the mechanism of Remote Procedure Calls (RPCs) to

transpa rently send and rec eive informa tion be tween C OM c omponents (i.e.

clients and servers) on the same network. RPC allows system developers to

control remote execution of p rog rams without the need to d evelop spec ific

proc ed ures for the server. The c lient p rog ram send s a me ssage to the server

with the a pprop ria te a rguments and the server returns a message c onta iningthe results of the exec uted prog ram.

4.2 OPC Data Model

The information a va ilab le from the OPC server is orga nized into g roup s of

rela ted items for efficienc y. Servers can conta in multip le g roups of item s, and

a g roup c an either be:

• a public group, ava ilable for ac c ess by a ny c lient,

• a loc a l group, only ac cessible by the c lient tha t c rea ted it.

In Figure 4-2 below we expand our earlier example to include two PLC’s

connecting to a computer running one or more OPC servers maintaining

grouped information. The PLCs and the OPC servers com munica te using the

native PLC protocol while the OPC clients running on the other computers

acc ess the d ata in the O PC server via DCOM.

Figure 4-2: OPC Interaction

In the ea rlier exam ple, where a MODBUS/ TCP OPC server wa s c onnec ted to

a M ODBUS capab le PLC, we m ight configure a “ Wate rLeve l” g roup on a n

HMI with five mem bers:





5. “ SP” (setpoint),

6. “ CO” (control output),

7. “ PV” (proc ess va riab le),

8. “ LoAlarm” (Low Wate r Alarm),

9. “ HiAlarm” (High Water Ala rm).

The HMI could reg ister the “ WaterLevel” group with the SP, CO PV and Alarm

members; then read the current values for all five items either at timed

inte rva ls or by exception (i.e. when their va lues changed ). The HMI could a lso

have w rite acc ess to the “ SP” setp oint va riab le.

One significant advantage of OPC is that we do not have to directly deal

with the c ontrol device’ s internal architec ture. The softw are c an dea l with

named items and groups of items instead of dealing with raw registernumbers and da ta types. This a lso a llow s for an easier job add ing or

changing control systems, such as when migrating from a proprietary

protocol to an Ethernet-based protocol, without altering the client

applications.





5 OPC Standards & APIs

One of the challenges faced by end-users attempting to secure their OPC

deployments is the lack of useful information on the OPC API’s which is

relevant and particularly useful for non-developers to answer risk-related

questions. To address this prob lem, this sec tion provides an overview of themo st imp ortant OPC spec ifica tions.

For each OPC specification, we discuss typical uses and key functionality

that is provided by the specification. We also define important differences

among the specifications, and provide a short overview of the namespace

and object hierarchy to illustrate the type of data that is exchanged

betwe en O PC c lients and servers. The number in parentheses indica tes the

version of the OPC spec ifica tion tha t was reviewed .

5.1 OPC Data Ac cess (3.0)

OPC Da ta Ac c ess (OPC-DA) is the oldest o f the OPC spec ifica tions, orig inally

relea sed in 1998 as the “ OPC Spec ifica tion.” As the name implies, OPC-DA is

primarily used to provide real-time access to process control and

manufacturing data in a single format, regardless of its origin. An OPC-DA

server may a llow acc ess to the current va lues of PLC reg isters, DCS data

points, and readings from a variety of I/O sources or other software

applications.

OPC-DA provides access to the most current value for a given data point.

The d a ta itself may be c ached loc a lly within the OPC server or retrieved on

req uest from another app lication or device.Eac h da ta element is called a po int and has three at tributes:

• Value - the ac tual da ta b eing read or written.

• Quality - defines how trustworthy the data is (good, bad, uncertain)

and more detailed information on the status of the data, for

examp le, based on the link to the I/O device.

• Time Sta mps - in some cases the device’s protocol may provide this

a ttribute for ea ch va lue. If it do es not, the OPC server will assign the

time va lue b ased on its internal time c loc k.4

According to most industry users, OPC-DA offers good performance and

offers robust communications once it is configured, hence its widespread

popularity. It also supports the transfer of double precision real numbers

4 Rand y Kond or, “ Und ersta nd ing OPC: Basics For New Users” , Ind ustria l Ethe rnet Boo k, Issue

19:44, http :// ethe rnet.industrial-netwo rking.c om / op c / a rticledisplay.asp?id=32





which many process control protocols can not do without difficult

workarounds.

5.1.1 Example o f OPC-DA Usage

Continuing the water level control example from above, an HMI (the OPC

Client) would be able to read the current water level and control output inthe PLC via the OPC server. In addition, it would be able to control the set

point in the PLC via the OPC server. Generally the HMI would a lso monitor the

qua lity attribute of a ll data and would indica te if it lost c onta c t with the OPC

server by some method such as graying, zeroing, or flashing the stale values

in its user inte rface.

5.2 OPC Alarms & Events (1.10)

The OPC Alarms & Events (OPC A&E) spec ifica tion d efines an interface for

alarm monitoring and acknowledgment. Unlike DA, A&E does not provide a

continuous strea m of d ata betw een c lient a nd server, but instea d supp lies ava lue only when a spec ific event occurs. These va lues inc lude proc ess

alarms, operator actions, informational messages, and tracking/auditing

messages. Several types of O PC A&E c lients a re d efined in the spec ifica tion:

• Op erato r sta tions

• Event/a larm logging comp onents

• Event/alarm management subsystems

OPC A&E servers may be directly connected to the data sources (i.e.

com munica tion devices or loc a l app lica tions) or to loc a l or external OPC-DA

servers. The OPC A&E server may eva lua te input from single o r multip le da ta

sources to determine whether an event (such as a device failure) has

occurred and may report these events to one or more clients. OPC clients

are normally “notified” of alarm conditions and irregular events using a

technique known as “ callbacks ” . These a re m ec ha nisms for the server to

send messages to the client with information that the client has previously

registe red an interest in receiving. This is simila r to unsolic ited messages used

in other SCADA protocols suc h as Distribute d Network Protoc ol 3 (DNP3).

5.2.1 Example of OPC A&E UsageReturning to the water tank control example, if you want to be notified only

when a tank level reaches a high alarm limit you would use OPC A&E to

capture the event. In contrast, OPC-DA would allow you to sample the tank

level at a fixed interval (such as once per minute), but communications

would not b e p articularly affec ted by a ny alarm o r event in the p roc ess.





5.3 OPC Historical Data Ac cess (1.20)

One of the limitations of OPC-DA is that it only provides visibility into a

relatively short window of time, making it difficult to perform data

visualization, trending, fault prediction or root cause analysis. OPC Historical

Data Access (OPC-HDA) overcomes this problem by providing a flexiblemeans of accessing two kinds of data, namely raw and aggregate process

control data 5. Raw d a ta is a collec tion of individua l samp les of d a ta stored in

the server da tabase, while a gg reg a te d ata sources are summ ary va lues such

as minimum , maximum , differenc e, or average over a pe riod of time.

OPC-HDA does not specify (or limit) the type of data that may be accessed.

Servers a re a lso a va ilab le for rela tiona l databases suc h as Orac le a nd

Mic rosoft SQL server. Just as OPC-DA attempts to provide a c om mon open

interfac e to a numb er of different d ata sources, OPC-HDA does the same for

historians, many of which have proprietary interfaces.

5.3.1 Example of OPC-HDA Usage

Continuing w ith the w ate r tank examp le, an OPC HDA ap plica tion c ould be

used to log the ana log va lues in the system on a continuous basis a t the OPC

server, a llow ing for la ter rev iew o f the d a ta . This would then prov ide the HMI

to access a historical record of the water levels, control outputs and set

points.

5.4 OPC Data Exc hange (1.0)

OPC Data Exchange (DX) defines an industry-standard set of interfaces that

provide interop erab le data exchange and server-to-server comm unicationsbetween devices and controllers connected to Ethernet networks using

different protocols. It is an extension of the existing OPC data access

specification, providing an application independent interface suitable for

bo th fac tory and p roc ess automa tion6.

OPC-DX allows OPC-DA servers to directly exchange data without the

requirement of an intermediate OPC Client. Functionally, OPC-DX servers

implement many of the features of DA servers, but provide more reliable

delivery mec ha nisms. The best way to think of a n OPC-DX server is as an

OPC-DA server that can be configured to exchange data with other OPC-

DA servers. As is the case with o ther OPC servers, a c lient is still used toconfigure, control, and monitor this data exchange .

5 Iwa nitz, Franz and Lang e, Juerge n; OPC: Fundam enta ls, Imp lem enta tion a nd Ap plic at ion

(2nd Ed ition) Huethig Verlag , Heidelbe rg , 2002 (p 58)6Don Holley; OPC-DX Glues Field buses Toget he r, Industrial Ethernet Book, Issue 8:34,

http://ethernet.industrial-networking.com/opc/articledisplay.asp?id=24





Based on our survey resea rch, it is unc lear whether OPC-DX has been wide ly

adop ted within the industry. In terms of imp lem enta tion, ma ny vend ors have

separate data bridge software for exchanging data between different

packages. In m ost c ases, OPC-DX seems to be imp lem ented as a p lug-in fo r

an OPC server tha t a llows users to ea sily mirror va lues to anothe r OPC server.

5.4.1 Example of OPC-DX Usage

OPC-DX could be used to solve the interoperability problems when two

dissimilar real time communications protocols are being used in a system. For

example, perhaps a second water tank is controlled by a PLC that used

Ethe rnet/ IP rather tha n MODBUS/ TCP. OPC-DA would req uire a n intervening

OPC c lient with som e sort of “ reflec tor” softw are to a llow the two OPC servers

to communicate, while OPC-DX would allow the two OPC servers to

comm unicate direc tly.

5.5 OPC Security (1.0)

The OPC Sec urity Spec ifica tion is designe d to ensure tha t OPC Servers

implement operating system security APIs in a consistent manner. It defines

three sec urity levels:

1. Disabled Security – no sec urity is enab led.

2. DCOM Sec urity - use of DCOM settings to determine launch and

ac cess permissions as we ll as message privac y and integrity.

3. OPC Sec urity - OPC server acts as a reference monitor to access

vend or spec ific ob jec ts tha t a re exposed by the O PC Server.

The spec ifica tion document provides som e background information defining

com mo n sec urity conc ep ts (such as authentica tion, authoriza tion, referenc e,

etc.) as well as some low-level information on how to implement the DCOM

security API. However, this specification provides little useful information for

end-users and provides minimal information on OPC threats and

vulnerabilities, nor does it include host or network security configuration

practices for OPC. Based on our research, it is unclear how many vendors or

users actually implement the security standard. Web research showed that

only Northern Dynamics, Yokogawa, Unicorn, and Novatek claim to support

the stand ard.

5.6 OPC XML-Data Ac cess (1.01)

EXtensible Ma rkup Language (XML) Web Services are b ec om ing the

standard method for exchanging data between enterprise applications and

are increasingly found in process control environments. OPC XML-DA was

relea sed in 2003 a fter several yea rs of d evelop ment , and p rovides a Simp le





Ob jec t Ap p lica tion Protoc ol (SOAP) inte rface to OPC DA 2.0/ 3.0 ob jec ts. This

allows client applications to be written in Java, Perl, Python, and other

languages tha t support SOAP.

SOAP and XML Web Services use Hyp erText Transfer Protoc ol (HTTP) and

HyperText Transfe r Protocol over Sec ure Socket Layer (HTTPS) as their

underlying transport mechanisms and provide a platform neutral

architecture that is more suitable for Internet-based traffic, as compared to

tec hnolog ies suc h as DCOM or Comm on Ob jec t Req uest Broker Architec ture

(CORBA). However, due to possible performance limitations, OPC XML-DA is

unlikely to be used for rea l time app lica tions, although it is com monly used as

a bridge between the enterprise and control network. Furthermore, only

OPC-DA functionality is provided in XML-DA, so it can be best seen as a

transitional pa th to a true Web Services architec ture tha t is currently under

deve lop ment with OPC-UA (Unified Architec ture) p rojec t.

5.6.1 Example of OPC XML-DA UsageOPC XML DA can be imp lemented on a ny device supporting HTTP and XML,

a llow ing limited OPC c om munica tions to non-OPC awa re system . Continuing

the water tank example, OPC-XML data access would allow clients that

could formulate SOAP XML requests over HTTP to retrieve info rmation a bout

the w ater ta nk level. These would typica lly be ente rp rise softwa re

app lica tions tha t do not typica lly support OPC

5.7 OPC Unified Architecture (RC 1.00)

OPC Unified Architec ture (OPC-UA) reflec ts Mic rosoft 's goa l of retiring DCOM

in favo r of .NET and movem ent towa rds Servic e O riented Architec tures. TheUA specification will ultimately consist of 13 parts, several of which have not

been released publicly (even in draft form) at the time of writing. As the title

suggests, OPC-UA integrates the functionality of previous specifications

(OPC-DA, OPC-HDA, OPC A&E, OPC-DX, etc .) into a single integrated

namespace. This will address the API d ifferences in the c urrent spec ifica tions

that were developed indep endently of eac h other.

OPC-UA abandons COM/DCOM in favor of two different transports:

SOAP/ HTTP(S) and a b inary message enc od ing sc hem e tha t operates d irec t

com munications on top of TCP. Due to the known p erforma nc e limita tions of

XML, the binary message encoding scheme was provided to allow highperformance data exchange, especially on embedded devices that

maintain real-time communications.

It is premature to assess the security of OPC-UA relative to DCOM-based

OPC, since the OPC-UA security APIs are still under development. However,

since there is now a much greater awareness in the OPC Foundation, the

OPC vendors, and Microsoft for the need for security, there is little question





tha t .NET will p rovide a more sec ure founda tion tha n COM/ DCOM. It will a lso

ma ke deve lop me nt o f OPC C lients and Servers on non-Microsoft p la tforms

muc h easier. OPC-UA a lso elimina tes DCOM firew all issues, but this does not

eliminate all security concerns. OPC-UA will expose a different attack surface

to an equally hostile set of threats in an area where active vulnerability

research is ongoing, with new web application threats and vulnerabilitydiscovered on a daily basis.

Only time will tell whether vendors can implement OPC web services

securely, and whether end-users can harden the application infrastructure.

Although vendors will most likely use existing XML stacks, the binary encoding

routines a re o f pa rticular concern, espec ially in em bed ded controllers, which

have been espec ia lly p rone to parsing errors in the p ast.





6 OPC Internals - Relevant OPC and Windows

Components

The previous ma teria l in this white p aper provided an overview of OPC, but

to fully understand and address the security problems end-users may face in

OPC deployments, more detail is needed. In this section we go beyond the

high-level concepts presented in the specifications, and analyze the

app lica tions, proc esses, and system com ponents running b ehind the scenes.

To b eg in with, it is important to understand tha t OPC Servers are not

monolithic applications, but are made up of a number of related software

com po nents. Som e of these c omponents are p art of the Windo ws op era ting

system, while others were developed and released by the OPC Foundation.

Still othe rs are server app lica tions develop ed by the OPC vendors. Finally,

custom OPC applications may be developed by end-users using

prog ramming languages such as Visua l Basic.

In most c ases an OPC Server consists of a number of sep ara te c om ponents:

• A service tha t is the a c tua l “ Engine” .

• A Graphica l User Interfac e (GUI) for interac ting w ith a nd configuring

the “ Engine” .

• DLL's implem enting the c od e c a lled by the “ Eng ine” .

• One o r mo re d rivers for com munica ting to the control device o ver a

non-OPC p rotoc ol (suc h as MODBUS); these may be impleme ntedas a DLL or as a sep arate service.

In addition to server or client specific components, there are a number of

ge neral purpose p ieces of softw are tha t we w ill desc ribe b elow.

6.1 Proxy / Stub DLLs

The OPC Found a tion p rovides a set o f Dynamic Link Libraries (DLL) tha t d efine

the c lient a nd server OPC interfac es. These c om ponents marsha l and un-

ma rsha l interfac e p ointers and the m ethod parame ters. The “ proxy” is the

client-side code, while the "stub" is the server side marshalling code thatinterac ts with the O PC server cod e d evelop ed the server deve lop er. Both the

proxy and the stub are generated from the Interface Definition Language

(IDL) w ithin the OPC Sta ndard.

In the past, vendors distributed their own versions of these files, but this led to

app lica tion inc om patibility and version ma nagem ent issues. To solve th is

problem, the OPC Foundation chose to distribute a single “approved”





version of these DLLs. Tod ay, a ll vendors must inc lude these com ponents with

their OPC servers. If a security bug were discovered in one of these DLL’s, it

would affec t a ll OPC imp lementa tions, and the OPC Founda tion w ould have

to issue new versions of the proxy stub libraries to pa tc h the vulnerab ility.

6.2 OPC Server Browser

The OPC Server Brow ser (typ ica lly imp leme nted by the OPCEnum.exe

executable), is a DCOM component that is used by the client software to

retrieve information about OPC server applications that may be active on a

given host. This com ponent exposes interfac es tha t a llow c lients to query the

Com po nent Ca tegory Manag er (CCM) in order to find out w hat OPC servers

are ava ilab le. The OPC Server Brow ser a llow s rem ote c lients to determine

which OPC Servers are ava ilab le without having to d irec tly browse the host’ s

reg istry, as was done in early OPC servers. The OPC Server Browser listens on

an a rbitra ry TCP port loc ated above 1024. It is a lso refe rred to as the "OPC

Disc overy Service Exec uta b le."

6.3 Windows Com ponents

Given OPC’s reliance on DCOM, it should come as no surprise that OPC

applications heavily rely on a number of Microsoft components for

configuration and operation. Like most Windows applications, OPC and

DCOM make extensive use of the Windows registry. When an OPC server is

installed, it often adds entries to the Windows registry. Here are some typical

entries:

1. Program Identifier (ProgID) - This string is defined as

"Manufa c turer.Serve rName" for OPC servers. By b rowsing the reg istry it

is possible to see which OPC applications are installed on a given

system. The prog ram identifier ent ry must a lso conta in the sub-keys

"OPC" and "Class Identifier (CLSID)."

2. Class Ident ifier (CLSID) - This is a sta ndard 128-b it Globa lly Unique

Identifier (GUID) which identifies all COM objects. Further Category

Identifiers (CATID) a re sto red as sub -keys within the CLSID and define

which of the OPC Spec ifica tions are a c tive. Each OPC vendor has a

unique CLSID and a unique value for eac h application

As noted earlier, older versions of OPC clients (prior to the inclusion of the

OPC Server Brow ser) b row sed the reg istry direc tly to identify ava ilab le server

applications. In some cases this required registry settings to be modified on

the c lient host to b e a b le to identify the server app lica tions.





Based on in-lab observations of a number of OPC systems, it turned out that

OPC Servers and Clients require a surprisingly small set of Windows system

services for op eration. These include:

• OpcEnum - OPC req uires this service to be running so rem ote c lients

can determine w hich OPC Servers are running on a host.

• Rem ote Proc ed ure Ca ll - req uired by OpcEnum.

• Server Proc ess – OPC servers are typ ica lly sta rted as a servic e but a

GUI c lient is used to c onfigure and control the proc ess.

Of c ourse the und erlying netw ork-rela ted services (suc h as IPSEC Services

and DNS Services) are typica lly needed a long with the RPC a nd COM+

services. As well, we found tha t the “ Plug and Play” Window s service must b e

enabled for many OPC applications to perform reliably. A more detailed list

for system configuration purposes is supplied in White Paper 2.

6.4 A Simple OPC Server

To he lp understand how these c om po nents fit tog ether and how they imp ac t

the configuration o f a host w e selec ted a simp le OPC server ca lled DSxP7 as

an example. This softwa re p rovides a simulat ion o f a "rea l-wo rld " OPC server

that clients can connect to for testing purposes. Installing this small server

does the follow ing to a Window s host:

1. Creates two d irec tories:

• C:\ Prog ram Files\ DSxP• C:\ Prog ram Files\ DSxP\ DSxPOp c Simulato r

2. Plac es four files into the ma in direc tory of the server:

• C:\ Program Files\ DSxP\ DSxPOp c Simula to r\ DSxPOp c Simula to r.exe

• C:\ Prog ram Files\ DSxP\ DSxPOp c Simulato r\ op cdata .xml

• C:\ Program Files\ DSxP\ DSxPOp c Simula to r\ unins000.exe

• C:\ Prog ram Files\ DSxP\ DSxPOp c Simulato r\ unins000.da t

3. Sets up the Sta rt menu:

• C:\ Doc uments and Settings\ All Users\ Sta rt M enu\ Prog ram s\ DSx

• C:\ Doc ume nts and Sett ings\ All Users\ Sta rt

Menu\ Program s\ DSxP\ DSxPOp c Simulato r.lnk

• C:\ Doc ume nts and Sett ings\ All Users\ Sta rt

Menu\ Prog rams\ DSxP\ DSxPOp cSimulato r.p if

7 http://www.dsxp.com





4. Places a link on the desktop, with a p rog ram information file:

• C:\ Doc uments and Settings\ op c ad min\ Desktop\ DSxPOp c Simulat or.lnk

• C:\ Docum ents and Settings\ op ca dm in\ Desktop \ DSxPOp c Simulator.pif

5. Crea tes a reg istry entry:

• HKEY_LOCAL_MACHINE\ SOFTWARE\ CLASSES\ DSXPOpc Simula to r.TSxOp c Simul

a tor.1Softw are\ Microsoft\ Window s\ Current Version\ Uninsta ll\ DSxPOp c Simula

tor_is1

This simp le examp le illustrates som e of the changes tha t running a n OPC

service c an have on a Window s host d evice. Typica lly, the more full-func tion

OPC applications would invoke two or three times the number of entries or

chang es noted here.





7 Conclusions

As we have discussed in the white paper, OPC is a software interface

technology designed to facilitate the transfer of data between industrial

control systems, HMIs, sup ervisory systems and enterprise systems suc h a s

historical databases. It was developed in response to the need for astandardized method for allowing different control systems to interface with

ea ch other. Tod ay it has grown to be the lead ing te chnology for integ ra ting

d ifferent co ntrol prod uc ts.

Despite claims to the contrary, OPC is not just used for data management

purposes on the plant floor, but instead is a critical component of many

production systems. Over a quarter of the end-users reported that loss of

OPC communications would result in a loss of production. In addition,

approximately 20% of the companies reported deploying OPC over the site

business network, enterprise network or corporate Intranet and

approximately 10% used OPC over the Inte rnet. This highlights the urgentneed for bette r OPC sec urity guida nce.

The c ha llenges of sec uring OPC d ep loyme nts a re c lear. The inherent

architectural complexity of OPC, the default security posture of many OPC

servers, and the lack of unambiguous guidance with regard to security all

contribute to the difficulties of securing OPC deployments. As well, OPC’s

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 tha t c an be a pp lied to OPC c lients and servers. We will discuss these

solutions in the white p apers # 2 and # 3.





Glossary

ACL - Access Control List: List of rules specifying access privileges to network

resources.

API - Application Programming Interface: The spec ifica tion of the interfac ean a pp lica tion must invoke to use certain system fea tures.

CATID - Ca tegory Identifier: Spec ifies the a c tive OPC spec ifica tions.

CCM - Component Category Manager: A utility that creates categories,

places components in specified categories, and retrieves information about

categories.

CERN - Conseil Europeen Recherche Nucleaire: European Laboratory for

Partic le Physics.

CIFS - Common Internet File System: Updated version o f SMB.

CIP - Common Industrial Protocol: CIP is an open standard for industrialnetwork technologies. It is supported by an organization called Open

Devic eNet Vend or Assoc ia tion (ODVA).

COM – Component Object Model: Microsoft’s architecture for software

com ponents. It is used for interprocess and interapp lica tion c om munica tions.

It lets com ponents built b y different vendo rs be c ombined in an app lication.

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

CORBA - Common Object Request Broker Architecture: Architecture that

enables objects, to communicate with one another regardless of the

programm ing langua ge and op era ting system be ing used .

CSP - Client Server Protocol: An Allen-Bradley protocol used to communicate

to PLCs over TCP/ IP.

DDE – Dynamic Data Exchange: A mechanism to exchange data on a

Microsoft Windows system.

DCOM – Distributed Component Object Model: This is an extension to the

Component Object Model that Microsoft made to support communication

am ong ob jec ts on d ifferenc e c om puters ac ross a netwo rk.

DCS – Distributed Control System: A Distribute d Co ntrol System a llows for

remote human monitoring and control of field devices from one or more

operation centers.

DDE - Dynamic Data Exchange: An interprocess communication system built

into Windows systems. DDE enables two running applications to share the

sam e d ata.





DLL - Dynamic Link Libraries: A file containing executable code and data

bo und to a program at loa d time or run time , ra ther than during linking.

DMZ - Demilitarized Zone: A small network inserted as a "neutral zone"

betw een a trusted priva te netwo rk and the o utside untrusted netw ork.

DNP3 - Distributed Network Protoc ol 3: A protoco l used betw een c omp onentsin p roc ess automation systems.

DNS – Domain Name System: A distributed database system for resolving

huma n rea dab le na mes to Internet Proto col ad dresses.

EN - Enterprise Network: A p rivate com munica tion netw ork of a firm.

ERP - Ente rprise Resourc e Planning : Set o f ac tivities a business uses to

manage it’s key resources.

GUI - Graphical User Interfac e: Graphica l, as op po sed to textual, interfac e to

a c omp uter.

GUID - Globally Unique Identifier: A unique 128-bit number that is produced

by the Windows operating system and applications to identify a particular

com po nent, ap p lication, file, data ba se entry or user.

HMI - Human Machine Interface: This inte rfac e enab les the inte rac tion of

man and m ac hine.

HTML - Hypertext Markup Lang uag e: The authoring softw are language used

on the Internet's World Wide Web .

HTTP - HyperText Transfer Protocol: The protoc ol used to transfer Web

doc uments from a server to a brow ser.

HTTPS - HyperText Transfer Protocol over SSL: A secure protocol used to

transfer Web doc uments from a server to a b row ser.

IIS - Internet Informa tion Serve r: Mic rosoft ’ s we b server.

IDL - Interfac e Definition Langua ge : Lang uag e for desc ribing the interfac e of

a software comp onent.

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

netw ork tra ffic .

IPX - Internetwork Packet Exchange: A networking protocol used by the

Novell Incorporated.

IPSEC – Internet Protocol SECurity: An Internet standard providing sec urity at

the ne twork layer.

IP - Internet Protocol: The standard p roto col used on the Internet tha t defines

the da tag ram format and a best effort pac ket de livery service.

I/O - Input/ Output: An interfac e for the input a nd output of informa tion.





ISA - Instrumentation, Automation and Systems Society: ISA is a nonprofit

organization that helps automation and control professionals to solve

tec hnica l instrumenta tion prob lem s.

IT - Information Tec hnology: The deve lop ment, insta lla tion and

imp lem enta tion o f ap p lica tions on c om puter system s.

LAN - Loc al Area Network: A com puter network that c overs a sma ll area .

LM - LAN MANager: An old Microsoft Windows authentication protocol.

LDAP - Lightweight Directory Access Protocol: Protocol to access directory

services.

MBSA - Microsoft Baseline Security Analyzer: A tool from Microsoft used to

test a system to see if Mic rosoft best p rac tices are b eing used .

MIB - Managem ent Information Base: The d atabase tha t a system running an

SNMP agent maintains.

MODBUSA communications protocol designed by Modicon Incorporated for

use with its PLCs.

NETBEUI - Ne tBIOS Extend ed User Interface: An enhanced version of the

NetBIOS protocol.

NetBIOS - Network Basic Input Output System: A de facto IBM standard for

ap p lications to use to com munica te over a LAN.

NTLM – New Tec hnolog y LAN Manager: A challenge - response

authentication protocol that was the default for network authentication for

Mic rosoft Window s New Tec hno logy (NT) operat ing systems.

OLE – Objec t Linking and Emb edding: A precursor to COM, allowing

ap plica tions to share da ta a nd manipulate shared da ta.

OPC – OLE for Proc ess Control: A standard based on OLE, COM and DCOM,

for acc essing p roc ess c ont rol informa tion on Microsoft Window s systems.

OPC-A&E - OPC Alarms & Events: Standards c rea ted by the OPC Found a tion

for a larm monitoring and ac know led gement.

OPC-DA - OPC Data Access OPC-DA: Standards c rea ted by the OPC

Foundation for accessing real time data from data acquisition devices such

as PLCs.OPC-DX - OPC Data Exchange: Standards c rea ted by the OPC Found a tion

to a llow OPC-DA servers to excha nge data without using an OPC c lient.

OPC-HDA - OPC Historical Data Access: Standards c rea ted by the OPC

Foundation for com munica ting d ata from de vices and app lica tions that

provide historica l data .





OPC-UA - OPC Unified Architecture: A standard being created by the OPC

Foundation to tie together all existing OPC technology using the .NET

Architecture.

OPC XML-DA - OPC XML Data Access: Standards c rea ted by the OPC

Found ation for accessing rea l time da ta , carried in XML me ssages, from da ta

acquisition d ev ices suc h a s PLCs.

OPCENUM – OPC ENUMerator: A service for enumerating OPC servers.

PLC – Programma ble Log ic Controller: A PLC is a small dedicated computer

used for controlling industria l machinery and proc esses.

PCN - Process Control Network : A communications network used to transmit

instruc tions and data to c ontrol devices and othe r industria l eq uipment.

PROGID - Program Identifier: A string that identifies the manufacturer of an

OPC server and the name of the server.

RPC – Remote Procedure Call: A standard for invoking code residing onano ther comp uter ac ross a netwo rk.

RSLinx Softw are p roviding p lant floo r device c onnec tivity for a w ide va riety of

applications.

SCADA – Supervisory Control And Data Acquisition : A system for industrial

control consisting of multiple Remote Terminal Units (RTUs), a c ommunica tions

infrastruc ture, and one or mo re Control Comp uters.

SID – Security Identifier: A unique name that is used to identify a Microsoft

Windows ob jec t.

SP - Service Pack: A bundle of softwa re up date s.

SPX - Sequenced Packet Exchange: A transport Layer protocol used by

Novell Incorporated.

SMB - Server Message Block: A Microsoft netwo rk ap p lication-level p rotoc ol

used between nodes on a LAN.

SNMP - Simple Network Management Protocol: A protocol used to manage

devices suc h as route rs, switches and hosts.

SOAP - Simple Object Access Protocol: A protocol for exchanging XML-

based m essages using HTTP.SSL - Secure Socket Layer: A de facto standard for secure communications

c rea ted by Netscap e Inco rpo rated .

TCP - Transmission Control Protocol: The standard transport leve l proto col tha t

provides a reliab le stream service.

UDP - User Data gram Protoc ol: Connec tionless netw ork transport p roto col.




URL - Uniform Resource Locator: The address of a resource o n the Internet .

WS-Security - Web Services Security: A c om munica tions p rotocol providing a

mea ns for ap p lying sec urity to Web Services.

XML - eXtensible Markup Language: A general-purpose markup language

for creating special purpose markup languages that are capable ofdesc ribing ma ny different kinds of d ata .


Iam Opc Security Wp1

Documents

Transcript of Iam Opc Security Wp1