opc security wp3

8/14/2019 OPC Security WP3

1/54

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 Whitepaper #3

Hardening Guidelines for OPC Hosts

PREPARED BY:

Digital Bond

British Co lumb ia Institute o f Tec hno logy

Byres Research

November 13, 2007

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

OPC Security Whitepaper #3

Hardening Guidelines for OPC Hosts


2/54


3/54

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

Table of Contents

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

1 Introduc tion ....................................................................................................... 4

1.1 The Issue s........................................................................................................ 41.2 Organiza tion of OPC White Paper Series..................................................6

1.3 Study Methodolog y......................................................................................6

1.4 Limita tions of th is Study ................................................................................ 7

2 Hardening Strateg y for OPC Hosts .................................................................. 9

3 General Windows Hardening Rec om mendations ...................................... 11

3.1 Patc h Mana gement fo r OPC Hosts.........................................................11

3.2 Minimum Required Services......................................................................12

3.3 Limiting User Privileges................................................................................ 13

3.4 Limiting Netw ork Access............................................................................14

3.4.1 Crea ting the Filter Lists........................................................................143.4.2 Crea ting the Bloc k Ac tion .................................................................16

3.4.3 Crea ting the Security Policy .............................................................. 16

3.4.4 Assigning the Security Policy .............................................................17

3.5 Protec ting the Registry...............................................................................17

3.6 Some Spec ia l Considerations for XP Systems.........................................19

4 OPC/ DCOM/ RPC Hardening Rec om mendations ....................................... 21

4.1 OPC Hardening Recommend ations ....................................................... 21

4.2 DCOM Hardening Recommend a tions ...................................................22

4.2.1 Controlling the Authentica tion Leve l...............................................24

4.2.2 Controlling the Loc ation .................................................................... 254.2.3 Mana ging DCOM Permissions...........................................................25

4.2.4 Limiting RPC Ports and Protocols......................................................27

4.2.5 Set ting the OPC Ap plica tions Ac count ......................................... 29

4.3 RPC Hardening Recommend a tions........................................................29

4.3.1 Restric ting Transport Protocols to TCP..............................................29

4.3.2 Restric ting TCP Port Rang es...............................................................30

4.4 More Spec ia l Considerations for XP Syste ms..........................................32

5 OPC Host Hardening Verification.................................................................. 34

5.1 Wind ows Service and Open Port Determination ..................................34

5.2 Wind ows Eve nt Log Ana lysis.....................................................................355.3 Vulnerab ility Scanning ...............................................................................36

5.3.1 Mic rosoft Security Baseline Ana lyzer 2.0..........................................36

5.3.2 Nessus Vulnerability Scanner............................................................. 37

5.3.3 Aud it Files fo r Nessus Vulnerability Scanner.....................................39

6 A Summary of OPC Host Hardening Prac tises............................................. 40

6.1 An Ac tion Plan for Hardening OPC Hosts...............................................40

Downloaded from www.PAControl.com


4/54

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

6.2 Summary of High Risk Vulnerab ilities and Mitiga ting Good Prac tices41

6.3 Some Fina l Tho ug hts...................................................................................43

7 Areas for Mo re Resea rch in OPC Sec urity.................................................... 44

7.1 Firewa ll and Netw ork Related Solutions for OPC Security....................44

7.2 OPC Tunne lling Solutions fo r Security Robustness.................................. 44

7.3 Network Intrusion Detec tion/ Intrusion Prevention Signatures..............44

7.4 Enhanc ements to Netw ork Vulne rab ility Scanners............................... 44

7.5 Resea rch Impleme nta tion Vulnerab ilities in OPC Components......... 44

7.6 Use of Domain Isolation in Control Environm ents..................................45

Glossary .................................................................................................................. 46



5/54

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

Executive Summary

In rec ent years, Supervisory Control 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 less isolation

from the outside world , resulting in the increased risk of c ybe r-based a tta cks

imp ac ting industrial p rod uction a nd huma n sa fety.

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

spread adop tion o f OLE for Proc ess Co ntrol (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

softw are. Unfortunate ly, sec urely dep loying OPC app lica tions has p roven tobe a challenge for most engineers and technicians. While OPC is an open

protoc ol with spec ifica tions free ly ava ilab le, eng ineers must wade through a

large amount of very detailed information to answer even the most basic

OPC sec urity 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 technology and how it is actuallydep loyed in industry

2. Outline the risks and vulnerabilities incurred in deploying OPC in acontrol environment

3. Summ arizes current good prac tices for sec uring OPC app lica tionsrunning on Window s-ba sed hosts.

The w hite p aper you are now rea d ing is the last of the three , and outlines

how a server or workstation running OPC can be secured in a simple and

effec tive ma nner. Typica lly this hardening must be cond uc ted in seve ra l

sta ges. First the op erating system (typica lly Window s) needs to be loc ked

dow n in such a ma nner that w ill ma ke it less susc ep tible to c om mo n O/ S-

based a tta cks. This involves five steps which a re:

1. Ensuring up-to-da te pa tching of the op erating system and app licationson the OPC ho st;

2. Limiting services to the req uired minimum for OPC;



6/54


3. Defining user ac counts and privileges;4. Limiting network ac cess via the Window s Firew all;5. Protec ting the Window s Reg istry.

Next, the specific OPC components must be hardened using the OPC and

DCOM configuration tools found in Windows. Unfortunately, completing thisstage successfully is more complex; our testing indicated that there are a

number of OPC applications that do not properly follow the DCOM

specifications for Windows software. As a result, several of the steps

sugg ested below ma y cause a ma lfunction of these OPC a pp lica tions. Thus

we suggest the OPC user consider the seven steps listed below as a menu to

choose from ra ther than a list o f una lterab le req uirem ents:

1. Controlling the authentica tion levels for various OPC a c tions;2. Controlling the loc ation o f va rious OPC ac tions;3. Ma naging the DCOM Permissions;4. Limiting p rotoc ols used by DCOM/ RPC a nd set ting a Sta tic TCP port;5. Set ting approp riate OPC servers ac counts;6. Restric ting Transport Protocols for RPC;7. Restric ting TCP Port Rang es fo r RPC.

Of these seven, perhaps the most unusual is step 4, as it gives the end-user

the op portunity to address one of the mo re vexing prob lem s in OPC sec urity,

name ly the prob lem o f dynam ic po rt alloc a tion. Unfortunate ly it was a lso

the solution most likely to cause issues with OPC software, since it wasapparent that not all vendors of OPC products respect the static setting of

port numbers. Thus we a lso p rovided step 7 as a lternative m ethod for po rt

restric tion, in c ase task 4 does not work co rrec tly on your OPC softwa re.

Next, the system needs to be tested to ensure these changes still allow all

OPC ap plications to function c orrec tly. Since we found a number of c ases

where OPC vendors were not respecting DCOM security settings and

requirements, this testing is critical before any security settings are deployed

on live p rod uc tion systems.

Lastly, verification of the fortifying effort is required to ensure no serious

sec urity holes have been left open. This inc ludes the follow ing steps:

1. Window s Servic e and Op en Port Determination2. Wind ows Event Log Ana lysis3. Vulnerab ility Scanning

These stage s a re expanded upon in a deta iled Ac tion Plan for Hardening

OPC Hosts within this rep ort. Spec ific examples are a lso p rov ided for ea c h



7/54


ta sk. In all, we b elieve by follow ing these guidelines, the typ ica l controls

tec hnic ian w ill be ab le to c rea te a mo re sec ure a nd robust OPC d ep loyment

on their plant floor and OPC can continue to grow as a valuable solution in

industria l da ta c om munications.



8/54


1 IntroductionThis rep ort is the third of three white p apers outlining the findings from a stud y

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

Co lumb ia Institute of Tec hno log y (BCIT). The ob jec tive of this stud y was to

c rea te a series of simp le, authorita tive white papers tha t summ arized currentgood practices 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, its basic components and how it is

ac tually dep loyed in the real world .

OPC Sec urity White Paper #2 OPC Exposed : What are the risks andvulnerab 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 IssuesIn rec ent years, Supervisory Control 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 Comp onent Ob jec t Model (DCOM) interfac e of the RPC (Rem ote

Procedure Call) service. Due to its vendor-neutral position in the industrial

