Open Systems

Chapter 49
49.1 Integration of Control and Information Systems
49.2 Standards and Enabling Technologies
49.3 Architecture
49.4 Data Objects
49.5 Object Linking
49.6 Open Process Control
49.7 OPC and the Internet
49.8 Openness and Security
49.9 Information and Control Security
49.10 Information Security Management
49.11 Firewalls
49.12 Demilitarised Zones
49.13 Malware Summary
49.14 Anti-Virus Software
49.15 Comments

An open system is one that is based on widely used
industrial standards. This covers programming
languages, operating systems, display technologies
and communications networks. There are three
principal issues involved in systems being open:
access, inter-operability and security. An open sys-
tem provides unrestricted access, from anywhere
in the system, to data for information and display
purposes. Inter-operability features include:
• Portability of application software, i.e. software
developed for one system capable of being run
on another
• Scalability of hardware, i.e. the ability to migrate
to a different, more powerful, processor without
having to rewrite any software
• Ability to mix and match hardware and software
from different suppliers
Open systems are the antithesis of the mono-
lithic ICS and early DCS systems, as described in
Chapter 38, which were based on proprietary oper-
ating systems and networks.It was difficult enough
to connect one system up to a another from the
same supplier, let alone from a different supplier.
The porting of software and implantation of new
processors was simply out of the question.
49.1 Integration of Control and
Information Systems
The ability to merge and manipulate real-time
data from control systems with cost, quality and
scheduling data from information systems enables
operators and managers to make timely decisions
about processes and production. There is an inex-
orable blurring of the boundaries between tradi-
tional so-called islands of automation, leading to
integration of control and information systems. A
variety of commercial pressures on both end-users
and control system suppliers are reinforcing this
move towards open systems. For example:
 352 49 Open Systems
• Access to on-line control data enables perfor-
mance against increasingly stringent environ-
mental and safety regulations to be monitored
more effectively.
• Advanced control and optimisation techniques
are commonly used to maximise profits. These
techniques are information rich and require ac-
cess to data about costs and production require-
ments.
• Responsiveness to market demands requires
flexibility in processing to meet rapidly chang-
ing production requirements. Thus control
schedules need to take operational constraints
into account.
• Flatter management structures mean that re-
sponsibility for decision making is pushed down
to the lowest levels practicable. This is only pos-
sible if appropriate information is readily acces-
sible at all levels.
• The advent of intelligent instrumentation pro-
vides much more control data than hitherto.
Also, data related to instrument performance is
available, for which there is a requirement for
integration with maintenance planning.
• Control systems’ hardware is increasingly be-
comes a commodity product. To retain prof-
itability, system suppliers are shifting towards
the provision of advanced control techniques
and the integration of control functions with
MIS and CIM capabilities.
• The end-user’s investment in application soft-
ware may well be the most valuable part of a con-
trol system as it represents the intellectual out-
put of some its best engineers. The use of stan-
dard operating systems, languages and proto-
cols enables portability, if not yet between man-
ufacturers but at least between systems from the
same supplier.
• Industrial quality control system hardware has
to be rugged for plant and control room use. Of-
fice equipment, such as PCs and workstations,
is relatively cheap. There are real cost benefits
from being able to mix industrial and commer-
cial equipment in the same system. This is only
possible if they work to the same communica-
tions standards and protocols.
• The cost of developing quality system software is
such that suppliers are entering into third party
agreements rather than develop it themselves.
Thus graphics packages, relational databases,
etc. are supplied as part of a system. This is only
feasible with a common platform.
49.2 Standards and Enabling
Technologies
It is obvious that a necessary prerequisite for open
systems is the existence of common standards,
whether they are of an industry de facto nature or
produced by a standards authority such as IEC or
IEEE. Standards take a long time to develop which,
in part, explains why open systems have taken so
long to come about. This is largely because the is-
sues are complex and it is often difficult to reach
genuine agreement between end-users and suppli-
ers, and between different countries. Choices have
to be made between differing practices and tech-
nologies and invariably there are conflicting inter-
ests. Nevertheless, a set of common standards has
emerged and others are coming to fruition. The
enabling technologies of particular note are:
• Operating systems: Windows 2003/XP, UNIX,
Linux
• Languages: C++, Visual Basic, Java, SQL, IEC
61131, DDL, etc.
• Networks: Ethernet (IEEE 802.3), token bus
(IEEE802.4), fieldbus (IEC 61158), etc.
• Data access: OLE (ActiveX), OPC, etc.
• Data structures: ISA S95 and IEC 61512
49.3 Architecture
The impact of open systems is to flatten the archi-
tecture of control systems into two domains, con-
trol and information, as depicted in Figure 38.11.
Elements at the control level are connected
to a highway which is typically token bus. If the
highway is proprietary and/or non-standard, gate-
ways are required to provide compatibility be-

