Abstract
An overview of supervisory control and data acquisition (SCADA) systems is presented and relevant security concerns are addressed. To secure IP-based SCADA systems, it is vital to implement secure architectures which prevent access to the SCADA from corporate IT, in addition to excellent management practices in managing IP-based networks. We give an overall explanation of SCADA systems along with their security concerns and vulnerability. In the case of legacy SCADA systems, the concerns regarding security were minimal since it used proprietary networks; however, since the move of SCADA systems to the Internet, security problems have become an imperative issue, especially problems regarding IP-based systems. We also discuss various forms of threats and vulnerabilities on future SCADA systems applied with IPv6 over low-power, wireless personal area networks (6LoWPANs) and suggest security management methods to overcome these concerns. In order to identify and remove various vulnerabilities and threats to SCADA systems over IP-based wireless sensor networks, especially for 6LoWPAN applications, we examine possible threats and propose proper and precise security management methods.
1. Introduction
A supervisory control and data acquisition (SCADA) system refers to an industrial control system (ICS); it is a common process automation system which is used to gather data from sensors and instruments located at remote sites and to transmit data at a central site for either controlling or monitoring purposes [1]. The collected data is usually viewed on one or more SCADA host computers located at a central or master site. Based on information received from remote stations, automated or operator-driven supervisory commands can be transmitted to remote station control devices, which are often referred to as field devices. SCADA systems are used to monitor and control industrial, infrastructure, or facility-based processes such as telecommunications, water control, oil and gas refining, and transportation. SCADA systems can be relatively simple, such as the one that monitors environmental conditions of a small office building, or incredibly complex, such as a system that monitors all the activity in a nuclear power plant.
Generally, a SCADA system consists of the following components. First, analytical instruments that sense process variables and operating equipment connected to instruments. Second, one or more field data interface devices, usually remote terminal units (RTUs), or programmable logic controllers (PLCs). RTUs connect to sensors in the process, converting sensor signals to digital data and sending digital data to the supervisory system. PLCs are used as field devices because they are more economical, versatile, flexible, and configurable than special-purpose RTUs. Third, communication infrastructure used to transfer data between field data interface devices and control units and the supervisory system. The infrastructure can be radio, telephones, cables, satellites, and so forth, or any combination of these. Fourth, host computers are the center of human monitoring and control of the processe—storing databases and displaying statistical control charts and reports. Host computers are also known as master terminal units (MTUs) or the SCADA server. Fifth, a human-machine interface (HMI) is the apparatus or device which presents process data to a human operator, and through this, the human operator monitors and controls the process. Nowadays, the distinctions between SCADA and the distributed control system (DCS) have mostly disappeared since each has adopted the strengths of the other as networking infrastructure with higher capacity has become available. Figure 1 shows an example of an integrated SCADA system.
Integrated SCADA system.
SCADA systems were designed when concerns for information security measures and protocols were minimal in 1960s. In the past, the systems operated in an isolated environment and relied mainly on proprietary software, hardware, and communication technology. Current SCADA systems are distributed, networked, and dependent on open protocols for the internet, which make them vulnerable to remote cyber terrorism. They are particularly vulnerable to unauthorized access, and we have examined a typical vulnerability and corresponding measures for security and present an example of concrete measures for the security of mass transportation as a critical infrastructure [2]. In the following section, we discuss the key security issues during the development of SCADA systems. A review of SCADA systems evolution allows us to better comprehend various security concerns that exist.
2. Vulnerability of SCADA Systems
In the past, when SCADA systems were independent and vendor-controlled systems with no connections to other systems and when the network protocol was proprietary, only a few people, such as developers and hackers, knew of the existence of SCADA installations. However, the present SCADA systems are widely distributed and networked. Since the systems are dependent on open protocols for the internet, they are vulnerable to external remote cyber threats as discussed in [2]. SCADA systems are different from general information systems in terms of security management. In the risk and security management of general information systems, after analyzing the assets, threats, and vulnerabilities of information systems and calculating the degrees of a risk, security measures are prioritized for calculating the remaining risk. In contrast, for SCADA systems, the analysis of the assets is performed not from the viewpoint of systems but from the viewpoint of target facilities managed and operated.
There are two distinct threats that can affect modern SCADA systems. The first one is the threat of unauthorized access to the control software, whether it is human access or changes made deliberately or unintentionally by virus infections and other software threats existing on the control host machine. The second is the threat of packet access to the network segments hosting SCADA devices. In particular, security researchers are concerned about security and authentication in the design, deployment, and operation of some existing SCADA networks. Moreover, they need to also take into consideration whether the SCADA networks are secured just because they are physically disconnected from the internet. In addition, security researchers are also concerned about the existing security and authentication protocols in the design, deployment, and operation of SCADA networks, with the belief that SCADA systems have the benefit of security through obscurity through the use of specialized protocols and proprietary interfaces.
The following list suggests ways to help protect the SCADA network in conjunction with the corporate network as discussed in [3]. Security measures of SCADA systems in terms of technology can be presented as follows: (1) strict limitations and authority control are needed for external connections, (2) reinforced security for the systems in demilitarized zones (DMZs) as well as for the internal network is recommended, (3) enhancing security using virtual private networks (VPNs) in addition to integrity tools of servers, (4) Minimization of access paths to the internal network and enhanced concentration of monitoring, (5) encryption of emails and locking of files and directories, (6) regular and thorough inspection of security and vulnerability, and (7) developing control and monitoring methods to cope with any contingencies in the SCADA equipment.
3. IP-Based SCADA Systems
One of the main reasons why the Internet Protocol (IP) is enormously successful is that it can be used over virtually any physical media. In complex SCADA architectures, there is a variety of both wired and wireless media and protocols involved in getting data back to the central monitoring site. This allows implementation of strong IP-based SCADA networks over mixed cellular, satellite, and landline systems. SCADA communications can employ various ranges of both wired (telephone lines, optical fibers, ADSL, cables) and wireless media (radio, spread spectrum, cellular, WLAN, or satellite). The choice depends on a number of factors that characterize the existing communication infrastructure. Factors such as existing equipment, connections, available communications at isolated sites, data rates and polling frequency, remoteness of site, installation budget, and ability to accommodate future needs all impact the final decision for SCADA architecture.
A major enhancement in new SCADA systems comes from the use of WAN protocols such as the Internet Protocol for communication between the central station and communications equipment. RTUs can communicate with the master station using an Ethernet connection [1]. Figure 2 shows a networked SCADA system. Another advantage brought about by the distribution of SCADA functionality over a WAN is that of disaster survivability. By distributing the processing across physically separated locations, it becomes feasible to build a SCADA system that can survive a total loss at any one location. Many of the traditional utility devices such as RTUs or even relays are today equipped with Ethernet interfaces. This, however, does not imply that all services can be migrated immediately in a plug-and-play manner to an IP-based communication infrastructure. Differential protection services are known as one of the most delicate applications.
IP-based SCADA system.
Legacy SCADA system components may still work as initially designed. However, new operational and business processes often require new, higher-level functionality not included in the original components. Such extensions, including new physical and logical communication network connections, bear additional risks in terms of cyber security. SCADA systems were traditionally walled off from business systems and operated independently via the operational network only. Prior to the awareness of the risk of possible attacks, this seemed to provide all the protection the SCADA system needed. Their often proprietary character (operating systems, protocols, etc.) were often seen as additional safety assurance.
To run SCADA information over an IP network, various issues have to be considered such as operating equipment types, bandwidth used for SCADA center communication, network redundancy criteria and protection schemes, restoration times in case of failures, and other IP services within the network. There are several relevant advantages brought by IP technology. These advantages include the efficient use of bandwidth to avoid the allocation of capacity where it is not necessary, widely accepted standards based on proven technologies and a high degree of interoperability. Also, reliability is enhanced because in IP networks, packets are instantly rerouted if a node or link fails. Other related advantages are scalability to cope with growth, high degree of freedom to evolve network performance according to the strategic needs of use, optimization of the total cost of ownership, and taking into account initial investments and later costs of operation. Lastly, upgrades, maintenance, and related personnel cost and protection of the investment are secured by the integration of Ethernet/IP over existing transport networks.
Along with advancements in IP technology, IP-based SCADA systems have incorporated various beneficial features as well. These features include unlimited locations for servers and clients where users can install and move their SCADA servers, RTUs, and terminal servers to any site, which gives high flexibility in terms of redundancy and security and in the case of failure in SCADA servers where servers connected to the IP network provide mutual backup for optimized availability. Also, other benefits we can consider are service takeover and remote support as the control centers are not manned during the night. During this period, other regions can either take over the control or supervise log-ins via VPN in case of emergencies. Lastly, savings are obtained through IP-enabled RTUs; many front-end devices are no longer required since a lot of hardware, spares, and cabling can be saved and maintenance costs reduced.
When considering migration from a serial system that uses analog communications to an Ethernet networked environment, it is not as straightforward as simply configuring the PLC, RTU, or field equipment to acknowledge communications from IP networks. Changes will probably need to be made at the front-end processor (FEP) server to switch the SCADA driver from a serial protocol to an Ethernet protocol.
Telecommunications media and hardware may need to be upgraded or replaced, and finally changes will need to be made in the field controller hardware as well. With the shift to IP communications, the risk to cyber threats is much greater since packets can be routed into field devices from other external networks, and attacks no longer require physical access to the analog circuits. Security risks should be considered when migrating to IP-based communications, together with practical steps for ensuring the reliability and security of SCADA systems when leveraging the Ethernet TCP/IP protocols and communications links.
4. Security of IP-Based SCADA Systems
SCADA systems were originally designed to control and monitor industrial processes using proprietary serial protocols. They were normally located away and secluded from other computer systems. However, in recent years, SCADA systems have been connected to corporate networks and the internet. This can enable businesses to monitor line processes and to support and enhance the process of making correct and beneficial decisions. However, the downside of this is that SCADA systems were never designed with security. With IP-based communications, unexpected threats that did not exist with legacy serial communications can occur at any point and anywhere. It is imperative that we understand how to securely design and to manage SCADA systems in internet-based settings and environments [4].
We need to understand why a conventional SCADA system is more vulnerable when connected to an IP-network. All SCADA systems involve sensors, instrumentation, or other metering devices in order to acquire information about the physical processes that they control and monitor. The sensors, instrumentation, and metering devices are connected to field control devices such as PLCs or RTUs. These devices are used to receive physical input signals, voltages, and currents from sensors and instrumentation. They then transmit the signals to digital data and determine the next decision based on predesignated programmed commands or logic of the system operators. The decisions can terminate or initiate other equipment or change system control parameters. These field devices used to be separated and isolated from cyber threats that faced computer systems, as they were initially deployed over serial analog circuits, and the attacker had to make physical contact with the analog circuits to clamp onto the channel and inject serial data into the circuit or otherwise disturb or capture the serial protocol. Unfortunately, cyber threat risks are now much greater with entry into IP communications [2]. With IP communications, packets can be routed into the field devices from anywhere and attackers are no longer required to gain physical access to analog circuits. Therefore, SCADA systems that are networked via IP communications are more vulnerable than serial communications.
To protect SCADA systems from cyber threats, we have to perform the following tasks [4]. (1) The SCADA IP network should be located physically separate from corporate networks and other untrustworthy networks. When physical separation is not possible, logical separation must be applied. Logical separation is more complicated to implement effectively and runs the risk of ineffective configuration. One should avoid the use of the virtual LAN technology for keeping SCADA IP communications logically separated from corporate IP communications, as VLAN technology is not designed as a security measure but as a bandwidth-shaping tool. (2) IP communications that originate from untrustworthy networks from outside the SCADA system networks should terminate in a buffer network. They should not be allowed direct connections with components in the SCADA system networks; devices inside the SCADA system networks should not be able to communicate directly with the internet. Occasionally, existing corporate IT network infrastructure such as switches, routers, and WAN links must be used as a transport method for portions of the SCADA communications. If that is the case, then the SCADA communications should be encrypted and routed through a VPN tunnel that runs through corporate IT or other noncritical networks. Avoid SCADA devices that are dual-homed to two or more networks at different security zones or trust zones. (3) Additionally, when building a complete end-to-end IP network, avoid using devices that use layer 3 separation between SCADA and other noncritical networks. For proper network isolation, operate equipment that can provide a layer 2 separation. Lastly, a solid cyber defense must offer active blocking devices such as firewalls, IPS, and in-line network antivirus appliances. (4) Designs and procedures are another crucial component. Develop quality insurance techniques to ensure that all security requirements are recognized during the design phase and then executed and tested within the final product. In addition, consider using the ISA S99 security levels as a model when constructing SCADA systems based on IP protocols. If remote access to the SCADA system is permitted over an IP-based network, do not allow users to undergo a similar authentication process used to log into the corporate network. Instead, a different authentication procedure should be applied.
Once a unique SCADA IP-based network is designed and constructed; here are eight recommendations to follow to manage security. First, disable unnecessary services which apply to IP-enabled telecommunication devices, network equipment, PLCs, RTUs, protocol gateway converters, and any other embedded device. Second, limit the utilization of clear text protocols such as telnet, ftp, and http. Instead, force the use of encrypted protocols where technically possible. Third, ensure that the latest version of the Simple Network Management Protocol (SNMP) is up to date, since most IP-enabled telecommunication devices are supported for monitoring the health and performance of the devices. Fourth, keep an event log resident on the device and have a copy sent down to the centralized Syslog server. Fifth, consider deploying in-line network appliances at the choke points that perform network intrusion prevention and antivirus functions. In this way one can filter and drop packets and traffic known to be malevolent based on heuristics and signature matches. Sixth, firmware for IP-enabled telecommunications equipment and control devices should be kept up to date with the latest version. Seventh, control devices such as PLCs, RTUs, smart meters, Ethernet I/O, and IP-enabled instrumentation should be employed with an encryption of PIN code. Eighth, any network devices in front of control devices should be given rate-limiting commands to restrict and limit data from flooding the device.
5. Threats to SCADA Systems over 6LoWPAN
One major advantage of the Internet Protocol version 6 (IPv6) is that it provides larger address space. Being a more recent protocol, IPv6 has a few design enhancements over IPv4, particularly in the areas of autoconfiguration, mobility, and extensibility. However, from a security standpoint, IPv6 implementations are much less mature than their IPv4 counterparts, making it likely that a number of vulnerabilities will be discovered and mitigated before their robustness matches that of existing IPv4 implementations [5]. In [6], Hui and Culler presented the design of a complete IPv6-based network architecture for wireless sensor networks and validated the architecture with a production-quality implementation that incorporates many techniques pioneered in the sensor network community. They claimed that IPv6 is better suited to the needs of WSNs than IPv4 in every aspect. Recent efforts within the IETF now make IP over low-power communication links feasible, including IEEE 802.15.4.
RFC 4944 gives a complete description of IPv6 over low-power wireless personal area networks (6LoWPANs), the packet format standardized by the IETF to enable IPv6 communication over LoWPANs [7]. The main 6LoWPAN features are summarized as follows: the compatibility with respect to stateless address autoconfiguration and neighbor discovery, IPv6 header compression and fragmentation, and support for IP-based routing [8]. The internet of the future is an IPv6 network connecting traditional computers and a large number of smart objects. IPv6 enables the Internet of Things (IoT). This IoT will be the foundation of many services and our daily life will depend on its availability and reliable operation. Billions of devices will use direct, secure, always on, and ubiquitous connections [9].
The challenge of implementing secure communication in the IoT must be taken into consideration for a future model of SCADA systems. On the traditional internet, IP security (IPsec) is the established and tested way of securing networks. IPv6 includes optional support for IPsec authentication and encryption, and web services typically make use of secure sockets or transport layer security mechanisms. These techniques may be too complex, especially for simple embedded devices. It is therefore sensible to explore the option of using IPsec as a security mechanism for the IoT. Smart objects are generally added to the internet using 6LoWPAN, which defines IP communication for resource-constrained networks. Therefore, to present security for the IoT based on the trusted and tested IPsec mechanisms, it is essential to define an IPsec extension of 6LoWPAN.
Various possible complications can be found and encountered in WSNs as described in previous sections. Consequently, determining the vulnerability level estimation and the possible countermeasures can be classified as imperative and substantial. Throughout this section, we provide an overview of layer-based security threats for 6LoWPAN and introduce countermeasures regarding attacks for each layer. Threats are possible which target a specific layer in the protocol stack, that is, the physical, data link, network, transport, application layers, or a combination of any of the mentioned. Eavesdropping, tampering, or jamming radio signal are also possible attacks on the physical layer. For this specific situation, enforcing spectrum techniques for radio communication can be used to prevent attacks. Attacks can also target the data link layer by interfering with the cooperation of the layer's protocols. Simply by inducing a collision or contention or by deliberately fragmenting packets to bypass the Intrusion detection system (IDS), an attacker is able to disrupt an entire message. Fortunately, the induction can be prevented by ignoring excessive requests without identifying authenticity or by adopting proper admission control mechanisms. Network layer protocols can extend their connectivity from neighboring nodes to all other nodes within the wireless sensor network range. To prevent incoming attacks such as message interruption, fabrication, and modification, commanding encryption mechanisms should be applied at the network layer. Additional attacks may be brought against routing protocols such as Wormholes, Sinkholes, or Sybil attacks. These attacks are prevented by building a durable key management and securing the routing protocols. At the transport layer, flooding attacks or session hijacking attacks are very possible. They can be inhibited by controlling the number of connections which a node can make or by using proper authentication mechanisms. Attacks including message interception, fabrication and modification, subversion, and malicious code can be aimed at the application. Simple malicious code detection, isolation, and enforcing a strong encryption mechanism are sufficient to prevent these types of attacks.
SCADA systems will utilize 6LoWPAN in the near future. Figure 3 shows an example of the 6LoWPAN architecture model for SCADA systems. In Figure 3, a border router connects a 6LoWPAN to other IP networks. A 6LoWPAN router provides a packet forwarding service to other nodes. 6LoWPAN remote assets (RAs) do not participate in networking and can only assume the role of leaf sensors to cooperatively monitor physical or environmental conditions, such as temperature, sound, vibration, pressure, motion, or pollutants at different locations. By communicating natively with IP, 6LoWPAN networks are connected to other IP networks simply by using IP routers. As shown in Figure 3, 6LoWPANs will normally function on the edge, acting as stub networks. The 6LoWPAN may be connected to other IP networks through one or more border routers that forward IP datagrams between diverse media. Connectivity to other IP networks may be provided through any arbitrary link, including Ethernet, Wi-Fi, GPRS, or satellite. Because 6LoWPAN only specifies operation of IPv6 over IEEE 802.15.4, border routers may also employ stateless IP/ICMP translation [10] or other IPv6 transition mechanisms to connect 6LoWPAN networks to IPv4 networks [11].
6LoWPAN architecture model for SCADA systems.
6. Security Analysis of SCADA Systems over 6LoWPAN
6LoWPAN networks cannot be protected using traditional network security techniques, because the sensor nodes have limited resources and often operate unattended in publicly accessible areas. In fact, some security issues are still to be addressed. Resource scarcity is the main constraint of 6LoWPAN technology and also affects the selection of the most appropriate security countermeasures [12]. To raise security to an acceptable level, appropriate risk management and security planning are needed. Such an approach allows for comparison between different configurations of the system, that is, with or without security countermeasures such that performance cost versus security improvements can be properly considered. In addition, existing IP security technologies have to be simplified to be implemented on 6LoWPAN small devices.
Figure 4 depicts a general overview of 6LoWPAN security model for SCADA systems. The interaction between a SCADA server and a SCADA RA can be done in a specific sequence as shown in Figure 5. The network joining process is the required initiation step to form a 6LoWPAN network. The RA node performs gateway discovery by broadcasting gateway solicitation messages. This process will let the gateway acknowledge the message so that the sensor nodes get bound to the gateway. The autoconfiguration is performed in the neighbor discovery (ND) process during bootstrapping. To protect the network against different forms of attacks, it is critical to discover a secured node. During this phase, sensor networks are vulnerable and exposed to a variety of attacks as noted previously. Providentially, SCADA RAs can utilize predeployed keys at which point an authentication is required upon access to the data, allowing only those who possess authorization permission to access the information. After the network establishes the connection, key management processes can initiate. Once the SCADA server authorizes the network, the server can get data from the node or send actions to it. The node performs the action or sends data to the SCADA server.
General overview of 6LoWPAN security model for SCADA systems.
Simplified request-response communication scheme.
In addition to feasible security threats due to connection to the IP, 6LoWPANs share all the same security challenges of WSNs. For 6LoWPAN, IEEE 802.15.4 uses IPsec (IP security protocol) as a default security protocol. Internet key exchange (IKE), the key management solution for IPsec, is considered to be too large due to great number of signaling messages. Having a smaller packet size and low communication overhead without compromising the security level would be considered as the key management solutions for 6LoWPAN. 6LoWPANs that require medium to low security authentications can use symmetric keys for tightening their security communication. In contrast, in an environment which may require an extreme security protection, like a nuclear power plant monitoring system, one may establish an asymmetric key-based system as it provides higher-level security. Asymmetric key encryption uses two different keys, also known as public/private key pairs, for encryption and decryption. When one of the keys from the key pair is used to encrypt a message, the other key is required to decrypt the message. The private key member of the pair must be kept private and secured. The public key, however, can be distributed to anyone who requests it. The public key of a key pair is often distributed by means of a digital certificate. Thus, if a SCADA master's public key is utilized to encrypt a data, then only SCADA RAs can decrypt the data. If a SCADA RA's private key is used to encrypt data, only a SACADA master's public key will be able to decrypt the data, thus indicating that SCADA RA was successful in encryption. Unfortunately, since public key algorithms are slower compared to symmetric algorithms, it is impractical to use them to encrypt large amounts of data. In practice, public key algorithms are mainly used to encrypt session keys. In the real world, symmetric algorithms are used for encryption and decryption of most data. Riaz et al. presented and evaluated key management schemes against an abroad range of metrics such as energy, resource utilization, scalability, and resilience to node compromises [13]. SCADA security experts may choose appropriate key management schemes depending on the desired outcome.
The intrusion detection system (IDS) must continuously monitor the network for abnormal activities and malicious nodes once the bootstrapping phase between the SCADA master and RAs is established. Once a malicious node has been detected, there exists an additional mechanism requirement to remove such a node. After malicious node isolation or abnormal activity detection, a key management process can be applied like the bootstrapping phase. All these requirements can be fulfilled by using a solid authentication and encryption mechanism.
6LoWPAN security architecture will be augmented with IP security technologies whenever available. IEEE 802.15.4 AES (Advanced Encryption Standard) should be used for 6LoWPAN security architecture in conjunction with IP security whenever available. Modified IPsec may be a feasible option for securing the IoT in terms of packet size, energy consumption, memory usage, and processing time [14]. Currently, AES is the default encryption algorithm as mentioned in 6LoWPAN specifications. IEEE 802.15.4 provides built-in encryption based on the 128-bit AES. A comprehensive but light weight key management system is also required to securely generate, distribute, and update keys to be used by AES. A result of utilizing 6LoWPAN is the proficient extension of IPv6 into wireless embedded domains, thus enabling end-to-end IP networking and features for a wide range of embedded applications, such as IP-based SCADA systems over wireless sensor networks.
7. Conclusions
The supervisory control and data acquisition (SCADA) industry's move into the TCP/IP world has been accelerated with business demand for more open and interoperable systems. Presently, operator consoles, SCADA servers, and control room system components are already most likely connected to an internet network. The last components to move to IP are embedded devices which include field controllers, meters, instrumentation, and telecommunications systems linking the control room with embedded devices in the field. Moving to IP-based communications opens up these devices in the field to other networks and systems. Unfortunately, the risk from cyber threat is therefore much greater, as these devices do not have the ability to support typical security features that most computing systems require (such as antivirus, authentication, encryption, and end-point security) and many do not support network monitoring and logging. Thus, to secure IP-based SCADA systems, it is vital to implement secure architectures which prevent access to the SCADA from corporate IT and other third-party networks and to enforce excellent management practices to manage IP-based networks.
It is worth noting that 6LoWPAN architecture for SCADA systems will be used in several areas such as industrial, military, and environmental applications. In such sensitive and critical environments, acceptable delay, high responsiveness, and reliable results and measurements as well as data and services availabilities will often be required. Disaster survivability is another major advantage brought about by the distribution of SCADA functionality over 6LoWPANs. By distributing processing across physically separate locations, it becomes possible to build a SCADA system that can survive a total loss at any one location. It is imperative that critical infrastructure such as power grids and water processing systems be monitored and protected. SCADA architectures, protocols, typical deployments, and security vulnerability concerns have been addressed in this paper. When considering the use of WSN technology with SCADA and control systems, network redundancy and isolation must be taken into consideration. Depending on the level of risk, various encryption standards can be implemented over telecommunication links, such as the Advanced Encryption Standard (AES). In addition, 6LoWPAN is the efficient extension of IPv6 to make an end-to-end IP networking for IP-based SCADA systems over WSN. We have provided an overview of IP-based SCADA systems as well as SCADA systems over 6LoWPANs and addressed their relevant security concerns. We have also proposed use of public key algorithms to encrypt session keys and symmetric algorithms for encryption and decryption of data for SCADA systems over 6LoWPAN. In order to identify and remove various threats and vulnerabilities to SCADA systems over IP-based WSNs, especially for 6LoWPAN applications, additional and supplementary research and studies on security management methods must be conducted at the national security policy level.
Footnotes
Acknowledgment
This work was supported by the Hansei University.