controls market, OPC is being increasingly used to interconnect Human



9/54


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 a s one of the few universa l protoc ols in the industria l controls

world, ad ding to its widespread ap pea l.

Many readers will be aware that the OPC Foundation is developing a new

version of O PC (c a lled OPC Unified Architec ture or OPC-UA) tha t is based on

protocols other than DCOM1. This is in conjunc tion with Microsoft's goa l of

ret iring DCOM in favour of the more sec ure .NET and service-oriented

architectures. Once most OPC applications make this migration from the

DCOM -ba sed a rc hitec ture to a .NET-ba sed a rchitec ture, industry will have

the opportunity for much better security when it comes to OPC, but also a

new set of risks.

Unfortunately, based on our experience in the industry, it may be a number

of yea rs befo re many co mpanies ac tua lly c onvert their systems. So, since

DCOM-based OPC is wha t is on the p lant floo r tod ay and will c ontinue to see

use for years to come, we focused our investigation on how to secure this

type of OPC.

Our initial research showed two main areas of security concern for OPC

dep loyme nts. The first (and most often quoted in the pop ular press) is tha t the

underlying protocols DCOM and RPC can be very vulnerable to attack. In

fac t, viruses and wo rms from the IT wo rld may be inc rea singly foc using on the

underlying RPC/ DCOM proto cols used by OPC, as note d in this a tta ck trend s

d iscussion:

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 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.2

At the same time, news of the vulnerabilities in OPC are starting to reach the

mainstream press, as seen in the March 2007 eWeek article entitled Hole

Found in Protocol Handling Vital National Infrastructure 3. 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.

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, A tta c k Trends QUEUE Ma gazine, Assoc iation o f Co mp 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 :// ww w.ew ee k.c om / a rticle2/ 0,1759,2107265,00.asp , Ma rch 23, 2007



10/54


11/54


OPC 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 andguidelines.

2. Ascerta ining potential threa ts and vulnerab ilities in OPC systems Identifying what operating system configuration issues exist in

typical OPC deployments.

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

3.

Creating recommendations for mitigating potential threats andvulnerabilities

Determining what could be done to secure the underlyingop eration system without impac ting the OPC func tionality.

Determining what could be done to secure RPC/DCOMcom 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 recom me nda tions

Lab testing a ll rec om mendations in a typica l OPC environm ent a ndmodifying our rec ommenda tions ac c ord ingly.

1.4 Limitations of this StudyIt 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 and

prac 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 reaof 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.

It is also important to understand that this document details nearly every

security measure that could be used to harden OPC installations. In order to



12/54


determine which of the mentioned countermeasures and strategies are

feasible and advisable for a specific OPC deployment, a risk assessment

should be conducted first. In addition, the industrial environment should be

checked to ensure all design elements will function flawlessly with the

prop osed sec urity counte rmea sures. Som e suggested countermea sures will

not work with -- or a re no t advisab le fo r -- every OPC insta llation.

Finally, we cannot guarantee that following our recommendations will result

in a completely secure configuration. Nor can we guarantee these

recommendations will work in all situations; some modifications may be

required 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.



13/54


2 Hardening Strategy for OPC HostsBuild ing on the ma teria l from the previous white p apers, this rep ort at tem pts

to detail all security measures and good practises that could be used to

harden OPC hosts4. We suggest the OPC user consider the mitigations listed

in this reports as a menu to choose from rather than a list of unalterablerequirements.

Typ ica lly this ha rdening should be c onduc ted in four sta ges. First, the

Windows platform itself needs to be locked down to make it less

susceptible to common Windows-based attacks, yet still allow OPC

app lica tions to func tion. Then the spec ific OPC c om ponents need to be

hardened using the OPC c onfigura tion too ls found in the Window s op erating

system. Next the system needs to be tested to ensure these changes still

a llow a ll OPC app lica tions to func tion correc tly. We found a numb er of ca ses

where OPC vendors do not respect DCOM security settings and

requirements, so the test stage is critical before any security settings aredeployed on live production systems. Lastly, verification of the fortifying effort

is req uired to confirm no serious sec urity holes have b een left open.

For the mo st p art these c onfigura tion guidelines will ap p ly to both c lients and

server hosts. The c a llbac k mechanism used by OPC essentia lly turns the OPC

client into a DCOM server and the OPC server into a DCOM Client. In our

examples we focus on OPC servers, but to take full advantage of these

recommendations they should be followed on all nodes that contain either

OPC servers or OPC c lients. Several sec tions d isc uss c lients spec ifica lly.

It is a lso imp ortant to note the exam p les show n below are p rimarily based onhosts running Windows XP/ SP2 or Windows Server 2003/SP1 (o r later). Earlier

versions of Windows can still take advantage of many (but not all) of these

suggestions, but will be c onsiderab ly more d iffic ult to c onfigure. Thus if at a ll

possible, a first step should be to upgrade any OPC host platforms to these

new er operating system versions.

Finally, these examples were performed and lab tested in a workgroup

setting; as a result, slight modifications may be required in domain-based

env ironments. In rea l-life industria l set tings dom a ins may be b enefic ial as they

provide the a bility to a pp ly these recom mendations uniformly ac ross a group

of hosts via group policy. In workgroup environments all recommendationswill have to be deployed individually on the host machines, increasing the

administrative effort and the chance for error. In addition, we are aware of

4 Please note that this report only focuses on OPC host security and does not attempt to

detail good practices for securing the network components (such as firewalls) for OPC

traffic. We hop e to offer this information in a fourth white pa per in 2008. In the m ea n time,

interested rea ders should c onsider the Mic rosoft Tec hnica l Article Using Distributed CO M

with Firew a lls by Michael Nelson a t http://msdn2.microsoft.com/en-us/library/ms809327.aspx



14/54


some possible domain specific security features that can be added, but

these were beyond the scope of this report and are not discussed in this

document.



15/54


16/54


17/54


Protec ted Storage (Automa tic ) Rem ote Proc ed ure Ca ll (RPC) (Autom atic) Sec urity Ac counts Ma nag er (Automa tic ) Sec urity Center (Automatic) (Req uired by XP) Server (Automa tic )

As we ll, som e O PC a pp lica tions req uire add itiona l servic es to be e nab led to

remain functional. For example, if the OPC application does not use the

OPCEnum com ponent (and thus needs to rem ote ly b row se the reg istry10) the

follow ing servic es are a lso req uired :

Comp uter Brow ser (Automa tic ) Remote Registry (Automatic)

While not stric tly a service, File and Printe r Sha ring should be d isab led . This isdo ne via the netwo rk connec tions pane l.