tween them.Gateways also enable serial links to in-
telligent instruments and to HART,Profibus and/or
fieldbus devices.
The information domain is invariably based on
Ethernet using TCP/IP, as described in Chapter 40,
which is the de facto multivendor network. This
enables any required combination of NT or UNIX
based workstations, X-Windows terminals, com-
puters and file servers to be used.
When all the elements of a system have a
common standard real-time operating system and
common communications and display standards,
data can be accessed and displayed at all levels:
operator displays at management levels and man-
agement displays at operator level,subject to access
control as appropriate. Likewise, data held in rela-
tional databases can be accessed by client-server
techniques at all levels.
An important development is the evolution
of operator control stations (OCS) based on a
ruggedised form of workstation which provides
operators and engineers with a single point of ac-
cess to both control and plant-wide information.
Thus a single workstation doubles up as a human
interface for system development and as an opera-
tors control program (OCP) for control purposes.
It is essential in handling information in the
control domain that the systems are:
• Robust in the sense that the operating systems
do not crash
• Deterministic in that events are guaranteed to
take place on time
• Permanent in the sense that critical software
cannot be corrupted
• Reliable and able to support redundancy if nec-
essary
• Secure from faults in the information system
• Tolerant of operator errors
• Resistant to unauthorised external access
49.4 Data Objects
Data objects are items such as process variables,
function blocks, parameter lists, programs, etc.
They exist as discrete entities within a data base.
49.4 Data Objects 353
The use of data objects is only meaningful in the
context of distributed databases within an open
system in which the objects are globally accessible.
There are various advantages in using data objects:
• Applications can access data in the form of ob-
jects by name only, typically a tag or block num-
ber, without reference to precise data addresses.
• The data object exists as a single point within the
system, thereby ensuring that the data accessed
is up-to-date, complete and consistent.
• A standard application program interface (API)
can be readily defined and provided to third par-
ties so that their applications and devices can be
seamlessly integrated.
• Structured query language (SQL) extensions can
be defined to access data objects within a client-
server architecture which can connect smoothly
and reside securely within larger, enterprise
wide, proprietary relational databases.
49.5 Object Linking
Object linking and embedding (OLE) is an open
standard for connecting applications in a Windows
or UNIX environment. It provides dynamic real-
time links with databases and networks for process
control using standard interfaces. Using OLE con-
cepts, applications can be developed with a stan-
dard interface to other applications developed to
the same standard, thereby offering true software
inter-operability. This is depicted in Figures 49.1
and 49.2 which contrast bespoke customised inter-
faces with OLE based ones.
Application X Application Y
Server A Server B Server C
Fig. 49.1 Customised interfaces
 354 49 Open Systems
