Get safe: Prepare for Security Intrusion

Control-system security is often portrayed as a reactive art. In reality, organizations that handle control-system security well are proactive, spending less time in a state of crisis and remediation, and more time in planning, design, implementation, and testing. In reading the growing volume of control-system security related reports, three themes reappear.

By Dave Harrold March 1, 2003

KEY WORDS

Process and advanced control

Control architectures

Safety

Networking

Internet/intranet

Open systems

Sidebars: Seven Commandments of Control-System Security Authenticate with 2 factors Additional reading On-line

Correction: The reference to DuPont Chemical in the first and third illustrations is inaccurate. The credit line should read: ”Souce: Control Engineering with data from DuPont.”

Control-system security is often portrayed as a reactive art. In reality, organizations that handle control-system security well are proactive, spending less time in a state of crisis and remediation, and more time in planning, design, implementation, and testing.

In reading the growing volume of control-system security related reports, three themes reappear.

First, business disruptions from malicious attackers (i.e., disgruntled employees or contractors) represent a far greater risk to businesses than a full-fledged terrorist attack-at least for now.

Second, waning business ethics combined with businesses drive to gain competitive advantage have increased attempts by ”information brokers” (hackers) to obtain competitive information; and

Third-and perhaps this is understood-the makeup and knowledge base of the committee developing any report is often reflected in its recommendations.

During ISA 2002, Oct. 21-23, in Chicago, several well-attended conference sessions focused on control-system security. However, many session speakers and panel members provided thoughts and recommendations based on the current state of their personal knowledge about control-system security vulnerabilities. While committees and conference sessions have value, it’s clear that securing control systems from accidental or intentional attacks is in its infancy.

Larry Falkenau of DuPont Engineering (Wilmington, DE) says, ”The critical success factor to control-system risk analysis is in forming a cross-functional team with representation from IT, control systems, process engineers, operations, and business.”

Mr. Falkenau adds that it’s quite interesting to watch the synergistic dialog that takes place during meetings as people become aware of open-system architecture vulnerabilities.

No ‘cook book’ solution

Managing security in a dynamic control-system environment is a continuous process. The process minics the familiar life-cycle model repeatedly used to improve a host of different business processes. Correction: The reference to DuPont Chemical in the above illustration is inaccurate. The credit line should read: ”Souce: Control Engineering with data from DuPont.”

One of the more obvious questions is: ”IT groups have been responsible for protecting business information assets for a couple of decades; why don’t we apply IT technologies and best practices to control systems?”

On first blush, that seems like a logical approach; however, IT risk management is designed to protect against the theft and/or changing of relatively slow moving data assets. Control systems are connected to assets that can go boom and therefore require different risk assessments and protection designs.

According to spokespersons for the Chemicals Sector CyberSecurity Information Sharing Forum (Washington, DC), a sub-group of Forum members is:

Evaluating the wide variety of risk assessment methodologies to determine a common control-system security assessment method;

Developing short-term recommendations users can apply to installed systems; and

Developing control-system security standards the Forum will encourage manufacturers to incorporate as part of future products.

That last item bodes well for future control-system installations, but systems often remain in place for 10 to 20 years, so it’s critical to beef up the security of the installed base.

Establish philosophies, policies

Until equipment suppliers develop devices and software that address the special needs of control systems, much of a company’s control-system security will rely on philosophies and policies designed to clearly establish what to protect and how that protection can and can’t be achieved.

Similar to activities made in preparation for Y2K, addressing control-system security begins by establishing philosophies detailed in supporting corporate policies, procedures, and processes. (See ”Security risk management activities” diagram.)

When establishing control-system security, philosophies include:

Assurances that management’s commitment to support security has equal emphasis and ramifications as ensuring safety and protection against injury;

Emphasis on management’s commitment to protecting the businesses intellectual knowledge; and

Establishment of roles, responsibilities, and commitments to ensure ongoing cooperation between IT and process control professionals.

Two key ingredients to successful policy development is the inclusion of rules, guidelines, and examples that leave little or no room for liberal interpretations; and addressing who, what, how, when, and why for every policy.

When developing policies, remember that many focused, smaller policies are easier to develop, understand, and administer than a few large policies.

Audit and access

Once philosophies and policies are in place, it’s time to audit control systems and determine what needs to be changed.

In this example, separate VIrtual Local Area Networks (VLANs) are defined for control and engineering domains. Users in each VLAN domain have access to the common server, but no access to devices in the other domain.