Again, since OPC dep loyments can wide ly va ry, it is essential that the effec ts

of disabling any service be tested on a non-critical offline system before

be ing dep loyed in a live control system.

3.3 Limiting User Privileg esIn most control environments, the day-to-day operation of OPC-based

applications does not require a highly privileged account. On the other

hand, the configuration of OPC applications often does. Unfortunately, inma ny system s we see the highly privileg ed acc ount sett ings being the norm,

exposing the system to num erous sec urity issues.

To address this, we rec om mend OPC a dministra tors c rea te two a ccounts,

one for day-to-day operations and one for configuration.11 Configure these

accounts as follows:

Crea te a n ac c ount (e.g. opc user) and set it to be a low privileg eaccount- This will be used for the normal execution o f OPC c lient

and server app lica tions. When the op c user account is c rea ted it

should b e a dded as a memb er of the Users group .

Crea te a n ac c ount (e.g. opc ad min) and set it to be a highprivileg e ac c ount This ac count w ill only be used for infrequent

10 Rem ote ly b row sing the registry is no longer a reco mm end ed prac tice b y the OPC

Found at ion. How eve r som e olde r ap p lic at ions ma y still req uire rem ote browsing to function

correctly.11 http: / /www.opcconnect.com/dcomcnfg.php



18/54


configuration c hange s and for the initial insta lla tion o f the OPC

softwa re. When the op cad min user is c rea ted it should be ad de d as

a m em ber of the Administrato rs group. It is often simp lest to rename

the existing ad ministrato r ac count to op c ad min.12

Finally the Guest a ccount should b e d isab led and rob ust p asswo rds (a mix ofletters, numbers and spec ial cha rac ters and not found in a d ictiona ry) should

be used for a ll accounts.

3.4 Limiting Network AccessIn most control environments there is little reason to allow every device on

the c ontrol netwo rk to c om munica te to O PC hosts. Typica lly there a re only a

small number of ma chines com munica ting using OPC. Bec ause of this, it

makes good security sense that network access should only be allowed

betwe en these few trusted machines. Window s 2000, Server 2003 and XP

contain host-based firewall capabilities that can use IP filters and a securitypolicy to restric t ne twork tra ffic to O PC ho sts.

Our recommendation is to add a simple host-based firewall rule allowing

traffic only to or from the IP addresses of other trusted OPC hosts. While this

might seem to be simple, we discovered that in practice, setting up such a

rule can be very cumbersome using the firewall configuration wizards

ava ilab le in Windows 2000, Server 2003 and XP. Thus these firewa ll wiza rds are

not used and the fo llow ing four-step proc ess is rec om me nded instea d.

It is wo rth not ing there a re o ther tec hnolog ies for controlling access betw een

hosts that can be even more robust. For example, Microsofts Domain

Isolation m od el13 is far more secure. However due to its complexity, detaileddirections for configuring it are beyond the scope of this report - it may be

cove red in subseq uent rep orts.

3.4.1 Creating the Filter ListsTwo filte r lists are required to properly sec ure a host. The first list m a tc hes a ll

tra ffic com ing to a nd from trusted ma chines. The sec ond list ma tc hes a ll

12 NOTE: For simp lic ity in this rep ort we refe r to user ac c ounts ra ther than acc ount g roup s.

How ever a be tter alternative is c rea ting an op c ad min group rather than just a dd ing an

op ca dm in user. Then within the opc ad min group an a cc ount ca n be ma de for everyone

who should have a dministrative p rivilege s to the OPC server. This will p rov ide c hange

ma nag em ent a c c ounta bility for the OPC host. The sam e a pplies to c rea ting op cuser group

ra ther tha n a single op cuser ac c ount tha t multiple users ac cess. For more information on

ac c ount g roup s in dom ain environm ents see :

http:// ww w.microsoft.c om/ tec hnet/sec urity/g uida nce / networksec urity/sec _ad _ad min_grou

ps.mspx13 http://www.microsoft.com/technet/itsolutions/msit/security/ipsecdomisolwp.mspx



19/54


othe r tra ffic . In the exam ples below there is only one trusted ma chine, but this

could easily be expand ed .

First, launch the Control Panel/Ad ministrative Tools/ Loc a l Sec urity Polic y

application. Next, while making sure the IP Sec urity Polic ies on Loc a l

Computer icon is selected, select Manage IP filter lists and filter actions

under the Actionsmenu.

Now select the Manage IP Filter Liststab and add the filter lists. Figure 3-1

show s wha t to expec t while the filter list for tra ffic betw een trusted ma chines

is being c rea ted. The filter list tha t matc hes a ll other tra ffic is the same excep t

no destination IP address is specified.

Figure 3-1: Creating the Filter Lists

Two c onfigura tion set tings are ra the r sub tle; Mirrored should be selectedand Protocol should be ANY. Mirrored refers to matching traffic between

trusted machines in both directions. ANY refers to allowing any protocol

running on top of IP for trusted machines. It is possible the protocol could be

narrow ed dow n to only TCP, but c are is needed to ensure tha t this doesn t

imp ac t o ther c ritica l services you m ay req uire.



20/54


3.4.2 Crea ting the Block Ac tionOnce the lists are created, actions for these lists are needed. In this case two

ac tions a re required . The first is Permit, and it exists by default. The othe r is

Bloc k and it need s to be c rea ted . If a filter list ha s an ac tion of Bloc k, then a ll

tra ffic tha t ma tc hes the filter list gets drop ped .

Using the Loca l Sec urity Set tings Tool, under the Actionsmenu item, select

Ma nage IP filter lists and filte r ac tions . Now selec t the Ma nage Filter Ac tions

tab to c rea te the Bloc k ac tion. Figure 3-2 illustra tes the a c tion being c rea ted .

Figure 3-2: Creating the Block Action

3.4.3 Creating the Sec urity Polic yAfter the Filter Lists and Block Action have been created, it is time to glue

them into a sec urity po lic y and ap ply them to a ll of the netw ork interfac es.

Selec t IP Sec urity Polic ieson Localand then under the Actionsmenu item o f

the Loca l Sec urity Set tings Tool, selec t Create IP Sec urity Polic y. Give the

polic y a m ea ningful nam e (such as OPC Hosts Polic y), dea c tivate the d efault

response rule and add filte r lists and ac tions. Set ac tion to Permit for traffic

be tween trusted ma chines and Bloc kotherwise.



21/54


Unfortunately this step is not quite this easy as it could be because these

policies have Internet Protoc ol Sec urity (IPsec ) fea tures tha t nee d to b e

addressed. To use our lists and ac tions to simp ly filter IP traffic , do not selec t

the default dynamic filter list, ignore the Authentication field, set Tunnel

Settingto None and Co nnec tion Type to All. Figure 3-3 shows what to expec t

while the p olic y is being c rea ted .

Figure 3-3: Creating the Sec urity Polic y

3.4.4 Assigning the Security PolicyThe last step is to assign the polic y. Simp ly right c lic k on the policy a nd selec t

assign. Figure 3-4 shows wha t to expec t w hile the policy is being assigned.

Onc e these four step s a re c om plete , a rule that only allow s tra ffic to or from

the IP address of trusted OPC hosts should b e in plac e.

Again, since OPC deployments can widely vary, it is essential that the effect

of these rules be tested on a non-critical offline system before being

deployed in a live c ontrol system.

3.5 Protecting the RegistryThe reg istry is the cent ra l rep ository for configura tion d ata in Window s. In

order to protect the registry as much as possible, regular users should not be