Application X Application Y
OLE interface OLE interface
OLE Server A OLE Server B OLE Server C
Fig. 49.2 OLE based interfaces
OLE allows programs to be broken down into ob-
jects, or components, which can be considered as
building blocks. They are built around standard
protocols and hence can communicate with each
other, are platform independent and are reusable.
Components are combined into an application by
a configuration type of process referred to as ag-
gregation. There is no limit to aggregation and ag-
gregated components may themselves aggregate.
OLE permits parallel transfer of data between
applications, with practically no limit to the size of
data block, which is very efficient. This is in stark
contrast with dynamic data exchange (DDE), an-
other Windows standard which relates to computer
aided design (CAD) environments, in which data
transfer is serial and block size is limited. DDE
is unsuitable for most control purposes, although
“fast DDE” does permit multiple block transfers.
OLE-DB incorporates the open database con-
nectivity (ODBC) access interface. It is being de-
veloped to enable corporate databases, either in
computers or of a relational nature in file servers,
to communicate with PC based data. The program-
mer will then be able to use OLE components to
access data anywhere in the organisation.
The OLE standard is now referred to as ActiveX
and its components are referred to as controls.
The Microsoft.Net development environment, us-
ing the Visual Basic language,provides facilities for
accessing and linking ActiveX components. This
enables fully functional systems to be created from
libraries of open components provided by the sup-
pliers of I/O hardware, display systems, etc., and
interfaced with standard packages such as Excel
and Access for calculation and logging.
Developments on the OLE front have caused a
revolution in productivity in the design of systems
for automation, especially in enabling the integra-
tion of control hardware and intelligent devices
with information systems. The cost of putting the
components together in building such systems is
but a fraction of what would be the cost of writing
them in the first place.
49.6 Open Process Control
OLE for process control (OPC) is an open standard
for process control. It focuses on the definition of
the components required for real-time transfer of
data between an OPC server and an OLE compliant
application. An OPC server is simply a device that
collects data that is consistent with the OPC proto-
col and makes that data available simultaneously to
any number of OPC clients. The standard consists
of an evolving set of plug-and-play OLE interfaces
intended for linking DCS, SCADA and PLC type
systems with each other and for integration with
applications such as control and data acquisition.
The objective of OPC is to enable inter-
operability between different automation applica-
tions written in different languages and running on
different platforms anywhere within an open sys-
tem. Fundamental to this objective is acceptance
of information system standards such as ISA S95.
The benefits of OPC are:
• Instrument and system hardware suppliers will
only have to produce one OPC compliant inter-
face for each device.
• Users will be able to choose the best mix of hard-
ware for a given application,
• Suppliers’ costs will be contained because the
same standard components will interface to dif-
ferent hardware.
• Efficient data transfer from devices to applica-
tions.
• Standard techniques for addressing information
in process control systems and devices.

An important extension to OPC is the development
of OPC-DX which acts as a software gateway. Each
device with an OPC-DX interface has both a client
and a server part. The client part consumes data
from other devices for use by its application (read)
and the server part produces data from its device
for other applications (write). Connection of de-
vices using DX interfaces is done by means of a
configuration tool from a library of device types
using drag and drop techniques.
OPC-DX is of particular significance in the
context of intelligent instrumentation. Network-
ing of field devices has resulted in a number of
widely accepted fieldbus protocols such as HART
and Profibus, as explained in Chapter 50, resulting
in the need for multiple bespoke gateways to es-
tablish effective communication with third party
devices. DX offers the prospect of becoming the
de facto API for communication with and between
fieldbus function blocks.
49.7 OPC and the Internet
Increasingly process control systems are being
connected to the internet. This might seem to be
a bizarre thing to do, given the security issues de-
scribed in the following section, but there are good
reasons for doing so. For example, under certain
safety or operability related circumstances, it may
be appropriate for a control system to alert key per-
sonnel to a situation by automatically generating
an e-mail. Sometimes, suppliers have access via the
internet to control systems that they have supplied
for diagnostic and maintenance purposes. Inter-
net connections are increasingly used to abstract
information from a control system into other ap-
plications, such as SPC packages. Access is often
provided over the internet to data within the con-
trol for management purposes.
For internet applications,the hypertext markup
language (HTML) is used to write small programs
(scripts). HTML scripts contain commands which
are executed when the program is run. However,
HTML is a scripting language largely concerned
49.7 OPC and the Internet 355
with display formats and does not support re-
usability of data. For example, if the same data is to
be displayed and printed, two separate script files
must be created with different format instructions
for video and printer.
An important extension to OPC is the extensi-
ble markup language (XML) which allows instruc-
tions to be distinguished from data. OPC XML
scripts enable identifiable packets of data to be
exchanged over the internet. XML is a web ser-
vice technology and control systems suppliers are
starting to incorporate programs written in XML
to distribute process and other data across TCP/IP
networks.
49.8 Openness and Security
The Achilles heel of openness is security. The es-
sential problem is that the more open a system
becomes the more vulnerable it is to unauthorised
access. This is especially so when MIS and (even)
control systems are connected up to intranets and
the internet. There are various dangers which may
be categorised as follows:
• Inadvertent. For example, persons using the in-
ternet to legitimately access data within an MIS,
or functions within a control system, may in-
advertently corrupt data or introduce a virus. A
summary of virus types is provided in Section
13.
• Mischief. Hacking is a well known phenomenon
for which tools and training is readily available.
Hackers are often motivated by the challenge
and satisfaction of breaking into a system rather
than for the damage they can cause. However, a
breach in security is damaging in itself because,
when revealed, usually by a message left by the
hacker, there is uncertainty as to what damage
may have been caused.
• Spying. Use of the internet, by hacking or oth-
erwise, provides access to data in a company’s
MIS.Data such as recipes and production sched-
ules can potentially give a competitor significant
commercial advantage.
 356 49 Open Systems