In October 2001, the American Chemistry Council (Arlington, VA) released ”Site Security Guidelines for the U.S. Chemical Industry.”

The guidelines address the identification of physical points of risk, including building and control room, equipment room, motor-control center (MCC), laboratory, field junction panel, and other control equipment physical vulnerability risk points.

Addressing these sorts of physical security vulnerabilities provides minimal deterrent to a terrorist, but they represent significant risk mitigation against malicious intruders.

Spoken information and document management are frequently overlooked as a security risk. For example, a collection of spoken information presented to several benign groups over time can provide far more detail than would be permitted in a single session.

Document-management audits should include what happens to documents provided as part of bid and construction packages after bidding and/or the project is completed.

Many engineers are familiar with process-related risk assessment methods that review piping diagrams and quantify risk scenarios. Assessing the control system is similar, but uses network-architecture diagrams and examines scenarios such as adversary access to the control system via the Internet.

Because many of today’s control-system technologies are developed using Internet technology, auditing the control system, computers, and networks should include evaluating vulnerability risks Internet-enabled controllers and related devices might introduce.

Control-system security consultant from Exida.com (Sellersville, PA), John Grebe, says, ”Threat profiles are something a lot of people don’t consider when they conduct their assessments. It’s important to identify who is trying to compromise the system and for what purpose. What often becomes clear is different mitigation actions are required to protect the same vulnerability coming from different threat profiles.”

Architect to support policies

Unless policies and network architectures complement one another, the control system will likely be left vulnerable and become increasingly more vulnerable over time.

Thomas Good of DuPont Engineering says, ”A good control-system network architecture eliminates or minimizes system entry points. All control systems determined to be of medium or high risk must be disconnected from any external network-LAN, WAN, Internet-or they must be protected via a firewall that’s monitored and co-managed by control system and IT professionals.”

Though not specifically intended to provide network security, virtual local area networks (VLANs), implemented using layer-2 and -3 switches, are an excellent way of dividing a network into functionally separate subnetworks. (See ”VLAN example” diagram.)

When designing an industrial network architecture, British Columbia Institute of Technology’s (BCIT, Burnaby, BC, Canada) Eric Byres, manager of BCIT’s Internet engineering lab says, ”Until a few years ago, the popular architectures used twisted-pair wiring with hubs and/or thickwire coaxial backbones with bridges connecting LANs, and some of these networks remain in place today. Major weaknesses of thickwire and hub-based architectures are a lack of security and no protection against broadcast packet storms.

The current industrial network design preference is to combine switches and routers in a single layer-3 switch. The ability of layer-3 switches to define filters based on address, IP subnet, protocol, or application permits this architecture to provide basic packet security and containment of broadcast storms in a very high throughput device.”

When applying a layer-3 switch architecture, keep in mind the switch filters only traffic that passes through it. Thus, if it’s important to filter traffic between two groups of devices, ensure each is attached to different switch ports.

Manage changes

Most companies have written policies, procedures, guidelines, and/or rules to address change control. Unfortunately, in the ”heat of the moment,” shortcuts around or through the change-control process are taken.

Several companies and consultants offer control-system security services that address policies, audits, change control, etc.

For example, over several years, DuPont Engineering evolved the DuPont Network Security Analysis Methodology (DNSAM).

Under a DuPont license agreement, Rockwell Automation (Mansfield, OH) uses DNSAM to analyze customer’s existing networks, assess risks, and recommend necessary changes.

DNSAM is a comprehensive security analysis methodology that:

Provides a standard process to analyze the probability and significance of information security risks;

Includes guidelines for safeguarding networked process control applications, data, and devices; and

Strengthens security policies and procedures between business and manufacturing process control systems.

The strength of DNSAM is its straightforward design, proven track record, and ability to be universally applied to any control system, in any company or industry.

Because of the designs of distributed control systems and newer hybrid control systems, change control management is usually easier because the system provides tools to compare actual (downloaded) software with ”approved” software and often includes audit trail features.

However, making the same comparison in a control solution assembled from a variety of programmable logic controllers, robots, drives, and human-machine interface software isn’t as easy.

Part of solving this problem is available in third-party solutions such as MDT Software’s (Alpharetta, GA) AutoSave.

Plan for emergencies

Lots of people and companies move through life with a ‘it won’t happen to me’ attitude, only to find themselves completely unprepared when it does happen to them.