given Administrator rights, and Remote Registry Editing should be

disabled from the Services panel of Ad ministrative Tools on Control



22/54


Panel. Note that restricting the ability to change values in the registry is not

the same as restricting read access. Read access is needed only for systems

that do not use OPCEnum for server browsing. If you have newer versions of

OPC a pp lica tions, there should b e little need for reg istry brow sing.

Figure 3-4: Assigning the Security Policy

When c hanging these settings there a re severa l imp ortant tips tha t should be

considered:

Neve r cha ng e SYSTEM p ermissions from Full Controlin the Registry.Any c hanges to this permission w ill cause yo ur system to fa il upon

reboot.

Co nside r removing permissions for the Power Users group if tha tgroup is not in use and rep lac e a ll permissions for Users and

Everyone group w ith Authentica ted Users.



23/54


Figure 3-5: Rem ote Reg istry Servic e

3.6 Som e Spec ial Considerations for XP System sAfter all this setup, you may find that remote access using the opcuser and

op cadmin does not work on your XP-ba sed server. The rea son is tha t fo r a ll

out-of-the-box installations of XP in workgroup architectures, the system

authenticates all remote users as "guest" regardless of the account name.The tric k is to te ll XP to use the "c lassic" authentica tion as shown in the

sc reenshot below.

To a c cess this sett ing launc h the Co ntrol Panel/ Ad ministrative Too ls/ Loc a l

Sec urity Polic y application. Next, select Loc a l Polic ies/ Sec urity Option as

sc roll dow n until you see the item Network Ac c ess:Sharing and sec urity mo del

for loc al ac c ounts. Right clic k and you c an ac cess the Propertiesoption.

If you configure this policy setting to Classic, network logons that use local

account c red entials authentica te with those c red entials. This Classic model

provides precise control over access to resources, and allows you to grant

different types of access to different users for the same resource, which is

exac tly wha t is needed for OPC. Conversely, the Guest-only mod el trea ts a ll

users equally as the Guest user account, and all receive the same level of

access to a given resource , which c an be e ither Rea d Only or Modify. This

c lea rly do esn t work for the OPC sec urity mod el we are p rop osing.



24/54


Figure 3-6: Setting the XP Rem ote Ac cess to Classic

Note that this policy setting does not affect network logons that use domain

acc ounts. The d efault for Window s XP com puters tha t a re joined to a dom ain

and Wind ows Server 2003 compute rs is Classic. This sett ing a lso has no effec t

on Windows 2000 or Server 2003 compute rs.



25/54


4 OPC/ DCOM/ RPC Hardening Rec ommendationsOnce the underlying Windows system is secure, it is time to address the

security of the OPC a pp lica tions. This involves carefully setting up user

accounts, putting in restrictions for DCOM objects and restricting RPC

beha vior. The configura tion required is d iscussed below in three parts; OPCHardening, DCOM Hardening and RPC Hardening.

It is important to note that this section is focused on guidance for the

Windows Server 2003/SP1 and Windows XP/ SP2 op erat ing systems. Mic rosoft

added a number of significant DCOM security enhancements to these

versions14 and the recommendations in this section are designed to take

advantage of these improvements. Users of older operating system versions

can still follow many of the guidelines below, but upgrading to the newer

versions is highly rec om mend ed .

Since OPC deployments can vary widely, it is essential that any of theserecommendations be tested on a non-critical test system before being

deployed in a live c ontrol system.

The rec om mendations in this sec tion require considerab le care and off-line

testing before they are deployed in critical systems. Our tests showed there

are a number of OPC applications that do not properly follow the DCOM

specifications for Windows software. For example, using the DCOM controls

to set a sta tic TCP port for an OPC a pp lica tion (as noted in Sec tion 4.2.4)

caused issues with the OPC softwa re from a number of vendors. In response,

we provided Sec tion 4.3.2 Restric ting TCP Port Rang es for RPC, as a lternative

method for port restric tion. Thus the OPC user should c onsider the suggestionslisted in this sec tion a s a menu o f sec urity op tions to choose from , ra ther tha n

a list of unalterab le req uirem ents.

4.1 OPC Hardening Rec ommenda tionsBy utilizing separate opcuser and opcadmin accounts or groups as

suggested in Sec tion 3.3, we can limit the sec urity expo sure by restric ting

what actions the OPC server and authenticated users can perform. We

recommend the opcadmin account be used only when installing the OPC

server or client software and making configuration changes, since this

account can both launch and access OPC servers. Even then, theopcadmin account should be limited to a specific list of OPC servers or

clients.

For the actual running of the server the opcuser account (or opcuser group

ac c ount) should be used . As defined be low, opc user ca nnot launch an OPC

server, but c an access a running server.

14 http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2netwk.mspx



26/54


Finally we suggest only running the OPCEnum service15 when it is necessary to

browse the O PC servers. When OPCEnum is run, limit its access to the

opcuser and opcadmin accounts. Left in its wide open state, OPCEnum can

present a considerable security risk and typically other users do not need to

access it.

4.2 DCOM Hardening Rec ommenda tionsThere a re two m a in goa ls for suc cessful DCOM hardening . First, we nee d to

only give as much permission as is required for users per DCOM object. For

example, if a computer is running three OPC servers, but only one needs to

be accessed remotely, only allow remote access to that one server.16

Simila rly, if a ll OPC servers and c lients are on a single host, then d isab le

rem ote ac c ess and a llow only loc a l acc ess.

Sec ond , we need to use the d ifferent level user ac c ounts c rea ted ea rlier for

Launch and Access permissions. Again we suggest opcadmin be the only

user account used to launch or configure OPC servers and should have the

servers it c an c onfigure restric ted . The op cuser ac count can b e used by users

who need only to connec t and acc ess running OPC servers.17

To a c hieve these two goa ls we use the DCOM Configuration Too l tha t is

found unde r Co ntrol Panel/Ad ministra tive Too ls/ Co mp onentServices18 shown

in Figure 4-1. It can also be accessed by starting dcomcng.exe from the

Run op tion in the Sta rt Menu.

Figure 4-1: Com po nent Servic es (DCOM) Configuration Too l

Once there, open up Comp onent Servic es. Within it, ignore COM+

Applications for now, and proceed to Computers. Click on Computers toget the sc reen shown in Figure 4-2.

15 http:/ / ww w.sentec h.co.nz/ ScenicHelp/ dc om sec urity.htm16 http:// ww w.opc ac tivex.co m/ Supp ort/DCO M_Config/ dc om_config.html17http:// itc ofe.web.ce rn.c h/ itco fe/Servic es/ OPC/ GettingStarted / DCOM/ RelatedDoc uments

/ ITCO DCO MSet tings.pd f18 http:// www .gefanuca utomation.co m/ opc hub/op cd co m.asp



27/54


Figure 4-2: DCOM Configuration Sc reen

Open My Computer, open the DCOM Config, and see what DCOM

ob jec ts can b e configured. Figure 4-3 shows the DSxP Op c Server Simulator

which is the server used for this example. On the plant floor you are likely to

see the OPC servers you a re using, but you may have to d ig around for them.

Figure 4-3: The Configuration Properties for an OPC Serve r



28/54


4.2.1 Controlling the Authentication LevelThe first change to make is the Authent ica tion Level of the OPC server as

shown in Figure 4-4. These Authentic a tion leve ls are d efined as fo llows:

Default- Ma y va ry dep end ing upon op erating system . Usua lly it iseffectively None o r Connec t .