• Malicious intent or sabotage.For somebody with
a grudge against a company, say a current or for-
mer employee, unauthorised access would pro-
vide the opportunity to wreak havoc. This may
be by the simple but effective means of deleting
files, programs or data within the MIS. Or it may
be more subtle by, for example, changing key pa-
rameters that lurk in a control system and cause
it to function incorrectly or even dangerously in
the future.
Restriction of access to authorised users depends
upon how they are trying to access a system.For in-
ternal personnel there is an obvious need for access
to the MIS and/or control system. The common
approach is to have a security policy which de-
termines level of access according to job function
and expertise. This is typically realised by means
of a password and, for greater security, can involve
keys, swipe cards or even signatures such as finger,
retina or voice prints. The essential thing is that
the policy is policed with named individuals, levels
of access, dates of issue and periods of validity all
being monitored, reviewed regularly and changed
if/as appropriate. Systems are at their most vulner-
able following personnel changes, or when third
parties are given temporary access for some spe-
cific project. See also Chapter 64.
For external personnel, access is usually via
the internet and is restricted by means of a so-
called firewall. Firewalls are discussed in more de-
tail in Section 49.11.In essence,a firewall is a device
through which messages via internet connections
are forced to pass, as depicted by the box labelled
FW in Figure 49.3. The messages are examined by
a program within the firewall and either accepted
or rejected according to some rule base. A fire-
wall will prevent unauthorised access and search
attachments to messages for known viruses, but
cannot prevent unknown (to the firewall) viruses
from getting through to the control system.
It should be remembered that there are other
means of remote access to a control system such
as dial-up connections, wireless systems and third
party connections. In focussing on internet access
and firewall solutions, these other forms of intru-
sion shouldn’t be overlooked.
FS1 WS Host PC1
Ethernet
FW
OCS
HM AM FS2 GW1 PC2
Highway
PCU PLC SLC Fieldbus
GW2
Fig. 49.3 Open system with simple firewall
49.9 Information and Control
Security
There are two generic standards,IEC 17799 (Part 1)
and BS 7799 (Part 2), concerning information se-
curity management systems. These have emerged
from the commercial world rather than control and
automation,and do not explicitly address the prob-
lems of IT security in the context of real-time sys-
tems. However, many of the principles involved are
common and are certainly applicable to any on-
line MIS connected to a control system, DCS or
otherwise, and to any off-line systems used for de-
sign purposes.
There are another two US standards which are
more specific to the process industries – AGA 12
and API 1164. These concern the security from cy-
ber attack of SCADA systems used in the gas and oil
industries respectively in relation to the national
critical infrastructure.
The body concerned with cyber attack in the
UK is the National Infrastructure Security Co-
ordination Centre which has produced a guide
to principles of good practice for process con-
trol security through the development of a secu-
rity framework. Although this NISCC (2005) guide
specifically refers to SCADA systems, it is just a
applicable to DCS, PLC and hybrid systems. Three
guiding principles are employed:

1. Protect, detect and respond:
• Put in place protection measures to prevent
and discourage electronic attacks.
• Deploy means to rapidly identify actual or
suspected attacks.
• Take appropriate action in response to con-
firmed security incidents.
2. Defend in depth:
• Implement multiple protection measures to
avoid single points of contact.
3. Manage protection:
• Recognise the contribution of procedural
and managerial measures such as change
control, firewall monitoring and assurance,
and training.
49.10 Information Security
Management
The NISCC (2005) guide focuses on seven key
themes, summarised below, for each of which fur-
ther more detailed guidance is being developed:
1. Understand the business risks.
The objective is to gain a thorough understand-
ing of the risks to the business from threats to
its control systems in order to identify and im-
plement the appropriate level of security pro-
tection. Good practice entails understanding:
• What systems are involved: their role, where
they are located, who owns, manages and
supports them, and how they interact.
• The threat: identify and evaluate the threats
facing the process control systems.
• The impact: identify potential consequences
of a breach of security.
• How the systems are vulnerable: this includes
networks, applications, remote access con-
nectivity, etc.
2. Implement secure architecture.
The objective is to implement appropriate se-
curity protection measures to provide a secure
operating environment for the control system.
Good practice requires that:
49.10 Information Security Management 357
• The number of external connections be iden-
tified and reduced to an absolute minimum.
Segregate and/or isolate process control sys-
tems from other networks,with dedicated in-
frastructure for safety related systems.
• Connections between the control system and
network connections be protected with fire-
walls. Implement effective management of
firewall configuration and change control.
• Control systems be hardened to prevent net-
work based attacks. Thus all unused services
and ports in the operating system and appli-
cations should be removed or disabled, and
all inbuilt system security functions enabled.
• E-mail and internet access from the control
system be disabled.
• Wireless networking be avoided wherever
possible.
• Control systems be protected with anti-virus
software on servers and workstations. Ac-
creditation and configuration guidance from
the control system supplier is strongly rec-
ommended.
• Any new device connected to the control sys-
tem is proven to be virus free.
• Security systems, that is firewalls and anti-
virus software,be kept up to date.Procedures
should be based upon supplier certification
of patches, testing of patches, and staged de-
ployment to minimise the risk of disruption.
• Remote access be logged and managed ef-
fectively. This involves maintaining an in-
ventory of connections, restricting access to
specified machines,users and times,auditing
and systematically reviewing access.
• A variety of user orientated measures be
put in place. This includes personnel back-
ground security checks, procedures for issue
and change of passwords, training, authori-
sation of new users and removal of former
users.
• There be proper documentation for access
control.
• Effective back-up and recovery procedures
are in place.
 358 49 Open Systems
• A variety of physical security measures are
put in place.Typical examples are drive locks,
tamper proof casings,intruder alarms,access
control systems, CCTV, etc.
• Control system activity be monitored to indi-
cate health of the system. This involves mon-
itoring network activity and time taken for
specific tasks against baselines for normal
operation.
3. Establish response capabilities.
The objective is to establish procedures for
monitoring, evaluating and taking appropri-
ate action in response to security events. Good
practice entails:
• Forming a computer emergency response
team (CERT) to respond to suspected se-
curity incidents. Responses may include in-
creased vigilance, isolation of control sys-
tems and application of patches.
• Ensuring that appropriate security response
and business continuity plans are in place
for the control systems, and that the plans
are maintained, rehearsed and tested.
• Establishing an early warning system to no-
tify appropriate personnel of security alerts
and incidents, and ensuring that all such
warnings are formally recorded and re-
viewed.
4. Improve awareness and skills.
The objective is to increase process control se-
curity awareness throughout the organisation
and to ensure that all personnel have the ap-
propriate knowledge and skills to fulfil their
role. Good practice requires that:
• Management understands the business im-
plications of the security risk to control sys-
tems and therefore commits to the manage-
ment of the risk and provision of tools and
training.
• IT personnel understand the differences be-
tween the security of control systems and IT
security in general. For example, control sys-
tem operations cannot be suspended whilst
patches are installed or reboots made to en-
able upgrades.
• Control engineers develop IT security skills
and commit to system security procedures.
• Links be established between IT personnel
and control teams to build working relations,
share skills and facilitate knowledge transfer.
5. Manage third party risks.
The objective is to ensure that all security risks
from suppliers,contractors and other third par-
ties are managed. Good practice requires that:
• All third parties that have legitimate access
to the system should be identified.
• The basis of third party access be de-
tailed contractually at the procurement stage,
defining the terms of the connection and
prompt notification of vulnerabilities.
• Third parties agree to be bound by the end-
users security regime.
• System suppliers agree to provide anti-virus
protection,security support and patches,and
agree to system hardening procedures.
• Other third parties be prevented from hav-
ing access to the control systems until their
equipment, systems and software is proven
to not be a security risk.
• There be regular security audits and reviews
of third party access.
6. Engage projects.
The objective is to ensure that any project that
may impact on control system security is iden-
tified and that, early in the project’s life cycle,
appropriate security measures are included in
its design and specification. Good practice in-
volves:
• Identifying all projects and developments
that could potentially have an impact on the
control system’s security.
• Ensuring that a named individual has re-
sponsibility for security risk management
throughout the project life cycle.
• Addressing security issues in the URS and
DFS documentation and subsequent con-
tracts, and ensuring that security policies are
adhered to.
• Carrying out security reviews and testing se-
curity at key points in the control system’s
development cycle.

