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.

What is S4?

A 3 day conference, dedicated to ICS cybersecurity, held in Miami South Beach and organized by Dale Peterson.

• 3 stages: the Main Stage at the Fillmore theater, stage 2 and stage 3 mainly for technical deep dives at the ELV
• the Cabana Sessions around the Surfcomber pool to network, discuss with vendors such as Dragos, Nozomi Networks, Phoenix Contact, Keysight and many others but also get a copy of the book “Countering Cyber Sabotage: Introducing Consequence-Driven, Cyber-Informed Engineering (CCE)” signed by Andy Bochman and Sarah Freeman
• the Welcome Party at the Botanical Garden

This year, around 800 people attended the conference to create the future and Wavestone was there through my participation as both an attendee but also a speaker.

S4 actually started on April 18th with two specific events:

• The first ICS4ICS exercice (I will talk about that a bit later in this article)
• Women in ICS Security social event: more than 160 women attended the conference this year and it was great having the opportunity to meet incredible talents at a women only event; it was the first time such an event was organized at S4 and I hope not the last!

The talks started on April 19th and Dale kicked off the event with a keynote introducing this  year’s theme: No Limits!

In this article, I am going to present some of my favorite talks.

If you are interested, all videos will be released in the next weeks on S4Events YouTube channel: https://www.youtube.com/c/S4Events/videos Here is the full S4x22 video release schedule: https://s4xevents.com/wp-content/uploads/2022/04/S4x22-Video-Release-Schedule.pdf Stay tuned!

A Tale of Two (very different) Secure ICS Architectures

Speaker: Alexandrine TORRENTS, Wavestone

Well, I can’t say this is my favorite talk but I have to start with this presentation as this year was a bit special for me: first time speaker at S4.

I had the opportunity to talk on the Main Stage, right after the keynotes and talk about ICS secure architectures.

No Limits! It gave me the idea of thinking about the future of ICS network architectures.

In this 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.

I won’t detail the whole presentation today as I will write a more detailed article in a few weeks just in time for the release of the video on June 13th.

Interview: CISA Director Jen Easterly

Dale Peterson interviewed CISA Director Jen Easterly on the Main Stage.

The video of the interview is already available on S4Events YouTube channel: https://www.youtube.com/watch?v=xOdIUA4lWnI

I found this interview very interesting, and also very inspiring.

Jen presented CISA’s goal: understand, manage and reduce risks, as well as specific objectives for 2022-2023.

One is oriented on processes:

• Baseline goals have been defined to drive common baselines across all sectors.
• Sector specific documents will be added in the next two years.

Another one is oriented on people:

• CISA wishes to expand its ICS team and is recruiting, especially senior ICS experts.
• CISA will create an ICS JCDC workgroup (Joint Cyber Defense Collaborative) to unify defensive actions and drive down risk in advance of cyber incidents related to ICS. The workgroup will include both public and private sectors.

