6XGIZOIGR:)6/6GTJ+ZNKXTKZ4KZ]UXQOTM Somewhere in the middle ground lies a hybrid approach that relies upon both independent CAs and peer-to-peer certification. In such an approach, businesses may act as their own CA, issuing certificates for its employees and trading partners. Alternatively, trading partners may agree to honor certificates signed by trusted third party CAs. This decentralized model most closely mimics today’s typical business relationships, and it is likely the way PKIs will mature. Building a public-key infrastructure is not an easy task. There are a lot of technical details to address – but the concept behind an effective PKI is quite simple: a PKI provides the support elements necessary to enable the use of public-key cryptography. One thing is certain: the public-key infrastructure will eventually – whether directly or indirectly – reach every Internet user. 9ZUXGMKGTJJOYZXOH[ZOUTULV[HROIQK_Y E-commerce transactions don’t always involve parties who share a previously established relationship. For this reason, a PKI provides a means for retrieving certificates. If provided with the identity of the person of interest, the PKI’s directory service will provide the certificate. If the validity of a certificate needs to be verified, the PKI’s certificate directory can also provide the means for obtaining the signer’s certificate. 8K\UIGZOUTULV[HROIQK_Y Occasionally, certificates must be taken out of circulation, or revoked. After a period of time, a certificate will expire. In other cases, an employee may leave the company or a person may suspect that his or her private key has been compromised. In such circumstances, simply waiting for a certificate to expire is not the best option, but it is nearly impossible to physically recall all possible copies of a certificate already in circulation. To address this problem, CAs publish certificate revocation lists (CRLs) and compromised key lists (KRLs). <KXOLOIGZOUTULV[HROIQK_Y The true value of a PKI is that it provides all the pieces necessary to verify certificates. The certification process links public keys to individual entities, directories supply certificates as needed, and revocation mechanisms help ensure that expired or untrustworthy certificates are not used. Certificates are verified where they are used, placing responsibility on all PKI elements to keep current copies of all relevant CRLs and KRLs. In an emerging standard, on-line certificate status protocol (OCSP) servers may take on CRL/KRL tracking responsibilities and perform verification duties when asked. 8KLKXKTIKY /TZKXTKZK^ZXGTKZOTZXGTKZYKI[XOZ_ General Index of Sources http://www-ns.rutgers.edu CERIAS Centre for Education and Research in Information Assurance and Security http://www.cerias.com Notes on hijack detection http://www.netsys.com Network monitoring (network flight recorder) http://www.nfr.com 9KI[XOZ_IUTYOJKXGZOUTY COAST (Computer Operations, Audit and Security Technology) http://www.cs-purdue.edu ISS (Information System Support, Inc.) http://www.iss-md.com CSI (Computer Security Institute) http://www.gocsi.com Network Security Policies http://www.baselinesoft.com CERT Coordination Center (Carnegie Mellon Software Engineering Institute) http://www.cert.org Internet Security Magazine http://www.securecomputing.com An example of specific product updates e.g. Microsoft Office http://officeupdate.microsoft.com +TIX_VZOUT Secure computing http://www.sctc.com VeriSign http://www.verisign.com PGP http://pgp5.mit.edu Entrust http://www.entrust.com ,OXK]GRRYVXU^_YKX\KXYKZI CISCO systems http://www.cisco.com SECURE computing http://securecomputing.com • Security operating systems • Virtual private networking Firewall Report Overview http://www.outlink.com Secure Zone http://www.sctc.com WinGate http://www.wingate.com 15 Process automation Objectives When you have completed study of this chapter you should be able to: • Explain legacy architectures and the factory of the future • Indicate the key elements of the modern Ethernet and TCP/IP architecture 15.1 Background In the past, supervisory control and data acquisition (SCADA) functions were primarily performed by dedicated computer-based SCADA systems. Whereas these systems still do exist and are widely used in industry, the SCADA functions can increasingly be performed by TCP/IP/Ethernet-based systems. The advantage of the latter approach is that the system is open, hence hardware and software components from various vendors can be seamlessly and easily integrated to perform control and data acquisition functions. One of the most far reaching implications of the Internet type approach, is that plants can be controlled and monitored from anywhere on the globe using the technologies that will be discussed in this chapter. Stand-alone SCADA systems are still being marketed. However, SCADA vendors such as WIZNET are now also manufacturing Internet compatible SCADA systems that can easily be integrated into an existing TCP/IP/Ethernet plant automation system. 15.2 Legacy automation architectures Traditionally, automation systems have implemented networking in a hierarchical fashion, with different techniques used for the so-called enterprise, device and ‘fieldbus’ layers. ‘Fieldbus’ is used here in a generic sense, and is printed in quotation marks in order to differentiate it from Foundation Fieldbus. • The enterprise layer is found at the top of the network hierarchy. It provides communication between conventional computers which are used for Process automation 235 applications such as e-mail and database applications. Users with browsers on their PCs could have access to this network. This network could also be connected via a firewall to the Internet in order to facilitate global access • The device layer is found at the bottom of the hierarchy and is used to allow control systems such as PLCs access to the remote input/output (I/O). Devices at this level include PLCs and robots, and the buses are high performance cyclic buses • The ‘fieldbus’ is found at the middle level and comprises networks with different levels of versatility and performance. This level in particular is highly fragmented, with strong proponents for each variant (ProfiBus, FIP, DeviceNet, ControlNet, Modbus Plus) and very little interoperability The interfaces between ‘layers’ require intricate data collection and application gateway techniques. The task of configuring these devices, in addition to configuring the PLCs and enterprise layer computers, provides much scope for confusion and delays. In addition to this, the need for different network hardware and maintenance techniques in the three levels complicates spares holding and technician training. In order to overcome this problem, there is a growing tendency to use a single set of networking techniques (such as Ethernet and TCP/IP), to communicate at and between all three levels. At the enterprise layer, this networking infrastructure is primarily used to transfer large units of information, on an irregular basis. Examples are sending electronic mail messages, downloading web pages, making ad-hoc SQL queries, printing documents, and fetching computer programs from file servers. A particular problem area is the ‘fieldbus’ level. At this level, there is an attempt to mix routine scanning of data values with on-demand signaling of alarm conditions, along with transfer of large items such as control device programs, batch reports and process recipes. Unfortunately, there are many networks used at this level, such as ProfiBus, FIP, Modbus Plus, DeviceNet, Fieldbus Foundation H-1. Even worse, the design characteristics of each are sufficiently different to make seamless interconnection very difficult. In particular, all these networks have their own techniques for addressing, error checking, statistics gathering, and configuration. This imposes complications even when the underlying data itself is handled in a consistent way. One technique commonly used to offset this problem is to divide the information available at each layer into ‘domains’, and have the devices which interconnect these domains be responsible for ‘translating’ requests for information. As an example, the PLC might use its device bus to scan raw input values, and then make a subset of them available as ‘data points’ on the ‘fieldbus’. Similarly, a cell control computer or operator station might scan data points from its various ‘fieldbus’ segments, and make available selected data available in response to queries on the enterprise network. Although these techniques can be made to work, they have a number of significant disadvantages: • The intermediate ‘boxes’, known as gateways or data collectors, need to be configured to handle any data, which is processed through them. This means that if a PLC program is updated, it is necessary to update any HMI or cell controller programs to reflect the changes, otherwise the information reflected to the user level will be incomplete or inconsistent. Often this must be done with little automatic support from the device vendors, who jealously guard the ‘features’ of their data items and resist the attempt to ‘dumb them down’ by conforming to standard naming and attribute conventions 236 Practical TCP/IP and Ethernet Networking • Although devices like PLCs are designed to be extremely reliable, HMI and cell controllers are typically general-purpose computer systems, and will have a higher incidence of failures due to hardware or software problems. When such failures occur (and they will, even if care is taken in hardware design), it is important to be able to configure a replacement system and get it running as rapidly as possible. Many users today experience downtime of many hours if a single gateway or HMI goes down, because of the difficulty of getting a replacement device to the same state as one which failed Typical MTBF (mean time between failures) of general-purpose computer systems are 50 000 hours for hardware and 14 000 hours for software. Typical MTBF for PLC sys- tems are 100 000 hours. At these rates, a plant with 100 PLCs or computers would expect to experience about one failure requiring hardware replacement PER MONTH. Losing a number of hours’ production each month due to hardware problems is an untenable situation. That is why automation vendors consider the ability to reinstall and restart a PLC or control system from virgin hardware in a rapid and reliable way to be mandatory. 15.3 The factory of the future It is widely recognized nowadays that the traditional hierarchical structure of factory automation systems can be replaced with a single network, using the Internet as a model. In this model, all stations can conceivably intercommunicate and all stations can also communicate to the outside world via a firewall. Such a network would obviously be segmented for performance and security. The traditional computer-based gateways separating the three layers (enterprise, device, fieldbus) can now be replaced with dedicated bridges, switches and routers which feature a high degree of reliability. One of the challenges in designing such a network-based solution, is the choice of a common interconnect. This should ideally be universal and vendor neutral and inexpensive to deploy in terms of hardware, cabling and training time. It should facilitate integration of all equipment within the plant, it should be simple to understand and configure, and it should be scalable in performance to support future growth of the network. Five specific areas have to be addressed in order to enable the implementation of fully open (or ‘transparent’) control systems architecture for modern day factories. They are: • The networking protocol stack • Application layer data structures • The use of embedded web servers • The replacement of computer-based gateways with dedicated routers and switches • Network access 15.3.1 The networking protocol stack The ideal choice here is a TCP/IP. This enables integration with the Internet, enabling access to the plant on a global basis. TCP/IP was originally designed for end-to-end connection oriented control over long- haul networks. It is tolerant of wide speed variations. It is compatible with firewalls and proxy servers, which are required for network security. It takes advantage of switching . ‘features’ of their data items and resist the attempt to ‘dumb them down’ by conforming to standard naming and attribute conventions 236 Practical TCP/IP and Ethernet Networking • Although. holding and technician training. In order to overcome this problem, there is a growing tendency to use a single set of networking techniques (such as Ethernet and TCP/IP) , to communicate at and. legacy architectures and the factory of the future • Indicate the key elements of the modern Ethernet and TCP/IP architecture 15.1 Background In the past, supervisory control and data acquisition