None- No authentica tion. Connect- Authentica tion oc curs when a c onnec tion is ma de to the

server. Co nnec tionless protocols, like UDP, do not use this.

Call- The a uthentica tion oc curs when a RPC c a ll is accep ted by theserver. Co nnec tionless p rotocols, like UDP do not use this.

Packet- Authentica tes the d a ta on a per-packet b asis. All data isauthenticated.

Packet Integrity- This authentica tes the d a ta tha t has com e from thec lient, and chec ks that the d a ta ha s not be en modified .

Packet Privacy- In ad dition to the checks ma de by the o therauthent ica tion method s, this authentica tion leve l c auses the data to

be encrypted.

Figure 4-4: General Configuration Tab for an OPC Server



29/54


30/54


Figure 4-6: Sec urity Configuration Tab fo r an OPC Serve r

These p ermissions control wha t user ac counts can exec ute which ac tion on

an OPC server. For all three options choose Customize, then Ed it and adjust

the accounts as follow s:

Launc h Permissions- Rem ove a ll existing entries and add theop cadmin ac count c rea ted ea rlier. If a p articular OPC server ismeant only to b e used loc a lly, then remo te a ccess to tha t server

can also b e d isabled.

Ac c ess Permissions- Rem ove a ll existing entries and add theop cadm in and op c user ac counts. Aga in, if a particular OPC server

is meant only to b e used loc a lly, then remote ac cess to tha t server

can also b e d isabled.

Configurat ion Permissions- Rem ove a ll existing entries other tha nthe Everyone ac c ount. Mod ify everyone to b e rea d-only, and ad d

op cad min with full control.

These set tings are shown in Figure 4-7. As noted above , if the server or client is

only to be used locally (i.e. the clients and servers are all on the same

ma chine) then Remoteshould b e turned off.



31/54


32/54


address one of the more vexing problems in OPC security, namely the

problem of d ynamic p ort a lloc ation.

Most o ther TCP server app lica tions use fixed port num bers to identify a ll

incoming pac kets. For example, MODBUS/ TCP uses port 502 and HTTP uses

port 80. This consistenc y makes firewall rule c rea tion relat ively simp le if you

wa nt to b lock all MO DBUS traffic through the firew all, simply define a rule tha t

b loc ks a ll pa ckets conta ining 502 in the destination port field.

Figure 4-8: Endpoints Configuration Tab fo r an OPC Serve r

The defa ult setup for DCOM (a nd RPC) c om plica tes the situa tion by a llow ing

the OPC server to dynamica lly p ick its ow n p ort num bers. The rea son is tha t

while only one web server will typically exist on a given host, there can be

multiple DCOM servers on the same device and each needs its own port

number. It is certainly possible to have an administrator manually set these

port numbers for each server, but early design decisions dictated this might

not be a n idea l solution, so d ynamic alloc a tion bec am e the d efault.

Tod ay, with sec urity becom ing a priority over administrative simp licity, it is

worth considering the option of statically setting these ports for each OPC

server. Of course it is critical to make sure two OPC servers on the same hostdo not g et set up using the sam e p ort numbe r.

Unfortunately not all vendors of OPC products respect the static setting of

port numbers, so this technique must be tested carefully. Matrikon and

NETxEIB OPC softw are p roduc ts worked well with sta tic ports, but several

othe r p rod uc ts d id not. Undoc ume nted reg istry cha nge s d id g et sta tic setting

of p ort numb ers wo rking on a few othe r vend ors p rod uc ts, but this wa s very



33/54


complex. Thus it is imp ortant is to c hec k w ith your OPC vendor before trying

this technique on a live system. If they do not support setting of static

end points, we offer an a lternative mitiga tion in Sec tion 4.3.2 - Restric ting TCP

Port Ranges.

If you want to use static port numbers for OPC traffic and your vendor

supports them, select Ad d on the Endpoints tab and the sc reen in Figure

4-9 should appea r. Then set the Protoc ol Seq uence to Connection-Oriented

TCP/ IP and enter a port value for the static endpoint. Be certain this port

number is not used by any other application in the host. In this example we

have configured the host so the O PC server ap p lica tion w ill use TCP port

7000.

Figure 4-9: Sec urity Configuration Tab fo r an OPC Serve r

4.2.5 Setting the OPC Ap plications Acc ountFinally, the Identity tab lets you configure what user account the DCOM

application will run under. As shown in Figure 4-10, the OPC software should

set to run as the opcuser ac count.

4.3 RPC Hardening Rec om mendations4.3.1 Restric ting Transport Protocols to TCPTo ma ke the Rem ote Proc ed ure Ca ll (RPC) m ec hanism mo re sec ure, it ma kes

sense to restric t the ava ilab le transport leve l protoc ols and to limit the range

of potential transport protocol ports. Forcing OPC clients and servers to use

only TCP (rather tha n UDP) will a llow intervening f irew alls to sta te fully police

TCP streams tha t c arry DCOM traffic . Henc e, it is rec om mend ed to only list

TCP in the list o f a va ilab le DCOM protoc ols. To do this, ed it the

HKEY_LOCAL_MAC HINE\ Softw are\ Microsoft\ Rpc \ DCOM Proto c ols registry

entry so that it only co nta ins the item ncacn_ip_tcp .



34/54


Figure 4-10: Identity Configuration Tab for an OPC Serve r

4.3.2 Restric ting TCP Port RangesAs an a lternative to defining a sta tic port for the OPC servers, one can make

changes to the Windows registry that will limit the range of potential RPC

ports used by an OPC server and allow simpler firewall rules. For example,

administrators can define a small range of ports for RPC to use on the OPC

host. This involves making reg istry changes and reb oo ting. To change theregistry, create an Internetkey under the follow ing loc ation:

HKEY_LOC AL_MACHINE\ Software\ Mic rosoft \ Rpc \

Figure 4-11: Creating a New Registry Key



35/54


Next create the following entries in this location:

Ports (typ e REG_MULTI_SZ) PortsInternetAva ilab le (type REG_SZ) UseInternetPorts (typ e REG_SZ)

The va lue for Portsshould b e the desired port range you wa nt to use for OPC

servers. For example, you c ould a lloca te 100 po rts by entering 7000-7100 in

Ports. We recommend you use a range of ports above port 5000 since port

numbers below 5000 may already be in use by other applications.

Furthermore, previous experience shows a minimum of 100 ports should be

opened, because several system services rely on these RPC ports to

comm unicate w ith eac h other.

The va lue of PortsInternetAvailable should be set to Y for the Ports range to

be noted . The va lue o f UseInternetPortsshould a lso be set to Y for the Portsrange to be noted. It is important to remember this will affect all RPC services

and not just OPC a pp lica tions so chec k with your vendor before trying this.

Figure 4-12: Add ing the Reg istry Va lues

Also note tha t since O PC uses c a llbacks, you m ust use TCP forcom munica tions throug h a firew all if you wa nt this mitiga tion to wo rk. The

reason for this is when the server makes a call to the client, the source port

will not b e w ithin the range spec ified about a nd thus when the c lient send s a

reply to the server's source port, it will not be able to penetrate the firewall.

This is not a prob lem with TCP bec ause m ost firewa lls keep track of TCP

connec tions and permit bidirec tional tra ffic on c onnec tions, reg ard less of the

source port, as long as they are opened from a machine on the inside. For



36/54


37/54


38/54


