An Overview of Honeywell s Secure Remote Access to Process Control Systems

Transcription

1 An Overview f Hneywell s Secure Remte Access t Prcess Cntrl Systems

2 An Overview f Hneywell s Secure Remte Access t Prcess Cntrl Systems 2 Table f Cntents Intrductin... 3 Overview f Security Requirements... 4 Access Cntrl and Authenticatin... 4 Data Encryptin and Message Integrity... 4 Security Measures Used by Hneywell fr Remte Access t Prcess Cntrl Systems... 5 Virtual Private Netwrk (VPN)... 5 Client Authenticatin... 5 SSL VPN Gateway... 5 s... 6 RSC Tls... 6 De-Militarized Zne (DMZ) at the End-User Site... 7 Hneywell Relay Nde at Target Prcess Cntrl System... 7 Hneywell Service Nde at Target Prcess Cntrl System... 7 Overview f a Remte Access Sessin... 7 Cnclusin... 8 Appendix Architecture Drawing... 9 Table f Figures Fig. 1 RSA SecurID key fb... 4 Fig. 2 OSI Cmmunicatin Mdel... 6 Fig.3 - Architecture Drawing... 9

3 An Overview f Hneywell s Secure Remte Access t Prcess Cntrl Systems 3 Intrductin There are many benefits in using subject matter experts (SMEs) t prvide system mnitring, perfrm diagnstics and repair prcess cntrl systems. The mst cnvenient and cst-effective way t deliver these services is via a secure remte cnnectin such that any available SME with the apprpriate skills, lcated anywhere in the wrld, can prvide the required service. This arrangement als allws cverage t be prvided 24 hurs a day, seven days a week t accmmdate time znes, wrk schedules and available resurces. There are several reasns why the remte cnnectin between the SME and the systems supprted must be secure: T prevent access by inapprpriate peple. This includes undesirables such as hackers, but als includes well intentined peple wh have n need t knw r thse wh d nt have relevant skills t ffer (the vast majrity f the ppulatin in the cntext f a prcess cntrl system). T limit the access by SMEs t specific system ndes relevant t their skills. T maintain the cnfidentiality f a custmer s plant data. T maintain the integrity f data as it passes frm client t server and vice versa. T give the end-user sufficient cnfidence t grant remte access t a critical business asset. By far the mst cnvenient way t cnnect t a custmer site is via the Internet. Hwever, as a cmmunicatins channel, the Internet is public and in nrmal usage it is very insecure because: (1) anyne can access it, (2) data can be tampered with, (3) data is in plain text and can be read by anyne and (4) inapprpriate r dangerus sftware can be inserted int a system (malware). Nevertheless, the Internet is ubiquitus and very cnvenient; therefre the design challenge is t add features t cmmunicatin channels which secure them while retaining the universal reach f the Internet. The bjective f this paper is t explain the measures that Hneywell uses t secure remte access t prcess cntrl systems via the Internet and the purpse f the measures adpted. In additin, this paper fcuses n security aspects rather than the functinality f the tls t prvide remte services.

4 An Overview f Hneywell s Secure Remte Access t Prcess Cntrl Systems 4 Overview f Security Requirements Access Cntrl and Authenticatin It is necessary t ensure that nly relevant authrized persns can access the prcess cntrl system and that the scpe f the access allwed is relevant t their rle and skills. There are tw aspects t access cntrl: Knwing wh the persn is, referred t as authenticatin. Once the persn is authenticated, limiting the access granted t that persn t system cmpnents and resurces relevant t their rle and skills. The cncept f authenticatin is built arund three different factrs by which a persn may be authenticated: Smething they knw (passwrd) Smething they have (access card) r Smething they are (bimetric characteristic such as a fingerprint). At the simplest level, authenticatin is generally a single factr, achieved by use f a user ID and passwrd (smething the user knws). Hwever, there are several weaknesses in this apprach such as weak passwrds, users nt lgging ff, passwrds being knwn r shared, etc. As a result, t prvide mre secure authenticatin, anther authenticatin factr will ften be emplyed. Such an apprach is called tw-factr authenticatin. In rder t be allwed access t a system, the user must pass bth challenges. Use f tw-factr authenticatin greatly increases the prbability that the persn requesting access really is wh they claim t be. Hneywell uses tw-factr authenticatin t access the Remte Service Center and then the prcess cntrl system. The tw factrs that Hneywell uses are: Use f lgin ID and passwrd t access a Micrsft Active Directry dmain (smething they knw) and Use f a hardware authenticatin tken, such as an RSA SecurID key fb authenticatr as shwn belw, displays a cde which changes every minute (smething they have). Fig. 1 RSA SecurID key fb Data Encryptin and Message Integrity In rder t prevent users n the Internet frm viewing cnfidential data such as user IDs, passwrds r end user data, it needs t be encrypted. All frms f encryptin depend upn changing the plain text data int cipher text via an encryptin algrithm and ne r mre keys which are knwn nly t the sender and legitimate receiver f the data. A majr prblem with the use f private keys is hw t send the key in a secure way t the receiver. Obviusly this cannt be dne in a secure way via the Internet. Secure data transmissin ver a public channel such as the Internet nrmally depends upn Public Key Infrastructure (PKI). PKI includes elements which allw the sender t be authenticated, the message t be encrypted by the sender and decrypted by the receiver, and a means f ensuring that the message has nt been altered in transmissin (accidentally r deliberately). PKI is a cmplex subject but in essence it includes:

5 An Overview f Hneywell s Secure Remte Access t Prcess Cntrl Systems 5 Use f digital certificates t authenticate the sender f the message. Digital certificates are usually issued by a Certificate Authrity. The certificate cnfirms that the wner f a specific public key is wh they say they are. Use f a pair f encryptin keys, a public key and a private key. The sender s private key is knwn nly t the sender and likewise the receiver s private key is knwn nly t the receiver. Thus the prblem f private key exchange des nt arise. By using the keys as a pair, secrecy can be maintained. The message is encrypted using the sender s public key but is decrypted using the receiver s private key. Public keys are published via digital certificates. In additin, measures need t be taken t ensure that the cntent f the message is nt changed while in transit, either deliberately r accidentally (crruptin). Security Measures Used by Hneywell fr Remte Access t Prcess Cntrl Systems Virtual Private Netwrk (VPN) The essential cmmunicatins cnduit used by Hneywell t remtely access cntrl systems is a Virtual Private Netwrk (VPN). A VPN adds a lgical privacy layer ver the tp f anther physical netwrk (the Internet) in rder t secure it frm public access. When a VPN is set up, a tunnel is said t be created between cmputers n the underlying netwrk. A VPN can prvide authenticatin, encryptin and message integrity. In rder t create the VPN, Hneywell uses Secure Sckets Layer (SSL). SSL includes features which prvide: A means f encryptin key exchange and hence encryptin. A means f authenticatin. A means f prtecting the integrity f data while in transit. SSL is a cmplex subject and this dcument nly prvides a basic verview f its functin. Hneywell uses VPNs between the client and the Remte Service Center (RSC), within the RSC itself and between the RSC and the target cntrl system. The remte access architecture drawing shws the varius VPN tunnels used t cmmunicate frm a remte client t the Hneywell Service Nde within the target cntrl system s Prcess Cntrl Netwrk (PCN). Client Authenticatin The individual user is authenticated via a user ID and passwrd. The user has a dmain accunt and a hardware authenticatin tken. These measures prvide tw-factr authenticatin and a high degree f certainty that the user really is wh they claim t be. SSL VPN Gateway The SSL VPN Gateway acts as a single prtal thrugh which all clients access all applicatins within the RSC. There are tw halves t the SSL VPN Gateway which intercmmunicate via a special cmmunicatins channel. The cmmunicatin frm the client t the prtal uses the Internet Prtcl (IP) which is then encapsulated within an SSL tunnel. This cmmunicatins cnduit terminates n ne side f the SSL VPN. The SSL VPN Gateway then sets up a separate cmmunicatins cnduit frm itself t the RSC s applicatins server. This cnduit als uses the IP which is then encapsulated within anther VPN tunnel. The tw cmmunicatins channels then intercmmunicate using a Cntent Intermediatin Engine. See the diagram (Fig. 2) belw. The SSL VPN Gateway will parse the input received frm the remte client and rewrite it t the RSC applicatin server. This technique prevents the prpagatin f netwrk wrms frm the client t the RSC r vice versa.