Numerous risk analysis-rating methods, similar to this one, exist. The common feature of all such methods is quantifying an event’s likelihood (probabilitly) and severity (criticality). Correction: The reference to DuPont Chemical in the above illustration is inaccurate. The credit line should read: ”Souce: Control Engineering with data from DuPont.”

According to a 2002 survey and report conducted by Computer Security Institute (CSI, San Francisco, CA) with participation of the Federal Bureau of Investigation’s (FBI) Computer Intrusion Squad in San Francisco, during the previous 12 months 90% of respondents detected computer breaches and 80% acknowledged financial losses due to computer breaches.

The CSI/FBI report also indicates that 44% of respondents said they had lost nearly $171 million dollars of proprietary information during the previous 12 months. Much of those losses resulted from computer software companies stealing source code from one another, as well as shenanigans within the financial community. However, it’s naive to believe that some time, somewhere, someone won’t attempt to penetrate an industrial control system to obtain recipe formulations, for a family of pharmaceutical products, for example.

Waiting till then is not the time for employees to begin reading policies, becoming familiar with security architectures, figuring out who to contact, and learning what to do until help arrives.

Industrial control systems are dynamic; it’s important to develop an emergency response plan and regularly train on the plan to:

Ensure the plan is adequate and employee response is appropriate for current operational conditions;

Identify undocumented system changes;

Address personnel changes and their understanding of what to do and not do during a security breach;

Ensure security is being maintained per established philosophies and policies, including at contractor and ‘trusted vendor’ sites; and

Report intrusions to appropriate authorities.

That last item is difficult for many companies to commit to doing.

In the 2002 CSI/FBI report, only 40% of 389 respondents who experienced security breaches reported those intrusions to law enforcement, citing negative publicity and fear competitors would use the information against them as major reasons for not doing so.

Computer security breach information can be reported to the FBI’s Infragard initiative and/or confidential, third-party databases, such as the BCIT Industrial Security Incident Database (ISID) managed by Mr. Byres , or a similar database available at the current- Good Automation Practices website.

Crime-scene investigation

Two currently popular TV shows provide insight to law-enforcement crime-scene investigations. What watchers learn is the need to preserve the crime scene, followed by evidence collection and analysis, the value of interviewing witnesses, and how to ”connect the dots” to determine when, how, who, and why the crime was committed.

What TV producers present weekly is pretty similar to what should be done when industrial control-system security breaches are detected.

Preserve the crime scene. The natural response is to restore the system to a normal state as quickly as possible. That often means rebooting devices and/or downloading backup software. Both actions potentially destroy valuable evidence that could prove useful in preventing future incidents.

Collect evidence. Products are available for collecting keystrokes, mouse clicks, and extracting images of a computer’s soft- and hard-memory. Even though employees may not be trained to analyze data, as first responders, they can be trained to gather physical evidence-including keystroke and pointer-collection devices, floppy disk, and CDs-and to use tools to gather memory-image evidence, before they reboot devices or download backup software.

Analyze the evidence. Part of disaster planning is to identify and establish a relationship with persons or organizations that can efficiently analyze collected evidence. It’s important these same persons be involved in training exercises.

Interview witnesses. Physical evidence analysis becomes more efficient when augmented with the testimony of witnesses-frequently the control-system operators and shift supervisors. Having evidence analysts conduct mock witness interviews as part of training exercises educates witnesses on how to be more observant.

Test the recovery plan

After the intrusion has been stopped and evidence collected, it’s time to recover. During recovery is a bad time to learn manual backup policies haven’t been followed, automatic backup devices aren’t working, and/or find a problem reading archived media.

Regularly test the disaster recovery plan, including loading archived software.

According to special FBI agent, Kelly Brennan, ”China is actively instructing its nationals on ways to use cyber security to disrupt U.S. business operations, and known terrorist communities are creating ‘game like’ environments where unsuspecting youth compete to become the first to locate and report defined ‘entry points’ to terrorist-defined targets.”

Threats are real! Failure to voluntarily address and mitigate business and control-system security can lead to business disruptions that measure in the billions of dollars. If left unaddressed, it may cause loss of insurance, as well as leading to legislative mandates. No one wants any of that to happen.

The difference will be, those companies that treat industrial control-system security risks as threats to safety and profits will be better prepared to safely weather a security storm and thus avoid most of the drama and crisis awaiting the unprepared.

-Comments? E-mail dharrold@reedbusiness.com .

Seven Commandments of Control-System Security

When assessing an industrial control system for security risk, thou shall:

Identify all risk as threats to safety;

Identify any previous incidents that potentially compromised safety;

Identify all engineering and administrative procedures, policies, and controls applicable to the risks as well as any interrelationships, such as appropriate application of detection methodologies, that provide early detection and warnings;

Detail the consequences of risk threats, including the failure of engineering and administrative procedures, policies, and controls;

Document physical and electrical siting of system entry points;

Consider the impact of human factors; and

Provide qualitative evaluations of possible safety and health effects the failure of physical and administrative controls would produce.

Source: Control Engineering

Authenticate with 2 factors

An example of two-factor authentication is CellToken, a software application that resides in many mobile (cell) phones.

CellToken software generates a new single-user access code for system services (i.e., Web, telnet, etc.) every 60 seconds. The user must present the code to the system service within the available window of time to access the service. Accessing the CellToken-software-generated password requires users to enter a 6-digit PIN code.

Possession of the device without the PIN, or knowledge of the PIN without the device’ forms the two-factor device security.

See ”Additional Reading” below for more information about one-, two-, and three-factor security.

Additional Reading

Other sources of business and industrial control-system security information include:

Expanded online material

Move beyond magnetic strips

Everyone’s familiar with the magnetic strip used on a variety of cards containing identification information. Smart cards are different from cards with magnetic strips and represent a key component of the public key infrastructure being implemented on several operating systems.

Popular in Europe, smart cards are widely used as telephone calling cards and for vending-machine purchases.

Smart cards contain an embedded computer that allows the card to conduct multidirection interaction with the card reader and the host security computer. Smart cards are a highly secure method of identification verification because they hold a secret key with the user’s identity and can communicate in two directions.

Search “smart

Terrorist group names professor

In 1995, when the University of Georgia (Athens, GA) was planning a conference to promote understanding of the Muslim world, one of the invited panelists was University of South Florida (Tampa, FL) professor Ramadan Abdullah Shallah.

Professor Shallah had been living in the U.S. since 1990 and during the conference, spoke eloquently and knowledgea-bly of what drives people to become terrorists.

Later in 1995, the Palestinian Islamic Jihad movement an-nounced Ramadan Abdullah Shallah as its choice to replace its assassinated leader Fathi Shaqaqi (according to Feb. 24, 1998, testimony to the U.S. Senate Judiciary Committee’s Subcom-mittee on Terrorism, Technology, and Government Informa-tion.)Among the terrorist activities the Palestinian Islamic Ji-had has been linked include the 1993 bombing of the World Trade Center, and dozens of deaths of Israeli soldiers and civil-ians.

The point is, it’s becoming extremely difficult to tell the good guys from the bad guys.

Even conducing extensive background checks may not re-veal everything, but it surely reduces the risk that your com-pany, or one of your “trusted vendor/contractors,” has unnec-essarily introduced a new threat.

An Internet alternative develop

Hoping to capitalize on ever increasing Internet security challenges, Sun Microsystems (Santa Clara, CA) Trusted So-laris 8 4/01 Operating Environment (Solaris OE) is being used as the basis for the Global Business Network (B/Net, www.bnet-global.com).

B/Net intends to replicate the Internet, but as a secure, closed network for safely conducting business-to-business transactions, including voice communication.

Companies wishing to become B/Net subscribers must ap-ply and agree to use Plenar server and gateway backbones run-ning on the Solaris OE platform.

It’s too early to predict B/Nets success rate, but for compa-nies that must conduct e-business, B/Net’s promise of a secure, virus-free worldwide communication network may be a wel-come alternative to dealing with Internet security challenges.

Know thy agent software

Computer services, such as system, working, program, registry, and configuration files, can be modified in a variety of ways including through the hidden action of agent software that includes ActiveX, Active Scripting, and Java software, according to the United Kingdom’s Health and Safety Executive report, “Safety implications of industrial uses of Internet technology.” ActiveX is a component-based technology (i.e., individual program designed for reuse) that was initially specified by Microsoft (Redmond, WA) for use within Web applications. It is based on the component object model (COM) that describes the standard interface between Microsoft Window components.

Consider a browser on computer A that is accessing a Web page somewhere on a network. If the Web page requires use of a particular ActiveX component unavailable on computer A, then that component is downloaded from computer B and executed on computer A.

Depending on computer A’s implemented security policies, the missing ActiveX component can be downloaded and executed without the knowledge of the person viewing the screen.