5 OPC Host Hardening VerificationEven a fter ap p lying the tec hniques for hardening Window s, OPC, DCOM and

RPC described in the previous chapter, we are still left with a number of

unanswered questions with regard to our OPC server:

Have the ha rde ning techniques be en p rop erly ap plied ? What other spec ific exposures should be a ddressed ? When is the system under attack and wha t kinds of a ttac ks are

being used?

To help answer these q uestions, som e a c tive and passive verifica tion

techniques can be used . These invo lve vulnerability scanning using freely

available tools and the enabling and monitoring of Windows auditing

features. Note, it is difficult to completely automate this verification process

so a manua l proc ess is used in the fo llow ing examples.

5.1 Windows Service and Open Port DeterminationThe first ta sk is to determine if the configurat ion o f the OPC servers has

resulted in the c orrec t servers sta rting, a nd if using sta tic ports, if the ports are

set c orrec tly. There a re many tools to do this, but one o f the simp lest is the

built-in Windows ut ility NETSTAT .

Netsta t d isp lays a ll ac tive TCP connec tions, the ports on w hich the com puter

is listening and a num ber of useful Ethernet , IP and TCP sta tistic s. To use

Netstat , simp ly op en c omma nd line w indo w a nd type netstat o . The -o

pa rameter disp lays a ll ac tive TCP c onnec tions and inc ludes the p roc ess ID(PID) for ea ch connec tion. You c an find the app lica tion ba sed on the PID on

the Proc esses ta b in Windows Task Manager. Othe r simila r tools inc lude

fport from www.foundstone.com.

Figure 5-1: Typic a l NETSTAT Output



39/54


5.2 Windows Event Log Ana lysisWindows 2000, Server 2003 and XP provide a rich set o f fea tures for

identifying malicious activity and policy violations. Unfortunately, many are

not enab led by de fault. Furthermore, typica lly the c ha lleng e is not in ge tting

the data, but in deciding which information is most valuable whenmonitoring OPC based app lica tions.

The first step is to ena b le Aud iting to ident ify and log m a licious ac tivity

aga inst OPC Servers. On sta nda lone systems, aud iting is configured using the

Loc a l Sec urity Polic y. Although we identify a minimal set of Audit Policy

recommendations, changes are often required. However in general the

set tings in the ta b le below will work we ll.

Polic y Rec omm ended

Sec urity Setting

Disc ussion

Audit Acc ount

Logon Events

Suc c ess and Fa ilure Sinc e we are d ifferentia ting betw ee n the

user ac c ount ne c essary to remo telyac c ess the OPC/ DCOM c omp onents

(opc user) a nd the a pp lica tion

administrator (opcadmin), it makes sense

to log both suc c essful and failed eve nts.

Note tha t interac tive log ins on the OPC

server should b e a relatively unc om mo n.

Audit Logon

Events

Suc c ess and Fa ilure

Audit Ob jec t

Access

Fa ilure Enab ling ob jec t ac c ess aud iting

ge nerates a signific ant am ount o f

ac tivity; so only failed a ttem pts to a c c essOPC ob jec ts should be enab led .

Audit Policy

Change

Suc c ess

Tab le 5-1: Gene ral Aud iting Settings

Since log in events are limited to interac tive c onsole logons, we must enab le

per object auditing on core OPC components. In Sec urity Options, enable

"Audit: Audit the access of global system objects. The ob jec t a ud it settings

should b e a s listed in the tab le b elow.

Objec t Settings

OPC Server Browser (OPCEnum .exe) Traverse Folding / Exec ute File: Fa iled

Opc_aeps.dll, opcbc_ps.dll,

op c c om n_ps.dll, OPCDAAuto .dll

Trave rse Folding / Exec ute File: Fa iled

OPC Server Ap p lic a tion Traverse Folding / Exec ute File: Fa iled

Tab le 5-2: Objec t Aud iting DCOM/ OPC files



40/54


It is imp ortant to remem be r that in order to ge t the m ost accurate picture of

hostile activity across the network and on multiple clients and servers, we

must be able to integrate data from a variety of sources, including routers,

firewalls, intrusion detection/prevention systems, Windows event logs, and

app lica tion spec ific log s ge nerated by OPC servers. This can be a cha lleng e

given the different terminology, different message formats and differenttypes of da ta (suc h a s IP addresses, po rt numbers, GUIDs, app lica tion names,

etc ) genera ted by a ll these systems. This is a non-trivial ta sk whe re more

resea rch and p rod uc t deve lop ment is need ed .

5.3 Vulnerability ScanningApart from enabling and analyzing security logs on OPC client and server

systems, we recommend that active methods be used to assess hosts for

sec urity de ficienc ies. The too ls and technique s desc ribed in this sec tion c an

identify a number of sec urity ga ps.

The foc us of this sec tion is only scanning for misconfigurat ion vulnerab ilities in

DCOM and OPC Servers and not identifying other vulnerab le services or

components that need to be upgraded. When evaluating existing

techniques, we discovered that existing tools fall short when it comes to

providing information about the state of DCOM and OPC security and at

times they p rovide conflic ting information. Two pop ula r too ls we used to

chec k the security of OPC ho sts are Mic rosoft s Security Baseline Ana lyzer

and Tenab le Netw ork Sec uritys Nessus Scanner. Other sc anners can b e used

as well.

5.3.1 Microsoft Security Baseline Analyzer 2.0The Microsoft Baseline Security Ana lyzer (MBSA) is a free tool useful for

checking systems to ensure they are set up in accordance with Microsoft

best practices and to ensure the basic Windows hardening techniques

described above are followed. It also helps to identify gaps in Microsoft

system and application updates. July 2005, Microsoft released version 2.0 of

this tool, which, according to the Microsoft web site, is now used in many

com merc ia l sec urity prod uc ts.

We recom mend using MBSA to scan the OPC server loc a lly since it p rov ides

the most usefu l information a nd is the least intrusive. Scans c an a lso be

conducted remotely if proper domain/local user credentials are available,remote registry browsing is enabled and access to the well known Microsoft

TCP and UDP ports is ava ilab le. Unfortuna tely this would involve p rac tices

that we specifically advise against for OPC hosts, thus we can not

rec om mend rem ote MBSA sc ans.

MBSA p rovides an ea sy-to-rea d rep ort using simp le p ass/ fa il c riteria and can

be sorted according to severity. Althoug h MBSA is by no means



41/54


42/54


One word of caution - Nessus has a track record of crashing embedded

devices suc h as PLCs and RTUs and even som e p oo rly imp lem ented Window s

applica tions. Som etimes the o perating system can bec om e unresponsive

and unreliable during Nessus scans. Thus we rec om mend these scans only be

run on o ffline systems.

Our scans of a defa ult OPC Server configura tion o n a pa rtially-patc hed

Window s 2000 SP4 Worksta tion p rod uc ed a la rge amount of informa tion

(a fter we provided Ad ministrato r level c red ent ials to Nessus).

1. Port Sc ans Given the use of multiple non-standard ports, port-scansagainst OPC are not very useful, but do help identify unnecessary

system services (IIS etc ) tha t may be running on an OPC host. They a lso

help confirm if the TCP port number restric tions in suggested in Sec tion

4.2 and 4.3.2 are e ffec tive.

2. SMB Sha re Enum erat ion If anonymous brow sing is enab led (or log inc red ent ials are provided) Nessus identifies rem otely accessible shares.

3. RPC Enumeration The RPC scanning mod ule p rovides outputgathered from prob es to RPC/ DCE. No useful information about OPC

