 infrastructure we have nowadays is power generation. If there's no power, we're pretty much screwed. Our next speakers will take a very close look at common industrial control systems used in power turbines and their shortcomings. So please give a warm round of applause to Reptap, Muradak and Kors. Good morning Congress. Thank you for waking up in the morning. We will talk about the security of power plants today, specifically about automation systems that are used in the power plants. You might think that this is another talk about how insecure the whole industrial things around us are and more or less it is. So for years we are, we and our colleagues speak about problems in industrial security. We are happy to say that things are getting better, but it's just that the temper is a little bit different and feels a little bit uncomfortable. So anyway, we will speak about like how power plants are built, what is the automation inside, what are the vulnerabilities and like the high level overview of what you can do with this. But at first, a little bit of introduction. We are security consultants. We work with a lot of industrial things like PLCs, RTUs, SCADES, DCSS, whatever it is. We were doing this for too long. We, actually for so long that we have a huge map of contacts with a lot of system integrators and vendors and throughout the time we are not just doing the consultancy work for some asset owner, for example, for a power plant. We also talk to other entities and we try to fix things all together. We work at Kaspersky and actually the whole research was done not just by me, Rado and Alexander who are here, but also with the help of Evgenia and the two sergates. Things, yeah, so things that are very important to note is that everything that we will discuss right now is reported to a respective vendor basically a long time ago. You can see like vendors here, but more or less we will speak only about one vendor today. It is Siemens, but we would like you to understand that similar security issues can be found in all other industrial solutions from other vendors. You would find some of the findings not, for example, that stellar and it doesn't require like weeks of work to find them out and this would be true specifically for all other vendors which are not mentioned in the talk. Jokes aside, we will share security issues of real power plants out there and it might look like we are kind of irresponsible guys, but in fact this is the other way around. I mean that to do some kind of research on with these systems that are working in the power plants, you need to get access to them, you need time to do this research, you need to have some knowledge to do this research and all these resources they are limited for guys like us for penetration testers, for auditors, for power plant operators and engineers, but for the bad guys like the potential attackers or adversaries, this is actually their job. They have a lot of investments to do some research, so we assume that bad guys already know this and we would like to share some information with the good guys so they would be able to act upon this. So let's go to the talk itself, power plants. Power plants is like the most common way how humans get their power, their electricity, they're everywhere around us and I believe the closest one to Leipzig is called Lipendorf power station and during this research when we were preparing an introduction we were surprised how many information about power plants you can get from the internet. It's not just for example a picture of this of the same power station on the Google Maps, it is actually a very good scheme of what you can see on the marketing materials from vendors because when they sell some system that automate power plant operations they sometimes start with building construction and on their websites you can find a schematic pictures of actually which building does what and where you will find some equipment which versions of equipment are used in these systems, but if you don't have this experience you can just Google things and you will find out which systems are used for automation in power plants. For example for Lipendorf it's some system that is called Siemens SPPA T2000 and P3000 which is actually have another Siemens system inside called Siemens SPPA T3000 so it's a little bit confusing and it is and we are still confused. This is exactly the system that would be that we will focus today. The Siemens SPPA T3000 and again it could be any other automation system but it just happened the way that we've seen this system more and more often than others. There is a way how you can actually see all the generation sites throughout the world thanks to the carbon monitoring communities. This is not just power plants, this is also like nuclear sites, wind generation, solar plants etc and etc. They are all here marked by different fuel types of generation. For example there is a coil and gas power plants marked there. So the topic is really huge and what we will focus today in our talk is mostly the power plants which work on coal and gas. This is important to mention. The heart of each power plant is actually a turbine. We don't have a picture of a turbine on the slides but more or less I think everybody saw it on the airplane. They are very similar specifically in terms of size and mostly how they work. On different vendors website you can actually find a lot of information where those turbines are used and this is for example the map of the turbines from Siemens. Not all turbines are specifically used in power plants. So they have a lot of different applications like chemical plants, oil and gas, a lot of other things. But if you correlate this information from previous slides you would be able to identify like which systems are used by which power plant and if you will Google more information you can actually tell the versions and the generations of the systems that are used on these power plants. This is important because of the vulnerabilities that we will discuss later on on the slide. So before we will speak about what is the automation on power plants we should understand a little bit how they work. So we will go from right to left and it's very easy. A little notice throughout the talk we will simplify a lot of things for two reasons. One of them to make it more suitable for the audience and another thing we don't really understand everything by ourselves. So the first thing you should get is a fuel. Fuel could be for example a coil or a gas and you will just put this inside the combustion chamber where you would put it, set it up on fire actually and it will generate a lot of pressure which will go to the turbine and because of the pressure the turbine will begin to rotate. The turbine have a shaft which will drive the electricity generator which is obviously will generate electricity and put it on the power grid. So it is important from now on to understand that when we generate some electricity on the power plant we put this power not just for for example for this congress center or for some city we put it in a big thing called power grid where other entities will sell this electricity to different customers. There is also a very interesting point about like when we do generate this pressure and the combustion chamber is on fire we have a lot of excessive heat and we have two options like one of them is to safely put it in the air with condensing towers. This is option number one and another option is we can do some form of recuperation. For example we would take this heat, we will warm water, the water will produce steam and we will put this steam in the steam turbine and produce additional electricity. This is kind of an optimization of some form. So what is the automation in this process? The automation systems that are used on the power plants are usually called distributed control systems or DCS's and everything that I just described actually is automated inside those systems. The vendor of the solution want to simplify all things for the operator because we don't want like hundreds of people working on the power plant we just want like maybe dozens of people working there and they want to simplify the whole process of like they don't care about where they get this guess or call how much they need it. They just should be able to stop the generation process, start it and they control one main thing which is called how much power we should produce to the power grid. So like how many megawatts of electricity we should produce. This describes actually the complexity hidden inside these solutions because there are a lot of small things happening inside and we will discuss it a little bit later. As I said this DCS's are not exclusively used on the power plants. There are a lot of other sites that would use the same solutions, the same software and hardware. The DCS is not just like a software that you can install. It's a set of hardware and software. There is input output models, sensors, etc. And etc. As I said sometimes they start from building construction of like there is a field please build us a power station. So it's a more complex projects most of the time. There are a lot of vendors that are doing it. As I said we are focusing in this talk on the Siemens one. Just a short description of how simplified things are for operators of this DCS software. So for example if we would like to answer the question how we would regulate the output in megawatts of our power plant we would need to control basically three things. Again we are oversimplifying here. First of all you would control how many, this is the example for the gas turbine. So we would need to regulate how many gas we would put inside the combustion chamber. We would control the flame temperature and we will control the thing that gets air inside the turbine. Basically three things that are controlled by simple PLCs in the whole system and you would be able for example to change 100 megawatts to 150 megawatts based on these settings. So the system itself that we are going to discuss is called Siemens SPPAT 3000. And actually again as all other DCS systems from other vendors this is a typical industrial system. It has all these things called PLCs, RTUs, HMIs, servers, OPC traffic, etc. The only thing that is different specifically for Siemens SPPAT 3000 is that they have two main things called application server and automation server. This software running on this server is not what you will find on other installations. Despite the fact that there are a lot of, like if you would read the manuals for the systems from Siemens there would be a lot of different networks and highways and a lot of things like Siemens would state that there is no connection between the application network and external networks. In practice and in the reality you will find things like specific sensor network like monitoring of vibration for an object and some noises inside the turbine. You will find the demilitarized zone because all in all like all power plant operators they won't have like on-site maintenance guys, engineers, they would try to do a remote support. They would need to install updates for operating system for their signatures for their antiviruses. They would need to push some OPC traffic so like information about the generation process outside either to corporate network or to some regulator because the whole energy market is regulated and there are different entities who would monitor how many electricity you are generating or they basically will tell you how many electricity you should generate because this is how many electricity was sold on the energy market. Basically the whole talk with structures like this we will speak first about application servers then automation server and then some summary. It all started with the process called coordinated vulnerability disclosure. We notified Siemens about some issues almost a year ago and like a month at the beginning of December Siemens published an advisory. It was not an advisory just from the issues just from us. A lot of other teams also contributed to it and this year's December doesn't mean that Siemens just released the patches. When the system SPPAT 3000 is exclusively supported so the system integrator for the system is Siemens itself so throughout the year after we notified them about some security issues they started to roll out patches and install updates on critical infrastructure they support and hopefully they did it with all the sensitive issues. There is a lot of things to discuss here. We will skip because we are a little bit in a hurry. Things like not all vulnerabilities are the same and we use for example CVSS here to talk about like how critical the vulnerability is but it's actually not very applicable to the industrial sites. You should understand what you can do with each vulnerability, how you can impact the process and we will skip this part. There is actually a kind of a threat model in the white paper that we will release later on like during January we will hope. So application server. Application server is this main resource that you would find in the SPPAT 3000 network. If someone will remotely connect to the system it would end up an application server. If someone wants to start the generation process or to change some values it would be the application server. If there are other servers that would for example try to communicate the application server they will actually start their work by downloading their software from application server and then executing it. So the first thing you might notice here is there are a lot of network ports available on this machine. And actually this is like the first point there is a huge attack surface for the adversary to choose whether or not he would like to compromise some Siemens software or it's Windows software or it's another third party. Huge attack surface starting from the fact that all of the installation of this SPPA systems are kind of different. So depending on the version and the generation you can find different Windows versions from I don't know 2003 to 2016. Hopefully they are all updated right now. But because the update process for such for such installations is a hard thing to do. I mean you should wait for maintenance and it should be like maybe once in a half a year or once a year you will always find some window where you can use some remotely exploitable vulnerabilities like eternal blue or blue keep are mentioned on this slide. There's tons of different additional software like old sidewind that will allow you to do privilege escalation and badly configured Tomcat and we have here this funny pie charts that show how configuration of different software is aligned with the best practices from these benchmarks. Those are usually those are basically security configuration hardening guides. The most important thing in the application server is a lot of Java software and in a minute rather will tell you about this surprise surprise. The one of the most notable problems in the Siemens SPPA 3000 is actually passwords. There are three important ranges. The first one is like what's all the installations before 2014 or maybe 2015. All passwords for the for all power stations were the same and you can easily Google them. We will also publish like the full world list in white paper. After this years Siemens started to generate the unique passwords for all power plants. But until this year it was kind of hard to change this password. So you need to be aware of how to do this. You need to know the process. You maybe need to contact to contact your system integrator to do this starting up from this December it would be much easier specifically to change passwords. So it's in the past it even if you know you have these issues you were not able to simply change all these things. Along with the passwords you can find the like the full diagrams and integrator documentation that can like show you how the system is built how it's operating specific accounts etc. And etc. Of course this was not published by Siemens though some power plant operators who thought it would be a good idea to share this information. So as I said the most important thing of the application server is a bunch of Java applications and please welcome Rado who will share the details about this. Hi everyone. Let's look how the software works on the application server operator can communicate with system through a thin client and fed client. I think client act as Java player inside Internet Explorer browser and communicate with server through HTTPS. So it can be outside of application network and its communications can be constrained by firewall. In opposite in case of fed client software should be installed on operator machine and client directly communicates with RMI registry to find services and after that directly communicates with this RMI services. So fed client should belong to application network. Illustration of SPP architecture was kindly provided by SPPA through the URL. Not to be messed let's divide it into spaces in red zone the item that process request from thin client and redirects them to RMI services. And in green zone there are RMI services which act as network services on dynamic TCP ports. SPPA consists of containers each container can encapsulate inside one or more RMI services. All type of containers are represented on illustration and all of them have self-explanatory names. Before we are going deep inside internals of SPPA let me introduce some tools which used in this research. First of all all jars files inside SPPA are up to skated with commercial product but the security measure can be easily bypassed by public available tool depth investigator. Also sometimes it is useful to see how legit software communicates with system. It helps to understand architecture of system and workflow of clients. In case of SPPA RMI detector was written. It represents the role of TCP streams in human readable formats. Inside it use method read object from Java SDK. It is known that this method is unsafe to insecure desalization. So be careful not to be exploited through remote pickup. The first pillar of SPPA it's Apache web server according it config folder Orion software config can be accessed by an author user. In fact this folder contains some sensitive information of system. For example files PC system configuration data XMLs and files inside AFC contain start up options and configuration of all containers either application work or automation work. As a configuration of Orion web application in Tomcat also can be accessed using this vulnerability. And about Tomcat. There are three web applications registered remote diagnostic viewer manager and Orion. According to configurations of Tomcat at Apache web server as Orion server lets can be accessed through HTTPS and in the file web.xml there are a list of all surlets of Orion application and the list is really huge. So some of these surlets have attractive names for attacker. For example browser. In fact it allows an author user listing directories of operation system but in case of exploitation another surlet is more attractive. File upload surlet allows an authorised file upload with system writes. Parameters base dir and target may fully control the name of the file. So this vulnerability can be easily transformed to remote code execution. You can override some start up scripts of SPPA or simply inject JSP shell in Tomcat web application and get remote code execution with system writes. Also there are some surlets which contain word service factory in the names. In fact they redirects HTTPS request to RMI services. Inside they parsed parameters from HTTPS request and search desirable RMI service according to parameter service URU and further invoke call to the public method of security service and the name of the method defined in serialised object in the data section of HTTPS request. Else parameters of these calls also defined in this object. So now we have situation when theme client and fed client can access RMI services. But in case of fed client it can also directly communicate with RMI registry. So if application server missed some important Java security updates it contains insecure digitalisation vulnerability and using public to your social serial we can simply exploit it and get code execution with system writes again. The next task will be to list all available RMI services of SPPA system. At first step we simply use class locate registry of Java SDK and get a big list of services. All but one are RMI services. I assume that they perform some general interface for common for control and manage containers of SPPA. For further investigation we only choose look up service. In fact this service looks like some collection of another RMI services. Using its public method list we get the name of all available services and using the name and public method look up we get the reference of RMI service. All RMI services in this step implement interface service factory. So according to this we can assume that this is again collection of another RMI services but in fact it doesn't have public method to get the name of the service. So we need to decompile the class and find some factory methods which create RMI service for example create admin script and inside we can find the name of created service. As it can be guessed it's admin service. So using public method get service and this name we finally get the reference to next level RMI service. And in final step we get the reference to RMI services which perform real job of SPPA. But it's this RMI service also contains a lot of public methods for an authority user. So to sum up we traverse registry and at each level we found a lot of RMI services and the last item also contains a lot of public methods. So the attack surface of SPPA system is really huge. So now when we list all available RMI services the next question is how does authentication of client request performs on the system? To answer this question let's look how client requests to security service process on system. First of all clients get the reference to security service using some client ID. Further PC service factory try to get valid session using this client ID in session manager. If session manager will fail in his task the exception will be thrown and client will be failed. But if it succeeds valid session ID will return to PC service factory. And further in its turn instance of security service will be created in factory method and security service will be stored in a login ID inside security service. And finally client will get the reference to security service. Further he can call some public method of it. But these methods can perform privilege checks of security service. So we have two security measures in the system but there is a question how user client can perform login operation if he doesn't have any valid client ID. In this case at start up of the system session manager will be added an anonymous session with client ID equals zero and client will use this client ID and perform login operation. But attacking can also use this feature and simply bypass first log. So to sum up there is only one security measure on the system and it fully delegated to method of remote services. But amount of service is huge. Amount of public methods is really huge and so it become really difficult to manage security service of system according to this information. So we know all inputs of system, we know all possible security measures of system so it's time to find vulnerabilities. In the list of remote services there is one which looks some attractive, it's admin service. It can be accessed with an anonymous session inside it has public method run script. This method doesn't perform any privilege checks. So we can call it without any credentials and so on. At first step this method create instance of class loader using bytes from arguments. And in fact this step will load arbitrary Java class. This class should implement interface admin script and defined method execute. And this method execute will be called by run script of remote services. For this case we create Java class that simply run OS common from arguments of run script. And we get code execution on system with system write. Of course there is more powerful post exploitation of this vulnerability than simply run OS common. You can, this vulnerability allows inject arbitrary Java class inside running SPPA application. So you can use some Java reflection to patch some variables of system and have influence of on technological process of SPPA. Also privilege check inside methods of remote service can be bypassed with second vulnerability in session service. This service has public method of get login sessions. In fact this method return all session data of all login users on system, this information includes user names, IP and client ID. So if in this amount there is client ID of user that has some admin privileges, attacker can use this client ID to get reference to security service and this reference will be with some more privileged session. Further, attacker can call public method of security service, get all users and get all private information about all users of the system and password has also included in this private information. So to sum up, we have two, both of these vulnerabilities can be accessed through HTTPS and firewalls, rules can be bypassed. In general all communication with RMI services are encrypted, so user names and password has are transferred in plain text. This is more critical for FED client case. Moreover password has doesn't perform any, doesn't have any session protection mechanism, so if attacker can perform man in the middle attack against some user of SPPA and capture the traffic between this user and application server, he can get valid username and password hash of the system and simply reuse this credentials and perform again operation on the system. Moreover, he can change the password of this user. I talk a lot about user names and password hashes, so it's time to understand how these items are organized on the system. Alex? Hello everyone, let's continue our discussion about application server. On the previous slide you can see how remote authentication works. Now, sorry, I repeat. On the previous slide you can see how remote authentication works on the, and now I'm going to tell you about how it's organized locally. After the system, after the system gets started, it begins to read two files, user1.xml and pdata1.xm to get the user list and the password respectively. The user's one file is a simple xml, while pdata1 has a slightly more difficult structure. It's a gzparkive encoded in base64, the right driver civilization object in the gzparkive containing a specific xml. The field of the xml presents on the slide. They are used to calculate hash value and check password during the authentication. On the bottom of the slide you can see password check algorithm in pseudocode. It's a, it's a cryptographic scheme is a typical, is a typical crypt hashing scheme, like in your Linux and Linux machine. It has a number of iterations, soles, and the only one thing that was added is hard code itself, which is the same for all user. The tool for password, the tool to extract password hashes and the parameters from the pdata1 file has been developed. On the slide you can see its output. The tool, the tool can be used during the password auditing to check password, the check weak or dictionary password, and the hash calculation parameters. The tool is available at the link below. Draw the line, draw the line under application server analysis. First, as we have seen, attack surface is really huge and includes a lot of different components. Secondly, it's about remote connections. Whether SPPA has or has no remote connections according to vendors or someone else who told you it, you should check it anyway. And the last thing is attacker has an opportunity to impact power generation process. For example, it can start stop generation, change some output value, or gather some additional information about generation process, and all this action can be done from application server. It's all about application server, and let's start discussion about automation. The main goal of the automation server is to execute real-time automation functions and tasks. Depending on the power plant project architecture and its features, the role of the automation server can be different. We have distinguished three roles. The first one is automation role. They may be slight confusion because the term is used both for server and for its role. But analyzing automation server configuration and publicly available information, we have found that whatever the role is, almost the same hardware and software are used, and we have decided to use this kind of classifications. That seems less confusing to us. At the same time, it's different from the vendor classification. Anyway, meaning automation role, having automation role means that the server is responsible for interaction with input output models, which control and monitor power plant equipment such as turbine, electric generator, some other. The second role is communication. In this role, this role is used for connection the third-party software and system. In other words, it's just a protocol conventer supporting such protocols as Modbus, IEC 101, 104, and some other. And the last role is a migration role. This role is used to connect previous version of SPPA T3000 and other legacy systems such as SPPA T2000 or Teleperum ME. Automation role in automation role, automation server in automation role can be run on Sematic S7 PLC and industrial PC. Other role can be run only on industrial PC. Now let's talk a little more about each role. And let's start with automation role based on PLC. PLC will directly control field devices like walls in turbine and access to them. And access to them is a game over for any security discussion. They usually represent the lowest level in different reference models, such as Purdue model, for example. Any configuration changes and updates for PLC require to stop technological process. So these devices always have security misconfiguration firmware without security updates and unsecure industrial protocols. In case of SPPA, they are S7 protocols LPC data. There are a lot of information about S7 protocols in the internet, but not so much about PLC data protocol. So we had to deal with it and analyzed ourselves. It's not a special protocol for SPPA. When you program your Sematic PLC and need to exchange some data between them in real time, you use this protocol. It's a quite simple protocol and maybe its description is available somewhere in the internet, but we couldn't find it. So just a case show you its structure. Anyway, there are no security mechanism in this protocol. So only obstacle while do the main in the middle attack to spoof data is the sequence number, which we can get from a packet and just fuzz the intimidation. For protocol analysis, we have developed a detector which available at the link below. During the security assessment of PLC configurations, one of the main things which we check is unauthorized access to reading and writing PLC memory. Availability of unauthorized access is determined by position of the mode selector of the PLC and some other configuration parameters. During the previous research conducted one of our colleague, Daniel Parnichev, the privileged matrix has been obtained. They shows unsecured states and configurations of PLC. The tool for gathering information from the PLC over the network and its analysis has been developed by Danila and also available in our repository. Now let's talk about application server based on industrial PC. It's just a Linux box. During the start, it tries to download some additional files from the application server. This file includes JAR files, bar scrapes, some configuration protocols files, and some other. In order to execute JAR files, the PTC PRC virtual machine is used. It's a runtime Java machine, widely spread in industrial, IOT, and military area. PTC PRC contains a head of time compilation mechanism. As a result, JAR files contains a byte code transformation. That's why regular decompiles fails with them. To solve this problem, we have written a PHP script to perform reverse transformation and we have done it successfully. After that, regular decompiles have been successful. Running JARs, open RMI services on the automation server and some of their extension. For example, in case of migration server, the Orion RPC services, which are extension of classic Java RMI services, are used. On the slide, you can see the list of the security issues of automation server based on industrial PTC are presented on the slide. Firstly, as you can see, there is a possibility to spoof downloaded files from application server. The file is downloaded over HTTP and there are no security mechanisms during the process. Secondly, it's about default credentials. You can get access over SSH to server with user CM admin and password CM. Next, it's vulnerabilities in Orion RPC services. These vulnerabilities allow to perform sensitive data exposure and remote execution. And finally, the last group is vulnerabilities found in the software used to fill a migration role for communication with SPP 80 2000, also known as TXP system. With a number of issues on immigration server with old TXP, you are not in magic position. A few words about Orion RPC vulnerabilities. They are in runtime engineering service. This service contains request runtime container method, where the first argument defines the action to be executed. Using the action read file, it's possible to get content of any file from the system. Using the write config file, it's possible to write information to the server. For example, it can be a JAR file, which execute a shell comment from the comment line and using some SPPA specific functions, you can execute these JAR files later. That's all about automation server. To sum up, automation server can be based on PLC or industrial PC. In case of PLC, it's a simple PC. It's a usual PLC with known security issues. In case of industrial PC, it's just a Linux box, which try to download some additional files from the application server and some of them execute with per virtual machine. So far, we haven't mentioned any network equipment using distributed control system. Using the research, we saw a wide variety of network devices and network infrastructure, including switches, firewalls and more rare devices such as data diet, for example. We tried to summarize all this information and got a common SPPA network topology and scam. We have shown in couple usual places of our network devices, but the same devices can be found in other vendors distributed control system. Network devices in industrial network usually have a lot of security issues. The reason for this is that most of them don't require any configuration before start and can be run out of the box. And that's why the things like guestable SNMP community string, credentials for different services, firmware with publicly available exploits and just a lack of security configurations, all these things are usual for network devices and they are usual security issues for industrial network. I think that's all. Now Gleb to sum up our discussion. Thank you. So the topic of power plants is huge. The system is huge and we try to cover this and that is a lot of small things in the talk and everything can be summed up on this slide. Those are just vulnerabilities. As you can see problems in Java, in web applications, in different simple mechanisms that you can exploit to actually directly, even not go into the PLCs or field level, you can impact the process itself. What we don't cover in this talk is actually what havoc or disaster could be caused by attacking such systems because it's actually not that bad. I mean, if we are talking about things like blackouts of the cities or things like this, this is not what you can do with attack on such system because the distribution of the power in the grid is not the, according to the threat model, it's not the problem of the power generation. There should be another regulator who should watch for enough capacity in the network to fill the electricity to the customers. What we are really speaking here is how we can impact, for example, the turbine itself, for example. But we had no access to the real turbine. They're big expensive and we haven't found anyone willing to provide us one so we would destroy it. But the point is we have an educated guess. Like PLCs, they control a lot of parameters of this turbine and the turbine is like a big mechanical monster that is actually self-degrading by working and putting it into different like uncomfortable operating modes will degrade it even faster or it will break it and it's not easy. You can have a spare PLC or some other device, you won't have a spare turbine. So the impact is there but it's not like very huge. So what we tried to do with this research mostly is to understand how we can help the power plant operators out there and we have to find out all the issues and analyzing these infrastructures on the customer side. We understood that all of the installations are actually the same and we can write a very simple do-it-yourself assessment and hopefully even like engineers on the power plants can test themselves. It is very easy like set of steps on two or three pages. You connect to application network, you connect to the automation network, you run the tests, you get the results and afterwards you talk with Siemens or you can fix something by yourselves and basically you don't have to hire like expensive consultants to do the job. You should be able to do it by yourself. We hope that you will be able to do it. Of course like to summarize the whole situation around DCSs, it is if you have seen other industrial solutions like SCADA, like substations anything actually, you would find a lot of similarities and the whole like it will have the same pain points as all other solutions. There is a good document from the IAC 62443 which describes how like power plant operator or asset owner should talk to the system integrator and in the vendor with the vendor in terms of what security they should require and how they should control it. We urge any power plant operator to read this standard and to require security from their vendors and system integrators because nowadays it depends from vendor to vendor, maybe vendor is more interested in the security of the plant or some regulator and like nobody knows how to act, this is the document where which describes how you should talk with all other entities. Of course, read the slides or read the white paper in January, call Siemens, update all systems, change your passwords and configurations, this is actually very easy to at least to shrink the attack surface. A lot of things inside SPPAT 3000 network are modern windows boxes and it's kind of easy to set up some form of monitoring so you should talk to your security operations center, they would be able to look for some logs, not most of the impact that we showed like it was the impact from the Java applications and you won't be able to monitor this with like security events and windows but at least it's still some form of detection process inside your network. And again, finally to summarize, it is not like a problem of one DCS from Siemens, there are exactly the same issues for other vendors not mentioned here. We will release a lot of things today, tomorrow and in January, basically like the big white paper about everything that we found out with recommendations what to do with the word lists, with do-it-yourself security assessments, with a lot of tools. One of the tools would help you to do the research and other tools would help you for example if you're using intrusion detection systems like IDSS, you would be able to parse the protocols and maybe write some signatures for that. We work closely with Siemens, we want to say thank you for the Siemens product search, they did a great job in communications between us and the product team that develops the products of the Siemens SPP-83000 itself. The main outlines from the vendor response is that if you are power plant operator, you should hurry and install a new version 8.2 SP2. There are, Siemens is trying to like educate and to raise awareness inside their customers that first of all they should change passwords, that there are critical vulnerabilities and they should do something with it. And there is not all the problems are fixable by Siemens themselves. There is an, the operator is viable for some of the activities to do, to the security by themselves. So that's actually it. Thank you. Thank you very much. Thank you, Congress. If you have any questions, please welcome. Thank all of you for this excellent talk. We have a short three minutes for questions. If you have questions, please line up at the microphones at the hall. If you're using hearing aids, there is an induction loop at microphone number three. Do we have questions from the internet? Yes. We have a question from our signal angel, please. So we've got a question. With the vulnerabilities found, could you take over those plans from the worldwide web without further mandal attacks? Can you please repeat? A little bit louder, please. Sorry. With the vulnerabilities found, could you take control over those plans without worldwide, from public internet without further mandal attacks? Actually, no, this is some form of a good news. As those systems are exclusively supported by one system integrator, by Siemens, they are more or less protected from the external access. Of course, there would be external access, but it's not that easy to reach it. And of course, we're not talking about internet, we're talking about some corporate networks or things like this. Next question, microphone three, power plant on my planet. And it's kind of bad for the atmosphere, I figured. So my question is, can you skip back to where the red button is to switch it off? And I'm asking for a friend. When I thought about that these materials can be used in this way, but yeah. Specifically, if you have operators or engineers friends on the power plants, you can talk to them. Do we have any more questions from the internet? Any questions from the hall? I guess not. Well then, thank you very much for this talk and a warm round of applause.