CPU Protection, Part I

To alter the normal operation of a system it is necessary to get access. For this reason we have to configure all available features to prevent that unauthorized people or software could carry out any action over them. However, we must not forget that security measures can obstruct the recovery of an equipment if do not define clear processes to get it back if something goes wrong or simply beaks down.

Two years ago, I wrote about some controls over Siemens S7-1200 PLCs. You can access it by clicking here. But today I will talk about other.

One of these features is to configure online control access to PLC CPUs. Not to protect the program and the content stored in it. Why is this important? Because when we connect any device to ethernet networks we are increasing the attack and exposure surface. Accordingly, to that, there are more possibilities to suffer any intentional or unintentional action that could affect to our OT devices.

With this feature we can set up passwords to restrict the access to functions and memory areas. In general, in level 1 hardware configuration can be read and modified by anybody; Level 2, read access do not need any password but if you want to change some parameter you will need to type a password; and finally, Level 3, without a password you cannot modify some several parameters. Obviously in both cases there are conditions and exceptions that you can do. For further information please visit “Virtual Library” and locate the following document named “Security with SIMATIC controllers” in SIEMENS area.

After several years in the Industrial Cybersecurity field, in most cases I have not seen this feature implemented that can be used to hamper unsolicited actions on process controllers. If we do not restrict access to anybody, they could upload the program, modify functions and other parametrizations and download it to the PLC again. After that, who knows what will happen if this occur. Other scenario could be the theft of intellectual property by the third parties that can participate in a project during a commissioning phase.

It does not matter which controller we are using, Siemens, OMRON, B&R, Schneider, or any other. The message is to request, identify or consider if this kind of feature is available and apply it to bring more security, to end devices. Of course, without introducing potential factors that could compromise the normal operation.

We know, there are scenarios where it could be difficult to start up some controls and invest more time to find compensatory measures instead of applying them natively. Obviously, if the device count with it.

In addition to that, keep in mind that a password or any other similar measure, could by cracked, but at least, we have applied one more step to reinforce the Defense in Depth concept that we must implement to protect our industrial environments.

Having said this, I hope you have enjoined this post!

To be continued…

Stay tuned!

 

 

2 comentarios en “CPU Protection, Part I

  1. Hello Edorta,

    great post again, this features are really not very used even if they are available in the controllers.

    Certainly user authentication adds an extra layer in PLC-governed installations.
    Of course due to the communication interfaces of the controllers, the controllers should not be used in safety-critical applications unless additional security appliances are used.

    The new generation of PLCs adds even more security features to our installations.

    I would like to refer this new features talking about the new PLCnext Technology from Phoenix Contact.

    User Authentication

    When user authentication is enabled, authentication with a user name and password is required for access to certain components of the controller and certain functions in PLCnext Engineer.
    When user authentication is disabled, authentication is not necessary to access the WBM, the OPC UA server of the controller, or to access the controller using PLCnext Engineer. Access
    to the file system via SFTP and access to the shell via SSH requires authentication (with administrator rights) even if user authentication is disabled.
    Via user authentication, the access data of all users who are authorized to access the controller is managed and the required access permissions are assigned to each user.

    Certificates

    Trusted certificates and revocation lists of possible communication partners are stored on the TrustStores in the Controller.

    The name for each store can be used with the interfaces for TLS communication, e.g., TLS_SOCKET block in IEC 61131-3 or TlsSocket class in C++ or C#.

    Firewall

    PLCnext Controllers are Linux based so it is easy to implement a firewall using iptables.
    In order to make it user friendly these rules can be set up from the web page of the controller.

    SD Cards

    Unauthorized persons can insert an SD card and restart the controller. In this case, the SD card is recognized during the initialization phase of the controller. If there is an overlay file system on the internal parameterization memory, it will be copied to the SD card. The overlay file system on the internal parameterization memory will be deleted.

    This overlay system can be disabled in PLCnext Controllers.

    Many thanks!

  2. Pingback: Enredando con redes ...Tools: PssEnredando con redes …

Los comentarios están cerrados.