Once downloaded, the ActiveX component can execute with all the privileges that apply to the local user, including accessing the hard drive, sending e-mail, moving local data to/from the computer, modifying system service files, etc.

Although Microsoft provides protection through certification mechanisms designed to allow only components from “trusted” sources, it requires sufficient user knowledge to properly apply the certification mechanisms. Active Scripting is the technology behind the Lovebug e-mail.

Like ActiveX, Active Scripting can be made to access the hard disk, open and modify most file types, and send e-mail, all without the user knowing.

There are also ways to use Active Scripting to manipulate or even create Web pages that, when viewed, can cause other Microsoft Office applications to perform unwanted operations.

Informed users and good computer security practices can limit abuse from Active Scripting. Java has generally caused fewer problems than ActiveX and Active Scripting, mainly because it was designed to run in protected areas of memory with limited access to host computer resources.

Java programs (applets) are unable to access local files and when running in a Web-browser; can only send data to the server where the Java applet originated.

When additional functionality is required, a specifically modified Web-browser must be developed and installed. However, as Java becomes more commonplace, the request for additional functionality is likely to be demanded, thus the likelihood of malicious use increases.

Above material was excerpted from the 38-page United Kingdom’s Health and Safety Executive report, “

Sample – control network assessment form

Development of control-system security solutions requires selecting mitigation strategies and tactics based on analysis of risk.

Using a control network characterization form, such as the one below, helps ensure an accurate inventory of control system and associated network components is obtained.

The inventory information is used to:

Develop a network block diagram that clearly depicts device and application relationships;

Indicate information flow paths and direction;

Assist in completing risk analysis; and

Assist in understanding and selecting appropriate mitigation strategies.

Once mitigation strategies are defined, the physical network and system architecture is developed, or modified, to incorporate appropriate security technologies, including firewalls, strong (two-factor) authentication, digital certificates, and/or data encryption.

Also, security polices and procedures must be developed, or modified, to accommodate and support the mitigation strategies.

Industrial Control System Network Assessment

Site

Business unit

Operating unit

Site IT contact Phone:

Site/unit control-system contact Phone:

Date of last update

Are control systems interfaced to site or corporate LANs?

Are control systems accessed from outside the control-system domain?

Defining the control system (CS) domain:

Total number of IP addressable nodes?

Number of IP addressable nodes accessible from outside the CS domain?

Number of concurrent users inside the CS domain?

Number of concurrent CS users requiring access to external resources?

Total number of users outside the CS domain requiring access to CS resources?

Number of concurrent users outside the CS domain requiring access to CS resources?

Is DHCP IP addressing used?

Is static IP addressing used?

Control-system platform information:

Number of CS platforms in use?

CS platform type (i.e., PLC, DCS, etc.)

CS platform manufacturer:

CS platform model:

CS platform type (i.e., PLC, DCS, etc.)

CS platform manufacturer:

CS platform model:

CS platform type (i.e., PLC, DCS, etc.)

CS platform manufacturer:

CS platform model:

Operator consoles & HMI device information:

Number of operator platforms in use?

Operator console platform manufacturer:

Operator console platform model:

Application node information (check all that apply):

Advanced process management control server:

SCADA:

OPC server:

Batch recipe server:

Other (specify):

Anticipated network security support:

Site resources (indicate number available):

Corporate resources (indicate number required):

Third-party resources (indicate number required):

Site network information (Yes/No response):

Current site network topology diagrams available and up-to-date?

Control-system nodes on isolated LAN segment?

Site control-system and information-security policies in place?

Information security audit completed? Date:

Two-pass authentication in use?

Control-system risk assessment completed? Date:

Remote access requirements (check all that apply):

Via site/corporate LAN?

Via dial-up modem?

Via Internet?

Via local/desktop modem directly to the CS nodes?

Local egress requirements (check all that apply):

Site applications (document management, quality, and/or business, systems)?

Corporate applications (document management, quality, and/or business, systems)?

Internet sites?

Source: Control Engineering with data from DuPont

More about virtual local area networks

Virtual local area networks (VLANs) are an effective way to isolate control-system network packet and broadcast traffic from other network traffic, such as engineering or business network traffic.

Grouping Ethernet ports together using fully compliant IEEE 802.1Q (tag enabled layer-3) switches forms a VLAN capable of rendering devices on other tagged VLANs unreachable.

Despite sharing common physical cable, VLANs functionally (logically) isolate extraneous traffic and can be configured to provide a level of security. However, because a port can belong to more than one VLAN and extend across multiple switches, managing a VLAN as a level of security can be challenging.