7. Establish on-going governance.
The objective is to provide clear direction for
the management of risks to control system se-
curity and to ensure on-going compliance and
review of policy and standards. Good practice
requires that:
• The roles and responsibilities of all con-
cerned with the control system’s security are
defined.
• Security policy and standards be defined,
documented and disseminated.
• Procedures be put in place for the manage-
ment of the policy and standards, which in-
cludes provision for their occasional review.
This may all seem to be rather tedious: yes, but
unfortunately necessary. Gone are the days when
IT security of control systems could be taken for
granted.
49.11 Firewalls
It is evident that effective firewalls are fundamental
to information security management. The NISCC
commissioned a guide to good practice on the de-
ployment of firewalls in SCADA and process con-
trol networks which has subsequently been pub-
lished.
This NISCC (2005) guide makes the point
strongly that there is more to deploying a firewall at
the interface between an IT network and a control
system than meets the eye. The two central issues
are that:
• The goals of IT and process control personnel
can be fundamentally different: the IT world
sees performance and data integrity as being
paramount whereas,ultimately,the control com-
munity’s commitment is to issues such as op-
erability, quality, reliability, safety and viability.
These differences in perspective, which can po-
tentially lead to conflicts in security practice,
have been noted and addressed in the previous
section.
• Whilst it is recognised as good practice that IT
and control networks be separated by firewalls,
49.11 Firewalls 359
that separation is unlikely to be effective without
careful design, configuration and management.
The rest of this section deals with those issues.
A firewall can be a separate hardware device phys-
ically connected to a network, a combined hard-
ware and software function unit, or even a com-
pletely software based solution installed on the
host machine to be protected. The first two cat-
egories, separate hardware or combined hardware
and software, are referred to as network firewalls
and typically provide the most secure solution for
the separation of control and IT networks. They
can be hardened to resist all but the most inge-
nious assaults and offer the best firewall manage-
ment options.
As stated, messages (network traffic), com-
prised of packets of information, are routed
through the network firewall. Each packet con-
sists of a header (source and destination addresses,
status information, etc.), data and a trailer, as de-
scribed in Chapter 40. A firewall, upon receiving
such a packet, analyses its characteristics and de-
termines what action to take. The firewall decides
whether to allow it through immediately, buffer it
temporarily,redirect it elsewhere or to block it.The
decision is based upon a set of rules, referred to as
access control lists (ACL).
According to their ACL sophistication,firewalls
can be classified as follows:
1. Packet filter firewalls. This is the simplest type
of firewall. It uses so-called static rules to check
the internet protocol (IP) addresses and port
numbers of the packets on an individual basis.
This approach, known as static filtering, lacks
the ability to understand the relationships be-
tween a series of packets and is the most readily
“hacked into” type of firewall. It is the cheapest
type of firewall but, in its favour, happens to
have the least impact on performance.
2. Stateful firewalls. This is a more sophisticated
type of firewall. It tracks the interrelationships
between packets allowed through it. By keeping
a history of accepted packets and being aware
of the state of current connections, it can ac-
cept only anticipated messages. The power of
 360 49 Open Systems