applica tions could be ga ined from the RPC scans during our tests.

4. Password Polic y & Histo ry For this module, passwords that havechang ed and o ther enforcem ent me chanisms such minimum leng th,

streng th, force logoff time , and numb er of logins until loc kout a re

rep orted . Som e o f these m ay not b e a pprop riate fo r control system

environments.

5. Rem ote Reg istry Ac c ess Nessus determined whether or not rem otereg istry b rowsing is possible.

6. User Enumeration Nessus rem otely d etermined the Sec urity Identifiers(SIDs) and names of ide ntified privileg ed and unprivileged user

accounts.

7. Known Vulnerabilities in Windows and 3rd Party Components Using loc a l and rem ote c hec ks, Nessus ident ified potentially vulnerab le

softw are versions.

8. Rem ote Servic e Enumerat ion In addition to standard services(Computer Browser, DHCP Client, etc.) Nessus identified the OPC

Server Browser and OPC Server when run a s a service.



43/54


9. Installed Software Nessus p rovided the name a nd version informa tionon insta lled OPC c lient and server ap p lica tions, in a dd ition to othe r 3rd

party softw are.

5.3.3 Aud it Files for Nessus Vulnerab ility ScannerTena ble Netw ork Sec urity has develop ed Nessus p lugins tha t w ill aud it theconfiguration of a device under test to an estab lished c onfiguration. Dig ita l

Bond has created an audit file based on the security recommendations in

white paper. The a ud it file, ava ilab le as Dig itia l Bond subsc riber content, will

a llow an OPC user to dete rmine if their OPC imp lem enta tion meets the g ood

prac tice sec urity rec om mendations in Part 3 of the OPC w hite paper series.

The aud it c apab ility is ava ilab le in Nessus 3 to Tena b le Direc t Feed

subsc ribers and Sec urity Center users. The Policy Com p lianc e p lug ins (IDs

21156 and 21157) must be enabled the credentials for an account with

Windows Ad ministrato r privileg es must be ente red into Nessus. The aud it file

for OPC servers is added via the c om pliance ta b.

Som e of the set tings req uire customization p er OPC server. For example,

aud iting the DCOM p ermissions requires the CLSID of the OPC server be

entered into the a ud it file. This va ries by vendor and prod uc t, but it is ea sily

determined on the OPC server and Dig ital Bond has a large list o f CLSIDs.

Additional instructions on the use and results from the OPC security audit file

are a va ilab le a t Digita l Bond s website.



44/54


45/54


6. Selec t appropriate OPC/ DCOM hardening prac tices for yourenvironment: Chose the OPC/ DCOM ha rde ning p rac tices effec tive for

your facility from the results of step 5.

7. Test hardening prac tises on offline test systems: Make sure that youhave tested any hardening techniques on non-critical systems andconduct functional testing to ensure OPC servers are operating

prop erly. Only a fter you are sure that they will not imp ac t your process

should you dep loy them on c ritica l systems.

8. Consult with your vend or/ system integrator to ad dress possible sec urityincompatibility issues: Unfortunately some applications may not

func tion p rop erly when either OS or OPC/ DCOM ha rdening prac tices

are applied. Work with your vendor/integrator to determine and

resolve these issues.

9. Implement hardening practises on operational systems: Once allhardening techniques have been confirmed on offline test systems,

dep loy them o n online system . Then c ond uc t func tiona l testing to

ensure a ll OPC servers a re op erat ing p rop erly.

10.Verify the dep loyed OPC/ DCOM and OS hardening p rac tices: Afterimplementing hardening practices, make sure they are operating as

expec ted using tec hniques desc ribed in Sec tion 5.

11.Implement other security countermeasures: The host ha rdeningguidelines desc ribed in this doc ument a re not suffic ient on their ow n - it

is prudent to have a defense-in-depth a pproa ch to sec urity. This will

include other solutions such as patch management, firewalls, antivirus

deployment a nd so on.

12.Monitor OPC hosts for intrusions or unusual activities: This c an be d oneusing host and network based monitoring tools as well as Windows

Aud iting and Log ging too ls as d iscussed in Sec tion 5.

6.2 Summary of High Risk Vulnerabilities and Mitiga ting GoodPractices

Using the results from White Paper # 2, we have summarized the key findings

relating to common operating system vulnerabilities that are most critical for

OPC deployments. We have then added the recommended practices for

mitiga ting them based on the g uide lines in this rep ort. Please remem ber this is

only a summary and is by no means a complete list of vulnerabilities or

mitigations.



46/54


Vulnerab ility Good Prac tice

Inadeq ua te Pa tc hing of Host Follow gu idanc e from OPC vend or and existing

orga niza tiona l g uidelines.

(Sec tion 3.1)

Unne c essary Servic es Disab le unnec essary servic es and ensure OPC

hosts a re single purpose p lat forms. (Sec tion 3.2)Unne c essary Acc ess to Host from

Other Devic es

Use Windows IP Filtering (Sec tion 3.4)

System Enum era tion & Profiling Disab le Unne c essary Services (Sec tion 3.2) and

Co nfirm w ith Vulnerab ility Sc anning (Sec tion

5.3)

Wea k Passwo rds Beyo nd the sc op e of this doc ument. Follow

esta b lished industry or orga nizationa l best

practices.

Rem ote Reg istry Ac c ess Harden reg istry and d isab le rem ote ed iting

(Sec tion 3.5). If p ossible d isab le remote

browsing.

Inadeq uate Sec urity Log ging Enab le system aud iting for OPC and DCOM

objects to identify unauthorized access

a ttemp ts. (Sec tion 5.3)

Table 6-1: High Risk O/ S Vulnerab ilities and Possible Mitiga ting Prac tice s

Vulnerab ility Good Prac tice

Lac k of Authentic a tion for OPC

Server Browser

Disab le OPC Server Brow ser and Ano nymous

Log in afte r initial configuration (Sec tion 4.1)

OPC Serve r Exec ute s w ith

Excessive Permissions

Configure OPC Server co mp one nts to run w ith

restricted permissions (Sec tion 4.2)

Ove rly Permissive Sett ings fo r OPCServer Browser

Rem ove Everyone ac c ess to OPCEnum andreq uire a uthentic a ted users and / or follow

vend or rec om mende d p rac tic es. (Sec tion

4.2)

Unnec essary Protoc ol Support for

OPC Server

Force RPC to only use TCP for transport and

either use sta tic ports or restric t p ort rang es

(Sec tion 4.3.1)

Excessive Open TCP ports on OPC

Server

Force RPC to e ither use sta tic ports (Sec tion

4.2) or restric t p ort ranges (Sec tion 4.3.2)

Lack of Confidentiality in OPC

Communications

Ena b le Pac ket Privac y if possible (Sec tion

4.2)

Lac k of Integ rity in OPCCommunications

Ena b le Pac ket Integ rity if po ssible. (Sec tion4.2)

Use of Histo ric a lly Insec ure

Transport

Ensure p a tc hing and upgrad e to O PC-UA

when ava ilab le.

OPC Sec urity Configuration Lac ks

Fine Grained Ac c ess Control

Ca n not b e a dd ressed a t this time

Tab le 6-2: High Risk DCOM/ OPC Vulnerab ilities and Possible Mitiga ting Prac tice s



47/54


6.3 Some Fina l ThoughtsBased on our research, the challenges of securing OPC deployments are