6 An Overview f Hneywell s Secure Remte Access t Prcess Cntrl Systems 6 7. Applicatin layer 6. Presentatin layer 5. Sessin layer 4. Transprt layer Cntent Intermediatin Engine 7. Applicatin layer 6. Presentatin layer 5. Sessin layer 4. Transprt layer IP Prtcl 3. Netwrk layer 3. Netwrk layer IP Prtcl Remte Client 2. Datalink layer 1. Physical layer 2. Datalink layer 1. Physical layer RSC internal netwrk OSI-7 layer OSI-7 layer Cmmunicatins Cmmunicatins Mdel Mdel SSL VPN Gateway in detail Fig. 2 OSI Cmmunicatin Mdel s In simple terms, firewalls are a means f blcking r allwing data transmissin between cmputers n a netwrk n a cnditinal basis. They prvide means f filtering messages by: IP address Prtcl Directin f data flw and State f the cmmunicatins channel (eg wh initiated the cmmunicatins). This technique is called stateful filtering. Mdern firewalls may be very sphisticated and may include numerus additinal features beynd the basic ability t filter messages. Hneywell makes extensive use f firewalls within the RSC as can be seen in the architecture drawing. In additin, Hneywell strngly recmmends the use f firewalls at the end-user site t prtect the DMZ and the prcess cntrl netwrk. RSC Tls The tls used in the RSC are hsted n varius servers. Fr the purpses f this paper, the main servers are the applicatin server, the database server and the cmmunicatins server. Used as a set, these ndes prvide the tls which are used t mnitr and diagnse the target prcess cntrl systems. Each f these ndes is prtected by a firewall. In additin, there are ther servers such as an antivirus update server, a patch server and a test system. These servers are used t supprt varius remte update services ffered by Hneywell.

7 An Overview f Hneywell s Secure Remte Access t Prcess Cntrl Systems 7 De-Militarized Zne (DMZ) at the End-User Site A DMZ is a separate netwrk which acts as a buffer zne between tw physical netwrks that d nt trust each ther but need t exchange limited amunts f data. The DMZ is created by use f a firewall between each f the netwrks and the DMZ, an intermediate layer between the tw untrusted netwrks. Hneywell always recmmends that if a PCN needs t cnnect t anther netwrk (which is nt trusted by the PCN), that this cnnectin is made via a DMZ. Hneywell Relay Nde at Target Prcess Cntrl System The Service Nde is a server prvided by Hneywell which is cnnected t the DMZ f the target prcess cntrl system. As can be seen in the architecture drawing, the RSC sets up a VPN tunnel t the Service Nde. The Relay Nde, which is in between the RSC and the Service Nde, sets up a separate TCP/IP sessin with the RSC and the Service Nde. Hneywell Service Nde at Target Prcess Cntrl System The Relay Nde in the cntrl system s DMZ cnnects via a VPN tunnel t the Service Nde lcated within the cntrl system s security zne. Imprtant security features applied t the Service Nde (SN) itself r t the cmmunicatins channels t and frm the SN include: The SN is cnfigured nly t cnnect t a specific IP address within the RSC. All cmmunicatin with the SN is ver prt 443 (this is the TCP prt used fr secure HTTP). As a result, n mdificatin f a crprate firewall is nrmally needed since prt 443 will almst always be pen anyway t allw SSL cmmunicatins t secure web servers n the Internet. The RSC and the remte cntrl system d nt reveal their true IP addresses. The SN cntrls the access allwed t the cntrl system ndes frm utside the PCN security zne. The end user is always in cntrl and decides what access is allwed per user and can terminate a cnnectin at any time if desired. In additin, the end user can apprve each remtely initiated activity and can supervise the remte peratins. Cmmunicatin frm the SN is initiated utbund nly. This apprach allws very effective use f a stateful firewall since all legitimate cmmunicatin is initiated frm the SN. Thus any unslicited cmmunicatin frm utside the PCN t the SN is illegal and will always be filtered. If the RSC requires cmmunicatin with the SN, it sets a request flag within its cmmunicatins server. The SN rutinely plls the cmmunicatins server. If, during a pll, it sees a pending request, it will validate that request versus its stred security plicies and nly grant the request if it is within plicy. The plicy limitatins may refer t the nature f the request itself r t the user requesting the access. See sectin 3 fr descriptin f the setup f a remte access sessin t the SN. The Service Nde and the cmmunicatin server in the RSC authenticate each ther using PKI befre initiating cmmunicatin. When it is required t dwnlad files, such as antivirus updates r patches, this transfer is pulled in tward the cntrl system. Access cntrl is arranged such that unslicited pushing f files frm utside the PCN security zne is prhibited. Extensive sessin recrding and lgging facilities are als prvided within the Service Nde t prvide a cmprehensive audit trail f accesses and activities. Overview f a Remte Access Sessin This sectin will cver the steps f a typical remte access sessin t shw hw the varius security measures detailed in earlier sectins manifest themselves. In this scenari, imagine that an end user has requested remte supprt frm Hneywell via telephne t investigate sme prblem with the cntrl system.

