intrinsica lly s ec ure po bo x 1 78 # 5 – 7217 L a nt z ville rd lantzville, bc c anada v0r 2h0 office 250.390.1333 fa x 250.390.3899 www.byressecurity.com Di g ital Bon d suite 130 1580 s a wg r a ss c orp p kwy sunrise, FL 33323 office 954.315.4633 www.digitalbond.com OPC Security Whitepaper #3 Hardening Guidelines for OP C Hosts PR EP A RE D BY: Digital Bond British Columbia Ins titut e o f T echno log y B yre s R es e arc h Novemb er 13, 2007 OPC Sec urity WP 3 (Vers ion 1-3c ).d o c OPC Security Whitepaper #3 Hardening Guidelines for OP C Hosts
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
OPC Sec urity WP 3 (Version 1-3c ).do c ii Novem ber 2007
Revision History
Revision Date Autho rs Details
0.7 Ma y 15, 2006 E. Byres, M Franz, Draft inte rnal review ve rsion
1.0 Ma y 31, 2006 E. Byres, J. Ca rter, MFranz
Draft for co ntrolled public review
1.1 Aug ust 31, 2006 E. Byres, M. Franz 2nd Draft for co ntrolled pub lic review
1.2 Februa ry 9, 2007 E. Byres, D. Peterson 3rd Draft for co ntrolled pub lic review
1.3 June 28, 2007 E. Byres, D. Peterson 4th Dra ft for co ntrolled pub lic review
1.3a August 31, 2007 E. Byres, D. Pete rson 5th Draft fo r fina l DHS review . Inc ludes
c om ments from the DHS
Rec omm ende d Prac tice s Group
1.3b Sep tem ber 9,
2007
E. Byres, D. Pete rson Co rrec tion of minor g ramm atica l
errors and added figures to Sec tion 3.6
1.3c Novem be r 13,
2007
E. Byres, D. Peterson Co rrec tion of minor ed itorial errors
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.
Severa l peop le stoo d out in their c ontributions and advice for this doc ume nttha t we would like to a cknow led ge. First a re Bill Co tte r of MSMUG a nd Chip
Lee of ISA - we tha nk you for all your help in ma king the user surveys possible.
We would also like to thank Ralph Langner for providing the four example
scenarios for this rep ort a nd lots of usefu l information o n OPC vulnerab ilities.
Finally we would like to thank Evan Hand for his vision and support. Without
him, this projec t never would have b een possible.
Disclaimer
Deployment or application of any of the opinions, suggestions 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.
Since OPC deployments can vary widely, it is essential that any of the
rec om menda tions in this report be tested on a non-c ritical test system be fore
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.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.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 tion’s 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.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
OPC Sec urity WP 3 (Version 1-3c ).do c 1 Novem ber 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 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 uc tion 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 actually
dep loyed in industry
2. Outline the risks and vulnerabilities incurred in deploying OPC in a
control 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 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 suscep 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 lications
on the OPC ho st;
2. Limiting services to the req uired minimum for OPC;
OPC Sec urity WP 3 (Version 1-3c ).do c 4 Novem ber 2007
1 Introduction
This 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 pape rs 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 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 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
OPC Sec urity WP 3 (Version 1-3c ).do c 5 Novem ber 2007
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 world 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 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.” 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 ture for 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
OPC Sec urity WP 3 (Version 1-3c ).do c 6 Novem ber 2007
Despite these concerns, it is our belief that the most serious issue for OPC is
that configuring OPC applications securely has proven to be a major
cha lleng e fo r most engineers and tec hnicians. Even thoug h OPC is an op en
protocol with the specifications freely available, users must wade through a
large amount of very detailed information to answer even basic security
questions. There is little d irec t guida nce o n sec uring OPC, and our resea rchindicates that much of what is available may actually be ineffective or
misguided.
All things considered, there is little doubt that some clear advice would be
very useful for the control engineer on how best to secure currently
dep loyed , COM/ DCOM-based OPC systems. This series of white papers a ims
to he lp fill tha t gap for the end -user.
1.2 Organization of OPC White Paper Series
As noted earlier, this is the third of three white papers outlining the findings
and recommendations from a study on OPC security. In White Paper #1 we
reviewed the OPC spec ific a tions, foc using on d eta ils tha t a re releva nt from a
security point of view and might be useful to users wishing to understand the
risks of OPC deployments. We then described the real-world operation of
OPC applications, identifying components that need to be understood to
harden ho sts running OPC c lient a nd server ap p lica tions.
In White Paper #2 we d efined a set o f vulnerab ilities and possible threa ts to
OPC hosts, based on OPC’s current architecture (i.e. the use of DCOM). We
also looked a t c om mo n m isconfigura tion vulnerab ilities found in OPC server
or client c om pute rs, both a t the op era ting system and OPC a pp lica tion level.
Finally, since the typical OPC host configuration is strongly influenced by the
guidance provided by the software vendor, we looked at the quality of
configuration utilities and guidance provided to end-users by the OPC
vendor community.
In White Paper #3, we use this information to give the OPC end-user a series
of p rac tica l rec ommenda tions they c an d raw upon to sec ure the ir OPC host
machines.
1.3 Study Methodology
Developing the findings and recommendations for all three of the whitepapers req uired the follow ing four-phase approa ch 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 tual
OPC Sec urity WP 3 (Version 1-3c ).do c 7 Novem ber 2007
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 OPC
deployments.
3.
Creating recommendations for mitigating potential threats andvulnerabilities
• 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 recom me nda tions
• 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.4 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 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
OPC Sec urity WP 3 (Version 1-3c ).do c 9 Novem ber 2007
2 Hardening Strategy for OPC Hosts
Build 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
OPC Sec urity WP 3 (Version 1-3c ).do c 12 Novem ber 2007
OPC sec urity issues. A number of the well-known w orms (suc h a s MSBlaster)
released in the past few yea rs have spec ifica lly ta rgeted the underlying RPC
and DCOM servic es for OPC. This has made users and vendors keenly aw are
of the need to patch operating systems and applications in industrial control
systems. Unfortunately, the difficulty with patch management is one cannot
automatically deploy new patches into the process control environmentwithout risking d isrup tion o f op erat ions. Thus ca reful polic y and p rac tice is
req uired tha t b a lances the need for system reliab ility w ith the need for system
security.
Based on our survey, it appears many users and vendors have developed
effec tive p a tc hing proc ed ures for PCs used in their co ntrol systems. For those
readers who do not currently have a good patch management process in
place, we suggest contacting your control system vendor or referencing the
GAO report “ Information Sec urity: Agenc ies Fac e Cha llenges in
Imp lementing Effec tive Softw are Pa tc h Ma nage me nt Proc esses ” 6, and the
Ed ison Elec tric Institute ’ s “ Patc h manage me nt Stra teg ies for the Elec tric Sec tor ” .7 Both provide excellent guidance for patch management in critical
system.
3.2 Minimum Required Services
In o rder to make Windows hosts more sec ure, it is c ritica l that a ll unnecessary
services be disabled. Based on lab testing, the following are the minimum set
of Windows 20008, Wind ows Server 2003 and Wind ow s XP9 services that are
typ ica lly req uired on sta nd-alone OPC c lients and servers. The name in
brackets follow ing the service na me is the rec om me nded Sta rtup Type :
• COM + Event System (Autom atic)
• COM + System App lica tion (Automa tic) (Req uired by XP)
• DNS Client (Automatic)
• Event Log (Autom atic )
• IPSEC Services (Automatic )
• Net Log on (Ma nual)
• NTLM Sec urity Support Provider (Autom atic )
• Plug a nd Play (Automatic)
6 “ Informa tion Sec urity: Ag enc ies Fac e Cha lleng es in Imp leme nting Effec tive Softw a re Pa tc h
Ma nage me nt Proc esses” , GAO Rep ort GAO -04-816T, US Ge nera l Acc ounting O ffic e, June
02, 20047 “ Pat ch mana gem ent Strateg ies for the Elec tric Sec to r” , White Paper, Ed ison Elec tric
Institute –IT Sec urity Working Group , Ma rch 20048 http://labmice.techtarget.com/articles/win2000services.htm9 http :// www .sysinternals.co m/ b log / 2005/ 07/ running-w indo ws-with-no-services.html
OPC Sec urity WP 3 (Version 1-3c ).do c 13 Novem ber 2007
• 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 es
In 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 e
account - 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 high
privileg 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
OPC Sec urity WP 3 (Version 1-3c ).do c 14 Novem ber 2007
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 Access
In 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 hosts.
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, Microsoft’s 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 Lists
Two 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 c ess. For more information on
OPC Sec urity WP 3 (Version 1-3c ).do c 15 Novem ber 2007
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 Actions menu.
Now select the Manage IP Filter Lists tab 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.
OPC Sec urity WP 3 (Version 1-3c ).do c 19 Novem ber 2007
Figure 3-5: Rem ote Reg istry Servic e
3.6 Som e Spec ial Conside rations for XP System s
After 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 Properties option.
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.
OPC Sec urity WP 3 (Version 1-3c ).do c 21 Novem ber 2007
4 OPC/ DCOM/ RPC Hardening Rec om mendations
Once 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 ommendations
By 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
OPC Sec urity WP 3 (Version 1-3c ).do c 31 Novem ber 2007
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 Ports should b e the desired port range you wa nt to use fo r 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 UseInternetPorts should 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
OPC Sec urity WP 3 (Version 1-3c ).do c 34 Novem ber 2007
5 OPC Host Hardening Verification
Even 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 Determination
The 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
OPC Sec urity WP 3 (Version 1-3c ).do c 36 Novem ber 2007
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 Scanning
Apart 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 urity’s 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
OPC Sec urity WP 3 (Version 1-3c ).do c 39 Novem ber 2007
9. Installed Software – Nessus p rovided the name a nd version informa tion
on 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 Scanner
Tena ble Netw ork Sec urity has develop ed Nessus p lug ins 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 (ID’s
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,
auditing the DCOM permissions 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 CLSID’s.
Additional instructions on the use and results from the OPC security audit file
OPC Sec urity WP 3 (Version 1-3c ).do c 40 Novem ber 2007
6 A Summary of OPC Host Hardening Prac tises
6.1 An Ac tion Plan for Hardening OPC Hosts
In earlier sections of this white paper we pointed out the best way to harden
an OPC host is to do it in stage s. One b eg ins by loc king dow n the op eratingsystem tha t the OPC server or client resides on, which in most c ases is some
version of Windows. Next, one should tackle the OPC applications by
restricting the O PC a ccounts, limiting DCOM ob jec t a cc ess and constra ining
RPC protoc ol options. Lastly, to verify the ha rdening has been suc c essful, it is
important to check for remaining security vulnerabilities using security
analyzer tools.
While it seems like a lot of effort, it is important to remember that effective
sec urity does not sta rt o r stop with these three steps. Sec urity is an ongoing
process and thus we recommend the following overall process for users of
OPC tec hnology:
1. Determine whether OPC or DCOM is in use in your facility: This ma y
seem like a trivial task, but some applications may not adequately
document what lower level API is used. We located at least one
company that was unaware that DCOM was in use on its control
system because it wa s bundled into a control produc t w ith a different
name.
2. Doc ument how OPC or DCOM is deployed in your fac ility: This inc ludes
determining what systems and devices communicate using OPC and
how critical this communications is for your operation. List all OPCservers and c lient app lica tions on ea ch host in your fac ility.
3. Evaluate possible operating system hardening practices: Sec tions 3
and Sec tion 6.2 (be low ) highlight c om mon areas of c onc ern and go od
practices for operating system hardening. Also investigate guidelines
from your IT department a nd othe r bod ies suc h as NIST and US-DoD20.
4. Selec t the app ropriate operating system hardening practices for your
environment: Chose the hardening practices effective for your facility
from the results of step 3.
5. Evaluate possible OPC/ DCOM ha rdening p rac tices: Review the
guideline listed in Sec tions 4 and 6.2 of th is report. Also rev iew the
recommendations of your OPC vendor and other bodies such as the
OPC Foundation, for security settings.
20 For examp le see http :/ / c src.nist.gov / itsec / SP800-68-20051102.pd f and
http :/ / iase.d isa .mil/stigs/ chec klist/ W2K3_Chec klist_V5-1-10_20070525.zip
OPC Sec urity WP 3 (Version 1-3c ).do c 43 Novem ber 2007
6.3 Some Fina l Thoughts
Based 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 ay’s 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.
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 of