Jen also talked about Shields UP (https://www.cisa.gov/shields-up) . Since Russia’s invasion of Ukraine, intelligence indicates that the Russian Government is exploring options for potential cyberattacks and CISA is asking every organization to be prepared to respond to disruptive cyber incidents. They published several recommendations on their website.

This interview made me think about what could be done within the French cybersecurity agency (ANSSI) regarding ICS cybersecurity. From my understanding, the ICS expertise is spread across different business units. But what if there was a dedicated ICS cybersecurity task force driving all efforts?

Security Truth or Consequences

Speaker: Dale Peterson

Dale presented a Hard Security Truth: Cybersecurity controls at best reduce the likelihood of attack, but they do not eliminate the possibility of compromise.

Indeed, even with the best security controls implemented and the best OT security program,organizations can be defeated by human errors, configuration errors, or 0day vulnerabilities. It is not a game asset owners can win, they can only reduce the chances of losing.

But what if companies could shift to a consequence reduction mindset and maybe win the cyber risk management game?

Let’s take the example of a glass manufacturer. One of the most sensitive PLCs controls the heat of the oven. if this PLC is compromised, it could be very dangerous for the process. Of course, you can reduce the likelihood of this compromise by implementing security controls, such as network filtering for example. But what if the PLC gets compromised anyway? How could you reduce the impact and get back the control of the process as quickly as possible?

Well, do not only think about cybersecurity and focus on the business and its resiliency. Adding a manual control on the production line could do the trick and make sure the consequence of an attack would not be that important.

Well, it is not always that simple but I find it interesting to focus on consequences and find business oriented solutions to reduce cyber risks.

Dale concluded his talk by presenting his 3-step approach for consequence reduction:

• Identify high consequence event within your organization
• Determine if a cyber attack can cause that event
• If yes, find a way that it won’t

This approach looks like a safety approach, but applied to additional consequences not covered by safety, like loss of revenue.

PIPEDREAM & ICS Cyber Threat In 2022

Speaker: Rob Lee, Dragos

Rob Lee was supposed to present his ICS Cyber Treat review but with the recent news, he made a focus on Pipedream, the ICS attack toolkit/malware analyzed by Dragos: https://www.youtube.com/watch?v=H82sbIwFxt4

This toolkit has been developed by the threat group Chernovite and its capability has not been employed yet. Pipedream seems to be the most flexible ICS attack framework to date. It uses ICS-specific protocols for reconnaissance and manipulation of PLCs.

The primary targets of the toolkit include PLCs from Omron and Schneider Electric. However, pipedream capabilities could impact much more PLC vendors.

Rob presented some of these capabilities, as well as potential attack scenarios following the ICS cyber kill chain:

• EVILSCHOLAR – A capability designed to discover, access, manipulate, and disable Schneider Elctric PLCs.
• BADOMEN – A remote shell capability designed to interact with Omron software and PLCs.
• MOUSEHOLE – A scanning tool designed to use OPC UA and FINS protocols to enumerate PLCs and OT networks.
• DUSTYTUNNEL – Custom remote operational implant capability to perform host reconnaissance and command and control.
• LAZYCARGO – Drops and exploits a vulnerable ASRock driver to load an unsigned driver. Works on all Windows systems not just those with ASRock

Dragos published a full report on pipedream: https://www.dragos.com/blog/industry-news/chernovite-pipedream-malware-targeting-industrial-control-systems/

What I find the most interesting in this toolkit is that it does not use a lot of CVEs, but mainly legitimate functionalities of PLCs and industrial protocols to target industrial control systems.

This toolkit was also analyzed by Mandiant, who called it Incontroller. They also made a presentation at S4 and published a detailed report of their analysis: https://www.mandiant.com/resources/incontroller-state-sponsored-ics-tool

Unpwning A Building

Speaker: Peter Panholzer, Limes Security

This presentation was pretty original as cybersecurity experts had to exploit a cybersecurity vulnerability to resolve a cybersecurity incident.

The incident: a building had a complete loss of their building automation system, using KNX devices.

The initial situation: Devices of the building were no longer operational and the vendor recommended replacing the devices (cost > 100k€).

Idea to resolve the incident: the BCU key is a security parameter used to protect the device from being modified; the BCU key was probably set on the device by the attacker. The idea was to retrieve the BCU key and reprogram the devices.

How: the cybersecurity experts asked for some samples of devices, and tried to read the key from the devices. They managed to dump the firmware of one of the devices and access the memory that was not protected. They used a sliding window and with some brute force, they managed to retrieve the key that was written in clear text in the memory.

Resolution: Fortunately (in this case), the key was the same for all devices and it could be used to reset the devices and restart the building automation system

Unprecedented Attack, Unprecedented Response – SUNBURST From The Inside

Speaker: Tim Brown, SolarWinds

You’ve all heard about the SUNBURST cyberattack on SolarWinds in December 2020.  In this presentation, Tim Brown, CISO of SolarWinds took us inside and explained how he managed this major incident in the first hours, days, weeks, and months that followed.

Besides the presentation in itself that was very good, the most interesting point for me is about the final thoughts and the fact that this incident has increased the level of transparency expected of vendors.

This event caused many changes and has brought supply chain security even more to the front of cybersecurity discussions. 

Using NTIA’s VEX to Tame the Vulnerability Tsunami

Speaker: Eric Byres, aDolus Technology

SBOM (Software Bill of Materials) was kind of trendy this year at S4. Vendors and asset owners should have a SBOM to list all components and libraries used in their products and use it in their vulnerability management process to identify patches to install.

With this, you could end up with thousands of vulnerabilities to patch. But is the vulnerability exploitable in your context?

Indeed, just because a vulnerability database references a particular software component doesn’t mean the vulnerability will actually be exploitable in every software product that includes that component. As a result, organizations can waste valuable time fruitlessly searching for and patching vulnerabilities, even though those vulnerabilities aren’t actually exploitable.

This introduces VEX (Vulnerability Exploitability eXchange), which is a security advisory profile that will be used in combination with SBOM. This profile allows software suppliers to issue a standardized, machine-readable document that states whether or not their products are “affected” by one or more known component vulnerabilities.

You can use VEX for multiple use cases:

• Multiple products to one vulnerability: what products are affected by Log4j?
• Multiple vulnerabilities to a specific product: which vulnerabilities affect the product I use?

The status of a vulnerability includes affected, not affected, fixed, or under investigation.

VEX provides a method for asset owners to focus on exploitable vulnerabilities that present the most risk.

Once you get a comprehensive list of vulnerabilities that could be exploited in your product, as an asset owner, you can use the SSVC methodology to decide what to do in your context with the vulnerability: patch now, patch during the next scheduled maintenance, defer.

Another talk was related to this subject during S4: CSAF, not SBOM, is the Solution, presented by Jens Wiesner from BSI. CSAF (Common Security Advisory Framework) is an open standard about security advisories.

Top 20 PLC Secure Coding Practices

Speakers: Vivek Ponnada, Nozomi Networks and Josh Ruff, Deloitte

The Top 20 PLC Secure Coding Practices is the result of a community effort to provide guidelines to engineers that are creating software (ladder logic, function charts etc.) to help improve the security posture of Industrial Control Systems: https://plc-security.com/

The idea came from a talk at S4x20 where Jake Brodsky asked why engineers and technicians aren’t trained to code and configure PLC’s in a secure manner, and then gave examples of what should be taught and done.

The aim of this session was to present some of the practices in detail and with concrete examples.

Below are two of the practices that were presented:

• Practice #3: Leave operational logic in PLC

While HMI visualization software provides some level of coding capabilities, this functionality should not be used for control or safety coding

The idea with this practice is to make sure that controls are performed by the PLC itself and not by the HMI. This way, if you bypass the HMI and send a request directly to the PLC, the PLC won’t automatically accept your request but will perform controls to make sure the logic makes sense.

It is similar to the OWASP recommendation in IT to implement controls on the server side and not on the client side for web applications.

• Practice #7: Validate paired inputs/outputs

When mutually exclusive paired inputs or outputs that physically cannot happen at the same time (e.g., motor start/stop, valve open/close) are asserted simultaneously, this may indicate a sensor failure or malicious activity.

The idea with this practice is to implement controls based on inputs/outputs that are linked together. For example, a compressor cannot be started and stopped at the same time. An attacker could turn on both the start and stop outputs simultaneously. To avoid that, a single output could be used to run the compressor with interlocks and delay timers.

If you already know the Top 20 PLC secure coding practices, you won’t learn anything with this presentation but I think it is a great introduction to understand the mindset behind these practices.

Something interesting as well, several talks this year were linked to PLC secure coding practices:

• PLC EDR: Model Checking of Logic
• PLC Library to Detect Abnormalities

You can find out more about these presentations, as well as others in Arnaud SOULLIE’s video on S4: https://www.youtube.com/watch?v=9XCNjmKJiTk

ICS4ICS: Results of the First Major Exercise

Speaker: Megan Samford, Schneider Electric

Like I mentioned earlier, S4 was the stage of the first ICS4ICS exercise on April 18th. ICS4ICS stands for Incident Command System for Industrial Control Systems.

Megan Samford talked at S4x20 about the fact that cyber was the only designated federal disaster type not currently using Incident Command System for its response framework.

Since 2020, a team of more than 1000 volunteers has been put together to create a global framework of cyber responders.

The Incident Command Process is based on a planning P cycle that provides a proven structured process to manage any incident with a standardized approach to organizing and executing work.

The objective of the exercise was to present this methodology as well as the structure of documents and templates that can be used to follow a cyber incident:

• Cover Sheet
• ICS-202 Incident Objectives
• IICS-203 Organization Assignment List
• ICS-204 Assignment List
• ICS-205A Communications List
• ICS-207 Incident Organization Chart
• ICS-208 Safety Message/Plan
• ICS-214 Activity Log

The goal for ICS4ICS after S4x22 is to expand its capabilities by:

• Conducting ICS4ICS exercices globally
• Offering ICS4ICS credentials and training globally
• Supporting more complex incidents

Of course, ICS4ICS is more of an organizational framework and does not give guidance about the cyber incident itself. I would be interested in the next few years to have insights on how companies actually used this framework and how it helped their ICS cyber incident response.

Finally, if you still have time, I recommend the following presentations as well:

• Cyber Conflict and International Relations
• Assessing the Balance Between Visibility and Confidentiality in ICS Network Traffic
• Inside Industroyer2 and Sandworm’s Latest Cyberattacks Against Ukraine
• The Great Debate: Cyber Insurance Will Play A Major Role In OT Risk Management
• When C-SHTF: Lessons Learned from the Front Lines in OT Incident Response

S4x22 was great! So many good talks but also (and foremostly) the opportunity to see again so many familiar faces of the ICS community and meet new people.

I already look forward to S4x23 that will take place from February 13th to February 16th, 2023. Next year, the conference will still be in Miami South Beach, but at the Loews as the Fillmore will be in renovation.

Cet article S4x22 – Write up of the ICS cybersecurity conference est apparu en premier sur RiskInsight.

Over 40 assessments of industrial sites

If you want to know more, you can find the detailed study.

Cet article Industrial sites cybersecurity : benchmark on 40 assessments est apparu en premier sur RiskInsight.

Reminder of the state of the threat

ANSSI states in ÉTAT DE LA MENACE RANÇONGICIEL – À L’ENCONTRE DES ENTREPRISES ET INSTITUTIONS[1] published on 05/02/2020: «  Since 2018, ANSSI and its partners have observed that more and more cybercriminal groups with significant financial resources and technical skills favour the targeting of particular companies and institutions in their ransomware attacks. ».

Faced with this observation, it is more necessary than ever to secure information systems. This involves applying the fundamentals of security: applying patches, managing accounts and passwords, managing network segmentation etc. As a reminder, the application of these initial measures permits a significant reduction in the probability that an information system will be subject to a ransomware but can in no way guarantee that this will not happen.

Specificity of the industrial sector

However, even though new defensive solutions are continually being developed, the cost and complexity of deploying some of them ultimately make them little used. This is truer in an industrial environment, where their integration can be complex, as some systems are fixed in a functional configuration. Moreover, the budgets allocated to IT security in an industrial environment, although increasing in recent years, are still not sufficient for many sites.

Furthermore, an industrial information system shares a common base with a conventional information system and is therefore subject to the same attacks. Of course, attacks such as Stuxnet, Triton, or BlackEnergy (on a smaller scale) require additional skills. However, it is always worth remembering that the targets of interest for groups possessing this type of means are generally already subject to regulatory obligations (LPM in France, NIS directive etc.), which if respected, greatly limit the risks of a successful attack against them. However, these systems are not invulnerable, and must therefore also be prepared to respond to an attack.

Inevitable attack on industrial systems: how to minimise the impact and restart operations quickly?

It therefore appears that:

• Protecting oneself from the threat is often limited to the application of basic security measures if there is no regulatory obligation applicable to the target information system;
• Identifying the sources of threat and detecting an attack before it reaches its objective requires in most cases resources that are too important in relation to the budgets of current industrial information systems.

If the probability of an information system undergoing a successful cyber-attack, and more specifically a ransomware, is almost certain, the following question arises: “How can we prepare for a major cyber-attack, maintain critical activities in a degraded mode, while rapidly regaining confidence in the industrial information system? ».

The answer to this question is covered by the last two pillars of computer security according to the NIST framework: respond and recover. An attempt to answer this question is presented in this article.

Note: the first part of this article “How to respond to an attack before it is too late?” is not necessary to implement the recommendations detailed in the second part “How to recover after an attack if it could not be contained? ». Although the implementation of network filtering measures is highly recommended, it may be interesting for sites where the implementation of such filtering measures takes too long to implement, to start with the preparation part of the remediation of a cyber-attack, which is easier to implement.

How to respond to an attack before it is too late?

Involving industrial teams

Before talking about the measures that can be put in place to respond to a digital security incident, it may be interesting to remember that industrial staff are used to crisis management.

Indeed, many industries regularly organise crisis management exercises (fire, chemical risk, natural disasters, etc.). On many sensitive sites, procedures are therefore already available to respond to this type of incident, under the direction of a dedicated manager. In addition, autonomous physical protection is generally available: pressure relief valve, non-return valve, sprinkler etc., although these are sometimes replaced by connected instrumented safety systems.

The context is therefore appropriate for adding a new procedure in order to respond to a computer attack. This will generally consist of isolating the industrial information system from the outside via a procedure known as the “red button”. In order to draw up the associated procedure, the involvement of site personnel will be essential, particularly to ensure that the application is not more harmful than the attack itself.

A prerequisite for the implementation of the isolation posture: the control of its flows and the implementation of network partitioning/filtering.

It is necessary to measure the impacts generated using the “red button”. To do this, it is necessary to list the interconnections of the industrial site with other systems.

List the interconnections with other information systems.

It may be interesting to start by listing the flows between the industrial information system and the outside. First of all, it is necessary to define what this system contains. In a basic case, it includes the PLCs, the supervision, as well as the equipment necessary for the interconnection of the first two.

Other equipment can then be added: an Historian server, client stations for supervision, a NAS, etc. This network, later called an industrial network, is generally connected with other networks in order to share information with the equipment of the latter.

It is possible to mention:

• Exchanges with the company’s ERP (whether an MES – Manufacturing Execution System is present or not), generally located on the office network;
• Exchanges with partners: regulation of electricity, water and gas networks, etc.;
• Exchanges with service providers: weather, cloud solutions for energy optimisation, predictive maintenance, etc.

These flows, although useful to simplify operations, can generally be temporarily cut off or replaced by alternative means (telephone call to indicate production levels for example).

Moreover, each industrial site is different, and therefore manages these interconnections differently. It is common to see MPLS networks dedicated to industrial sites when the company owns several of them. In other cases, the office network will be used to federate them. It is also true for the connection needs between these industrial networks and the Internet, which sometimes pass first through the office network, or benefit from a direct output.

List its internal flows

After listing the interconnections between the industrial network and the outside, the internal flows remain to be listed. Most of these flows should be strictly necessary for the proper functioning of the industrial process, such as those between supervision and PLCs. Cutting off these connections would therefore require stopping the industrial process, or at least making it safe.

It may then be interesting to separate the equipment and associated flows into several zones:

• Supervision;
• Field network;
• Others (supervision client stations, historian server, etc.).

Setting up these zones allows the exposure of these components to be drastically reduced. Indeed, only the supervision should have access to the field networks, while the “Others” category should only have access to the supervision.

Other zones may be necessary to implement such as:

• An administration zone: which could also be used to program the PLCs according to the distribution of roles and responsibilities on site;
• A DMZ: which can accommodate a relay server so that equipment outside the industrial site does not connect directly to the supervision system to retrieve production data, etc.

Depending on the services offered (WSUS server, antivirus server, Terminal Server for remote access etc.) other zones can of course be added.

Evaluate the real need for these flows

After listing all these flows, it is interesting to identify the real need for each of them. For example, is it necessary to be able to access e-mails from a supervision server?

In order to limit the exposure of the industrial network to the outside, it could also be necessary to take some equipment out of it. For example, if a database accessed from the office network is fed by the supervision, but not useful to it, hosting it directly on the office network may prove simpler than trying to limit access.

Once the necessary flows have been clearly identified, the associated filtering rules must be configured in detail (source IP address, destination IP address, destination port). This work generally requires a significant human investment, mainly from the teams in charge of the industrial site, as well as a significant material cost to acquire security equipment. However, it is a prerequisite for setting up the fallback postures described below. In an ideal case, application filtering (level 7 of the OSI model) could also be implemented.

This work, although essential to the implementation of isolation postures, is also one of the fundamental actions to be carried out within the framework of securing an information system (industrial or not). Indeed, each flow cut off is a flow that does not need to be monitored, as well as one that is less exploitable by an attacker.

Preparing fallback postures

Complete isolation of all the equipment in an industrial information system is not always desirable, even in the event of an attack. After having listed these flows, it may be interesting not to set up a single isolation posture, but several fallback postures, allowing in some cases to continue working almost normally.

Preventive fallback posture: isolate the plant in the event of an attack on an external network

After identifying the flows between the industrial network and the outside, it is possible to create an associated fallback posture in order to deactivate them if necessary. The objective of this posture is to cut all interconnections of the industrial network with the outside in order to prevent any propagation of an attack. A proven solution is to group these flows on a few dedicated Ethernet ports. Thus, it is sufficient to indicate in the associated procedures to disconnect the associated cables to activate the fallback posture. This also avoids having to intervene on the configuration of firewalls in the event of a cyber security incident.

In addition, it is also necessary to define the cases in which this posture should be activated. If it can be activated without posing any problem to production, or adding too much work to the site staff, the question may arise as to whether these flows are necessary.

If this posture does have an impact on the site’s industrial activities, a good balance must be found between triggering it too early (as soon as the antivirus software on an office workstation raises an alert), or too late (after the first industrial workstations have been encrypted). This will also depend on the context of the company and its resources (dedicated or non-dedicated security monitoring team, etc.).

Specificity (distributed sites, non-autonomous sites, etc.)

If all flows with the outside do not have the same destination, it may also be interesting to define several specific fallback positions. Indeed, if the service provider in charge of managing the site’s cameras warns that he is undergoing a ransomware attack, it seems more optimal to disconnect only the flows between this service provider and the factory network, rather than all the flows, including those to the ERP.

In the case where the industrial process is distributed over several sites (production and distribution plant in particular), the activation of the preventive fallback posture should not cut off the flows between these different sites. Indeed, specific links should be dedicated to this. If this is not the case, use of the office network to ensure these connections, for example, a project to overhaul the industrial network is probably to be expected (deployment of a dedicated VRF, or a SDWAN network for example).

Finally, it is always good to remember that each factory is different, so a local study will have to be carried out on each one to understand its specificities.

Last resort fallback position: switch off the information system in the event of a proven attack on the plant

Finally, it may be interesting to prepare a last resort fallback posture. This should consist of isolating each VLAN (if defined, preferably with a local HMI per VLAN to ensure a degraded mode) or each piece of equipment (turn off the switches) in order to prevent the attacker from continuing his actions, which in the most advanced cases of attack, could directly target the site’s industrial process.

The objective is then to secure the site or ensure its essential services. The activation of this posture implies working without an information system and should only be applied in the event of proven compromise of at least one piece of equipment on the site, since it leads to the same immediate result as a ransomware, if not worse.

An upstream work with the operators will be necessary in order to list all the actions to be carried out when this posture is activated and to define degraded modes. Indeed, this will generally require the activation of on-call duty in order to manually perform certain tasks: checking the correct operation of equipment, especially on remote sites, use of local HMIs, etc. Moreover, some industrial processes are no longer manually controllable today, and will therefore have to be stopped since no degraded mode is available.

In order to estimate the impacts of activating such a posture, it may be interesting to look at the impacts listed in the event of fire or a general power failure. Moreover, only a real test of this posture can ensure its operational impacts.

How to recover after an attack if it has not been contained?

In some cases, the activation of fallback postures may not be sufficient to protect the entire industrial information system, especially if they are activated too late. It is then essential to be able to proceed with the reconstruction of all or part of the said system in a sufficiently short time to limit the associated impacts.

The main prerequisites for restoring an industrial information system are listed below.

What must be backed up to be able to restore its PLCs?

In order to be able to restart the factory, it is necessary in most cases to start restoring PLCs, which requires two main elements.

Having an up-to-date copy of your PLC programs

PLCs are spared in most current attacks, probably because targeting Windows workstations is enough for attackers to achieve their intended objectives. However, attacks are likely to be increasingly targeted, and most PLCs currently in use are not secure (unencrypted and unauthenticated communications, default passwords, administration functionality that cannot be deactivated, etc.).

It is therefore necessary to save these programs, which is already generally the case, particularly on the programming station (sometimes belonging to a service provider) used when the device is commissioned. It should be noted that these backups should be stored on at least one off-line medium, so that they are not encrypted in the same way as the workstation hosting them.

These observations remain valid even for the new generations of PLCs, which, although benefiting from a level of security that is far superior to that of their predecessors, are not invulnerable.

Save a means of downloading these programs to the PLCs

Many PLCs require dedicated software to be programmed. This is even the case if you just want to download an already written program. It is therefore advisable to have a copy of these programs.

In some cases, a programming station disconnected from the network and reserved for this purpose can be a solution. It should be noted, however, that maintaining such a station in a safe condition can quickly become complex. If this solution is selected, this station could also host the copy of the PLC programs. Keeping a second backup set off-line (external hard disk for example) would however be an additional security measure.

Furthermore, if new generations of PLCs are used, with the latest security features enabled, other elements should be backed up such as: PLC program passwords, certificates used for certain communications (or a means of regenerating them) etc.

These prerequisites are also valid for network equipment (firewalls, switches etc.).

What needs to be backed up to be able to restore essential computer hardware?

Identifying what is really needed

Restoring SCADA system, and associated client workstations, is generally equivalent to restoring a Windows system and associated programs. Several questions must be asked to identify the items to be backed up:

• What equipment is needed? An engineering workstation, a SCADA server, a few operator workstations?
• Is it possible to reinstall the SCADA system from scratch (new installations of Windows and the supervision software) and then deposit a backup of the SCADA configuration? Is this feasible in a sufficiently short time?
• Would not a complete copy of the SCADA server disk be simpler? It would indeed be sufficient to insert the saved disk to reboot.
• Are changes regularly made to the supervision software? If yes, is it necessary to back them all up? In this case, it seems complex to make a complete copy of the disk each time.

Backing up intelligently

In many cases, backups of Windows workstations are made in the same way as those of PLC programs, by copy/paste. It could then be interesting to look at automatic backup mechanisms. However, these are probably to be avoided for factories starting from scratch and not having enough budget to install them serenely. Indeed, implementing this type of solution in a secure manner is generally more complex than making a simple bit-by-bit copy of a hard disk.

Do not neglect documentation and training

However, it is not enough to have complete backups available. It is also necessary to draw up detailed operating procedures for restoring these backups. Indeed, if a crisis were to occur, the stress of the teams and the potential unavailability of some of the knowledge could lead to handling errors in the absence of documentation.

These procedures are not intended to enable a complete restoration of all systems, but at least to enable the essential elements previously identified to be restarted:

• An engineering workstation with the associated PLC programming software;
• A SCADA server;
• Two to three operator workstations;
• The plant’s essential PLCs.

In addition, it is generally recommended to have at least two sets of backups, one to be stored near the equipment concerned, the other to be stored on another physical site, with access limited to a limited number of people. It may be tempting to store an additional set of backups online, but it should be noted that in the event of a cyber-attack, and activation of fallback procedures, it is complex to download these backups and deposit them on the systems to be restored.

Finally, it is essential to test all these procedures to ensure that they are exhaustive. A test could, for example, be the opportunity to realise that the backup of the SCADA configuration does not include the licence key, or that the passwords configured when the complete disk was copied have since been modified without keeping the history.

Conclusion

Crisis management is an important component of the business for many industrial system operators. These same people are also the most experienced in their perimeter. However, they are generally not IT experts. Pragmatic measures, adapted to their context, will therefore be far more useful than a generic 200-page guide containing all the good practices to be applied to an information system.

As in development with the KISS principle (Keep it simple, stupid), fallback postures, as well as restoration procedures, should be kept simple to understand, and stupid to apply.

Furthermore, although the application of a strict network filtering policy can only be advised, it is not strictly necessary for the implementation of backup and recovery actions. Thus, even if the probability of a successful attack is increased, it will still be possible to restore critical systems.

Finally, it should be noted that more and more industrial processes are nowadays operating in a just-in-time mode. In this type of context, the preservation of the industrial system from an attack, or the ability to restore it quickly, would not be sufficient to maintain the level of production if the management of orders or distribution, for example, are unavailable. Cyber resilience must therefore be considered at the company level, and not only at the level of the industrial site.

Key elements

To respond to an attack before it is late, it is necessary:

• To involve the industrial teams (without which it is highly likely that the computer will survive the attack, but without the factory continuing to fulfil its primary mission);
• To control its flows and implement network partitioning/filtering in order to be able to set up fallback postures:
  • Preventive, in order to isolate the factory in the event of an attack on an external network without having too significant an impact on the industrial process;
  • As a last resort, in order to shut down the information system in the event of a proven attack on the factory before the attacker modifies the industrial process.
• To test these fallback postures, in order to ensure that their activation is not worse than the attack.

And in the case where the attack could not be contained, the following elements are generally necessary in order to recover from the said attack:

• Possess an up-to-date copy of your PLC programs;
• Save a means of downloading these programs to the PLCs;
• Have at least one copy of all critical backups on an off-line medium (external hard disk for example);
• Identify its essential computer equipment (in particular so as not to restore the history server before the supervision server, etc.);
• Backing up intelligently, sometimes a bit-by-bit copy of the hard disk is more efficient than an automatic copy on a dedicated server, generally encrypted at the same time as the system whose backups it hosts;
• Don’t neglect documentation and training (otherwise a forgotten license key, or someone on holiday could quickly sign the end of the restore…).

[1] www.cert.ssi.gouv.fr/uploads/CERTFR-2020-CTI-001.pdf

A new version of the threat assessment was published at the beginning of the year: https://www.cert.ssi.gouv.fr/uploads/CERTFR-2021-CTI-001.pdf

Cet article Cyber resilience in an industrial environment est apparu en premier sur RiskInsight.

Pourtant, le volet IAM « Identity and Access Management » est souvent relégué au second plan dans les Programmes de mise en conformité LPM/NIS mis en œuvre par les Opérateurs d’Importance Vitale (OIV) / Opérateurs de Service Essentiel (OSE).

Comment comprendre cette situation et quelles leçons en tirer pour construire sa feuille de route IAM pour ses infrastructures critiques ?

L’IAM est un des piliers du volet cybersécurité de la LPM/NIS

Les mesures IAM à mettre en place sur les infrastructures critiques sont décrites dans les quatre règles suivantes :

Auxquelles il convient d’ajouter la règle portant sur les indicateurs (règle 20 pour la LPM et règle 4 pour NIS).

Les bonnes pratiques IAM habituelles à appliquer à tous les accès

Les exigences des trois premières règles reprennent les bonnes pratiques habituelles à appliquer à la gestion des comptes et des droits, tant pour les utilisateurs physiques que pour les processus automatiques accédant aux infrastructures critiques :

• Gérer le cycle de vie des utilisateurs, notamment les mutations et départs
• Affecter les droits selon le principe du moindre privilège
• Revoir (ou recertifier) régulièrement les droits affectés, a minima annuellement
• Contrôler et auditer les droits
• Attribuer des comptes et des moyens d’authentification strictement nominatifs

Le cadre ci-dessous résume les règles concernées :

Ces règles fixent un cadre mais laissent une grande liberté aux Opérateurs pour les décliner dans leur contexte.

Des comptes d’administration dédiés et soumis aux mêmes exigences

La quatrième règle (n°14 LPM et n°11 NIS) traite spécifiquement des comptes d’administration, destinés aux seuls personnels en charge de l’administration des infrastructures critiques : installation, configuration, maintenance, supervision, etc. L’exigence forte est la mise en place de comptes d’administration dédiés à la réalisation des opérations d’administration.

Au-delà du principe de moindre privilège explicitement mentionné, les comptes d’administration doivent respecter les mêmes exigences que les autres comptes telles que décrites précédemment.

Des indicateurs à produire pour surveiller les comptes à risque élevé

Enfin, la règle sur les indicateurs prévoit la définition de plusieurs indicateurs concernant la gestion des comptes présentant un niveau de risque élevé :

• Pourcentage de comptes partagés
• Pourcentage de comptes privilégiés
• Pourcentage de ressources dont les éléments secrets ne peuvent pas être modifiés

Au vu de ces exigences, l’intégration des infrastructures critiques dans les outils IAM (ci-après appelés « l’IAM ») de l’Opérateur apparaît comme la réponse nécessaire ; à compléter par l’application de mesures de durcissement (suppression, désactivation ou changement de mot de passe des comptes par défaut).

NB : les exigences LPM et NIS étant très similaires, nous emploierons par la suite le terme « OIV » pour désigner aussi bien les Opérateurs d’Importante Vitale et les Opérateurs de Service Essentiel, et le terme « SIIV » pour désigner les Systèmes d’Informations d’Importance Vitale et les Systèmes d’Informations Essentiels.

Pourtant, les Opérateurs hésitent encore à raccorder leurs infrastructures critiques à l’IAM

Les règlementations LPM et NIS ont accéléré la mise en place et le déploiement de solutions de bastion d’administration afin de sécuriser les accès d’administration. Cependant, bien que ces projets soient nécessaires, ils ne permettent de répondre que très partiellement aux exigences évoquées précédemment.

Ces règlementations devraient pourtant être un bon driver pour les projets IAM, mais les Opérateurs sont confrontés à deux principaux problèmes :

• La complexité d’intégration des systèmes industriels avec l’IAM – pour les Opérateurs industriels.
• Le risque induit par le raccordement des infrastructures critiques à l’IAM.

Des systèmes industriels complexes à intégrer

Les systèmes industriels présentent en effet des spécificités qui, d’une part complexifient le raccordement à un outil IAM, et d’autre part le rendent moins indispensable. Car, de façon générale :

• le nombre d’utilisateurs est limité ;
• ces systèmes sont cloisonnés, voire isolés du réseau d’entreprise ;
• la maturité sécurité des éditeurs et constructeurs est en retrait, les capacités d’interfaçage sont réduites, tant pour la gestion des comptes que pour la délégation d’authentification ;
• la granularité des droits d’accès est faible, se limitant souvent à autoriser l’accès ou non à l’ensemble du système, et non fonctionnalité par fonctionnalité.

Une intégration potentiellement génératrice de risques

Mais, au-delà de ces considérations propres aux systèmes industriels, les Opérateurs sont parfois réticents à mettre en place cette intégration, car elle est perçue comme génératrice de risques. En effet, si l’outil IAM ne présente pas un niveau de sécurité à la hauteur des règlementations, il pourrait paradoxalement constituer un point d’entrée sur les SIIV et ainsi amener de nouvelles vulnérabilités : création de compte ou attribution de droit illégitime, suppression malveillante de tous les comptes, etc.

Quant à mettre en place un IAM entièrement dédié au périmètre SIIV, cela représente un investissement très conséquent, parfois disproportionné, et qui ne permet pas de tirer tous les avantages d’un IAM mutualisé, par exemples les liens avec les sources autoritaires comme le SI RH.

Différentes approches d’intégration IAM permettent de répondre aux exigences règlementaires en maintenant un niveau de cloisonnement élevé

Dès lors, comment répondre efficacement aux exigences de la LPM et de la directive NIS ? Comment tirer parti des services proposés par les outils IAM sans ouvrir de nouvelle porte sur les infrastructures critiques ?

Nous distinguons différentes approches pour intégrer un système avec les outils IAM.

L’approche « délégation », à l’état de l’art mais fortement couplée

La première approche consiste à déléguer l’authentification et l’autorisation à l’IAM, en l’occurrence au service d’authentification et de contrôle d’accès, via un protocole de Fédération d’Identités (SAML2, OpenID Connect / OAuth2) ou via un raccordement Active Directory / LDAP.

Cette solution permet une gestion des comptes et des accès à l’état de l’art, mais rend le SIIV totalement dépendant de ce service et l’expose aux risques évoqués précédemment. Même en situation de crise, une isolation du SIIV serait difficilement envisageable.

Cette approche est donc plutôt à réserver aux applications qui fonctionnent déjà sur ce principe, typiquement les applications du SI de gestion avec un grand nombre d’utilisateurs. Pour les systèmes industriels, la solution à privilégier est de conserver le service d’authentification au sein du SIIV et d’opter pour une autre approche.

L’approche « provisioning », avec un niveau de couplage à ajuster au contexte

Cette approche consiste à conserver un système d’authentification et de contrôle d’accès propre au SIIV mais provisionné – c’est-à-dire alimenté – par l’IAM : les comptes et droits des utilisateurs sont stockés dans un référentiel interne au SIIV, et la solution IAM les gère au travers d’un connecteur. En fonction du niveau d’isolation souhaité, ce connecteur peut prendre différentes formes :

• Un connecteur automatique, permettant à l’IAM d’écrire directement les informations sur les comptes et accès dans le SIIV. Une isolation temporaire devient possible, en situation de crise ou en cas de détection d’activité anormale (par exemple : suppression massive de tous les comptes). Mais rien n’empêche un utilisateur malveillant ayant la main sur l’IAM de se donner accès au SIIV.
• Des ordres transmis aux administrateurs du SIIV (par ticket ITSM ou par mail) qui réalisent les actions manuellement. Un « sas » d’isolation est ainsi maintenu entre l’IAM et le SIIV, avec une étape de contrôle par les administrateurs.

Cette approche permet de bénéficier des processus de gestion des identités et des accès : validation et traçabilité des demandes d’accès, retrait des comptes et droits en cas de mutation ou de départ, etc. tout en préservant un degré de cloisonnement du SIIV.

L’approche « revue », orientée contrôle a posteriori

L’approche « revue » (également appelée « recertification ») se distingue des autres par le fait qu’elle repose sur une logique de contrôle a posteriori plutôt que de gestion a priori. Il s’agit cette fois d’analyser périodiquement les accès déclarés dans le SIIV afin de vérifier s’ils sont toujours légitimes. Cette vérification peut reposer sur un rapprochement des comptes avec un référentiel de collaborateurs (fichier RH, solution IAM, etc.), ou sur une validation explicite de la part des responsables des utilisateurs.

Ce peut être l’occasion de réaliser des contrôles approfondis (par exemple détection de combinaisons toxiques), de produire des indicateurs et des rapports d’audit.

Adapter son projet IAM – Infrastructures critiques à son niveau de maturité et à la typologie du SIIV

Sur la base de ces différentes options, nous proposons ci-dessous des pistes pour construire la feuille de route de mise en conformité LPM/NIS en fonction du niveau de maturité IAM et de la typologie des SIIV concernés.

Conserver la brique d’authentification et autorisation localement dans chaque SIIV

Il est préférable de conserver un référentiel de comptes et de droits d’accès localement dans chaque SIIV. Cependant, pour les systèmes déjà raccordés à un service mutualisé d’authentification et d’autorisation, le système mutualisé peut être conservé mais l’Opérateur doit lui appliquer les mesures prévues par la LPM et NIS : a minima le cloisonnement réseau, le durcissement, le maintien en conditions de sécurité, l’administration depuis un SI d’administration dédié, l’envoi des logs au SIEM, etc.

Dans un environnement de gestion des identités et des accès non mature, commencer par la revue des comptes et des droits

En l’absence d’outillage de gestion IAM mature, le moyen le plus rapide d’atteindre un premier niveau de maîtrise des risques et de conformité est de définir et mettre en œuvre un processus de revue régulière, sur une base a minima annuelle.

Sur un SIIV au nombre d’utilisateurs limité, le processus peut être déroulé manuellement, avec un niveau de qualité acceptable et une charge de travail raisonnable. Mais pour gérer des volumétries plus importantes, un outillage adéquat est à envisager : il facilite le pilotage des campagnes de revue et garantit la traçabilité des décisions. Il constitue en outre une opportunité pour envisager ensuite la mise en place d’un outil de gestion IAM.

Lorsqu’un outil de gestion IAM est en place, le sécuriser pour y raccorder les SIIV

Lorsque l’Opérateur dispose d’un outillage IAM mature, le provisioning des SIIV par l’IAM est recommandé : l’automatisation, la fiabilisation et la maîtrise que permettent les outils doivent compenser les risques induits par le couplage. A condition toutefois de garantir la sécurité de l’IAM : en complément des mesures techniques précédemment évoquées, l’Opérateur doit configurer l’IAM de sorte à ce que seuls les utilisateurs susceptibles d’accéder au SIIV peuvent demander l’accès, que le propriétaire du SIIV valide les demandes d’accès et puisse consulter facilement la liste des utilisateurs autorisés, et enfin que des contrôles permettent de détecter des anomalies sur les comptes et accès.

Le rehaussement de la sécurité profitera d’ailleurs à l’ensemble du Système d’Informations.

Trouver le bon équilibre risques / bénéfices pour construire son projet IAM – Infrastructures critiques

Ces propositions doivent permettre à tout Opérateur de construire sa feuille de route IAM pour ses infrastructures critiques en trouvant le bon équilibre entre les bénéfices apportés, les risques induits et le coût de mise en conformité.

Cet article Quelle approche pour gérer les identités et les accès sur les infrastructures critiques ? est apparu en premier sur RiskInsight.

La sécurité des Systèmes d’Informations Industriels (SII) est aujourd’hui au centre des préoccupations dans les entreprises concernées. Ces systèmes permettent une action directe dans le monde « physique » à l’aide d’instructions provenant du monde « logique » et pilotent les outils de production de nombreuses entreprises.

Du fait du manque de sécurité de ces systèmes, de nombreuses attaques ont été recensées dans le monde ces dernières années. La dernière en date ayant eu le plus gros impact est l’attaque du réseau électrique de l’Ukraine en décembre dernier [1]. De nombreuses personnes se sont retrouvées sans électricité suite à une attaque du réseau industriel.

Le plus bas niveau des SI industriels est le réseau de production. Les capteurs et les actionneurs sont reliés aux entrées/sorties des automates industriels. Les protocoles utilisés pour communiquer avec ces automates sont généralement des protocoles propriétaires. Parmi les plus utilisés, on retrouve : Modbus, S7comm, DNP3, Profibus, Hart… Ces protocoles manquent souvent des principales fonctions de sécurité à savoir l’authentification et le chiffrement des flux. Il est donc possible de rejouer des requêtes et de réaliser des actions malveillantes directement sur les automates.
Modbus, protocole de Schneider Electric publiquement documenté et libre de droits, est une norme de référence pour les communications industrielles. De nombreux outils utilisant ce protocole existent pour communiquer avec les automates Schneider :

Cet article S7comm : un outil de communication avec les Automates Programmables Industriels Siemens est apparu en premier sur RiskInsight.