Summary:
In the aftermath of the 9/11 tragedy, and with the ever-growing threat of "cyber terrorism", a very important question has arisen concerning the vulnerability of the computer-based, supervisory control systems (SCADA) that are used to monitor and control our water distribution systems, our oil and gas pipelines and our electrical grid. Much has been said and written on this subject, but there is no single answer to that basic question. Depending on the particular characteristics of a given SCADA system, it is more or less susceptible to such an assault. The architecture of such systems have evolved, along with computer technology, over the past twenty years and current designs, although more flexible and functional, may also be more vulnerable. Also, it is important to understand that an attack on such a system can come from "within" just as easily as from an external source. This paper discusses the ways in which a SCADA system can be attacked and what can be done to reduce or eliminate the possibilities of such an attack.
Introduction:
Supervisory control (SCADA) systems have been in use since the early 1970’s as the means for monitoring, and remotely controlling, geographically widely distributed processes such as water treatment and distribution, oil and gas pipelines and electrical power transmission and distribution. In basic architecture these systems all consist of a “central” computer system (generally fully redundant or “fault tolerant”) that communicates, using one or more of a range of possible telecommunication technologies, to numerous, remote, electronic units (called RTUs or remote terminal units) that are interfaced with the field-based process equipment (see Figure 1.0). Over time, through the 1980’s and 1990’s, as microprocessor, Personal Computer and networking technology evolved, the design of SCADA systems changed to incorporate the latest technologies. In the late 1990’s and into the 2000’s the Internet and Internet-based technologies started becoming integrated into SCADA system designs. Today, a modern SCADA system (architecturally) looks more like a corporate IT network than a “real-time” control system (see Figure 1.1). But, the point is that a SCADA system IS a real-time control system and that a successful attack on such a system could have much more serious and widespread consequences (in terms of loss of life and physical damage) than a “denial of service” attack on a corporate web site.
Purpose of an attack:
The purpose of a cyber attack on a SCADA system could range from a hacker trying to prove he can get through your defenses, to a terrorist that wants to damage a major petroleum products transportation pipeline. Possibly someone might set up an attack for espionage (industrial) purposes or to generate “false” information to the SCADA system. The most serious threats are those that intend to either seriously disable the system (which could include generating false data so that operators are unaware of problems developing) or those attempting to commandeer the system to cause damage to the process or equipment being controlled by sending out improper control commands.
SCADA system robustness:
It is important to remember that most SCADA systems are designed with full redundancy and possibly some additional levels of fault tolerance. This is because (for good reasons) people have never fully trusted the reliability of electronic equipment. That means that such a system is going to be harder to “kill” than an ordinary IT server. None the less, if a serious terrorist were targeting a SCADA system, there are “cyber” ways in which to achieve his goal.
Physical security:
This paper will not address physical security, but it would seem obvious that allowing someone, with a chainsaw, axe or shotgun, near your SCADA system, would be a bad idea and should be prevented if at all possible. And actually, physical security is vital, and the topic is deserving of a whole separate white paper. This paper addresses non-physical attacks (things other than physical damage, power outage, etc.) against SCADA systems.
External connections:
With the old, original, SCADA systems the only external connections to the outside world were the telecommunication channels used to “poll”, and communicate with, the RTU equipment at the remote sites (see figure 1.0). The communications technologies used for this could be anything from private, utility-owned and installed, microwave telecom equipment or leased telephone circuits (provided by “Ma Bell” back then) or simply half-duplex, licensed radio. Communications over these circuits was managed using specialized, proprietary, vendor-specific, communication protocols. These protocols included basic error detection and correction capabilities, but nothing that guarantees “secure” communications. Over time, the incompatibility among proprietary protocols, combined with SCADA/RTU vendors going out of business, caused RTU and SCADA system customers to push for “standardized” protocols. In the water/waste-water industry these same factors spurred a widespread migration to PLC (programmable logic controllers) equipment for use as RTUs. These moves were good economic and technical decisions, but they increased the options for a cyber assault. For a protocol to be a “Standard” means that it is well published and documented and available from many sources. Someone with an RTU “test set” (a laptop computer running protocol simulation software) and a compatible radio could, in reality, sit near an RTU site and send out control commands that would be accepted by the RTU as coming from the central SCADA system (see figure 2.0). If s/he could gain access to the telephone circuit into a remote site, it would be even easier to commandeer the RTU. This sort of attack totally ignores the “host” system and goes directly to the locations where control and monitoring is actually being performed. Some types of RTUs, and most PLCs, support the downloading of control logic via their communication ports. This opens up the possibility of a terrorist “reprogramming” a remote unit via this same scheme.
In order to make it easier for the system vendor’s technical and support personnel to correct system software and configuration problems (without traveling to the customer’s site) many SCADA systems starting being delivered with a dial-in telephone port (see Figure 3.0). This allowed a person with the phone number and a valid ID/password, to have administrative-level access to the SCADA system. Worse yet, many such access ports supported a “secret” password/ID known only to the vendor (and anyone who ever worked for that vendor) in case the customer totally messed up the system ID/password files. Hackers with “war dialers” and password cracking software could also attack those ports. Entry to the system via such ports often granted the highest level of system access. But, most hackers come out of the UNIX/Microsoft world as these have been the most prevalent operating system environments since “on-line” systems became widespread in the 1980s (starting with bulletin-board systems and leading to the Internet.) This means that many would have little or no familiarity with the operating systems running in these older SCADA systems. This would limit their access.
As P.C.s started becoming the basis for the operator workstations, it became possible to consider supporting additional P.C.s, remotely connected over dial-up telecommunications circuits, so that a plant manager or engineer could “dial-in” from home with their own P.C., rather than having to run back to the plant or control center in an emergency. As with the maintenance and support “ports”, this capability offered a point of penetration for a would-be hacker. Without having to know anything about protocols, if access to the dial-in communications circuit were gained, this would be a perfect candidate for a "replay" attack whereby messages are recorded and retransmitted later. Most commercial protocol analyzers would suffice for this task. Many UNIX based systems used the X-Window standard for these remote workstations. This meant that anyone with a PC, X-Window software, and access to the communications circuit, would have a full-function operator’s console, typically protected by just an ID/password login.
Since SCADA systems collect a lot of data and generate a lot of reports, it was only reasonable that eventually the SCADA systems would be connected to the business systems for an automatic exchange of this data. In early implementations this might have been done with custom applications software. But, in the past half-dozen years this would have been accomplished with TCP/IP networking and standardized IP applications like “ftp” (file transfer protocol) or XML (web page) data exchanges. Once a system is connected via TCP/IP to another (with any number of others in between them), unless security provisions are enabled, a user on the “other” system has numerous ways to penetrate the target system, much the same as a penetration in through the maintenance port (see Figure 1.1).
Which bring us to the “ultimate” external vulnerability: connectivity to the Internet. As was just mentioned, once a system is connected using TCP/IP networking, a user on any other system on the same network, regardless of how many other computers are “between” them, can gain access to the target system. This is the beauty and power of the Internet “IP” design. But it also means that every wacko, anywhere in the world, with an Internet connection, can be trying to break into your SCADA system. So, unless you make specific provisions with security, if your SCADA system is connected to a system that is connected to a system that is connected to…etc….a system that is connected to the Internet, then YOUR SCADA system is connected to the Internet. This exposes your system to hackers, worms and a variety of cyber attacks.
Most of the old, original SCADA systems (1960s/70s) ran on computers with proprietary, vendor-developed operating systems. Then, in the 1980s, “standard” commercially available operating systems like UNIX and VAX/VMS became available. This made system development and support much easier. But as with standard RTU protocols, this also enabled a large base of people to know a lot about the basic workings of the systems based on this commercial technology. In the past ten years an increasing number of SCADA systems have been based on Microsoft operating system technology. For a number of reasons, hackers just LOVE to assault Microsoft products (many such individuals come out of the UNIX/LINUX world) and there have been (and continue to be) a large number of known and documented security “holes” in Mr. Gates’ software products. These can be exploited if proper protections (such as the latest Microsoft service packs) are not employed.
Internal Threats: Erecting a secure cyber-barrier around your SCADA system is a good idea and not an insignificant effort. But many of the ways in which a SCADA system could be disabled, damaged or used to wreak havoc, would involve an "inside job". It is sad but true that disillusionment with the government, a career, or even a relationship, can set an otherwise “normal” person on a path to do damage. The bombings in Oklahoma City are a pointed reminder of that fact. Although we all want to have trust and confidence in our co-workers, managers and employees, they are only human. And in an economic environment where many companies have “down sized” there are ex-co-workers (and former employees of vendors) out on the street with potentially dangerous knowledge.
An internal threat can be in the form of an accidental action that results in damage, or an intentional action. Good security procedures should make either one less possible. As previously mentioned, this paper won’t address physical security, which includes topics such as access control, credential verification and surveillance. But security procedural issues are a central component of internal threat prevention and include functions like password management and administration.
There are several possible scenarios for inflicting damage to a SCADA system from the “inside”. One way is to introduce malicious software into the system. An employee that brings unauthorized software in from home (possibly downloaded shareware) and puts it into his desktop PC (or a PC that functions as an operator workstation) stands the chance of introducing a virus, worm, Trojan horse or other form of software “infection” into interconnected systems. As operator workstations have evolved into PCs, this has become a definite threat to SCADA systems. Depending on the system design, and the O.S. of the servers, the results of this might only be the loss of the particular PC, or it could spread across the system.
Application programs running in the central SCADA computer often have indirect access to the control outputs of the field-based RTUs. (They can request that the protocol “drivers” issue commands in the same way the operators can command them through the workstation interface.) It is definitely possible, for a person with programming experience on a given SCADA product (available from the system vendor), to develop and introduce an application program that could turn off selected alarms and issue control commands to the field devices (see Figure 4.0). A variation on this would be making modifications to an existing supervisory application so that it does the intended damage. This would generally require detailed, specific knowledge of the target system. A suitably motivated operator could potentially do the same things through his user console, if no one was watching, and he had password authority (although this would not constitute a “cyber” attack). SCADA systems typically provide for multiple “levels” of access authority. Unfortunately password security is often lax and only newer SCADA systems can support two-component (e.g. mag-card in addition to a password) identity authentication.
A similar attack could be made on systems where there are “settings” that get read from the central computer file systems and converted into parameters and commands that are then dispatched to the field RTUs. In the electric utility world these might be setpoints for voltage regulation or commands to cap banks. In the water industry these might be level and pressure setpoints that vary during the daily load swings. If these tables were modified the results would be similar to launching a malicious application program.
An employee with access to the system (and appropriate passwords) could also run system-level utilities (such as a file manager) that would erase essential system software and shut the system down. Although, unless they could delete the redundant system’s software first, the redundant unit would immediately assume control. Most SCADA systems have “watch dog timer” hardware that would be triggered by such actions, but probably only after the damage was done. The efficacy of such an attack is questionable since one would hope that backup copies of the system would be stored locally (and off-site) in a safe and protected location. A system could probably be restored to full operation in about an hour in most cases, presuming that no physical damage was inflicted (probably not a safe assumption). It has also becoming more prevalent for critical SCADA systems to be supported by backup systems, located at alternate geographical sites. Any action that totally shut down the primary SCADA system site (such as an earthquake, flood, terrorist attack or really effective Cyber attack) would cause the backup site to assume control.
As part of the “external” threats, one previously discussed was the potential for reprogramming an RTU or PLC by accessing the polling/communication circuit. A similar action could be taken as part of an inside attack. The files containing the valid programming for RTUs and PLCs could be replaced by “evil” software (see Figure 5.0). This could be done and the files downloaded immediately, or by merely replacing the valid software in the file system, the “evil” software would get downloaded at the next point in time where an RTU or PLC required reloading (not normally a frequent occurrence). An immediate, wholesale download to multiple remotes would have a much greater impact. It is important to remember that not all RTUs and protocols support remote downloading over the telecom channel (but many PLCs do!) In the oil & gas pipeline industry it is not uncommon for RTUs to contain a fair amount of sequence control and regulatory control logic. Replacing this logic with malicious logic, or merely downloading dangerous settings, could inflict damage on pipeline equipment and operations. Again, these sorts of attacks would require high-level access plus a fair degree of system knowledge and expertise.
Summary:
SCADA system vendors, like most of us, never thought that 9/11 and Oklahoma City could happen. Therefore no one designed SCADA systems with integral protections against a cyber attack. They were designed to be tolerant of minor human error and to keep out the honest. Some critical SCADA systems have been architected to survive natural catastrophes, which makes them less likely to totally fail under a cyber assault. The SCADA system technology employed today is much more susceptible to a concerted cyber attack, essentially due to the adoption of “IT” technologies and “standards” into the design of such systems. Many older systems would be nearly immune to a remote cyber attack or much more difficult to attack using conventional hacking methods. The IT world has developed a range of technologies and techniques for protection IT assets. Many of these same approaches can be used to safeguard modern SCADA systems. All SCADA systems are open to internal attacks, although an internal cyber attack (not a physical attack) will generally require a high degree of technical knowledge about the system. Direct attacks on an RTU requires physical access to the communications channels, but if this is obtained, generally any/all protections have been bypassed at that point of access. PLC equipment is also more vulnerable to remote reprogramming due the inherent design of these devices and their origins on the factory floor.
In the aftermath of the 9/11 tragedy, and with the ever-growing threat of "cyber terrorism", a very important question has arisen concerning the vulnerability of the computer-based, supervisory control systems (SCADA) that are used to monitor and control our water distribution systems, our oil and gas pipelines and our electrical grid. Much has been said and written on this subject, but there is no single answer to that basic question. Depending on the particular characteristics of a given SCADA system, it is more or less susceptible to such an assault. The architecture of such systems have evolved, along with computer technology, over the past twenty years and current designs, although more flexible and functional, may also be more vulnerable. Also, it is important to understand that an attack on such a system can come from "within" just as easily as from an external source. This paper discusses the ways in which a SCADA system can be attacked and what can be done to reduce or eliminate the possibilities of such an attack.
Introduction:
Supervisory control (SCADA) systems have been in use since the early 1970’s as the means for monitoring, and remotely controlling, geographically widely distributed processes such as water treatment and distribution, oil and gas pipelines and electrical power transmission and distribution. In basic architecture these systems all consist of a “central” computer system (generally fully redundant or “fault tolerant”) that communicates, using one or more of a range of possible telecommunication technologies, to numerous, remote, electronic units (called RTUs or remote terminal units) that are interfaced with the field-based process equipment (see Figure 1.0). Over time, through the 1980’s and 1990’s, as microprocessor, Personal Computer and networking technology evolved, the design of SCADA systems changed to incorporate the latest technologies. In the late 1990’s and into the 2000’s the Internet and Internet-based technologies started becoming integrated into SCADA system designs. Today, a modern SCADA system (architecturally) looks more like a corporate IT network than a “real-time” control system (see Figure 1.1). But, the point is that a SCADA system IS a real-time control system and that a successful attack on such a system could have much more serious and widespread consequences (in terms of loss of life and physical damage) than a “denial of service” attack on a corporate web site.
Purpose of an attack:
The purpose of a cyber attack on a SCADA system could range from a hacker trying to prove he can get through your defenses, to a terrorist that wants to damage a major petroleum products transportation pipeline. Possibly someone might set up an attack for espionage (industrial) purposes or to generate “false” information to the SCADA system. The most serious threats are those that intend to either seriously disable the system (which could include generating false data so that operators are unaware of problems developing) or those attempting to commandeer the system to cause damage to the process or equipment being controlled by sending out improper control commands.
SCADA system robustness:
It is important to remember that most SCADA systems are designed with full redundancy and possibly some additional levels of fault tolerance. This is because (for good reasons) people have never fully trusted the reliability of electronic equipment. That means that such a system is going to be harder to “kill” than an ordinary IT server. None the less, if a serious terrorist were targeting a SCADA system, there are “cyber” ways in which to achieve his goal.
Physical security:
This paper will not address physical security, but it would seem obvious that allowing someone, with a chainsaw, axe or shotgun, near your SCADA system, would be a bad idea and should be prevented if at all possible. And actually, physical security is vital, and the topic is deserving of a whole separate white paper. This paper addresses non-physical attacks (things other than physical damage, power outage, etc.) against SCADA systems.
External connections:
With the old, original, SCADA systems the only external connections to the outside world were the telecommunication channels used to “poll”, and communicate with, the RTU equipment at the remote sites (see figure 1.0). The communications technologies used for this could be anything from private, utility-owned and installed, microwave telecom equipment or leased telephone circuits (provided by “Ma Bell” back then) or simply half-duplex, licensed radio. Communications over these circuits was managed using specialized, proprietary, vendor-specific, communication protocols. These protocols included basic error detection and correction capabilities, but nothing that guarantees “secure” communications. Over time, the incompatibility among proprietary protocols, combined with SCADA/RTU vendors going out of business, caused RTU and SCADA system customers to push for “standardized” protocols. In the water/waste-water industry these same factors spurred a widespread migration to PLC (programmable logic controllers) equipment for use as RTUs. These moves were good economic and technical decisions, but they increased the options for a cyber assault. For a protocol to be a “Standard” means that it is well published and documented and available from many sources. Someone with an RTU “test set” (a laptop computer running protocol simulation software) and a compatible radio could, in reality, sit near an RTU site and send out control commands that would be accepted by the RTU as coming from the central SCADA system (see figure 2.0). If s/he could gain access to the telephone circuit into a remote site, it would be even easier to commandeer the RTU. This sort of attack totally ignores the “host” system and goes directly to the locations where control and monitoring is actually being performed. Some types of RTUs, and most PLCs, support the downloading of control logic via their communication ports. This opens up the possibility of a terrorist “reprogramming” a remote unit via this same scheme.
In order to make it easier for the system vendor’s technical and support personnel to correct system software and configuration problems (without traveling to the customer’s site) many SCADA systems starting being delivered with a dial-in telephone port (see Figure 3.0). This allowed a person with the phone number and a valid ID/password, to have administrative-level access to the SCADA system. Worse yet, many such access ports supported a “secret” password/ID known only to the vendor (and anyone who ever worked for that vendor) in case the customer totally messed up the system ID/password files. Hackers with “war dialers” and password cracking software could also attack those ports. Entry to the system via such ports often granted the highest level of system access. But, most hackers come out of the UNIX/Microsoft world as these have been the most prevalent operating system environments since “on-line” systems became widespread in the 1980s (starting with bulletin-board systems and leading to the Internet.) This means that many would have little or no familiarity with the operating systems running in these older SCADA systems. This would limit their access.As P.C.s started becoming the basis for the operator workstations, it became possible to consider supporting additional P.C.s, remotely connected over dial-up telecommunications circuits, so that a plant manager or engineer could “dial-in” from home with their own P.C., rather than having to run back to the plant or control center in an emergency. As with the maintenance and support “ports”, this capability offered a point of penetration for a would-be hacker. Without having to know anything about protocols, if access to the dial-in communications circuit were gained, this would be a perfect candidate for a "replay" attack whereby messages are recorded and retransmitted later. Most commercial protocol analyzers would suffice for this task. Many UNIX based systems used the X-Window standard for these remote workstations. This meant that anyone with a PC, X-Window software, and access to the communications circuit, would have a full-function operator’s console, typically protected by just an ID/password login.
Since SCADA systems collect a lot of data and generate a lot of reports, it was only reasonable that eventually the SCADA systems would be connected to the business systems for an automatic exchange of this data. In early implementations this might have been done with custom applications software. But, in the past half-dozen years this would have been accomplished with TCP/IP networking and standardized IP applications like “ftp” (file transfer protocol) or XML (web page) data exchanges. Once a system is connected via TCP/IP to another (with any number of others in between them), unless security provisions are enabled, a user on the “other” system has numerous ways to penetrate the target system, much the same as a penetration in through the maintenance port (see Figure 1.1).
Which bring us to the “ultimate” external vulnerability: connectivity to the Internet. As was just mentioned, once a system is connected using TCP/IP networking, a user on any other system on the same network, regardless of how many other computers are “between” them, can gain access to the target system. This is the beauty and power of the Internet “IP” design. But it also means that every wacko, anywhere in the world, with an Internet connection, can be trying to break into your SCADA system. So, unless you make specific provisions with security, if your SCADA system is connected to a system that is connected to a system that is connected to…etc….a system that is connected to the Internet, then YOUR SCADA system is connected to the Internet. This exposes your system to hackers, worms and a variety of cyber attacks.
Most of the old, original SCADA systems (1960s/70s) ran on computers with proprietary, vendor-developed operating systems. Then, in the 1980s, “standard” commercially available operating systems like UNIX and VAX/VMS became available. This made system development and support much easier. But as with standard RTU protocols, this also enabled a large base of people to know a lot about the basic workings of the systems based on this commercial technology. In the past ten years an increasing number of SCADA systems have been based on Microsoft operating system technology. For a number of reasons, hackers just LOVE to assault Microsoft products (many such individuals come out of the UNIX/LINUX world) and there have been (and continue to be) a large number of known and documented security “holes” in Mr. Gates’ software products. These can be exploited if proper protections (such as the latest Microsoft service packs) are not employed.
Internal Threats: Erecting a secure cyber-barrier around your SCADA system is a good idea and not an insignificant effort. But many of the ways in which a SCADA system could be disabled, damaged or used to wreak havoc, would involve an "inside job". It is sad but true that disillusionment with the government, a career, or even a relationship, can set an otherwise “normal” person on a path to do damage. The bombings in Oklahoma City are a pointed reminder of that fact. Although we all want to have trust and confidence in our co-workers, managers and employees, they are only human. And in an economic environment where many companies have “down sized” there are ex-co-workers (and former employees of vendors) out on the street with potentially dangerous knowledge.
An internal threat can be in the form of an accidental action that results in damage, or an intentional action. Good security procedures should make either one less possible. As previously mentioned, this paper won’t address physical security, which includes topics such as access control, credential verification and surveillance. But security procedural issues are a central component of internal threat prevention and include functions like password management and administration.
There are several possible scenarios for inflicting damage to a SCADA system from the “inside”. One way is to introduce malicious software into the system. An employee that brings unauthorized software in from home (possibly downloaded shareware) and puts it into his desktop PC (or a PC that functions as an operator workstation) stands the chance of introducing a virus, worm, Trojan horse or other form of software “infection” into interconnected systems. As operator workstations have evolved into PCs, this has become a definite threat to SCADA systems. Depending on the system design, and the O.S. of the servers, the results of this might only be the loss of the particular PC, or it could spread across the system.
Application programs running in the central SCADA computer often have indirect access to the control outputs of the field-based RTUs. (They can request that the protocol “drivers” issue commands in the same way the operators can command them through the workstation interface.) It is definitely possible, for a person with programming experience on a given SCADA product (available from the system vendor), to develop and introduce an application program that could turn off selected alarms and issue control commands to the field devices (see Figure 4.0). A variation on this would be making modifications to an existing supervisory application so that it does the intended damage. This would generally require detailed, specific knowledge of the target system. A suitably motivated operator could potentially do the same things through his user console, if no one was watching, and he had password authority (although this would not constitute a “cyber” attack). SCADA systems typically provide for multiple “levels” of access authority. Unfortunately password security is often lax and only newer SCADA systems can support two-component (e.g. mag-card in addition to a password) identity authentication.A similar attack could be made on systems where there are “settings” that get read from the central computer file systems and converted into parameters and commands that are then dispatched to the field RTUs. In the electric utility world these might be setpoints for voltage regulation or commands to cap banks. In the water industry these might be level and pressure setpoints that vary during the daily load swings. If these tables were modified the results would be similar to launching a malicious application program.
An employee with access to the system (and appropriate passwords) could also run system-level utilities (such as a file manager) that would erase essential system software and shut the system down. Although, unless they could delete the redundant system’s software first, the redundant unit would immediately assume control. Most SCADA systems have “watch dog timer” hardware that would be triggered by such actions, but probably only after the damage was done. The efficacy of such an attack is questionable since one would hope that backup copies of the system would be stored locally (and off-site) in a safe and protected location. A system could probably be restored to full operation in about an hour in most cases, presuming that no physical damage was inflicted (probably not a safe assumption). It has also becoming more prevalent for critical SCADA systems to be supported by backup systems, located at alternate geographical sites. Any action that totally shut down the primary SCADA system site (such as an earthquake, flood, terrorist attack or really effective Cyber attack) would cause the backup site to assume control.
As part of the “external” threats, one previously discussed was the potential for reprogramming an RTU or PLC by accessing the polling/communication circuit. A similar action could be taken as part of an inside attack. The files containing the valid programming for RTUs and PLCs could be replaced by “evil” software (see Figure 5.0). This could be done and the files downloaded immediately, or by merely replacing the valid software in the file system, the “evil” software would get downloaded at the next point in time where an RTU or PLC required reloading (not normally a frequent occurrence). An immediate, wholesale download to multiple remotes would have a much greater impact. It is important to remember that not all RTUs and protocols support remote downloading over the telecom channel (but many PLCs do!) In the oil & gas pipeline industry it is not uncommon for RTUs to contain a fair amount of sequence control and regulatory control logic. Replacing this logic with malicious logic, or merely downloading dangerous settings, could inflict damage on pipeline equipment and operations. Again, these sorts of attacks would require high-level access plus a fair degree of system knowledge and expertise.Summary:
SCADA system vendors, like most of us, never thought that 9/11 and Oklahoma City could happen. Therefore no one designed SCADA systems with integral protections against a cyber attack. They were designed to be tolerant of minor human error and to keep out the honest. Some critical SCADA systems have been architected to survive natural catastrophes, which makes them less likely to totally fail under a cyber assault. The SCADA system technology employed today is much more susceptible to a concerted cyber attack, essentially due to the adoption of “IT” technologies and “standards” into the design of such systems. Many older systems would be nearly immune to a remote cyber attack or much more difficult to attack using conventional hacking methods. The IT world has developed a range of technologies and techniques for protection IT assets. Many of these same approaches can be used to safeguard modern SCADA systems. All SCADA systems are open to internal attacks, although an internal cyber attack (not a physical attack) will generally require a high degree of technical knowledge about the system. Direct attacks on an RTU requires physical access to the communications channels, but if this is obtained, generally any/all protections have been bypassed at that point of access. PLC equipment is also more vulnerable to remote reprogramming due the inherent design of these devices and their origins on the factory floor.