this approach, known as dynamic packet filter-
ing, is due to the fact that the rules can be made
conditional. For example: a packet will only be
accepted for a particular destination if it was
received in response to a specific request for a
certain type of data sent to a particular source
address.
Stateful firewalls offer a high level of security,
good performance and transparency to users.
However, they are more expensive and, because
of their complexity, can be less secure than
packet filters if not administered by competent
personnel.
3. Proxy firewalls. These work at the application
layer of the OSI model as described in Chap-
ter 40. The packets are opened, processed ac-
cording to ACL rules, reassembled, and for-
warded to the intended target device. The fire-
wall is typically designed to handle a variety
of protocols, through the one device, and then
forward the messages to individual host com-
puters for servicing. Thus, instead of connect-
ing directly to an external server, the client con-
nects directly to the proxy firewall which in turn
initiates a connection to the requested external
server.
Proxy firewalls can provide significant addi-
tional security functionality. For example, ACL
can be used to require users or systems to pro-
vide additional levels of authentication before
access is granted. Also rules can be created that
are protocol specific. For example, a proxy fire-
wall can be used to block all inward bound
HTTP messages that contain scripts whereas,
by contrast, a filter based firewall could block
all HTTP messages, or none, but not a subset.
Whilst proxy firewalls offer a high level of secu-
rity, they do have a significant impact on net-
work performance. Furthermore, most proxy
firewalls only support common internet proto-
cols, such as file (FTP), hypertext (HTTP) and
simple mail (SMTP) transfer protocols. Thus
messages based upon control protocols such as
common industrial protocol (CIP) and Mod-
bus/TCP, etc., will still require the firewall to
process the messages by filter or stateful means.
The current position is that most firewalls on
the market use a combined stateful and appli-
cation proxy approach.
4. Deep packet inspection (DPI). A DPI firewall
offers deeper filtering into the application layer
than the traditional proxy firewall, without per-
forming a full proxy on the TCP connection.For
example, DPI firewalls can inspect simple ob-
ject access protocol (SOAP) objects in XML on
web connections and enforce policy on what
objects are allowed through the firewall. This
firewall market is still in development.
Firewall suppliers usually offer other services be-
sides their basic message handling functionality.
Such services may comprise intrusion detection,
deployment of anti-virus software, authentication
services, secure encrypted “tunnels” and network
address translation. These additional services ob-
viously increase the cost and complexity and re-
duce the performance of the system. However,
making good use of them can significantly improve
the overall security of the control system.
49.12 Demilitarised Zones
There are various architectures available for de-
ploying a firewall between an IT network and
a control system. These configurations involve
routers and switches, multiple ports, single and
multiple firewalls, and demilitarised zones (DMZ).
Of these, on the grounds of security, manageability
and scalability, the DMZ configurations are over-
whelmingly the most effective. One common DMZ
configuration is depicted in Figure 49.4.
This configuration requires that the firewall
has three or more ports. Thus one port is used
to interface with the control system, a second with
the IT network, a third to an intermediate local
area network referred to as a process information
network (PIN) and possibly a fourth to either a
wireless local area network (WLAN) or remote and
third party access systems.
Common servers such as history (HM) and
application (AM) modules would typically be lo-
cated on the PIN and remote users would have le-
 49.13 Malware Summary 361

FS1 WS Host PC1 FS1 WS Host PC1

Ethernet Ethernet
DMZ
PIN DMZ
PIN FW GW1 FW1

HM AM
HM AM FS 2 GW1 PC2 OCS FW2 PC2
OCS
FS 2

Highway Highway

PCU PLC SLC Fieldbus PCU PLC SLC Fieldbus

GW2 GW2

Fig. 49.4 Demilitarised zone with single firewall Fig. 49.5 Demilitarised zone with twin firewalls

gitimate access to them via the internet and the
firewall. Likewise, for updating and/or application
purposes, the control system has access to these
modules via the gateway and firewall. By locating
the HM and AM modules inside the DMZ,no direct
communication channels are required between the
IT network and the control system: each effectively
ends in the DMZ. The objective of ACL design is
to maintain a clear separation between the IT net-
work and control system.
The primary security risk with this particular
architecture is that if one of the modules inside
the DMZ is compromised, it can be used to launch
an attack on the control network. This risk is ob-
viously reduced by hardening the devices on the
PIN and by actively keeping the firewall itself up to
date.
An alternative DMZ configuration, which uses
a pair of firewalls between the IT network and the
control system, is as depicted in Figure 49.5.
Again, common servers such as the HM and
AM are located on a PIN within the DMZ. The first
firewall FW1 provides security at the IT network
interface and the second firewall FW2 secures the
interface with the process control network. An at-
tractive feature of the twin firewall approach to
DMZ is that it allows both IT and control groups to
have clearly separated device responsibility since
each can independently manage its own firewall.
The principal disadvantage of the twin firewall ap-
proach is increased cost and management com-
plexity.
If firewalls from different suppliers are used
then the diversity of design provides enhanced se-
curity.Indeed,the obvious direction for the control
industry to evolve is for gateway design and fire-
wall functionality to become integrated within the
same physical unit.
An extension to the concept of diverse firewalls
is the use of disjoint protocols across the DMZ.
Thus, for example, if Ethernet is used for the IT
network it is explicitly not allowed between the
DMZ and the control network. Likewise, if token
bus is used for the highway, then it is explicitly not
allowed between the DMZ and the IT network.
Once the firewall architecture is fixed, the main
focus of effort is in determining what traffic to al-
low through the firewalls. The NISCC (2005) guide
provides detailed guidance on recommended prac-
tice for the design of ACL rule sets and on the man-
agement of firewalls.
49.13 Malware Summary
Malware is the generic term that refers to viruses,
trojans, worms, etc. A virus is a program, or macro,
that is capable of attaching itself to files and repli-
cating itself repeatedly, typically without the user’s
knowledge or permission. Some viruses attach to
 362 49 Open Systems