c lea r. The inhe rent a rchitec tura l issues with the current versions of OPC, the

default security posture and poor compliance to DCOM security settings of

ma ny OPC p rod uc ts, and the lack of unam biguous guidance w ith regard tosecurity, all contribute to the difficulties of securing OPC deployments in most

companies.

This does not m ea n OPC users should throw up the ir hands in despa ir. OPC s

reliance upon the Microsoft platform is both a blessing and a curse - while

Windows has flaws, we were able to uncover a wealth of practices for

hardening Windows servers that can be applied to OPC clients and servers.

Furthermore, the fact that a few OPC vendors are providing good security

guidance and a degree of hardening during the installation process shows

tha t it is possible to red uc e the pa in of sec urity that many users are feeling .

What is needed from the vendor community is an immediate and focused

effo rt towa rds improving OPC/ DCOM insta lla tion p roc esses and sec urity

guida nce. Waiting for the da y when there is widesprea d ava ilab ility and

deployment of the more secure OPC-UA is not a solution that is simply too

far in the future to help tod ays OPC end-users.

End-users can also do much to improve their security posture with regards to

OPC. First, many o f the vulnerab ilities in OPC hosts tha t w e d isc ussed in White

Paper #2 are well within the control of the knowledge ab le end -user. Using a

well-defined security plan, such as the one supplied in this document, the

end -user can significantly red uce their OPC sec urity risk. Sec ond , the end -

user community can start demanding better OPC guidance from their

vendors as we noted in White Paper #2, a few vendors already do an

excellent job, so the challenge is to move the remaining vendors in this

d irec tion. Only end -users wielding the powe r of the purcha se order can

ma ke this happen in a timely fashion.

Finally, it is critical the OPC end-user keep both operating systems and OPC

app lica tions as current a s possible. The sec urity of most softwa re p rod uc ts

have improved significantly in the past five years. This is espec ially true for

Mic rosoft Window s and va rious OPC p rod uc ts. The eventua l relea se o f OPC-

UA based software is likely to significantly help reduce the security effort and

risk currently fac ed by industry tod ay. This can only happen if the com munity

em brac es the new UA tec hnolog ies over the next few yea rs.



48/54


7 Areas for More Research in OPC Sec uritySince the foc us in this p rojec t w as on the hardening o f OPC hosts, a numb er

of other interesting sec urity possibilities were not pursued during our resea rch.

We feel that these are worth investigating in future studies and have listed

them below.

7.1 Firewall and Network Rela ted Solutions for OPC Sec urityReaders may have noted that there is no discussion in this white paper on

best p rac tises for firewa ll configurat ion fo r OPC systems. This was conside red

out of scope for this project focusing on OPC hosts, but is an area urgently

need ing further resea rc h.

7.2 OPC Tunnelling Solutions for Security RobustnessGiven the difficulty in developing firewall rule sets for DCOM-basedapplications (and the challenges of OPC use across multiple Windows

domains), there are a number of 3rd party products or built-in techniques to

tunnel OPC/ DCOM tra ffic ove r a sing le p ort. Although these techniques ma y

make the life of the systems administrator simpler, it is not clear if they

improve security. Detailed analysis of these tunnelling solutions is urgently

required.

7.3 Network Intrusion Detec tion/ Intrusion Prevention SignaturesIn the past few yea rs intrusion d etec tion signa tures for SCADA protoc ols suc h

as DNP3 and MODBUS have been develop ed based on likely misuse o f va lidprotocol patterns. We believe that a similar approach could be conducted

for OPC to a lert on una uthorized a ttempts to access OPC Server GUIDs,

Program IDs, or othe r c lient o r server messages.

7.4 Enhancem ents to Network Vulnerab ility ScannersAlthough scanning tools suc h as Nessus and MBSA p roved useful for

identifying Window s OS vulnerab ilities, very little DCOM / OPC spec ific

information wa s p rovide d by these too ls.

7.5 Resea rch Implementa tion Vulnerabilities in OPC Com ponentsOver the past several years, a number of tools have been released that

attempt to find implementation flaws in ActiveX and COM components.

Althoug h Inte rnet Sec urity Systems Inc orporated s Sc anner/ Intrusion

Detec tion System (IDS) has a signa ture fo r an OPC Buffe r overflow21, to our

21http:/ / xforce.iss.net/ xforc e/ xfdb / 13393



49/54


knowledge no implementation flaws have been disclosed in the OPC

Foundation C om ponents such a s Proxy/Stub DLL s or OPC Ap plica tions.

7.6 Use o f Dom ain Isola tion in Control Environm entsDomain Isolation is tec hnique based on IPSec and Group Polic y to prevent

access from untrusted devices to trusted devices on a corporate network.

While very promising on the surfac e, just how effec tively this tec hnology c an

be used in the industria l c ont rols env ironment req uires add itiona l resea rch.



50/54


Glossary

ACL - Access Control List: List of rules in a router or firewall specifying access

privileg es 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 Europen Recherche Nucleaire: European Laboratory for

Partic le Physics.

CIFS - Common Internet File System: Updated version of Server Message

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

CIP - Common Industrial Protocol: CIP is an open standard for industrial

network technologies. It is supported by an organization called Open

Devic eNet Vend or Assoc ia tion (ODVA).

COM Component Object Model: Microsofts 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 thatenables objects, to communicate with one another regardless of the

programm ing langua ge and op erating system being 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 to support communication among objects

loc ate d on different c om pute rs 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

common data.



51/54


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

bo und to a program at the a pp lications loa d or run time , ra ther than linking

during the com pilation of the ap p lications cod e.

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 onents

in SCADA systems (p rima rily in the power and wate r industries).

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: The corpora tion-wide business com munication

netw ork of a firm.

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

manage its key resources.

GUI - Graphical User Interfac e: Graphica l, as op po sed to textual, interfac e toa 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: A softw are o r hardwa re system tha t ena b les

the interac tion of ma n and ma chine.

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 Server: Microsoft s web server app lica tion.

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.



52/54


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 andimp 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: A now obsolete Microsoft Windows networking system

and authentication protoc ol.

LDAP - Lightweight Directory Access Protocol: A protocol for accessing

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 - Management Information Base: The da tabase that a system running an

SNMP agent maintains.

MODBUS - A communications protocol designed by Modicon Incorporated

fo r use with its PLCs.

NETBEUI - Ne tBIOS Extend ed User Inte rface: 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 hnology LAN Manager: A challenge - responseauthentication protocol that was the default for network authentication for

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

OLE - Object Linking and Embedding : A precursor to COM, allowing

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

OPC - OLE for Proc ess Contro l: An industrial API standard based on OLE, COM

and DCOM for accessing process control information on Microsoft Windows

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.



53/54


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: Standards c rea ted by the OPC

Foundation for integ ra ting the existing OPC standards.

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 discovering and listing OPC

servers.

OPC Unified Architecture - OPC UA: Standard to tie together a ll existing OPC

tec hnology and rep lace the underlying DCOM p roto cols in OPC with SOAP

ba sed protoc ols.

PLC Programm ab le Log ic Controller: A PLC is a small dedicated computerused 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 comm unications protoc ol for invoking c od e

residing on a nothe r c om puter ac ross a netw ork.

SAP - Systems, Applications and Products: A German company that

prod uc es client/ server b usiness software.

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 more c entral host c om puters.

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 messages using HTTP.



54/54

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 Servic es 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 of

desc ribing ma ny different kinds of d ata .


opc security wp3

Documents