Source: http://www.readbag.com/ncs-library-tech-bulletins-2004-tib-04-1
Timestamp: 2019-09-18 11:48:57
Document Index: 718102238

Matched Legal Cases: ['art 1', 'art 2', 'art 3', 'art 4', 'art 1', 'art 2']

Read Microsoft Word - SCADATIBFinalReport.doc
Read Microsoft Word - SCADATIBFinalReport.doc text version
NCS TIB 04-1
The National Communications System (NCS), Technology and Programs Division (N2) develops and implements national level programs that provide for an enduring and effective telecommunications infrastructure to fulfill National Security and Emergency Preparedness (NS/EP) requirements under all circumstances. It also develops and implements plans for technology development, procedures, and strategic architectures. These improve the reliability, interoperability, and infrastructure protection of the Federal Government's owned or commercially provided NS/EP telecommunications and related Information Systems (IS) resources, ensuring the Federal Government receives the maximum benefit of emerging technologies. Technologies are also evaluated for their use in NS/EP and Critical Infrastructure Protection (CIP) missions. N2 analyzes new technologies that may offer substantial operational and performance improvement for NS/EP applications. SCADA systems have been used in the Utilities industry in the United States (U.S.) since the 1960s. These systems are used to monitor critical infrastructure systems and provide early warning of potential disaster situations. One of the most important aspects of SCADA has been its ability to evolve with the ever-changing face of technology that is now referred to as Information Technology (IT) systems. SCADA has evolved from a monolithic architecture to a networked architecture. This Technical Information Bulletin (TIB) focuses on: · · · · · Introducing the concepts of SCADA systems Identifying what components make up a typical SCADA system Plotting the evolution of SCADA systems through its monolithic, distributed, and networked evolution Looking at the ways in which a SCADA system can be deployed Examining the protocols used in these systems currently as well as the standards and potential future SCADA protocols
Based upon the analysis in this TIB, the following generalized observations and conclusions are as follows: · · SCADA systems have been around since the 1960s and have evolved as technology changes Today's SCADA systems are able to take advantage of the evolution from mainframe-based to client/server architectures. These systems use common communications protocols like Ethernet and TCP/IP to transmit data from the field to the master control unit.
· SCADA protocols have also evolved from closed proprietary systems to an open system allowing designers to choose equipment that can help them monitor their unique system using equipment from mixed vendors The NCS should: · Undertake to analyze IEC 60870-5, DNP3, and UCA 2.0 to see which one may suit their NS/EP and CIP missions best · Monitor and participate as appropriate in the IEEE standards process as it relates to SCADA systems, which are being developed through the IEEE Power Engineering Society · Participate in the ANSI-HSSP. This panel is looking into refining and creating standards critical to Homeland Security. They are looking at Utilities in particular which heavily utilize SCADA systems. · Monitor and participate as appropriate in the IEC standards process as it relates to SCADA systems. More specifically, participate in the development of the UCA 2.0 specification. Specific conclusions and recommendations are contained in Sections 8 and 9.
The National Communications System (NCS) was established through a Presidential Memorandum signed by President John Kennedy on August 21, 1963. The memorandum assigned NCS the responsibility of providing necessary communications for the Federal Government under national emergency conditions by linking together, improving, and expanding the communication capabilities of the various agencies. In April 1984, President Ronald Reagan signed Executive Order (E.O.) 12472, Assignment of National Security and Emergency Preparedness (NS/EP) Telecommunications Functions, which broadened the mission and focus of the National Communications System. Since that time, the NCS has been assisting the President and the Executive Office of the President (EOP) in exercising wartime and non-wartime emergency telecommunications and in coordinating the planning for, and provisioning of, NS/EP communications for the Federal Government under all circumstances. In this regard, the Office of the Manager, NCS (OMNCS), particularly its Technology and Programs Division (N2), always seeks to improve the Federal Government's ability to respond to National Security and Emergency Preparedness situations. As part of this mission, the N2 division identifies new technologies that enhance NS/EP communications capabilities and ensures key NS/EP features such as priority, interoperability, reliability, availability, and security are supported by emerging standards. In concert with this approach, the N2 manages the Federal Telecommunications Standards Program. Additionally, the N2 division directs efforts in both NS/EP management and applications services. National Security and Emergency Preparedness requirements fall into the areas [1] [2] as shown in Table 1.1, and are identified in the Convergence Task Force Report [3]. The goal of this Technical Information Bulletin (TIB) is to: · · · Examine Supervisory Control and Data Acquisition (SCADA) systems Describe how SCADA systems have evolved since being deployed in the 1960s Examine how SCADA protocols have evolved from strictly proprietary to the development of open protocols which allow equipment from various manufacturers to work together Addresses the security aspects of SCADA systems Examines the standards that currently exist or are being drafted to help support the growth of these systems Observations, conclusions, and recommendations on how these technologies could support the NCS and their NS/EP and CIP mission
Voice and data services supporting NS/EP missions should be provided preferential treatment over other traffic These services ensure the availability and survivability of the network, prevent corruption of or unauthorized access to the data, and provide for expanded encryption techniques and user authentication Should a service disruption occur, voice and data services must be capable of being reprovisioned, repaired, or restored to required service levels on a priority basis Voice and data services must provide access to and egress from international carriers Voice and data services must interconnect and interoperate with other government or private facilities, systems, and networks The ability of voice and data infrastructure to support transportable, redeployable, or fully mobile voice and data communications (i.e., Personal Communications Service (PCS), cellular, satellite, High Frequency (HF) radio) Voice and data services must be readily available to support the National security leadership and inter- and intra-agency emergency operations, wherever they are located Voice and data services must be robust to support surviving users under a broad range of circumstances, from the widespread damage of a natural or manmade disaster up to and including nuclear war The service must provide voice band service in support of presidential communications NS/EP users must be able to manage the capacity of the communications services to support variable bandwidth requirements Addressability is the ability to easily route voice and data traffic to NS/EP users regardless of user location or deployment status. Means by which this may be accomplished include &quot;follow me&quot; or functional numbering, call forwarding, and functional directories
SCADA is an acronym for Supervisory Control and Data Acquisition. SCADA systems are used to monitor and control a plant or equipment in industries such as telecommunications, water and waste control, energy, oil and gas refining and transportation. These systems encompass the transfer of data between a SCADA central host computer and a number of Remote Terminal Units (RTUs) and/or Programmable Logic Controllers (PLCs), and the central host and the operator terminals. A SCADA system gathers information (such as where a leak on a pipeline has occurred), transfers the information back to a central site, then alerts the home station that a leak has occurred, carrying out necessary analysis and control, such as determining if the leak is critical, and displaying the information in a logical and organized fashion. These systems can be relatively simple, such as one that monitors environmental conditions of a small office building, or very complex, such as a system that monitors all the activity in a nuclear power plant or the activity of a municipal water system. Traditionally, SCADA systems have made use of the Public Switched Network (PSN) for monitoring purposes. Today many systems are monitored using the infrastructure of the corporate Local Area Network (LAN)/Wide Area Network (WAN). Wireless technologies are now being widely deployed for purposes of monitoring. SCADA systems consist of: · · One or more field data interface devices, usually RTUs, or PLCs, which interface to field sensing devices and local control switchboxes and valve actuators A communications system used to transfer data between field data interface devices and control units and the computers in the SCADA central host. The system can be radio, telephone, cable, satellite, etc., or any combination of these. A central host computer server or servers (sometimes called a SCADA Center, master station, or Master Terminal Unit (MTU) A collection of standard and/or custom software [sometimes called Human Machine Interface (HMI) software or Man Machine Interface (MMI) software] systems used to provide the SCADA central host and operator terminal application, support the communications system, and monitor and control remotely located field data interface devices
Field data interface devices form the &quot;eyes and ears&quot; of a SCADA system. Devices such as reservoir level meters, water flow meters, valve position transmitters, temperature transmitters, power consumption meters, and pressure meters all provide information that can tell an experienced operator how well a water distribution system is performing. In addition, equipment such as electric valve actuators, motor control switchboards, and electronic chemical dosing facilities can be used to form the &quot;hands&quot; of the SCADA system and assist in automating the process of distributing water. However, before any automation or remote monitoring can be achieved, the information that is passed to and from the field data interface devices must be converted to a form that is compatible with the language of the SCADA system. To achieve this, some form of electronic field data interface is required. RTUs, also known as Remote Telemetry Units, provide this interface. They are primarily used to convert electronic signals received from field interface devices into the language (known as the communication protocol) used to transmit the data over a communication channel. The instructions for the automation of field data interface devices, such as pump control logic, are usually stored locally. This is largely due to the limited bandwidth typical of communications links between the SCADA central host computer and the field data interface devices. Such instructions are traditionally held within the PLCs, which have in the past been physically separate from RTUs. A PLC is a device used to automate monitoring and control of industrial facilities. It can be used as a stand-alone or in conjunction with a SCADA or other system. PLCs connect directly to field data interface devices and incorporate programmed intelligence in the form of logical procedures that will be executed in the event of certain field conditions. PLCs have their origins in the automation industry and therefore are often used in manufacturing and process plant applications. The need for PLCs to connect to communication channels was not great in these applications, as they often were only required to replace traditional relay logic systems or pneumatic controllers. SCADA systems, on the other hand, have origins in early telemetry applications, where it was only necessary to know basic information from a remote source. The RTUs connected to these systems had no need for control programming because the local control algorithm was held in the relay switching logic. As PLCs were used more often to replace relay switching logic control systems, telemetry was used more and more with PLCs at the remote sites. It became desirable to influence the program within the PLC through the use of a remote signal. This is in effect the &quot;Supervisory Control&quot; part of the acronym SCADA. Where only a simple local control program was required, it became possible to store this program within the RTU and perform the control within that device. At the same time, traditional PLCs included communications modules that would allow PLCs to report the state of the control program to a computer plugged into the PLC or to a remote computer via a telephone line. PLC and RTU manufacturers therefore compete for the same market. 6
Software products typically used within a SCADA system are as follows: · Central host computer operating system: Software used to control the central host computer hardware. The software can be based on UNIX or other popular operating systems. Operator terminal operating system: Software used to control the central host computer hardware. The software is usually the same as the central host computer operating system. This software, along with that for the central host computer, usually contributes to the networking of the central host and the operator terminals. Central host computer application: Software that handles the transmittal and reception of data to and from the RTUs and the central host. The software also provides the graphical user interface which offers site mimic screens, alarm pages, trend pages, and control functions. Operator terminal application: Application that enables users to access information available on the central host computer application. It is usually a subset of the software used on the central host computers. Communications protocol drivers: Software that is usually based within the central host and the RTUs, and is required to control the translation and interpretation of the data between ends of the communications links in the system. The protocol drivers prepare the data for use either at the field devices or the central host end of the system. Communications network management software: Software required to control the communications network and to allow the communications networks themselves to be monitored for performance and failures. RTU automation software: Software that allows engineering staff to configure and maintain the application housed within the RTUs (or PLCs). Most often this includes the local automation application and any data processing tasks that are performed within the RTU.
SCADA systems have evolved in parallel with the growth and sophistication of modern computing technology. The following sections will provide a description of the following three generations of SCADA systems: · · · 3.1 First Generation ­ Monolithic Second Generation ­ Distributed Third Generation ­ Networked Monolithic SCADA Systems
When SCADA systems were first developed, the concept of computing in general centered on &quot;mainframe&quot; systems. Networks were generally non-existent, and each centralized system stood alone. As a result, SCADA systems were standalone systems with virtually no connectivity to other systems. The Wide Area Networks (WANs) that were implemented to communicate with remote terminal units (RTUs) were designed with a single purpose in mind­that of communicating with RTUs in the field and nothing else. In addition, WAN protocols in use today were largely unknown at the time. The communication protocols in use on SCADA networks were developed by vendors of RTU equipment and were often proprietary. In addition, these protocols were generally very &quot;lean&quot;, supporting virtually no functionality beyond that required scanning and controlling points within the remote device. Also, it was generally not feasible to intermingle other types of data traffic with RTU communications on the network. Connectivity to the SCADA master station itself was very limited by the system vendor. Connections to the master typically were done at the bus level via a proprietary adapter or controller plugged into the Central Processing Unit (CPU) backplane. Redundancy in these first generation systems was accomplished by the use of two identically equipped mainframe systems, a primary and a backup, connected at the bus level. The standby system's primary function was to monitor the primary and take over in the event of a detected failure. This type of standby operation meant that little or no processing was done on the standby system. Figure 3.1 shows a typical first generation SCADA architecture. 3.2 Distributed SCADA Systems
protocols and making it possible to distribute SCADA functionality across a WAN and not just a LAN. Open standards eliminate a number of the limitations of previous generations of SCADA systems. The utilization of off-the-shelf systems makes it easier for the user to connect third party peripheral devices (such as monitors, printers, disk drives, tape drives, etc.) to the system and/or the network. As they have moved to &quot;open&quot; or &quot;off-the-shelf&quot; systems, SCADA vendors have gradually gotten out of the hardware development business. These vendors have looked to system vendors such as Compaq, Hewlett-Packard, and Sun Microsystems for their expertise in developing the basic computer platforms and operating system software. This allows SCADA vendors to concentrate their development in an area where they can add specific value to the system­that of SCADA master station software. The major improvement in third generation SCADA systems comes from the use of WAN protocols such as the Internet Protocol (IP) for communication between the master station and communications equipment. This allows the portion of the master station that is responsible for communications with the field devices to be separated from the master station &quot;proper&quot; across a WAN. Vendors are now producing RTUs that can communicate with the master station using an Ethernet connection. Figure 3.3 represents a networked SCADA system.
In a SCADA system, the RTU accepts commands to operate control points, sets analog output levels, and responds to requests. It provides status, analog and accumulated data to the SCADA master station. The data representations sent are not identified in any fashion other than by unique addressing. The addressing is designed to correlate with the SCADA master station database. The RTU has no knowledge of which unique parameters it is monitoring in the real world. It simply monitors certain points and stores the information in a local addressing scheme. The SCADA master station is the part of the system that should &quot;know&quot; that the first status point of RTU number 27 is the status of a certain circuit breaker of a given substation. This represents the predominant SCADA systems and protocols in use in the utility industry today. Each protocol consists of two message sets or pairs. One set forms the master protocol, containing the valid statements for master station initiation or response, and the other set is the RTU protocol, containing the valid statements an RTU can initiate and respond to. In most but not all cases, these pairs can be considered a poll or request for information or action and a confirming response. The SCADA protocol between master and RTU forms a viable model for RTU-toIntelligent Electronic Device (IED) communications. Currently, in industry, there are several different protocols in use. The most popular are International Electrotechnical Commission (IEC) 60870-5 series, specifically IEC 60870-5-101 (commonly referred to as 101) and Distributed Network Protocol version 3 (DNP3). 4.1 IEC 60870-5-101
IEC 60870-5 specifies a number of frame formats and services that may be provided at different layers. IEC 60870-5 is based on a three-layer Enhanced Performance Architecture (EPA) reference model (see Figure 4.1) for efficient implementation within RTUs, meters, relays, and other Intelligent Electronic Devices (IEDs). Additionally, IEC 60870-5 defines basic application functionality for a user layer, which is situated between the Open System Interconnection (OSI) application layer and the application program. This user layer adds interoperability for such functions as clock synchronization and file transfers. The following descriptions provide the basic scope of each of the five documents in the base IEC 60870-5 telecontrol transmission protocol specification set. Standard profiles are necessary for uniform application of the IEC 60870-5 standards. A profile is a set of parameters defining the way a device acts. Such profiles have been and are being created. The 101 profile is described in detail following the description of the applicable standards.
Figure 4.1: Enhanced Performance Architecture · IEC 60870-5-1 (1990-02) specifies the basic requirements for services to be provided by the data link and physical layers for telecontrol applications. In particular, it specifies standards on coding, formatting, and synchronizing data frames of variable and fixed lengths that meet specified data integrity requirements. IEC-60870-5-2 (1992-04) offers a selection of link transmission procedures using a control field and optional address field; the address field is optional because some point-to-point topologies do not require either source or destination addressing. IEC 60870-5-3 (1992-09) specifies rules for structuring application data units in transmission frames of telecontrol systems. These rules are presented as generic standards that may be used to support a great variety of present and future telecontrol applications. This section of IEC 60870-5 describes the general structure of
application data and basic rules to specify application data units without specifying details about information fields and their contents. · IEC 60870-5-4 (1993-08) provides rules for defining information data elements and a common set of information elements, particularly digital and analog process variables that are frequently used in telecontrol applications. IEC 60870-5-5 (1995-06) defines basic application functions that perform standard procedures for telecontrol systems, which are procedures that reside beyond layer 7 (application layer) of the ISO reference model. These utilize standard services of the application layer. The specifications in IEC 60870-5-5 (1995-06) serve as basic standards for application profiles that are then created in detail for specific telecontrol tasks.
Each application profile will use a specific selection of the defined functions. Any basic application functions not found in a standards document but necessary for defining certain telecontrol applications should be specified within the profile. Examples of such telecontrol functions include station initialization, cyclic data transmission, data acquisition by polling, clock synchronization, and station configuration. The Standard 101 Profile provides structures that are also directly applicable to the interface between RTUs and IEDs. It contains all the elements of a protocol necessary to provide an unambiguous profile definition so vendors may create products that interoperate fully. At the physical layer, the Standard 101 Profile additionally allows the selection of International Telecommunication Union­Telecommunication Standardization Sector (ITU-T) standards that are compatible with Electronic Industries Association (EIA) standards RS-2321 and RS-4852, and also support fiber optics interfaces. The Standard 101 Profile specifies frame format FT 1.2, chosen from those offered in IEC 60870-5-1 (1990-02) to provide the required data integrity together with the maximum efficiency available for acceptable convenience of implementation. FT 1.2 is basically asynchronous and can be implemented using standard Universal Asynchronous Receiver/Transmitters (UARTs). Formats with both fixed and variable block length are permitted. At the data link layer, the Standard 101 Profile species whether an unbalanced (includes multi-drop) or balanced (includes point-to-point) transmission mode is used together with which link procedures (and corresponding link function codes) are to be used. Also specified is an unambiguous number (address) for each link. The link transmission procedures selected from IEC 60870-5-2 (1992-04) specify that SEND/NO REPLY, SEND/CONFIRM, and REQUEST/RESPOND message transactions should be supported as necessary for the functionality of the end device. Additionally,
used primarily by utilities like the electric companies, but it operates suitably in other areas. The DNP3 is specifically developed for inter-device communication involving SCADA RTUs, and provides for both RTU-to-IED and master-to-RTU/IED. It is based on the three-layer enhanced performance architecture (EPA) model contained in the IEC 608705 standards, with some alterations to meet additional requirements of a variety of users in the electric utility industry. DNP3 was developed with the following goals: · High data integrity. The DNP3 data link layer uses a variation of the IEC 60870-5-1 (1990-02) frame format FT3. Both data link layer frames and application layer messages may be transmitted using confirmed service. Flexible structure. The DNP3 application layer is object-based, with a structure that allows a range of implementations while retaining interoperability. Multiple applications. DNP3 can be used in several modes, including: 1. Polled only 2. Polled report-by-exception 3. Unsolicited report-by-exception (quiescent mode) 4. Mixture of modes 1. through 3. It can also be used with several physical layers, and as a layered protocol is suitable for operation over local and some wide area networks. · Minimized overhead. DNP3 was designed for existing wire-pair data links with operating bit rates as low as 1200 bit/s and attempts to use a minimum of overhead while retaining flexibility. Selection of a data reporting method, such as report-byexception, further reduces overhead. Open standard. DNP3 is a non-proprietary, evolving standard controlled by a users group whose members include RTU, IED, and master station vendors, and representatives of the electric utility and system consulting community.
DNP3 provides the rules for substation computers and master station computers to communicate data and control commands. DNP3 is a non-proprietary protocol that is available to anyone. Only a nominal fee is charged for documentation, but otherwise it is available worldwide with no restrictions. This means a utility can purchase master station and substation computing equipment from any manufacturer and be assured that they will reliably talk to each other. Vendors compete based upon their computer equipment's features, costs and quality factors instead of who has the best protocol. Utilities are not stuck with one manufacturer after the initial sale. The substation computer gathers data for transmission to the master such as: · · · · Binary input data that is useful to monitor two-state devices. For example, a circuit breaker is closed or tripped, or a pipeline pressure alarm shows normal or excessive. Analog input data that conveys voltages, currents, power, reservoir water levels and temperatures Count input data that reports kilowatt hours of energy Files that contain configuration data
The master station issues control commands that take the form of: · · Close or trip a circuit breaker, raise or lower a gate, and open or close a valve Analog output values to set a regulated pressure or set a desired voltage level
DNP3 User's Code DNP3 Software
billing, etc. An objective of the client is to keep its database updated. It accomplishes this by sending requests to the server (slave) asking it to return the values in the server's database. This is termed polling. The server responds to the client's request by transmitting the contents of its database. Arrows are drawn at the bottom of Figure 4.1 showing the direction of the requests (toward the server) and the direction of the responses (toward the client). Later we will discuss systems whereby the slaves transmit responses without being asked. The client and the server shown in Figure 4.3 each have two software layers. The top layer is the DNP3 user layer. In the client, it is the software that interacts between the database and initiates the requests for the server's data. In the server, it is the software that fetches the requested data from the server's database for responding to client requests. It is interesting to note that if no physical separation of the client and server existed, eliminating the DNP3 might be possible by connecting these two upper layers together. However, since physical or possibly logical separation of the client and server exists, DNP3 software is placed at a lower level. The DNP3 user's code uses the DNP3 software for transmission of requests or responses to the matching DNP3 user's code at the other end. Data types and software layers will be discussed later in the report. However, it is important to first examine a few typical system architectures where DNP3 is used. Figure 4.4 shows common system architectures in use today. At the top is a simple oneon-one system having one master station and one slave. The physical connection between the two is typically a dedicated or dial-up telephone line.
DNP3 User's Code DNP3 Application Layer Psuedo Transport Layer DNP3 Link Layer
Figure 4.5: DNP3 Layers [8] The data payload in the link frame contains a pair of CRC octets for every 16 data octets. This provides a high degree of assurance that communication errors can be detected. The maximum number of octets in the data payload is 250, not including CRC octets. (The longest link layer frame is 292 octets if all the CRC and header octets are counted). One often hears the term &quot;link layer confirmation&quot; when DNP3 is discussed. A feature of DNP3's link layer is the ability of the transmitter of the frame to request the receiver to confirm that the frame arrived. Using this feature is optional, and it is often not employed. It provides an extra degree of assurance of reliable communications. If a 26
confirmation is not received, the link layer may retry the transmission. Some disadvantages are the extra time required for confirmation messages and waiting for multiple timeouts when retries are configured. It is the responsibility of the transport layer to break long messages into smaller frames sized for the link layer to transmit, or when receiving, to reassemble frames into the longer messages. In DNP3 the transport layer is incorporated into the application layer. The transport layer requires only a single octet within the message to do its work. Therefore, since the link layer can handle only 250 data octets, and one of those is used for the transport function, then each link layer frame can hold as many as 249 application layer octets. Application layer messages are broken into fragments. Fragment size is determined by the size of the receiving device's buffer. It normally falls between 2048 and 4096 bytes. A message that is larger than one fragment requires multiple fragments. Fragmenting messages is the responsibility of the application layer. Note that an application layer fragment of size 2048 must be broken into 9 frames by the transport layer, and a fragment size of 4096 needs 17 frames. Interestingly, it has been learned by experience that communications are sometimes more successful for systems operating in high noise environments if the fragment size is significantly reduced. The application layer works together with the transport and link layers to enable reliable communications. It provides standardized functions and data formatting with which the user layer above can interact. Before functions, data objects and variations can be discussed, the terms static, events and classes need to be covered. In DNP3, the term static is used with data and refers to the current value. Thus static binary input data refers to the present on or off state of a bi-state device. Static analog input data contains the value of an analog value at the instant it is transmitted. DNP3 allows a request for some or all of the static data stored in a slave device. DNP3 events are associated with something significant happening. Examples are state changes, values exceeding some threshold, snapshots of varying data, transient data and newly available information. An event occurs when a binary input changes from an &quot;on&quot; to an &quot;off&quot; state or when an analog value changes by more than its configured deadband limit. DNP3 provides the ability to report events with and without time stamps so that the client can generate a time sequence report. The user layer can direct DNP3 to request events. Usually, a client is updated more rapidly if it mostly polls for events from the server and only occasionally asks for static data as an integrity measure. The reason updates are faster is because the number of events generated between server interrogations is small and, therefore, less data must be returned to the client.
DNP3 goes a step further by classifying events into three classes. When DNP3 was conceived, class 1 events were considered as having higher priority than class 2 events, and class 2 were higher than class 3 events. While that scheme can be still be configured, some DNP3 users have developed other strategies more favorable to their operation for assigning events into the classes. The user layer can request the application layer to poll for class 1, 2 or 3 events or any combination of them. DNP3 has provisions for representing data in different formats. Examination of analog data formats is helpful to understand the flexibility of DNP3. Static, current value, analog data can be represented by variation numbers as follows: · · · · · · A 32-bit integer value with flag A 16-bit integer value with flag A 32-bit integer value A 16-bit integer value A 32-bit floating point value with flag A 64-bit floating point value with flag
The flag referred to is a single octet with bit fields indicating whether the source is online, value contains are start value, communications are lost with the source, the data is forced and the value is over range. Not all DNP3 devices can transmit or interpret all six variations. DNP3 devices must be able to transmit the simplest variations so that any receiver can interpret the contents. Event analog data can be represented by these variations: · · · · · · · · A 32-bit integer value with flag A 16-bit integer value with flag A 32-bit integer value with flag and event time A 16-bit integer value with flag and event time A 32-bit floating point value with flag A 64-bit floating point value with flag A 32-bit floating point value with flag and event time A 32-bit floating point value with flag and event time
numbers. Static analog values are assigned as object 30, and event analog values are assigned as object 32. Static analog values, object 30, can be formatted in one of 6 variations, and event analog values, object 32, can be formatted in one of 8 variations. When a DNP3 server transmits a message containing response data, the message identifies the object number and variation of every value within the message. Object and variation numbers are also assigned for counters, binary inputs, controls and analog outputs. In fact, all valid data types and formats in DNP3 are identified by object and variation numbers. Defining the allowable objects and variations helps DNP3 assure interoperability between devices. DNP3's basic documentation contains a library of valid objects and their variations. The client's user layer formulates its request for data from the server by telling the application layer what function to perform, like reading, and specifying which objects it wants from the server. The request can specify how many objects it wants or it can specify specific objects or a range of objects from index number X through index number Y. The application layer then passes the request down through the transport layer to the link layer that, in turn, sends the message to the server. The link layer at the server checks the frames for errors and passes them up to the transport layer where the complete message is assembled in the server's application layer. The application layer then tells the user layer which objects and variations were requested. Responses work similarly, in that, the server's user layer fetches the desired data and presents it to the application layer that formats the data into objects and variations. Data is then passed downward, across the communication channel and upward to the client's application layer. Here the data objects are presented to the user layer in a form that is native to the client's database. One area that has not been covered yet is transmission of unsolicited messages. This is a mode of operating where the server spontaneously transmits a response, possibly containing data, without having received a specific request for the data. Not all servers have this capability, but those that do must be configured to operate in this mode. This mode is useful when the system has many slaves and the master requires notification as soon as possible after a change occurs. Rather than waiting for a master station polling cycle to get around to it, the slave simply transmits the change. To configure a system for unsolicited messages, a few basics need to be considered. First, spontaneous transmissions should generally occur infrequently, otherwise, too much contention can occur, and controlling media access via master station polling would be better. The second basic issue is that the server should have some way of knowing whether it can transmit without stepping on someone else's message in progress. DNP3 leaves specification of algorithms to the system implementer. One last area of discussion involves implementation levels. The DNP3 Users Group recognizes that supporting every feature of DNP3 is not necessary for every device. Some devices are limited in memory and speed and do not need specific features, while other
Twisted-pair telecommunications cable is the most popular medium used by utilities and has existed in its present form for many years. The cables are essentially the same as those used by the Telephone Company and contain a number of pairs of conductor. Aerial cables would be more appropriate for installation in the utility's service area since the Utility may own a large number of distribution poles from which the cables could be suspended. The smallest aerial cables can be self-supporting, whereas large aerial cables have to be attached to supporting wires (messengers) by lashing wire. Table 5.1 shows the Twisted-Pair Cable advantages and disadvantages.
Advantages · · · · No licensing, fewer approvals Existing pole Infrastructure Economical for short distances Relatively high channel capacity (up to 1.54 MHz) for short distances · · · ·
Right-of-way clearance required for buried cable Subject to breakage Subject to water ingress Subject to ground potential rise due to power faults and lightning · Failures may be difficult to pinpoint · Inflexible Network Configuration Table 5.1: Twisted-Pair Advantages/Disadvantages [8]
Advantages · No licensing, fewer approvals · · · ·
· Right-of-way clearance required for buried cable Existing pole Infrastructure · Subject to breakage Economical for short distances · Subject to water ingress Higher channel capacity than Twisted- · Subject to ground potential rise due to Pair Metallic power faults and lightning More immune to Radio Frequency (RF) · Failures may be difficult to pinpoint noise interference the Twisted Pair · Inflexible Network Configuration Metallic Table 5.2: Coaxial Cable Advantages/Disadvantages [8]
Fiber optic technology has improved considerably since its inception in 1970. The technology has improved to the point where commercially available fibers have losses less than 0.3 dB/km. Losses of this magnitude, as well as the development of suitable lasers and optical detectors, allow designers to consider fiber optic technologies for systems of 140 km or more without repeaters. Optical fibers consist of an inner core and cladding of silica glass and a plastic jacket that physically protects the fiber. Two types of fibers are usually considered: multi-mode graded index and single-mode step index fiber. Single-mode fiber supports higher signaling speeds than the multi-mode fiber due to its smaller diameter and mode of light propagation. Communication services usually supported by optical fiber include voice, data (low speed), SCADA, protective relaying, telemetering, video conferencing, highspeed data, and telephone switched tie trunks. Optical fiber cables have similar characteristics to twisted-pair communications cables in that aluminum tape or steel-wire armors and polyethylene outer jackets can protect them. However, the inner core is constructed to accommodate the mechanical characteristics of the fibers. Typically, the fibers are placed loosely in semi-rigid tubes, which take the mechanical stress. Special types of fiber optic cables have been developed for the power industry. One type of fiber cable is the Optical Power Ground Wire (OPGW) that is an optical fiber core within the ground or shield wire suspended above transmission lines. Another type of optical fiber cable is the All-Dielectric Self-Supporting (ADSS) cable that is a long-span of all dielectric cables designed to be fastened to high voltage transmission line towers underneath the power conductors. A Wrapped Optical Cable (WOC) is also available that is usually wrapped around the phase conductor or existing ground/earth wire of the transmission or distribution line. In the Utility's case, aerial fiber optic cable can be fastened to the distribution poles under the power lines. Table 5.3 shows the Fiber Optic Cable advantages and disadvantages. 32
· Immune to electromagnetic · Novel technology, i.e. new skills must be interference learned · Immune to ground potential rise · Expensive test equipment · High channel capacity · Inflexible network configuration · Low operating cost · Cable subject to breakage and water ingress · No licensing requirement Table 5.3: Fiber Optic Cable Advantages/Disadvantages [8] The cost per meter of fiber optic systems is expected to continually decrease. The cost of single mode fiber optic cables is now less than multimode fiber optic cable because of the increasing demand for single mode fiber. Conversely, the multimode fiber optic has limited distance and bandwidth characteristics. The fiber optic terminal equipment is simpler and generally less expensive than microwave equipment. Optical transmitters can be either light emitting diodes (LEDs) or laser diodes. They operate at 850, 1310, or 1550 nm wavelengths, depending on the application. Many optical terminals have been developed for the telephone industry for large numbers of channels. There are now a number of products specifically designed for power utilities. These are low capacity terminals that feature surge withstand capabilities and special channel units for tele-protection signaling. Parameters that influence the choice of the type of optical cable to be used are: · · Overhead cable can be OPGW, ADSS, or WOC Underground cable can be duct cable (light, medium, or heavy duty), ADSS for use in a duct, or direct burial cable with armor jacket Power Line Carrier
Advantages · Located where the circuits are required
Disadvantages · Not independent of the power distribution system · Carrier frequencies often not protected on a primary basis · Inherently few channels available
· Equipment installed in utility owned land or structures · Economically attractive for low numbers of channels extending over long distances · Digital PLC has capacity for three to · Expensive on a per channel basis four channels (e.g., two voice and one compared to microwave (normally, over high speed data) four channels) · Analog PLC has capacity for two · Will not propagate through open channels (one voice and one &quot;speech disconnects plus&quot; low speed data) Table 5.4: Power Line Carrier Advantages/Disadvantages [8] 5.5 Satellites
The use of satellites has been investigated for a number of years. The satellites are positioned in geo-stationary orbits above the earth's equator and thus offer continuous coverage over a particular area of the earth. Satellites contain a number of radio transponders which receive and retransmit frequencies to ground stations within its &quot;footprint,&quot; or coverage, on the earth's surface. A network facility on the ground tracks and controls the satellite. Earth stations are comprised of an antenna pointing at the satellite, a radio transceiver with a low-noise amplifier, and baseband equipment. Satellites use both the C-band and the Ku-band. Very Small Aperture Terminal (VSAT) technology has advanced to the point where a much smaller antenna (down to about one meter) can be used for Ku-band communications. This has resulted in the Ku-band being preferred for sites with modest communications requirements. VSAT technology is advancing steadily, and the capital costs have dropped substantially. Continual time-ofuse charges must be considered in the use of satellite communications. Developments in
Advantages · · · · Wide area coverage Easy Access to remote sites Costs independent of distance Low error rates · · · ·
Total dependency on a remote facility Less control over transmission Transmission time delay Reduced transmission during solar equinox · Adaptable to changing network patterns · Continual leasing costs · No right-of-way necessary, earth stations located at premises Table 5.5: Satellite Advantages/Disadvantages [8] 5.6 Leased Telephone Lines
Leased telephone circuits have long been used to meet communications needs. Most organizations use standard telephones connected to the Public Switched Network (PSN) for office communications and for routine voice traffic to stations. Leased dedicated circuits are used for dedicated communication requirements, such as telemetry and SCADA. Wideband channels may be available for high speed data signaling. Circuit characteristics can often be conditioned for many other uses, including voice and various types of low and medium speed data. Table 5.6 shows the Leased Circuit advantages and disadvantages. Advantages · Small Capital Outlay Disadvantages
· Repair and maintenance is not controlled by the lessee · Maintained circuit quality · Circuits may not be available at some sites · No communications expertise required · Metallic links require protection against ground potential rise · Adaptable to changing traffic patterns · Continual leasing costs Table 5.6: Leased Circuits Advantages/Disadvantages [8] 5.7 Very High Frequency Radio
Advantages · Frequency assignments available · Propagation over non-line-of-sight paths · Low cost radios compared to microwave
Disadvantages · Low channel capacity · Low digital data bit rate · Limited transmission techniques available
· Less stringent waveguide and antenna requirements · Not dependent on power lines and common carriers · Greater field strength coverage patterns than UHF band Table 5.7: VHF Radio Advantages/Disadvantages [8] 5.8 Ultra High Frequency Radio
· Frequency assignments available · Low channel capacity · Propagation possible over non-line-of- · Low digital data bit rate sight paths · Low cost radios compared to · Limited transmission techniques microwave available · Less stringent waveguide and antenna requirements · Not dependent on power lines and common carriers Table 5.8: Point-to-Point UHF Radio Advantages/Disadvantages [8] 5.8.2 Multiple Address Radio Systems
Advantages · Frequency assignments available · Propagation possible over non-line-ofsight paths · Low cost radios compared to microwave · Less stringent waveguide and antenna requirements
Disadvantages · Low channel capacity · Low digital data bit rate · Limited transmission techniques available · Multi-point operation restricts data speed compared to Point-to-Point UHF or dedicated paths between stations
· Not dependent on power lines and common carriers · Lower cost than Point-to-Point media Table 5.9: MARS UHF Radio Advantages/Disadvantages [8] 5.8.3 Spread Spectrum Radio Low power spread spectrum radios3 are allowed to operate in the 902­928 MHz band, 2.4, and 5.3 GHz band without licenses. This has prompted the development of packettype radio networks for data systems, which are appropriate for Digital Multiples System (DMS) applications, such as Distribution Automation (e.g., utilities). There are also systems offered in the 450­470 MHz band by a number of manufacturers. Each band can provide suitable signaling rates and characteristics for DMS communications, although the 900 MHz systems appear to have more advanced features at this time. Table 5.10 shows the Spread Spectrum Radio System advantages and disadvantages.
Advantages · No radio frequency license required
· Subject to interference from co-channel transmitters · Low cost equipment · No primary license status · Limited path lengths because of restrictions on Radio Frequency (RF) power output Table 5.10: Spread Spectrum Radio Advantages/Disadvantages [8] 5.9 Microwave Radio
and data rates, and they are available in either analog or digital transmission technologies. Analog transmission was the first microwave technology available. It is the most mature method of transmission. There have been a number of developments, which have affected the traditional balance between digital and analog technologies. On the analog side, direct-to-baseband analog channel units have been developed to ease the addition of channels to existing multiplexer equipment and to reduce the complexity of modifying the channel plan. On the digital side, products such as digital cross-connects and direct first order hierarchical level access to Private Branch Exchange (PBXs) have reduced costs further and added flexibility. There is also a growing demand for circuits with very high data rates, which can be transported much easier on the digital systems. New protocols and standards are being introduced for utility data communications that are more easily accommodated by digital carrier systems. Therefore, even for light communication traffic routes, digital is judged to be the more appropriate technology for new installations. Services usually supported by microwave communications include voice, data (low speed and high speed), SCADA, compressed video, protective relaying, telemetering, frame relay, Broadband Integrated Services Digital Network (B-ISDN), and fractional T1. In the lower part of the frequency range, microwave radios are designed in both point-topoint and point-to-multipoint configurations. The radios use similar technologies but are configured, operated and controlled differently. Point-to-point radio systems have dedicated transceivers and directional antennas at each end of a link. Point-to-multipoint radio systems have a common master transceiver with a non-directional antenna at the hub of a number of radial links. Point-to-point radios carry a fixed number of channels continuously. The equipment to which the channel interfaces are connected determines channel usage. For instance, they can be fixed, full-time data circuits interconnecting computer systems or telephone exchanges with usage determined by voice traffic. Channels are operational even if the circuits are idle. Point-to-multipoint radios operate like a local area network with a number of shared channels, which are used on a demand basis. Point-to-multipoint radios can operate in several modes: · · · Frequency Division Multiple Access (FDMA) Time Division Multiple Access (TDMA) Code Division Multiple Access (CDMA)
Advantages · High Channel Capacity · Transports high data rates · Circuits added at low unit cost
Disadvantages · Line of sight clearance required · Specialized test equipment and training required · Frequency assignments sometimes unavailable in urban areas · More expensive site development
· Independent from power lines and common carriers · Future standardized high-speed · Limited capacity networks · Not vulnerable to &quot;backhoe fading&quot; · Low right-of-way costs · Simpler installation than cable technology Table 5.11: Microwave Radio Advantages/Disadvantages [8]
SCADA systems have evolved in recent years and are now based on open standards and COTS products. Most SCADA software and hardware vendors have embraced Transmission Control Protocol/Internet Protocol (TCP/IP) and Ethernet communications, and many have encapsulated their proprietary protocols in TCP/IP packets. While all of this evolution towards more open-based standards has made it easier for the industry to integrate various diverse systems together, it has also increased the risks of less technical personnel gaining access and control of these industrial networks. On October 1, 2003 Robert F. Dacey, Director, Information Security Issues at the General Accounting Office (GAO) eluded to this and other issues in his testimony before the Subcommittee on Technology, Information Policy, Intergovernmental Relations, and the Census, House Committee on Government Reform. He said: &quot;For several years, security risks have been reported in control systems, upon which many of the nation's critical infrastructures rely to monitor and control sensitive processes and physical functions. In addition to general cyber threats, which have been steadily increasing, several factors have contributed to the escalation of risks specific to control systems, including the (1) adoption of standardized technologies with known vulnerabilities, (2) connectivity of control systems to other networks, (3) constraints on the use of existing security technologies and practices, (4) insecure remote connections, and (5) widespread availability of technical information about control systems&quot;. [9] There are many tools and techniques that could be used to address these threats, and flexibility of security configurations is a key design consideration. There is no one magic solution for industry. Each entity must determine what their goals are and arrive at a cost effective solution to these issues. 6.1 Attacks Against SCADA Systems
In today's corporate environment, internal networks are used for all corporate communications, including SCADA. SCADA systems are therefore vulnerable to many of the same threats as any TCP/IP-based system. SCADA Administrators and Industrial Systems Analysts are often deceived into thinking that since their industrial networks are on separate systems from the corporate network, they are safe form outside attacks. PLCs and RTUs are usually polled by other 3rd party vendor-specific networks and protocols like RS-232, RS-485, MODBUS4, and DNP, and are usually done over phone lines, leased private frame relay circuits, satellite systems, licensed and spread spectrum radios, and other token-ring bus topology systems. This often gives the SCADA System Administrators a false sense of security since they assume that these end devices are protected by these non-corporate network connections.
Security in an industrial network can be compromised in many places along the system and is most easily compromised at the SCADA host or control room level. SCADA computers logging data out to some back-office database repositories must be on the same physical network as the back-end database systems, or have a path to access these database systems. This means that there is a path back to the SCADA systems and eventually the end devices through their corporate network. Once the corporate network is compromised, then any IP-based device or computer system can be accessed. These connections are open 24x7 to allow full-time logging, which provides an opportunity to attack the SCADA host system with any of the following attacks: · · · · · · · · Use a Denial of Service (DoS) attack to crash the SCADA server leading to shut down condition (System Downtime and Loss of Operations) Delete system files on the SCADA server (System Downtime and Loss of Operations) Plant a Trojan and take complete control of system (Gain complete control of system and be able to issue any commands available to Operators) Log keystrokes from Operators and obtain usernames and passwords (Preparation for future take down) Log any company-sensitive operational data for personal or competition usage (Loss of Corporate Competitive Advantage) Change data points or deceive Operators into thinking control process is out of control and must be shut down (Downtime and Loss of Corporate Data) Modify any logged data in remote database system (Loss of Corporate Data) Use SCADA Server as a launching point to defame and compromise other system components within corporate network. (IP Spoofing)
For a company to protect its infrastructure, it should undertake the development of a security strategy that includes specific steps to protect any SCADA system. Such a strategy may include the following approach. Developing an appropriate SCADA security strategy involves analysis of multiple layers of both the corporate network and SCADA architectures including firewalls, proxy servers, operating systems, application system layers, communications, and policy and procedures. Strategies for SCADA Security should complement the security measures implemented to keep the corporate network secure Figure 6.1 below illustrates the typical corporate network &quot;ring of defenses&quot; and its relationship with the SCADA network. Successful attacks can originate from either Internet paths through the corporate network to the SCADA network, or from internal attacks from within the corporate office. Alternatively, attacks can originate from within the SCADA network from either upstream (applications) or downstream (RTUs) paths. What is an appropriate configuration for one installation may not be cost effective for another. Flexibility and the employment of an integrated and coordinated set of layers are critical in the design of a security approach.
Corporate Network Border Router Firewall Proxy Operating System Applications Policies &amp; Policies &amp; Procedures Procedures SCADA Network SCADA Network Firewall Firewall SCADA Internal Network Operating Systems
SCADA Policies &amp; Procedures
Figure 6.1: Relationship Between Corporate and SCADA Networks [10] Most corporate networks employ a number of security countermeasures to protect their networks. Some of these and a brief description of their functions are as follows: · Border Router and FirewallsFirewalls, properly configured and coordinated, can protect passwords, IP addresses, files and more. However, without a hardened
operating system, hackers can directly penetrate private internal networks or create a Denial of Service condition. · Proxy ServersA Proxy server is an internet server that acts as a firewall, mediating traffic between a protected network and the internet. They are critical to re-create TCP/IP packets before passing them on to, or from, application layer resources such as Hyper Text Transfer Protocol (HTTP) and Simple Mail Transfer Protocol (SMTP). However, the employment of proxy servers will not eliminate the threat of application layer attacks. Operating SystemsOperating systems can be compromised, even with proper patching, to allow network entry as soon as the network is activated. This is due to the fact that operating systems are the core of every computer system and their design and operating characteristics are well known world wide. As a result, operating systems are a prime target for hackers. Further, in- place operating system upgrades are less efficient and secure than design-level migration to new and improved operating systems. ApplicationsApplication layer attacks; i.e., buffer overruns, worms, Trojan Horse programs and malicious Active-X5 code, can incapacitate anti-virus software and bypass the firewall as if it wasn't even there. Policies and ProceduresPolicies and procedures constitute the foundation of security policy infrastructures. They include requiring users to select secure passwords that are not based on a dictionary word and contain at least one symbol, capital letter, and number, and should be over eight characters long. Users should not be allowed to use their spouse, child, or pet's name as their password. The above list is common to all entities that have corporate networks. SCADA systems for the most part coexist on the same corporate network [10]. The following list suggests ways to help protect the SCADA network in conjunction with the corporate network: · SCADA FirewallsSCADA Systems and Industrial Automation Networks, like corporate network operating systems, can be compromised using similar hacking methods. Oftentimes, SCADA systems go down due to other internal software tools or employees who gain access into the SCADA systems, often without any intention to take down these systems. For these reasons, it is suggested that strong firewall protection to wall off your SCADA networking systems from both the internal corporate network and the Internet be implemented. This would provide at least two layers of firewalls between the SCADA networking systems and the Internet. SCADA Internal Network DesignSCADA networks should be segmented off into their own IP segment using smart switches and proper sub-masking techniques to protect the Industrial Automation environment from the other network traffic, such as file and print commands. Facilities using Wireless Ethernet and Wired Equivalent Protocol (WEP) should change the default name of the Service Set Identifier6 (SSID).
This will at least require someone driving by with a wireless card to know the name of the SSID, and have the appropriate encryption key for the wireless network. · SCADA Server Operating SystemsSimply installing a firewall or segmenting SCADA IP addresses will not ensure their SCADA Infrastructure is secure. An experienced hacker can often bypass firewalls with ease and can even use Address Resolution Protocol (ARP) trap utilities to steal Media Access Control (MAC) addresses. The hacker can also deploy IP spoofing techniques to maneuver through switched networks. Operating systems running the SCADA applications must also be maintained. SCADA applications on Windows NT, 2000, or XP are properly patched against the latest vulnerabilities, and that all of the default NULL NT accounts and administrator accounts have been removed or renamed. SCADA applications running in UNIX, LINUX, Novell, or any other Operating System (OS), must also be maintained as above. All operating systems have back doors and default access accounts that should be removed and cleaned off of these SCADA Servers. SCADA ApplicationsYou must also address security within the SCADA application itself. Trojan horses and worms can be inserted to attack application systems, and they can be used to manipulate data or issue commands on the server. There have even been cases of Trojan horses being deployed that completely emulate the application. The operator or user thinks that he is clicking on a command to stop a pump or generate a graph of the plant, but he is actually clicking on buttons disguised to look like the SCADA screen, and these buttons start batch files that delete the entire hard drive, or send out pre-derived packets on the SCADA system that turn all outputs to ON or &quot;1&quot; state. Trojan horses and viruses can also be planted through an email opened by another computer in the plan, and then it is silently copied over to adjacent SCADA servers, where they wait until a specified time to run. Many times plant control rooms will have corporate computers with the Internet and email active on them within the same physical room, and network switches as SCADA computers. Methodologies to mitigate against these types of situations are: the use of anti-virus software running on the computer where the SCADA application resides; systems administrators disabling installation of any unauthorized software unless the user has administrator access; and Policies and Procedures applicable to SCADA systems, which are addressed below. SCADA Policies and ProceduresSCADA policies and procedures associated with remote vendor and supervisory access, password management, etc. can significantly impact the vulnerabilities of the SCADA facilities within the SCADA network. Properly developed Policies and Procedures that are enforced will greatly improve the security posture of the SCADA system.
In summary, these multiple &quot;rings of defense&quot; must be configured in a complementary and organized manner, and the planning process should involve a cross-team with senior staff support from operations, facility engineering, and Information Technology (IT). The SCADA Security team should first analyze the current risks and threat at each of the rings of defense, and then initiate a work plan and project to reduce the security risk, while remembering to avoid any major impacts to operations.
The IEEE Standards Association (IEEE-SA) is a membership organization that produces Electrical and IT-Related standards that are used internationally. The IEEE has been involved in standardizing technologies for many years. The following standards have been published by the IEEE with respect to SCADA systems: · IEEE Std 999-1992 ­ IEEE Recommended Practice for Master/Remote Supervisory Control and Data Acquisition (SCADA) Communications. This recommended practice applies to the use of serial digital transmissions by supervisory control and data acquisition (SCADA) systems having geographically dispersed terminals. These types of systems typically utilize dedicated communication channels, such as private microwave channels or leased telephone lines, which are limited to data rates of less then 10,000 b/s. IEEE Std 1379-2000 ­ IEEE Recommended Practice for Data Communications Between Remote Terminal Units and Intelligent Electronic Devices in a Substation. This recommended practice presents a uniform set of guidelines for communications and interoperation of IEDs and RTUs in an electric utility substation. This recommended practice does not establish an underlying communication standard. Instead, it provides a specific limited subset of two existing communication protocols and encourages understanding and timely application. American National Standards Institute
The American National Standards Institute (ANSI) is a private, non-profit organization (501(c)3) that administers and coordinates the U.S. voluntary standardization and conformity assessment system. The Institute's mission is to enhance both the global competitiveness of U.S. business and the U.S. quality of life by promoting and facilitating voluntary consensus standards and conformity assessment systems, and safeguarding their integrity. The mission of The American National Standards Institute's Homeland Security Standards Panel (ANSI-HSSP) is to identify existing consensus standards, or, if none exists, assist the Department of Homeland Security (DHS) and those sectors requesting assistance to accelerate development and adoption of consensus standards critical to homeland security. The ANSI-HSSP promotes a positive, cooperative partnership between the public and private sectors in order to meet the needs of the nation in this critical area. Established by ANSI in February 2003, the ANSI-HSSP's scope is to catalog, promote, accelerate and coordinate the timely development of consensus standards within the
The Electric Power Research Institute (EPRI) was founded in 1973 as a non-profit energy research consortium for the benefit of utility members, their customers, and society. Their mission is to provide science and technology-based solutions of indispensable value to global energy customers by managing a far-reaching program of scientific research, technology development, and product implementation. EPRI is the only science and technology consortium serving the entire energy industryfrom energy conversion to end usein every region of the world. With expertise in a wide spectrum of scientific research, technology development, and product application, they are able to offer solutions that cut across traditional boundaries, taking advantage of the latest advances in many fields. EPRI provides the knowledge, tools, and expertise you need to build competitive advantage, address environmental challenges, open up new business opportunities, and meet the needs of your energy customers. The (EPRI) has developed The Utility Communications Architecture (UCA) to integrate communications for &quot;real-time&quot; utility operations for SCADA systems. The UCA is the only existing protocol that provides interoperability among different monitoring and control equipment and interconnectivity among databases for utility operations. The UCA Version 2 Specification has been recently published by the Institute of Electrical and Electronic Engineers (IEEE) Standards Board as Technical Report TR1550. EPRI takes great pride that the UCA technology has been published by the IEEE. In addition, UCA is in review by the International Electrotechnical Commission (IEC) to become the international standard for integrated utility operations. The new UCA Version 2 includes four parts that are published in two volumes, as follows: · TR1550 Volume 1: Part 1: Introduction to UCA (TM) Version 2.0; Part 2: UCA (TM) Profiles; Part 3: UCA (TM) Common Application Service Models (CASM). And TR1550 Volume 2: Part 4: UCA (TM) Generic Object Models for Substation and Feeder Equipment (GOMSFE) Part 1: Introduction. Gives an overview of the UCA Version 2. This document presents a background, philosophy, and applications of UCA to provide a basic understanding of UCA. Part 2: Profiles. Presents the profiles and protocols for various communication media, including local area networks, radio, fiber optic, and telephone; including guidelines on the use of the Internet protocols in a UCA context.
The International Electrotechnical Commission (IEC) Technical Committee 57 Working Group 03 (TC57 WG03) was chartered to develop protocol standards for telecontrol, teleprotection, and associated telecommunications for electric utility systems, and it has created IEC 60870-5, a group of five utility-specific protocol standards. IEC 60870-5 specifies a number of links, frame formats, and services that may be provided at each of three layers. IEC 60870-5 uses the concept of a three-layer enhanced performance architecture (EPA) reference model for efficiency of implementation in devices such as RTUs, meters, relays, etc. used in SCADA systems. IEC 60870-5 specifies a number of frame formats and services that may be provided at different layers. IEC 60870-5 is based on a three-layer EPA reference model for efficient implementation within RTUs, meters, relays, and other IEDs. Additionally, IEC 60870-5 defines basic application functionality for a user layer, which is situated between the OSI application layer and the application program. This user layer adds interoperability for such functions as clock synchronization and file transfers. The following descriptions provide the basic scope of each of the five documents in the base IEC 60870-5 telecontrol transmission protocol specification set. Standard profiles are necessary for uniform application of the IEC 60870-5 standards. Such profiles have been and are being created. The Standard 101 Profile is described in detail following the description of the applicable standards. · IEC 60870-5-1 (1990-02) specifies the basic requirements for services to be provided by the data link and physical layers for telecontrol applications. In particular, it specifies standards on coding, formatting, and synchronizing data frames of variable and fixed lengths that meet specified data integrity requirements. IEC-60870-5-2 (1992-04) offers a selection of link transmission procedures using a control field and optional address field; the address field is optional because some point-to-point topologies do not require either source or destination addressing. IEC 60870-5-3 (1992-09) specifies rules for structuring application data units in transmission frames of telecontrol systems. These rules are presented as generic standards that may be used to support a great variety of present and future telecontrol applications. This section of IEC 60870-5 describes the general structure of application data and basic rules to specify application data units without specifying details about information fields and their contents.
The development of DNP3 was a comprehensive effort to achieve open, standards-based interoperability between substation computers, RTUs, IEDs (Intelligent Electronic Devices) and master stations (except inter-master station communications) for the electric utility industry for SCADA systems. Also important was the time frame; the need for a solution to meet today's requirements. As ambitious an undertaking as this was, the objective was achieved. Since the inception of DNP, the protocol has also become widely utilized in adjacent industries such as water/waste water, transportation, and the oil and gas industry. DNP3 is based on the standards of the International Electrotechnical Commission (IEC) Technical Committee 57, Working Group 03, who have been working on an OSI 3 layer &quot;Enhanced Performance Architecture&quot; (EPA) protocol standard for telecontrol applications. DNP3 has been designed to be as close to compliant as possible to the standards, as they existed at time of development with the addition of functionality not identified in Europe but needed for current and future North American applications (e.g. limited transport layer functions to support 2K block transfers for IEDs, RF and fiber support). DNP3 has been selected as a Recommended Practice by the IEEE C.2 Task Force; RTU to IED Communications Protocol. DNP3 was developed by Harris, Distributed Automation Products. In November 1993, responsibility for defining further DNP3 specifications and ownership of the DNP3 specifications was turned over to the DNP3 Users Group, a group composed of utilities and vendors who are utilizing the protocol. DNP3 is an open and public protocol. In order to ensure interoperability, longevity and upgradeability of protocol, the DNP3 User Group has taken ownership of the protocol and assumes responsibility for its evolution. The DNP3 User Group Technical Committee
evaluates suggested modifications or additions to the protocol and then amends the protocol description as directed by the User Group members. Complete documentation of the protocol is available to the public. The four core documents that define DNP3 are: Data Link Layer Protocol Description, Transport Functions, Application Layer Protocol Description, and Data Object Library (referred to as the &quot;Basic 4 Document&quot;). The User Group also has available to members the document &quot;DNP3 Subset Definitions&quot; which will help implementors identify protocol elements that should be implemented.
This TIB has presented an overview of SCADA system, relevant to the NCS in support of their NS/EP and CIP missions. SCADA systems have been used for years in the utilities industry with great success. Now more than ever, it is important that our critical infrastructures such as power grids, water processing systems, and the Public Switched Network (PSN), be monitored and protected. SCADA architectures, protocols, typical deployments, and security vulnerability concerns have been addressed. The following observations and conclusions are provided: · Today's SCADA systems are able to take advantage of the evolution from mainframe based to client/server architectures. These systems use common communications protocols like Ethernet and TCP/IP to transmit data from the field to the central master control unit. SCADA protocols have also evolved from closed proprietary systems to an open system, allowing designers to choose equipment that can help them monitor their unique system using equipment from variety of vendors SCADA systems are widely used to monitor and control U.S. critical infrastructure utilities such as Electrical Power Plants and Water Distribution Centers SCADA systems, like other computer systems, are subject to many common security attacks such as viruses, denial of service, and hijacking of the system Because SCADA systems use leased telephone lines, twisted pair cable, microwave radio, and spread spectrum techniques, they have many of the same security vulnerabilities While SCADA protocols are more open today, there is no clear consensus of which protocol is best. IEC 60870-5 series and DNP3 have many similarities but are not 100% compatible. UCA 2.0, developed by EPRI, has been published by the IEEE as a Technical Report and submitted to IEC for review. UCA is a new SCADA protocol that may replace both DNP3 and IEC 60870-5.
In their current state, SCADA systems may not be fully able to support the NS/EP and CIP missions of the NCS. Several issues need to be addressed, especially in the area of vulnerabilities associated with computer usage and the communications within SCADA systems. To facilitate SCADA systems' ability to support the NS/EP and CIP missions of the NCS, the following are recommended: · · NCS should monitor the development, and make contributions when appropriate, of IEC 60870-5, DNP3, and UCA 2.0 Monitor and participate, as appropriate, in the IEEE standards process as it relates to SCADA systems, especially in security features or requirements with SCADA Standards NCS should participate in the ANSI-HSSP. This panel is looking into refining and creating standards critical to homeland security. They are looking at utilities in particular, which heavily utilize SCADA systems. NCS should look at commissioning additional studies that examine unconventional attacks, such as those using Electro Magnetic Pulse (EMP) weapons, against SCADA system supporting NS/EP and CIP NCS should pursue, with the developers of SCADA protocols, incorporation of security features internal to the protocol rather than external
[1] [2] [3] &quot;Convergence Task Force Report,&quot; President's National Telecommunications Advisory Committee, Washington, DC, June 2001 Security
J. Walrand and P. Varaiya, High Performance Communication Networks, Second Edition, San Francisco: Morgan Kaufmann Publishers, 2000 &quot;Information Technology Progress Impact Task Force Report On Convergence,&quot; President's National Security Telecommunications Advisory Committee, Washington, DC, May 2000 Walski, Thomas M., et. al., Advanced Water Distribution Modeling and Management, Haestad Press, January 2003 McClanahan, R.H., The Benefits of Networked SCADA Systems Utilizing IPEnabled Networks, Rural Electric Power Conference, 2002. 2002 IEEE, 5-7 May 2002 Pages: C5 - C5_7 IEEE Recommended Practice for Data Communications Between Remote Terminal Units and Intelligent Electronic Devices in a Substation, IEEE Std 13792000 (Revision of IEEE Std 1379-1997), 21 September 2000 Curtis, Ken, A., DNP3 Protocol Primer, DNP Users Group, 1 June 2000 Marihart, D.J., Communications Technology Guidelines for EMS/SCADA Systems, Power Delivery, IEEE Transactions on, Volume: 16, Issue: 2, April 2001 Pages: 181­188 &quot;Critical Infrastructure Protection Challenges in Securing Control Systems&quot;, General Accounting Office (GAO) Report, GAO-04-140T, October 1, 2003
DCS, PLC, PC, or PAS?