Security level offered by PLC.

Transcription

1 European Laboratory for Particle Physics Laboratoire Européen pour la Physique des Particules CH-1211 Genève 23 - Suisse PLC Support Document Version: Document Date: 10 April 2003 Document Status: Draft Document Author: IT-CO-FE Abstract The document describes the solutions implemented by PLC manufacturers to deal with the security issues of their devices connected to ETHERNET. 1 Introduction The security level analysed in this document is based on the availability for anybody within CERN to have access to running PLCs with a standard tool. This means to have a write access to the data memory area, to be able to modify a PLC setup, to be able to change any line of code. The survey does concern the 3 most popular families of PLC available on site (Schneider, Siemens, Wago). ( National Instruments devices will be analysed for the next publication. draft page 1

2 2 Access paths. Version/Issue: 2.0/2 2 Access paths. Industrial Fieldbus (CAN, Profibus, FIP, ETHERNET) Fieldbus Console PC RS232 RS485 PLC/Coupler Ethernet Console Dev.Station OPC server PC CERN ETHERNET Backbone As already mentioned, the survey will analyse more deeply the access via ETHERNET but it has to be mentioned the 2 others standard path usually connected to the PLC. Access to a PLC are 1. Via a straight forward cable connected to a PC. (RS232/RS485 line) 2. from a FieldBus (Profibus, Ethernet, CanOpen, WorldFip or FIP). 3. through a general purpose ETHERNET connection 2.1 Security access through the console path. The console access path is the ultimate access path when the system has a serious problem. It is therefore not a good practice to set some software access restriction associated to this path. For most manufacturer, the console cable required is specific for the unit and the most simple security level is to place this cable in a safe place. A second level of security will be to place the PLC unit in a locked rack or room. page 2 draft

3 3 Detailed survey. Version/Issue: 2.0/2 2.2 Security access through Fieldbus. This path is considered as completely isolated network and the security access will be considered as satisfiable. 2.3 Security access through the ETHERNET path. There is two ways to restrain the access to a PCL. 1. A high level of security is reached when the ETHERNET network is completely isolated from external access. This can be obtained by physically separate the control network from a backbone network. Meanwhile there is ways to keep secure between an isolated network and a backbone. Their are: The use of gateway with a limited fire wall function that will control the traffic between the backbone and secure network. The use of router with a manually built in route table. The use of gateway with VLAN option (Virtual LAN) connected to the backbone that will create a virtual network of a selected subset of users completely invisible from the backbone community. 2. The second way is to control the access in the PLC itself. Some ETHERNET interface may have a look up table of remote systems allowed to talk with the PLC. Note: Even if a PLC has a proper access control it may have security hole due to the implementation and the use of services like Web Server, SMTP, Telnet etc. 3 Detailed survey. 3.1 Schneider products. 1. Console access under the UNI-TE protocol running on top of tcp/ip. The development software tools (PL7 or Concept) can be connected to the PLC via the ETHERNET interface with a TCP/IP (UNI-TE) protocols. (UNI_TE means UNIversal TElemecanique) draft page 3

4 3 Detailed survey. Version/Issue: 2.0/2 On Quantum Processor, There is a two consoles protocols available. You have either an ASCII protocol (UNI-TE) or the IEC protocol requiring an RTU console (Remote Terminal Unit). The RTU solution has write access security level but its usage is not available via the ethernet interface. With the ASCII protocol, there is no access control. There is no protection that prevent an user to connect to a running Quantum PLC. The only security is that the PLC can manage only one connection at a time. On premium At the level of the ETHERNET interface it is possible to allow only the communication to remote systems defined in the PLC but: The XWAY address of the PC unit must be defined within a range. Network number [0-127] station number [0-63]. on some ETHERNET modules, the last digit of the IP number must match the XWAY address and this requirement cannot fit with the General CERN policy on IP numbering of devices. The proposed protection mechanism to prevent an user to connect to a running Premium PLC is valid. The only security is that the PLC can manage only one connection at a time. 2. Access to the PLC from a PC via Modbus protocol With a Modbus protocol tool (like modscan) we may gain access to the PLC. On quantum, we do not have any security. There is no protection to disable a remote access via TCP/IP Modbus. On Premium, the security mechanism describe on the console access level is also valid. There is a mechanism that forbid non allowed TCP/IP Modbus access. 3. Access to the PLC from another PLC via the Modbus protocol. On quantum, we do not have any security beside the need to configure the XWAY address (network number, station number) There is no protection to disable a remote access from another PLC via the ETHERNET interface. On Premium the security mechanism describe on the console access level is also valid. There is a mechanism that forbid non allowed TCP/IP Modbus access. 4. Access to the PLC via the TCP/IP telnet/ftp protocol. On Quantum there is a telnet/ftp service available but it require the knowledge of a login name and a password. The kernel of the ETHERNET interface run the VxWorks Operating System. There is a mechanism that restrict the access to the PLC page 4 draft

5 3 Detailed survey. Version/Issue: 2.0/2 On Premium there is a telnet/ftp service available but it require the knowledge of a login name and a password The kernel of the ETHERNET interface run the VxWorks Operating System There is a mechanism that restrict the access to the PLC 5. Access to the PLC via the SNMP protocol. On quantum, there is no SNMP agent. On Premium the security mechanism describe on the console access level is also valid. Also at the level of SNMP it is possible to set an community password for the GET or SET command. There is a mechanism that forbid a SNMP access. 6. Access to the PLC via the HTTP protocol. On quantum, the access to the first page is protected via an user name and a password. There is a mechanism that control the access of WEB pages. On Premium the access to the first page is protected via an user name and a password. There is a mechanism that control the access of WEB pages. 7. Access to the PLC via DCOM and an OPC server. The connection between an OPC client and an OPC Server dependent of the security level apply in the OPC server itself. DCOM and OPC have a complete set of standard security level. Of course, the OPC server will talk to the PLC via Modbus/TCPIP. Note: If an user install an OPC server (OFS) and make an attempt to gain an access to a PLC then all the DCOM/OPC security are irrelevant. The only valid security is the one provided for the access via Modbus TCP/IP. On quantum, we do not have any security. There is no protection to disable a remote access via TCP/IP Modbus. On Premium, the security mechanism describe on the console access level is also valid. There is a mechanism that forbid non allowed TCP/IP Modbus access. 3.2 Siemens products. Siemens devices used a large variety of protocols and even for one connection you may have 2 protocols involved. They have implemented the TCP/IP, UDP, ISO, S7(TCP/sap) protocols and the user do not have a choice on their usage. draft page 5

6 3 Detailed survey. Version/Issue: 2.0/2 1. Console access via ETHERNET The development software tool Simatic Step7 can be connected to the PLC via the ETHERNET interface On S300-CP343 and On S400-CP4431 it is possible configure the PLC in a READ only mode (From panel key) but in this case it is NOT possible via any external access (even OPC) to modify a variable. This level of security is not applicable in our case. There is no protection to disable a remote access via the ETHERNET interface. 2. Access to the PLC from a PC On S300-CP343 and On S400-CP4431 Siemens use more or less proprietary communications mechanisms and I did not find a tool adapted to their protocols. Of course with the use of an ETHERNET basic monitor/generator it is always possible to recreate the communication protocol. The access to Siemens device would be quite difficult without a deep knowledge of their communication protocols. 3. Access to the PLC from another Siemens PLC. On S300-CP343 and On S400-CP4431 The communication between to PLC via ETHERNET require the use of the ISO protocol. Today, this protocol do not pass through the CERN GPN network. I also suspect that there is no protection beside the definition of the S7 subnet ID (number of the project, number of the subnet) There is no serious protection to disable a remote access from another PLC via the ETHERNET interface. 4. Access to the PLC via the TCP/IP telnet/ftp protocol. On S300-CP343 without HTTP server. The telnet/ftp service is refused. On S400-CP4431with HTTP server. The telnet service is refused. there is a ftp service protected via an user name and a password. There is a mechanism that restrict the access to the PLC 5. Access to the PLC via the SNMP protocol. On S300-CP343 There is no SNMP server. On S400-CP4431 There is no SNMP server. There is no SNMP access. 6. Access to the PLC via the HTTP protocol. On S300-CP343 There is no HTTP server. page 6 draft

7 3 Detailed survey. Version/Issue: 2.0/2 On S400-CP4431 There is one HTTP server protected via an user name and a password. It is possible to buy a CP4431 without Web server. There is a mechanism that control the access of WEB pages. 7. Access to the PLC via DCOM and an OPC server. Comments mentioned for the Schneider are also valid here. are On S300-CP343 and On S400-CP4431 there is no protection. There is no protection to disable a remote access via the ETHERNET interface. 3.3 Wago unit. WAGO recommend to use a FIREWALL for the protection of the Control Intranet Network from any backbone. 1. Console access under the Modbus protocol There is no security mechanism in the WAGO PLC. There is no protection that prevent an user to connect to a running WAGO PLC. 2. Access to the PLC from a PC via the Modbus protocol. There is no protection that prevent an user to connect to a running WAGO PLC. 3. Access to the PLC from another PLC via the Modbus protocol. There is a mechanism that forbid non allowed TCP/IP Modbus access. 4. Access to the PLC via the TCP/IP telnet/ftp protocol. The telnet/ftp service is refused There is no telnet/ftp access. 5. Access to the PLC via the SNMP protocol. There is no SNMP agent. There is no SNMP access. 6. Access to the PLC via the HTTP protocol. The we page do provide only a read function of the hardware configuration. There is no way to modify informations in the PLC via HTTP. 7. Access to the PLC via DCOM and an OPC server. same remark as the one provided for the Schneider product. There is no protection that prevent an user to connect to a running WAGO PLC. draft page 7

8 4 Summary Version/Issue: 2.0/2 4 Summary To read this table you my ask you the following question: Will it be possible to protect my PLC from the access of undesirable people using their own development environment ((Schneider/Siemens/Wago)? Will it be possible to protect in read or write access my PLC from undesirable people using their own PC with an OPC server (Schneider/Siemens) The reply provided by the table is: Yes : There is a protection mechanism No : There is NO protection - : Facility not present. page 8 draft

9 5 Conclusion. Version/Issue: 2.0/2 Table 1 List of communication path with a controlled access mechanism Manufacturer ETHERNET access Schneider Quantum Schneider Premium Siemens S300-CP343 Siemens S400-Cp4431 Wago With a Development station. No Yes No a No b No from another PLC No Yes No No No with Siemens Protocols - - Yes c Yes d - With Modbus protocol Via TCP/IP Telnet/FTP No Yes - - No Yes Yes - Yes - via SNMP - Yes via HTTP Yes Yes - Yes Yes With Siemens OPC server With Modbus OPC server - - No No - No Yes - - No a. Yes at the level of the process but No at the level of the ETHERNET module b. same as for (a) c. because siemens use more or less proprietary protocols d. same as for (c) 5 Conclusion. If you have to use a PLC connected to ETHERNET, make sure that this network as a restricted access from the rest of the CERN network. draft page 9

10 5 Conclusion. Version/Issue: 2.0/2 page 10 draft