Caution: Creating a VLAN using untagged switches may require disabling Spanning Tree Protocol (STP). For example, if two untagged VLANs exist on two switches, a physical connection is required between them. STP would interpret this as a communication loop, and disallow the links, thus STP would need to be disabled.

Because VLANs provide functional segregation, they can be used to segment broadcast domains within a network, thus reclaiming network bandwidth by breaking down broadcast domains and segments from one another within the same switch.

Other VLAN configurations can conserve bandwidth, such as whether or not to pass or block multicasts and rate limit broadcasts.

Using technologies, such as IEEE 802.3p, Quality of Service (QoS), seven levels of packets can be prioritized by setting three bits in the packet header. In the event of a traffic bottleneck, this allows traffic types or port assignments, such as control-system devices, to have higher communication priority.

Though not specifically a security measure, prioritization helps preserve control-system network traffic integrity.

This information is an excerpt from a Schneider Electric white paper titled, “Building a Secure Ethernet Environment.”Visit the following Web sites to learn more about VLANs: https://howstuffworks.lycoszone.com/lan-switch8.htmwww.ict.tuwien.ac.at/skripten/datenkomm/print/10-VLANIntroduction.pdfwww.schneiderelectric.com

Configuring DCS & business networks– Case history

While planning an upgrade to a pulp-mill distributed control system (DCS), the issue of network security came up, as noted in a white paper titled “Protect that network: Designing secure networks for industrial control,” by Eric Byres of the British Columbia Institute of Technology.

Since operator workstations were on the control-system network and the only application loaded was the DCS graphic station, they were not viewed as high-risk devices. However, the engineering workstation needed to communicate with DCS devices on the control-system network and with document and maintenance systems residing on the business network.

Adding to the complexity, some engineering workstations would be located in the mill’s engineering area, far from the DCS.After careful analysis the decision was made to connect the engineering workstation to the business network and use routing (layer-3) switches to manage traffic to/from the control-system network.

The first step was to assign IP addresses in such a way as to make switch configuration and management as easy as possible.IP addresses of 10.4.1.1 to 10.4.1.254 with a subnet mask of /24 was reserved for DCS controllers, operator consoles, and servers.

DCS servers were assigned IP addresses of 10.4.1.1 and 10.4.1.2.

IP addresses of 10.5.1.1 to 10.5.1.254 with a subnet mask of /24 were reserved for the business-network-based engineering workstations. Following installation, protocol analysis indicated the following TCP port numbers were used for various DCS-related actions

TCP port numbers recorded during engineering workstation sessions to the DCS server

Action
Destination port #
Source port #

Log-in to DCS server
6000
1153, 1154, 1155, 1156

Perform DCS diagnostics
6000
1154, 1156, 1157

View graphics
6000
1154, 1156, 1159

Print report
6000
1154, 1156

For most routing hardware, the following filtering rules would apply.

[Permit/Deny] [Source Host/Mask] [Destination Host/Mask] [TCP Socket = ???]For the mill DCS example, the following rules were applied:

[Permit] [10.5.1.0/24] [10.4.1.0/31] [TCP Socket = 6000] Permit engineering workstation traffic to enter the DCS network if it’s directed to the two servers and is using TCP port 6000.

[Permit] [10.4.1.1/32] [10.5.1.0/24] [TCP Socket >=1152 & TCP Socket ,+ 1160] Permit only DCS server #1 traffic to enter the business network, and only if it’s directed to the engineering workstations and is using TCP ports between 1152 and 1160.

[Permit] [10.4.1.2/32] [10.5.1.0/24] [TCP Socket >= 1152 & TCP Socket &= 1160] Permit only DCS server #2 traffic to enter the business network, and only if it’s directed to the engineering workstations and is using TCP ports between 1152 and 1160.

[Deny] [0.0.0/0] [10.4.1.0/24] This final rule denies all other traffic into the control-system network .

This case history example illustrates filtering:

A range of addresses using a subnet mask;

A host using the complete address; and

Specific packets for a TCP socket number.

Each packet entering or leaving the control-system network is tested against the configured rules. Packets that satisfy a rule are permitted to pass through, all others are deleted, thus the importance of the final DENY statement This case history was excerpted from a white paper titled “Protect that network: Designing secure networks for industrial control,” written byEric Byresof the British Columbia Institute of Technology. The white paper was the source of a 1999 article that appeared in IEEE Industrial Applications magazine.