files such that when the file is executed so too is
the virus. Other viruses sit in a computer’s mem-
ory and infect files as they are created, opened,
edited, copied, etc. They may display symptoms
and/or cause damage, but neither symptoms nor
damage are essential in the definition of a virus: a
non-damaging virus is still a virus.
Viruses spread from computer to computer via
network connections, via shared storage media
such as file servers and via portable storage me-
dia such as compact discs and USB sticks. By far
the most common form of infection is by viruses
attached to e-mails. The effects of virus infection
are various and include:
• Just leaving a simple screen message
• Accessing e-mail address books, replicating
messages to every address, and overloading the
network
• Deleting and/or corrupting files
There are many virus variants:
1. Boot Sector Infector. This virus infects the boot
sector of a disc which contains the boot record
which is used by the computer to boot itself up.
When the computer reads and executes the pro-
gram in its boot sector, the virus is transferred
into memory and gains control over basic com-
puter operations.
2. Encrypted. The virus’ code begins with a de-
cryption algorithm: the rest of the virus is in
encrypted code. Each time it infects, it auto-
matically encodes itself differently and thus at-
tempts to avoid detection by anti-virus soft-
ware.
3. File. This type of virus usually replaces or at-
taches itself to .com and .exe files. Most are res-
ident.
4. Macro. A macro is a series of instructions de-
signed to simplify repetitive steps. A macro
virus is typically attached to a document file,
such as Word or Excel. When the document is
opened, the macro runs, does its damage and
copies itself into other documents.
5. Resident. A resident virus loads into memory
and remains inactive until triggered, say by a
date such as Friday 13th. When the event oc-
curs, the virus activates and does its damage.
6. Stealth. This type hides itself by feeding anti-
virus software a clean image of infected files
or boot sectors. For example, the size of an in-
fected file would be returned as the size of the
file without its virus.
7. Trojan. This is a malicious program that pre-
tends to be benign and causes an application to
behave in an unpredictable way. Strictly speak-
ing, a Trojan is not a virus because it does not
replicate.
8. Worm. This is a parasitic program which repli-
cates but, unlike a virus, does not infect other
programs or files. It can replicate itself on the
same computer or send copies to other com-
puters via a network, typically as an e-mail at-
tachment.
49.14 Anti-Virus Software
Anti-virus software scans a computer’s memory
and disc drives for viruses. If a virus is found, the
software informs the user and may wipe clean, dis-
infect or quarantine any files, directories or discs
affected. Detection is by means of signature scan-
ning using a so-called signature file. The file holds
a search pattern, often simple strings of characters
and bytes, for every known virus. Signature files
are huge and growing. Generally speaking, anti-
virus programs will detect 100% of known viruses,
provided the signature file is up to date: it is their
ability to detect unknown ones that is critical.
Disinfection reverses the effects of viruses.This
requires a complete understanding of what the
virus does when it infects. Once detected, the virus
is removed from the system and, whenever pos-
sible, the affected data is recovered. Disinfection
alone is considered to be inadequate because the
user may inadvertently re-introduce a virus.
Anti-virus software therefore includes live ac-
tivity checking (LAC) in the operating system ker-
nel which monitors all operating system activity
for viruses. Modern systems are invariably sup-
 49.15 Comments 363

plied with LAC already installed in the operating 49.15 Comments

system. An alternative approach is to use a back-
Open systems are concerned with the unrestricted
ground file pattern scanner which intermittently
access to data and interoperability. They enable the
checks a system’s hard disc for virus signatures. If
integration of control and information systems. It
the background scanner is effective there should be
is evident that most of the prerequisites for open
no need for LAC too. However, in practice, LAC is
systems in the form of industry standards for op-
invariably used because of the potential for intro-
erating systems, communications, programming,
ducing a virus during the installation or updating
display and so on already exist. The move towards
of anti-virus software.
open systems is being driven by strong commer-
cial pressures. However, protection against unau-
thorised access and malicious intent is a funda-
mental constraint. The scope for damage is huge.
The cost of protection will rise inexorably and, in
years to come, the notion that system’s used to have
open access will be seen to be quaint.