8 An Overview f Hneywell s Secure Remte Access t Prcess Cntrl Systems 8 1. In respnse t a telephne request by the end user, a Hneywell supprt engineer lgs in t the RSC using twfactr authenticatin 2. The Hneywell engineer then accesses the relevant site and system. (The engineer will nly be able t see systems t which he/she has access rights in the verall list f custmers, sites and systems.) 3. The Hneywell engineer will navigate t the alarm and event list fr that system in the RSC and examine the entries. 4. In this scenari, imagine that the alarm message in the RSC is incnclusive and the Hneywell engineer wishes t run a diagnstic test n the target cntrl system in rder t gather mre infrmatin. A set f diagnstic scripts is already stred n the SN. The diagnstic test will prduce sme results which will be fed back t the RSC. 5. Depending n the plicies agreed with the custmer, remte access t the cntrl system and initiatin f a diagnstic script may be restricted as fllws: Remte access may nly be allwed at certain times f the day and days f the week. The remte access sessin may be limited in its duratin. Access may nly be allwed t certain devices. The end user may need t apprve the remte initiatin f diagnstics. The end user may wish t inspect the results f remte diagnstics via a view f the remte desktp. In all cases, the end user can cancel a remte access sessin at any time. In this scenari, imagine that the end user is required t apprve the running f diagnstics. 6. Via the RSC, the Hneywell engineer requests t run a specific diagnstic script n the target system. When the SN next plls the RSC, it will see this request. It will then check the request against its stred plicies and see that the user is authrized t run this diagnstic script but nly subject t apprval frm the end user. 7. The SN will send an request t the end user s server n the crprate netwrk. The PCN firewall wuld be cnfigured t allw utbund but nt inbund t the PCN. The end user engineer then receives an which states that the Hneywell engineer is requesting permissin t run a diagnstic script. If the end user engineer is satisfied with that request, he/she will lgin t the SN and apprve the request. 8. Once the diagnstic script has run, typically results will be sent back frm the SN t the RSC. 9. The remte access actins, the script running actins and the actual remte sessin keystrkes will be recrded fr audit purpses and fr subsequent replay if required. Cnclusin Hneywell views the security f remte access t prcess cntrl systems as being f paramunt imprtance. As described here, Hneywell s security plicies and prcesses are rigrus in rder t achieve the required level f security t secure ur custmer s prcess cntrl netwrks.

9 An Overview f Hneywell s Secure Remte Access t Prcess Cntrl Systems 9 Appendix Architecture Drawing Hneywell Remte Access Architecture I n t e r n e t SSL VPN Gateway Crperate Optinal prxy server Enterprise netwrk User PC SSL VPN Gateway Dmain cntrller Authenticatin server PCN Relay server Relay server DMZ tw factr authenticatin Applicatin server step 1: User-id Passwrd step 2 : PIN cde hardware key Database server Cmmunicatin server Hneywell Service Nde site t allw / deny access OR Patch update server pre-installed security certificate AntiVirus update server Other servers like back-up, test, dem, develpment, etc. PCN Nde 1 PCN Nde N Prcess Cntrl Netwrk vrsc (virtual Remte Service Center) Legend: RSC (Remte Service Center) Redundant Amsterdam / Hustn End-User Plant VPN Tunnel Cntent Intermediatin Engine Address & Prt translatin Internal Netwrk Fig.3 - Architecture Drawing

10 An Overview f Hneywell s Secure Remte Access t Prcess Cntrl Systems 10 Mre Infrmatin Fr mre infrmatin abut Remte Access, visit ur website at r cntact yur Hneywell accunt manager. Autmatin & Cntrl Slutins Prcess Slutins Hneywell 1860 W. Rse Garden Lane. Phenix, AZ, WP ENG August 2010 Printed in USA 2010 Hneywell Internatinal Inc.