Safety control systems practices and examples
There will be no stories about the penetration of cyber terrorists into nuclear facilities and the mass use of cyber weapons to destroy the infrastructure of the enemy. And there will be several ordinary examples from personal practice, according to the currently fashionable safety trend of an automated process control system at a typical Russian average production.
The next article on the safety of industrial systems from Positive has taken up the pen.
www.ptsecurity.ru/download/SCADA_analytics_russian.pdf
And the subsequent Homeric laughter from specialists of the industrial control system
.
asutpforum.ru/viewtopic.php?f=11&t=3239
')
In the discussion of the article there were several typical examples of such basic problems: about mass distribution of Windows systems on servers and workstations scud, about the absence of even antiviruses on them, about the fact that there is no reception against scrap and going down to a lower level of controllers and programmed Sensors can not mess things up. Well, of course, about evil security guards who only drink blood and use meaningless pieces of paper on top :).
The red line is the main idea of ​​the correct approach to ensuring the security of an automated process control system, not the protection of confidential data, but ensuring the continuity of the production process. Very few people are interested in a dump of readings from the temperature sensors of the power units, but to disable these sensors and stop production, this is a more tasty goal for a potential competitor.
Directions to building a security policy can be many. I prefer the following accents.
The first goal of ensuring information security of an automated process control system is to maximize the transfer of all risks of an attack from a remote software-network plane to the plan of the actual physical presence of the attacker. In order for a potential intruder, there was no difference to break this notorious sensor with a hammer, or to approach it with a laptop and reprogram it.
The second goal of ensuring the security of the process control system smoothly arising from the first one is banal protection against a fool :).
Below I will give typical problems that I encountered in my practice when analyzing the security of industrial networks.
1. High risks of viral infections.
When, after analyzing an automated process control system, such a trivial situation was revealed as the absence of anti-virus protection. The answer to the question “Why?” Was, they say, “Why? Only computers load, everything slows down. "
This blissful state lasted until the emergence of an ancient networked p2p worm on the network, which tritely put all that it could with its furious traffic, and production switched to manual control mode (the benefit was such a mode). Moreover, every hour of inactivity could result in significant monetary losses.
2. Lack of blocking of workstations on the physical level.
What is an automated workplace, on typical such average Russian manufacture? This is a banal personal computer on which Windows is spinning and the “picture” of SCADA is stretched over the desktop. The computer at the same time defenseless stands on the operator's table.
On what tricks only the operators do not go so as not to miss the night shift. Attempts to shove spinned flash drives with toys into workstations, trying out various key combinations for folding the SCADA interface (they would have to break the payment terminals!). Operators of automated workplaces are no longer old people, but more and more “advanced” young people.
Saves only the iron box with a lock. Why precisely complete blocking through the iron box? In memory, a fresh example, when poking into the flooded USB ports, the resourceful operator simply unscrewed the screws of the system card and connected to the internal interfaces of the motherboard. :)
3. Insufficient separation between segments of production networks.
Very often I have seen how office and technological tasks spin in one network. There is nothing to even comment on.
4. Multiple points of entry into the network of automated process control systems at the program-network level.
This problem arises from the previous two and usually leads to viral infections, and in particularly bad cases, and to the easy realization of malicious intent. Too many points of connection for portable devices, too many points of contact between networks. Ideally, the entry point to the process control network should be one. Dedicated fully controlled car.
5. Lack of password policy.
The report of Positives talked about standard engineering passwords. These are flowers. Passwords are often simply not set - for convenience. Neither controllers interfaces and SCADA schemes, nor administrative accounts of workstations and servers.
6. Upgrading the network software
Sick question. How many times have you had a server crash as a result of a crooked update? How long did it take to eliminate the joint? And if in the case of any online store, restoring a server after such a failure means a momentary recovery in sales, then an emergency stop of the central control system server for half an hour can lead to a complete restart of the production line, which can last more than one hour (new boilers related preparatory work, etc.). This will be a tangible monetary loss. This, however, will be no different from the actual sabotage. :)
As a result, there can be no automatic update of speech. All updates are tied only to planned production stops for repairs. At the same time, a manual analysis of the required patches is made, and they are distributed throughout the network of the process control system through a single entry point.
This is right, but wrong, “It works and we don’t touch, why do we need to update extra problems!” :)
Incidentally, in the report of Positives, great emphasis was placed on remote attacks on industrial systems, buffer overflow, and so on. But these are flowers in comparison with the holes in windows systems, on which all these components are spinning. I somehow on one AWS-e counted a dozen critical vulnerabilities allowing to seize complete control over the machine.
7. Engineering protection and security.
This is somewhat out of the topic of information security, but since the main idea is to reduce all the risks of an attack from a remote software-network plane and bring them to the plan for a real physical presence, several inexpensive IP cameras on the most critical automated process control system nodes are highly disciplined from hasty making. :)
Now a little about the other side of the coin - insider and bookmarks.
There are always risks of having undocumented bookmarks in the control programs of industrial controllers, a little less, the possibility of an insider and targeted damage to the control programs by service personnel.
Risks difficult-to-close due to the high cost of implementing protection. Very few people will allow an army of wardens and auditors to feed themselves (yes, every warden engineer with a whip and a total code audit).
However, it is very useful to collect and analyze the statistics of the operation of automated process control system nodes for failures.
It may happen that interesting patterns come out. Which then will be opened with interesting consequences, namely the desire to earn some money for "support and restoration" by unscrupulous vendors.
I cannot fail to give an example of an article when, through a closed firmware of the controller, production was wanted to be put “on the headstock”.
The tricky subroutine counted the time interval and stopped the machine tool.
plc4good.org.ua/view_post.php?id=107
copy
www.sendspace.com/file/h4681k
Quote
Judging by the comments, the cases are far from single.
The next article on the safety of industrial systems from Positive has taken up the pen.
www.ptsecurity.ru/download/SCADA_analytics_russian.pdf
And the subsequent Homeric laughter from specialists of the industrial control system
.
asutpforum.ru/viewtopic.php?f=11&t=3239
')
In the discussion of the article there were several typical examples of such basic problems: about mass distribution of Windows systems on servers and workstations scud, about the absence of even antiviruses on them, about the fact that there is no reception against scrap and going down to a lower level of controllers and programmed Sensors can not mess things up. Well, of course, about evil security guards who only drink blood and use meaningless pieces of paper on top :).
The red line is the main idea of ​​the correct approach to ensuring the security of an automated process control system, not the protection of confidential data, but ensuring the continuity of the production process. Very few people are interested in a dump of readings from the temperature sensors of the power units, but to disable these sensors and stop production, this is a more tasty goal for a potential competitor.
Directions to building a security policy can be many. I prefer the following accents.
The first goal of ensuring information security of an automated process control system is to maximize the transfer of all risks of an attack from a remote software-network plane to the plan of the actual physical presence of the attacker. In order for a potential intruder, there was no difference to break this notorious sensor with a hammer, or to approach it with a laptop and reprogram it.
The second goal of ensuring the security of the process control system smoothly arising from the first one is banal protection against a fool :).
Below I will give typical problems that I encountered in my practice when analyzing the security of industrial networks.
1. High risks of viral infections.
When, after analyzing an automated process control system, such a trivial situation was revealed as the absence of anti-virus protection. The answer to the question “Why?” Was, they say, “Why? Only computers load, everything slows down. "
This blissful state lasted until the emergence of an ancient networked p2p worm on the network, which tritely put all that it could with its furious traffic, and production switched to manual control mode (the benefit was such a mode). Moreover, every hour of inactivity could result in significant monetary losses.
2. Lack of blocking of workstations on the physical level.
What is an automated workplace, on typical such average Russian manufacture? This is a banal personal computer on which Windows is spinning and the “picture” of SCADA is stretched over the desktop. The computer at the same time defenseless stands on the operator's table.
On what tricks only the operators do not go so as not to miss the night shift. Attempts to shove spinned flash drives with toys into workstations, trying out various key combinations for folding the SCADA interface (they would have to break the payment terminals!). Operators of automated workplaces are no longer old people, but more and more “advanced” young people.
Saves only the iron box with a lock. Why precisely complete blocking through the iron box? In memory, a fresh example, when poking into the flooded USB ports, the resourceful operator simply unscrewed the screws of the system card and connected to the internal interfaces of the motherboard. :)
3. Insufficient separation between segments of production networks.
Very often I have seen how office and technological tasks spin in one network. There is nothing to even comment on.
4. Multiple points of entry into the network of automated process control systems at the program-network level.
This problem arises from the previous two and usually leads to viral infections, and in particularly bad cases, and to the easy realization of malicious intent. Too many points of connection for portable devices, too many points of contact between networks. Ideally, the entry point to the process control network should be one. Dedicated fully controlled car.
5. Lack of password policy.
The report of Positives talked about standard engineering passwords. These are flowers. Passwords are often simply not set - for convenience. Neither controllers interfaces and SCADA schemes, nor administrative accounts of workstations and servers.
6. Upgrading the network software
Sick question. How many times have you had a server crash as a result of a crooked update? How long did it take to eliminate the joint? And if in the case of any online store, restoring a server after such a failure means a momentary recovery in sales, then an emergency stop of the central control system server for half an hour can lead to a complete restart of the production line, which can last more than one hour (new boilers related preparatory work, etc.). This will be a tangible monetary loss. This, however, will be no different from the actual sabotage. :)
As a result, there can be no automatic update of speech. All updates are tied only to planned production stops for repairs. At the same time, a manual analysis of the required patches is made, and they are distributed throughout the network of the process control system through a single entry point.
This is right, but wrong, “It works and we don’t touch, why do we need to update extra problems!” :)
Incidentally, in the report of Positives, great emphasis was placed on remote attacks on industrial systems, buffer overflow, and so on. But these are flowers in comparison with the holes in windows systems, on which all these components are spinning. I somehow on one AWS-e counted a dozen critical vulnerabilities allowing to seize complete control over the machine.
7. Engineering protection and security.
This is somewhat out of the topic of information security, but since the main idea is to reduce all the risks of an attack from a remote software-network plane and bring them to the plan for a real physical presence, several inexpensive IP cameras on the most critical automated process control system nodes are highly disciplined from hasty making. :)
Now a little about the other side of the coin - insider and bookmarks.
There are always risks of having undocumented bookmarks in the control programs of industrial controllers, a little less, the possibility of an insider and targeted damage to the control programs by service personnel.
Risks difficult-to-close due to the high cost of implementing protection. Very few people will allow an army of wardens and auditors to feed themselves (yes, every warden engineer with a whip and a total code audit).
However, it is very useful to collect and analyze the statistics of the operation of automated process control system nodes for failures.
It may happen that interesting patterns come out. Which then will be opened with interesting consequences, namely the desire to earn some money for "support and restoration" by unscrupulous vendors.
I cannot fail to give an example of an article when, through a closed firmware of the controller, production was wanted to be put “on the headstock”.
The tricky subroutine counted the time interval and stopped the machine tool.
plc4good.org.ua/view_post.php?id=107
copy
www.sendspace.com/file/h4681k
Quote
There is a timer code for 360 work shifts of 8 hours. The timer counts only when some output is turned on, such as turning on the hydraulic pump of the pressure booster, that is, when the machine is running. When the timer counts to the end, a flag is set with the address M13.0 :), like, all guys, pay money! What is this, if not extortion!
Judging by the comments, the cases are far from single.
Source: https://habr.com/ru/post/170221/
All Articles