SCADA system

What is the scada system ?

================

SCADA system

Scada

A shortcut Supervisory control and data aquisition for

Supervisory control and data aquisition

Is a system for control and monitoring and supervision only and is often used in large-scale projects, in the cause of rising costs in this system, and is used in power plants and oil fields, where in such projects need to be controlled in a very very large set of elements (valves, pumps, motors, switches, actuators) or control anything in the system.

This system is very large, you can not be controlled by plc for example only and at the same time, you need to monitor the current situation to all elements of the system, so that you can make a particular decision in the open, for example, valve, if that scada system is based on control through controllers calledRTU (remote terminal uint) May be plc these are connected to all units in the room or the main controller called HMI (human machine interface), which is the link between worker and order in full, in order to be able to monitor and control system which also It is worth to mention that scada is one of the branches instrumentation So Scada Refers to the system to collect data from various sensors in a factory, plant or in remote locations and then sends this data to the computer (Central Computer), then this computer in the control of data and is a term that is used on a large scale, in order to portray and control and management solutions in a wide range of industries, Some of the industries that use scada is the water management systems, electric power, traffic signals, and mass transit networks, systems and environmental control systems and manufacturing industries.

And usually includes setups signal (input and output) controllers and networks the user interface (hmi), and communications equipment and software besides all that, the term refers to the scada full in the central system, and the central system usually monitors data from various sensors, that are either close to or off site (sometimes miles).

In proportion to the bulk of the brains of a scada system carried out by a remote terminal units (sometimes referred to as rtu). After the station consists of modules in programming logic conversion, has usually rtu set to specific needs, but most rtu allow human intervention, forExample, put in a factory, rtu can control the situation conveyer belt, and speed can change or override the system at any time, by human intervention, and in addition to that, any changes or errors are usually automatically for registration and submission, and in mostOften, scada monitoring system and making minor changes on the job in the best way; scada systems is a closed loop with the operating systems and only a relatively small amount, from human intervention.

One of the key processes in scada is the ability to monitor the entire system in real time, and this is making it easier to purchase operations, including data meter reading, check the home sensor, and once they are at regular intervals and according to this system, and added toData used by the rtu, as it is before the man that is able to interact with the system to override the settings or make changes when necessary.

Scada system can be considered as with many of the data elements called points, usually is all monitoring points, or sensor, and usually can be either hard or soft spots, (a) and documented data can be monitoring the actual point, and the conduct of the point can be be seenOn software application or physical elements and non-physical data account, the points that are usually always recorded in order to create and record a time or date stamp

The user interface (hmi) a scada system and includes user interface, usually called the human-machine interface (hmi). The hmi scada of the system where the data processing and presentation to be viewed by the operator and monitoring rights, and this reaction usually involves controls, where it can be to the individual that interactsWith scada system.

Hmi which is an easy way to develop uniform standards in order to facilitate multi-rtu monitor or control circuits (Programmable Logic Control). Rtu normally or control circuits will be pre-programmed to run the process, but it is to monitor all of them individually can be difficult, because they are usually distributedOn the system. Rtu and control because historically circles not standardized method in the data view or in this operator, scada system communicates with the control circuits across the network information system and the operations of the system in which to publish easily, by hmi. Hmi 's It also can be linked to the database, and can use the data collected from control circuits or rtu In order to provide graphs for trends, market information, and circuit diagrams or mechanical sensing devices or special machine or even provide evidence that can be accessed in order to troubleshoot and repair these errors, in the last decade, fromPractically include all scada hmi integrated systems and control circuits in order to end, making it an easy tool to manage and monitor the scada system.

Scada computer hardware and software components

Scada represent these systems in a useful way to the end in order to manage and control operations, a large in proportion to the small applications, such as climate control, or the system can be used in highly effective in applications such as monitoring and control of a nuclear power plant or transmission systemCollective.

Scada can not be achieved in an open sources and protocols in the property, the smaller the system and at a reasonable price to the end, and can be either buy a complete system, or can be mixed and matched with specific elements, large systems can also be arise withOff the shelf components, Scada system software can also be easy configuration for any application, and thus eliminate the need for software development.

* System problems Supervisory control and data aquisition SCADA

Challlanges related to SCADA patching

The integration of SCADA technology into highly interconnected corporate networks and the Internet has been accompanied by the awareness that these systems needs to be secured better.

One way to do this is through efficient patch management.

Patch management has already been defined to a great extent in the IT domain but patching SCADA systems, partially due to the criticality

and complexity of the systems and the processes, is quite different. In this chapter an overview is given of open issues related to SCADA patching and SCADA patch management.

A. Procedural challenges:

Appropriate boundaries for the service agreement - should be defined between the vendor and the customer. This can be done in the patch management service contract or some other service agreement.

Responsibilities, in case of failure, should be clearly defined. For

instance, although a vendor will thoroughly test a patch on a laboratory environment it cannot be guaranteed that this patch will not break system functionality when placed on the production environment of a customer, especially when a vendor is not able to test a patch the system of a customer. However, even if a patch is tested on a system similar to the one utilized by the customer it is still difficult to identify the party responsible once the patch breaks the system.

Vulnerabilities are rated with the use of the classic IT scoring method CVSS (Common Vulnerability Scoring System). These scorings may not be suitable for control systems like SCADA. ICS-CERT recommends that control systems owners and operators customize the CVSS score to their local environment but this can lead to different parties using different scorings. Furthermore, some experts state that the ICS-CERT's vulnerability reporting is not addressing the underlying issue – “that the most serious vulnerabilities in control systems are deliberate design features, not bugs” referring to design features like default credentials and the lack of encryption.

Another issue with vulnerability reports sometimes

include exploit code, or information on how to make an exploit. Combined with the lengthy patch deployment interval in SCADA systems this could lead to attackers having an advantage on an unpatched system.

If patches need to be extensively tested in the field, this requires that the patch itself is known to a comparatively large number of people long before it can be applied. This allows a potential attacker to reverse-engineer the vulnerability from the patch, and use it on the still unprotected systems. There are some techniques to resolve these issues on IT systems, but it is unclear if they can be directly translated to the SCADA setting.

Compensating controls (for instance: application

whitelisting and intrusion detection) can be utilized to reduce the risks during this window of vulnerability.

Vulnerability discovery - Not all vulnerabilities, issues and patches are communicated through the same channel. An organization should therefore maintain relations with all the suppliers relevant to its systems. These relationships can vary, from weekly or monthly calls to just subscriptions to a vendor's security announcement list. Without a patch management

service contract organizations are often not aware of new vulnerabilities and patches related to the system.

B. Technical challanges

There are different ways to do this (media like DVD, internet portals with access control for customers, secure file transfer implementations etc.) but there is no standardised guideline. Preferably a dedicated patch management system is used for obtaining and applying software patches. There are however very few automated patch deployment solutions for SCADA systems. A patch management system could also introduce significant risks; they could be infected or used as a centralized attack vector to industrial systems. Adequate sandboxing of patch management systems is paramount.

* Patch deployment intervals - Ideally an organization would deploy patches as soon as they

come available, however this is often not possible because of the complexity of the process in which SCADA systems are incorporated and because the systems often need to be operable at any given moment. Furthermore patches need to be tested thoroughly before they can be applied to production environment, which can take days or even weeks, during

which a system is vulnerable. Ideally alternative controls should be used during the window of exposure for preventing a vulnerability to be exploited. For instance, when a webserver vulnerability has been discovered the organization could, if possible, block unwanted traffic to the webserver or disable the webserver all together. Some organizations rely on the

vendor to patch their SCADA systems, which is agreed upon in the service contract.

Decisions on patch deployment intervals are discussed between vendor and customer and are related to the size of an ICS solution, the criticality of installing new patches and the size of an organization. Experience from vendors shows that patching deployment intervals could range anywhere from every six months to a year. Deploying patches on a more regular interval is often too expensive for vendors because of the test processes and the complexity of deploying patches.

Legacy systems - Another issue is that many ICS utilize older versions of operating systems that are no longer supported by the vendor. Consequently, available patches may not be applicable.

This could be the case when the vendor has ceased to exist. In this case the

systems should be replaced but this could turn out to be a costly undertaking. Often an organization will adapt the “if it isn’t broken, don’t fix it” mentality, especially when there is no patch management policy in place. These legacy systems often contain outdated SCADA system but also outdated Operating Systems which are equally as problematic. For instance, Microsoft will end support for Windows XP in 2014, which means that even though vulnerabilities and exploits might be discovered, no new patches are developed and distributed anymore. Furthermore, developing own patches for OS and SCADA applications is almost impossible, especially when the source of the OS or application is proprietary.

C. Legal challenges :

International business - Most SCADA vendors serve a worldwide market. As such, they have to face legal issues arising from customs regulations of each country which might affect the ability to deliver software to the respective countries. In terms of SCADA patch management this can mean that a provider of SCADA patch management would not be allowed to deliver the required patches to a country of its customer, although this is not an issue within the European Union (EU). It can be a problem for any provider of SCADA patch management that does not reside in the EU.

Use of open source software (OSS) - For vendors, there is also an important legal issue originating from the use of OSS in SCADA applications. OSS has to be cleared internally for use with the vendors own solution so that the vendor is able to use OSS without any legal claim. Another important open issue is the process of developing new patches when possible legal issues could arise in regards to OSS. It might happen that the vendor has to develop two critical patches OSS in a short time frame. Since the patches are critical they have to be quickly tested and released to customers. However, the patches have to be cleared first by the legal department before they can be distributed. This slows down development and distribution.

Vendor warranty - Another issue is vendor warranty – an asset owner can lose its warranty when patching their system. Arrangements should be made with vendors to address this issue before deployment.

Asset management - Asset management is an important part of patch management. Asset management is defined as the process whereby a large organization collects and maintains a comprehensive list of the items it owns such as hardware and software. This data is used in connection with the financial aspects of ownership such as calculating the total cost of ownership, depreciation, licensing, maintenance, and insurance. Asset management in the field of SCADA is much different from existing solutions for IT infrastructures. First of all there is no defined asset classification to be used by different vendors of SCADA solutions.

Each vendor is inventing its own classification for the used assets. So the question arising from that is if it would be an improvement for the transparency towards the customers if there would be a standardized asset classification used by all vendors of SCADA solutions.

Furthermore, there are not a lot of discovery tools (scanning for used hardware and software independent from the used platform) for complex and distributed systems used in SCADA solutions on the market. The usage of these tools is often prohibited due to possible technical issues that the scanning might cause. This leads to the open issue to what extent it is possible to automate the process of asset discovery and asset documentation.

? Procurement and design for patch ability - A number of patching issues would become substantially easier if systems are designed with updatability in mind. This does, however, require additional resources and thus makes the system more expensive during purchasing.

Next to identifying, developing and integrating the measures into the system and device design it is therefore important that procurement departments learn how to add the proper requirements into tenders, and how to measure the level to which the requirements are met.

* Good practices and recommendations

This section contains a list of good practices and recommendations related to SCADA patching.

A. Compensating controls :

Installing and distributing patches on a regular basis, is difficult for organizations and vendors because of the procedural and technical issues related to it. Patching should not be seen as a single method of defense, a good practice is to increase defense in depth (DiD) through the use of compensating controls. The term defence in depth is a term that refers to a strategy where multiple layers of defense are used to prevent attacks.

Important elements of a defense in depth strategy for SCADA systems are:

a. Create awareness and understanding in the organizations as to what failure of the SCADA systems could mean to the operations of the organization and what the policies and best practices are regarding patch management and security as a whole. A training program should be set up with job relevant information on how to apply security and how to respond to security threatening situations.

b. Hardening the SCADA systems, hardening the system means removing unnecessary features and locking down the functionality of the various components of the SCADA system.

Microsoft Windows for instance contains a lot of different applications and services that are not necessary for operations, and they should be removed or disabled.

c. Firewalls should be configured in a way that only allows connections between trusted machines to trusted ports. Other ports should be closed when not in use. Firewalls should also implement an alarm-reporting mechanism to alert any time that abnormal behavior is

detected. Intrusion Detection Systems (IDS) could also be used to detect this behavior.

Where applicable, one-way communication diodes can provide an even higher level of protection. Deep Packet Inspection (DPI) Firewalls could also be used to check traffic for strangely formatted messages or unusual behaviours.

d. Increase defense in depth through network segmentation. Network segmentation is a complex measure but the basics are straightforward. Sets of equipment should be identified based on trust and similarity and placed into different zones. The next step is to identify what communications need to pass between the zones. At the points where zones communicate access controls like firewalls should be placed.

e. Conducting regular risk and security assessments to reduce potential security risks. Risks that cannot be eliminated should be reduced and the residual risk controlled.

f. Application White Listing (AWL) to compensate for malware code injection and execution by defining the allowed applications on a system, and restricting all other applications from running.

telecommunications equipment often suggest configuration changes to their clients Microsoft also offers this service, included in most Security Bulletins is a section called “Workarounds” which describes how the system could be altered to reduce the risk of possible exploitation. Not a lot of SCADA vendors offer a likewise strategy, but there are numerous possibilities. For instance, if a vulnerability has been found in the webserver, and the webserver is not being used by any business

critical operations, the webserver could be temporarily disabled or special rules could be deployed on the firewall or IDS to detect malicious behaviour.

B. Establishing a patch management program and service contract:

a. Asset owners should establish a patch management program. Without an established patch management policy, the process of applying patches could prove to be a very difficult undertaking. Even when the decision is made not to patch SCADA systems, due to more focus on compensating controls or because of the criticality of the systems, it should be formulated in a policy.

b. Asset owners should have a well-designed policy

in place so to reduce the effort of patch management and the risk of making mistakes. Such a policy will define responsibilities and will help teams to understand what is expected and what they need to do. Important elements of a patch management program include

: asset / configuration management,

patch management plan, backup/archive plan, plan for testing patches, an incident response plan and plans for documenting patches.

c. Asset owners should also establish a patch management service contract - A patch management service contract helps to define on the responsibilities of both the vendor and the customer in the patch management process. An agreement should be made on the focus of the patches (SCADA application, OS, 3 party application), patch deployment intervals, how the patches will be distributed, installed and tested, whose responsibility it is when something goes wrong and until when the service contract is valid.

C. Testing patches :

Testing patches before deployment is especially important for SCADA systems since unexpected behavior could potentially harm the operational functionality and could pose serious problems for asset owners.

a. Asset owners should always conduct their own tests. This can be done virtually or by maintaining separate systems to test on. While patches for SCADA systems are often thoroughly tested by their vendors, there is still no guarantee that they will not disturb operations in a production environment. The environment an asset owner maintains can be

very different from the environment that the vendor uses to test their patches and it is too costly to recreate a likewise environment.

b. The test environment should closely simulate the operational environment. A common way to do is to apply the DTAP street concept, which includes systems for Development, Test, Acceptance and Production.

c. Redundant systems could be used to deploy the patch on, which are then put in to production. During the evaluation whether the patch works as expected additional operational staff should be available to give their support to any potential issues caused by the patch. If the patch fails the organization can revert to the earlier system.

d. Certified systems should be re-certified after a patch is applied. This is an extremely important point. Technically speaking, any system that has been certified from a security perspective (e.g. a cryptographic device that is FIPS 140-2 certified) should be re-certified following a software patch. This is something that the industry tends to ignore because it costs time and money.

D. Distributing patches :

It is preferred to dedicate a patch management system for obtaining and applying software patches.

The sandboxing of such a system is paramount, as a patch management system could introduce significant risks attackers could potentially use it to distribute unwanted software.

The following best practices may be considered:

a. Locate the patch management within an enclave that already has open Internet access, such as the business network. If the patch management systems needs to be located in SCADA or DCS networks (e.g., if the business network is geographically separate), create a unique enclave for patch management with true air gap boundaries.

b. The patch management system is responsible for downloading and testing patches, configuration files, upgrades, and other third-party material; testing it for malware; and then archiving the validated files to read-only media (preventing any subsequent infection or manipulation).

c. If required, implement two instances of the patch management system: one to retrieve patches in isolation and one to distribute the validated patches after they have been hand carried across a true air gap.

d. Evaluate patches and updates in a test environment in order to asses the risk of deployment. “Early Adopter” machines could also be used to test patches before they are deployed to “Business Critical” machines.

e. Utilize digital signatures on patches or do hash verification where possible/feasible.

E. Patch scheduling:

a. Patch scheduling and deployment can be done after a patch has been tested thoroughly and when the patch is approved for deployment.

b. Depending on the chosen distribution method the approval of production managers is necessary before deployment can be executed.

c. Preferably the deployment is incorporated into regular maintenance schedules, or when systems are less critical for operations, for instance during night time or during a period of low production.

* Conclusions

Although patch management should not be seen as a silver bullet to resolve the security issues of SCADA systems it is nevertheless important that organizations establish a patch management policy. Without a well-designed patch management policy organizations might be vulnerable for attacks from the outside and the process of patching itself could prove to be a difficult undertaking.

In the United States patch management is required for organizations that have to comply with the NERC CIP standard. While NERC CIP is mandatory for most utilities in Northern America there is no

such universally mandatory standard in Europe.

Therefore many different approaches are taken by asset owners within the European Union to handle patch management. The European Union or the

Member States could increase the awareness of patches and patch management through enforcing that the issue of patch management should be taken into consideration when new requirements for

devices are established.

*******************************

* SCADA systems component ...

- Key ICS Components in SCADA systems

To support subsequent discussions, this section defines key ICS components that are used in control and networking. Some of these components can be described generically for use in both SCADA systems, DCSs and PLCs, while others are unique to one.

incorporates these components.

1 - Control Components

The following is a list of the major control components of an ICS:

Control Server. The control server hosts the DCS or PLC supervisory control software that is designed to communicate with lower-level control devices.

The control server accesses subordinate control modules over an ICS network.

SCADA Server or Master Terminal Unit (MTU). The SCADA Server is the device that acts as the master in a SCADA system.

Remote terminal units and PLC devices (as described below)

located at remote field sites usually act as slaves.

Remote Terminal Unit (RTU).

The RTU, also called a remote telemetry unit, is special purpose data acquisition and control unit designed to support SCADA remote stations. RTUs are field devices often equipped with wireless radio interfaces to support remote situations where wirebased communications are unavailable.

Sometimes PLCs are implemented as field devices to serve as RTUs; in this case, the PLC is often referred to as an RTU. Programmable Logic Controller (PLC). The PLC is a small industrial computer originally designed to perform the logic functions executed by electrical hardware (relays, drum switches, and mechanical timer/counters). PLCs have evolved into controllers with the capability of controlling complex processes, and they are used substantially in SCADA systems and DCSs.

Other controllers used at the field level are process controllers and RTUs; they provide the same control as PLCs but are designed for specific control applications.

In SCADA environments, PLCs are often used as field devices because they are more economical, versatile, flexible, and configurable than special-purpose RTUs.

Intelligent Electronic Devices (IED). An IED is a “smart”sensor/actuator containing the intelligence required to acquire data, communicate to other devices, and perform local processing and control. An IED could combine an analog input sensor, analog output, low-level control capabilities, a communication system, and program memory in one device. The use of IEDs in SCADA and DCS systems allows for automatic control at the local level.

Human-Machine Interface (HMI).The HMI is software and hardware that allows human operators to monitor the state of a process under control, modify control settings to change the control objective, and manually override automatic control operations in the event of an emergency.The HMI also allows a control engineer or operator to configure set points or control algorithms and parameters in the controller. The HMI also displays process status information,

historical information, reports, and other information to operators, administrators, managers,business partners, and other authorized users. The location, platform, and interface may vary a great deal. For example, an HMI could be a dedicated platform in the control center, a laptop on a wireless LAN, or a browser on any system connected to the Internet.

Data Historian.

The data historian is a centralized database for logging all process information within an ICS.

Information stored in this database can be accessed to support various analyses,

from statistical process control to enterprise level planning.

Input/Output (IO) Server.

The IO server is a control component responsible for collecting,

buffering and providing access to process information from control sub-components such as PLCs, RTUs and IEDs. An IO server can reside on the control server or on a separate computer platform.

IO servers are also used for interfacing third-party control components, such as an HMI and a control server.

2 - Network Components

There are different network characteristics for each layer within a control system hierarchy.

Network topologies across different ICS implementations vary with modern systems using Internet-based IT and enterprise integration strategies.

Control networks have merged with corporate networks to allow

engineers to monitor and control systems from outside of the control system network.

The connection may also allow enterprise-level decision-makers to obtain access to process data. The following is a list of the major components of an ICS network, regardless of the network topologies in use:

Fieldbus Network:The fieldbus network links sensors and other devices to a PLC or other controller.

Use of fieldbus technologies eliminates the need for point-to-point wiring between the controller and each device.

The sensors communicate with the fieldbus controller using a specific protocol.

The messages sent between the sensors and the controller uniquely identify each of the sensors.

Control Network:The control network connects the supervisory control level to lower-level control modules.

Communications Routers:A router is a communications device that transfers messages between two networks. Common uses for routers include connecting a LAN to a WAN, and connecting MTUs and RTUs to a long-distance network medium for SCADA communication.

Firewall:A firewall protects devices on a network by monitoring and controlling communication packets using predefined filtering policies. Firewalls are also useful in managing ICS network segregation strategies.

Modems:A modem is a device used to convert between serial digital data and a signal suitable for transmission over a telephone line to allow devices to communicate Modems are often used in SCADA systems to enable long-distance serial communications between MTUs and remote field devices.

They are also used in both SCADA systems, DCSs and PLCs for gaining remote access for operational functions such as entering command or modifying parameters, and diagnostic purposes.

Remote Access Points:Remote access points are distinct devices, areas and locations of a control network for remotely configuring control systems and accessing process data. Examples include using a personal digital assistant (PDA) to access data over a LAN through a wireless access point, and using a laptop and modem connection to remotely access an ICS system.

*******************************

System problems Supervisory control and data aquisition SCADA

Challlanges related to SCADA patching

The integration of SCADA technology into highly interconnected corporate networks and the Internet has been accompanied by the awareness that these systems needs to be secured better.

One way to do this is through efficient patch management. Patch management has already been defined to a great extent in the IT domain but patching SCADA systems, partially due to the criticality and complexity of the systems and the processes, is quite different. In this chapter an overview is given of open issues related to SCADA patching and SCADA patch management.

A. Procedural challenges:

Appropriate boundaries for the service agreement - should be defined between the vendor and the customer. This can be done in the patch management service contract or some other service agreement.

Responsibilities, in case of failure, should be clearly defined.

For instance, although a vendor will thoroughly test a patch on a laboratory environment it cannot be guaranteed that this patch will not break system functionality when placed on the production environment of a customer, especially when a vendor is not able to test a patch the system of a customer. However, even if a patch is tested on a system similar to the one utilized by the customer it is still difficult to identify the party responsible once the patch breaks the system.

Vulnerabilities are rated with the use of the classic IT scoring method CVSS (Common Vulnerability Scoring System). These scorings may not be suitable for control systems like SCADA.

ICS-CERT recommends that control systems owners and operators customize the CVSS score to their local environment but this can lead to different parties using different scorings. Furthermore, some experts state that the ICS-CERT's vulnerability reporting is not addressing the underlying issue – “that the most serious vulnerabilities in control systems are deliberate design features, not bugs” referring to design features like default credentials and the lack of encryption. Another issue with vulnerability reports sometimes include exploit code, or information on how to make an exploit. Combined with the lengthy patch deployment interval in SCADA systems this could lead to attackers having an advantage on an unpatched system.

Patch confidentiality - The most critical time period for any security vulnerability is the time between the vulnerability being known to potential attackers, and the time the patch to fix this vulnerability is deployed. If patches need to be extensively tested in the field, this requires that the patch itself is known to a comparatively large number of people long before it can be applied. This allows a potential attacker to reverse-engineer the vulnerability from the patch, and use it on the still unprotected systems. There are some techniques to resolve these issues on IT systems, but it is unclear if they can be directly translated to the SCADA setting.

Compensating controls (for instance: application whitelisting and intrusion detection) can be utilized to reduce the risks during this window of vulnerability.

These relationships can vary, from weekly or monthly calls to just subscriptions to a vendor's security announcement list. Without a patch management service contract organizations are often not aware of new vulnerabilities and patches related to the system.

B. Technical challanges

* Transferring and obtaining patches - Another open issue on finding the most suitable way of distributing patches, which can be big packages with more than two gigabyte of data, within an organization or between vendor and customer. There are different ways to do this (media like DVD, internet portals with access control for customers, secure file transfer implementations etc.) but there is no standardised guideline. Preferably a dedicated patch management system is used for obtaining and applying software patches. There are however very few automated patch deployment solutions for SCADA systems.

A patch management system could also introduce significant risks; they could be infected or used as a centralized attack vector to industrial systems. Adequate sandboxing of patch management systems is paramount.

* Patch deployment intervals - Ideally an organization would deploy patches as soon as they come available, however this is often not possible because of the complexity of the process in which SCADA systems are incorporated and because the systems often need to be operable at any given moment. Furthermore patches need to be tested thoroughly before they can be applied to production environment, which can take days or even weeks, during which a system is vulnerable. Ideally alternative controls should be used during the window of exposure for preventing a vulnerability to be exploited. For instance, when a webserver vulnerability has been discovered the organization could, if possible, block unwanted traffic to the webserver or disable the webserver all together. Some organizations rely on the vendor to patch their SCADA systems, which is agreed upon in the service contract.

Experience from vendors shows that patching deployment intervals could range anywhere from every six months to a year.

Deploying patches on a more regular interval is often too expensive for vendors because of the test processes and the complexity of deploying patches.

Legacy systems - Another issue is that many ICS utilize older versions of operating systems that are no longer supported by the vendor.

Consequently, available patches may not be applicable.

This could be the case when the vendor has ceased to exist. In this case the

These legacy systems often contain outdated SCADA system but also outdated Operating Systems which are equally as problematic. For instance Microsoft will end support for Windows XP in 2014, which means that even though vulnerabilities and exploits might be discovered, no new patches are developed and distributed anymore. Furthermore, developing own patches for OS and SCADA applications is almost impossible, especially when the source of the OS or application is proprietary.

C. Legal challenges :

It might happen that the vendor has to develop two critical patches OSS in a short time frame. Since the patches are critical they have to be quickly tested and released to customers. However, the patches have to be cleared first by the legal department before they can be distributed. This slows down development and distribution.

Asset management - Asset management is an important part of patch management.

Asset management is defined as the process whereby a large organization collects and maintains a comprehensive list of the items it owns such as hardware and software. This data is used in connection with the financial aspects of ownership such as calculating the total cost of ownership, depreciation, licensing, maintenance, and insurance. Asset management in the field of SCADA is much different from existing solutions for IT infrastructures. First of all there is no defined asset classification to be used by different vendors of SCADA solutions.

The usage of these tools is often prohibited due to possible technical issues that the scanning might cause.

This leads to the open issue to what extent it is possible to automate the process of asset discovery and asset documentation.

* Good practices and recommendations

This section contains a list of good practices and recommendations related to SCADA patching.

A. Compensating controls :

Important elements of a defense in depth strategy for SCADA systems are:

b. Hardening the SCADA systems, hardening the system means removing unnecessary features and locking down the functionality of the various components of the SCADA system.

Microsoft Windows for instance contains a lot of different applications and services that are not necessary for operations, and they should be removed or disabled.

d. Increase defense in depth through network segmentation.

Network segmentation is a complex measure but the basics are straightforward. Sets of equipment should be identified based on trust and similarity and placed into different zones.

The next step is to identify what communications need to pass between the zones.

At the points where zones communicate access controls like firewalls should be placed.

e. Conducting regular risk and security assessments to reduce potential security risks.

Risks that cannot be eliminated should be reduced and the residual risk controlled.

f. Application White Listing (AWL) to compensate for malware code injection and execution by defining the allowed applications on a system, and restricting all other applications from running.

vulnerability has been found in the webserver, and the webserver is not being used by any business critical operations, the webserver could be temporarily disabled or special rules could be deployed on the firewall or IDS to detect malicious behaviour.

B. Establishing a patch management program and service contract:

a. Asset owners should establish a patch management program.

Without an established patch management policy, the process of applying patches could prove to be a very difficult undertaking.

Even when the decision is made not to patch SCADA systems, due to more focus on compensating controls or because of the criticality of the systems, it should be formulated in a policy.

b. Asset owners should have a well-designed policy in place so to reduce the effort of patch management and the risk of making mistakes. Such a policy will define responsibilities and will help teams to understand what is expected and what they need to do. Important elements of a patch management program include : asset / configuration management,patch management plan, backup/archive plan, plan for testing patches, an incident response plan and plans for documenting patches.

An agreement should be made on the focus of the patches (SCADA application, OS, 3 party application), patch deployment intervals, how the patches will be distributed, installed and tested, whose responsibility it is when something goes wrong and until when the service contract is valid.

C. Testing patches :

a. Asset owners should always conduct their own tests. This can be done virtually or by maintaining separate systems to test on.

While patches for SCADA systems are often thoroughly tested by their vendors, there is still no guarantee that they will not disturb operations in a production environment.

The environment an asset owner maintains can be very different from the environment that the vendor uses to test their patches and it is too costly to recreate a likewise environment.

b. The test environment should closely simulate the operational environment.

A common way to do is to apply the DTAP street concept, which includes systems for Development,Test, Acceptance and Production.

c. Redundant systems could be used to deploy the patch on, which are then put in to production.

During the evaluation whether the patch works as expected additional operational staff should be available to give their support to any potential issues caused by the patch.

If the patch fails the organization can revert to the earlier system.

d. Certified systems should be re-certified after a patch is applied. This is an extremely important point.

Technically speaking, any system that has been certified from a security perspective (e.g. a cryptographic device that is FIPS 140-2 certified) should be re-certified following a software patch. This is something that the industry tends to ignore because it costs time and money.

D. Distributing patches :

It is preferred to dedicate a patch management system for obtaining and applying software patches.

The sandboxing of such a system is paramount, as a patch management system could introduce significant risks attackers could potentially use it to distribute unwanted software.

The following best practices may be considered:

e. Utilize digital signatures on patches or do hash verification where possible/feasible

E. Patch scheduling:

a. Patch scheduling and deployment can be done after a patch has been tested thoroughly

and when the patch is approved for deployment.

b. Depending on the chosen distribution method the approval of production managers is necessary before deployment can be executed.

c. Preferably the deployment is incorporated into regular maintenance schedules, or when systems are less critical for operations, for instance during night time or during a period of low production.

* Conclusions

In the United States patch management is required for organizations that have to comply with the NERC CIP standard. While NERC CIP is mandatory for most utilities in Northern America there is no such universally mandatory standard in Europe. Therefore many different approaches are taken by asset owners within the European Union to handle patch management. The European Union or the Member States could increase the awareness of patches and patch management through enforcing that the issue of patch management should be taken into consideration when new requirements for devices are established.

15\12\2014

-------------------------------------------

SCADA Systems Operation

---------------------------------------

1 - Overview of SCADA, DCS, and PLCs

SCADA systems are highly distributed systems used to control geographically dispersed assets, often scattered over thousands of square kilometers, where centralized data acquisition and control are critical to system operation.

They are used in distribution systems such as water distribution and wastewate collection systems, oil and gas pipelines, electrical power grids, and railway transportation systems.A SCADA control center performs centralized monitoring and control for field sites over long-distance communications networks, including monitoring alarms and processing status data.

Based on information received from remote stations, automated or operator-driven supervisory commands can be pushed to remote station control devices, which are often referred to as field devices. Field devices control local operations such as opening and closing valves and breakers, collecting data from sensor systems, and monitoring the local environment for alarm conditions.

DCSs are used to control industrial processes such as electric power generation, oil and gas refineries, water and wastewater treatment, and chemical, food, and automotive production. DCSs are integrated as a control architecture containing a supervisory level of control overseeing multiple, integrated subsystems that are responsible for controlling the details of a localized process.

Product and process control are usually achieved by deploying feed back or feed forward control loops whereby key product and/or process conditions are automatically maintained around a desired set point. To accomplish the desired product and/or process tolerance around a specified set point, specific programmable controllers (PLC) are employed in the field and proportional, integral, and/or differential settings on the PLC are tuned to provide the desired tolerance as well as the rate of self-correction during process upsets. DCSs are used extensively in process-based industries.

PLCs are computer-based solid-state devices that control industrial equipment and processes.

While PLCs are control system components used throughout SCADA and DCS systems, they are often the primary components in smaller control system configurations used to provide regulatory control of discrete processes such as automobile assembly lines and power plant soot blower controls. PLCs are used extensively in almost all industrial processes.

The process-based manufacturing industries typically utilize two main processes :

1 - Continuous Manufacturing Processes.

These processes run continuously, often with transitions to make different grades of a product.

Typical continuous manufacturing processes include fuel or steam flow in a power plant, petroleum in a refinery, and distillation in a chemical plant.

Batch Manufacturing Processes.

These processes have distinct processing steps, conducted on

a quantity of material. There is a distinct start and end step to a batch process with the possibility of brief steady state operations during intermediate steps.

The discrete-based manufacturing industries typically conduct a series of steps on a single device to create the end product. Electronic and mechanical parts assembly and parts machining are typical examples of this type of industry.

Both process-based and discrete-based industries utilize the same types of control systems, sensors, and networks.

Some facilities are a hybrid of discrete and process-based manufacturing.

While control systems used in distribution and manufacturing industries are very similar in operation, they are different in some aspects.

One of the primary differences is that DCS or PLC-controlled subsystems are usually located within a more confined factory or plant-centric area, when compared to geographically dispersed SCADA field sites.

DCS and PLC communications are usually performed using local area network (LAN) technologies that are typically more reliable and high speed compared to the long-distance communication systems used by SCADA systems.

In fact, SCADA systems are specifically designed to handle long-distance communication challenges such as delays and data loss posed by the various communication media used. DCS and PLC systems usually employ greater degrees of closed loop control than SCADA systems because the control of industrial processes is typically more complicated than the supervisory control of distribution processes.

These differences can be considered subtle for the scope of this document, which focuses on the integration of information technology (IT) security into these systems.

Throughout the remainder of this document, SCADA systems, DCSs and PLC systems will be referred to as ICSs unless a specific reference is made the basic operation of an ICS .

2 - Key components include the following:

Control Loop. A control loop consists of sensors for measurement, controller hardware such as PLCs, actuators such as control valves, breakers, switches and motors, and the communication of variables. Controlled variables are transmitted to the controller from the sensors.

The controller interprets the signals and generates corresponding manipulated variables, based on set points, which it transmits to the actuators.

Process changes from disturbances result in new sensor signals, identifying the state of the process, to again be transmitted to the controller.

Human-Machine Interface (HMI). Operators and engineers use HMIs to configure set points,control algorithms, and adjust and establish parameters in the controller.

The HMI also displays process status information and historical information.

Remote Diagnostics and Maintenance Utilities.

Diagnostics and maintenance utilities are used to prevent, identify and recover from failures.

A typical ICS contains a proliferation of control loops, HMIs, and remote diagnostics and maintenance tools built using an array of network protocols on layered network architectures. Sometimes these control loops are nested and/or cascading –whereby the set point for one loop is based on the process variable determined by another loop. Supervisory-level loops and lower-level loops operate continuously over the duration of a process with cycle times ranging on the order of milliseconds to minutes.

---------------------------------------------

SCADA systems securtiy

* ICS Security Controls in SCADA systems

Security controls are the management, operational, and technical controls (i.e., safeguards or countermeasures) prescribed for an informational system to protect the confidentiality, integrity, and availability of the system and its information. This section discusses the security controls specified in

NIST SP 800-53, which was developed as part of the FISMA implementation project. See Appendix E for additional information regarding FISMA and the NIST-led implementation project.

NIST SP 800-53 provides guidelines for selecting and specifying security controls for information systems in support of Federal government information systems. Security controls are organized into three classes; management, operational, and technical controls. Each class is broken into several families of

controls; each control contains a definition of the control, supplemental guidance, and possible enhancements that will increase the strength of a basic control.

NIST has initiated a high-priority project in cooperation with the public and private sector ICS community to develop specific guidance on the application of the security controls in NIST SP 800-53 to ICSs. Since the project is still ongoing, the resulting guidance could not be included in the current release

of this document or NIST SP 800-53, but will appear in future releases.

Initial ICS specific recommendations and guidance, if available, will be provided in an outlined box for each section.

A single security product or technology cannot adequately protect an ICS. Securing an ICS is based on a combination of effective security policies and a properly configured set of security controls. An effective cyber security strategy for an ICS should apply defense-in-depth, a technique of layering security

mechanisms so that the impact of a failure in any one mechanism is minimized. Use of such a strategy is explored within the security control discussions and their applications to ICS that follow.

6.1 Management Controls Management controls are the security countermeasures for an ICS that focus on the management of risk

and the management of information security. NIST SP 800-53 defines four families of controls within the Management controls class:

Risk Assessment (RA): the process of identifying risks to operations, assets, or individuals by determining the probability of occurrence, the resulting impact, and additional security controls that would mitigate this impact

Planning (PL): development and maintenance of a plan to address information system security by performing assessments, specifying and implementing security controls, assigning security levels, and responding to incidents

System and Services Acquisition (SA): allocation of resources for information system security to be maintained throughout the systems life cycle and the development of acquisition policies based on risk assessment results including requirements, design criteria, test procedures, and associated documentation

Certification, Accreditation, and Security Assessments (CA): assurance that the specified controls are implemented correctly, operating as intended, and producing the desired outcome.

These management controls are discussed in more detail in the sections to follow. Initial ICS specific recommendations and guidance, if available, will be provided in an outlined box for each section.

* Risk Assessment

Risk is a function of the likelihood of a given threat source exploiting a potential vulnerability and the resulting impact of exploiting this vulnerability.

Risk assessment is the process of identifying risks to an organization’s operations, assets, and individuals by determining the probability of occurrence that an identified threat will exploit an identified vulnerability and the resulting impact. An assessment includes an evaluation of security controls that can mitigate each threat and the costs associated with implementing them.

A risk assessment must also compare the cost of security with the costs associated with an incident.

Achieving an acceptable level of risk is a process of reducing the probability of an incident that is accomplished by mitigating or eliminating vulnerabilities that can be exploited as well as consequences resulting from an incident. Prioritization of vulnerabilities must be based on cost and benefit with an

objective to provide a business case for implementing at least a minimum set of control system security requirements to reduce risk to an acceptable level.

A mistake often made during a risk assessment is to select technically interesting vulnerabilities without taking into account the level of risk associated with them. Vulnerabilities should be assessed and rated for risk before trying to select and implement security controls on them.

The security controls that fall within the NIST SP 800-53 Risk Assessment (RA) family provide policy and procedures to develop, distribute, and maintain a documented risk assessment policy that describes purpose, scope, roles, responsibilities, and compliance as well as policy implementation procedures.

An information system and associated data is categorized based on the security objectives and a range of risk levels.

A risk assessment is performed to identify risks and the magnitude of harm that could result from the unauthorized access, use, disclosure, disruption, modification, or destruction of an information system

and data. Also included in these controls are mechanisms for keeping risk assessments up-to-date and performing periodic vulnerability assessments.

In the FISMA Risk Framework , the risk assessment process is

applied after the Security Categorization activity and baseline Security Control Selection activity.

Risk assessment is performed in the Security Control Refinement activity to determine if the selected security controls need to be enhanced or expanded beyond the baseline security controls.

NIST SP 800-30, Risk Management Guide for Information Technology Systems (currently under revision) provides a risk assessment methodology, which includes the following steps:

1. System characterization – produces a picture of the information system environment, and delineation of system boundaries .

2. Threat identification – produces a threat statement containing a list of threat-sources that could exploit system vulnerabilities .

3. Vulnerability identification – produces a list of the system vulnerabilities that could be exercised by the potential threat sources .

4. Control analysis – produces a list of the planned controls used for the information system to mitigate the likelihood of a vulnerability being exercised and reduce the impact of such an adverse event.

5. Likelihood determination – produces a likelihood rating (High, Medium, or Low) that indicates the probability that a potential vulnerability may be exercised.

GUIDE TO SUPERVISORY CONTROL AND DATA ACQUISITION (SCADA) AND INDUSTRIAL CONTROL SYSTEMS SECURITY (DRAFT)

6. Impact analysis – produces a magnitude of impact (High, Medium, or Low) resulting from the exploitation of a vulnerability.

7. Risk determination – produces measurement for risk based on a scale of high, medium, or low 8. Control recommendations – produces recommendations of security controls and alternative solutions to mitigate risk .

9. Results documentation – produces a risk assessment report that describes the threats and vulnerabilities, measures the risk, and provides recommendations for control implementation.

Supplemental guidance for the RA controls can be found in the following documents:

NIST SP 800-12 provides guidance on security policies and procedures [39].

NIST SP 800-30 provides guidance on conducting risk assessments and updates

[19].

NIST SP 800-40 provides guidance on handling security patches [40].

NIST SP 800-42 provides guidance on network security testing [41].

NIST SP 800-60 provides guidance on determining security categories for information types [24].

ICS Specific Recommendations and Guidance Organizations must consider the potential consequences resulting from an incident on an ICS.

Welldefined policy and procedures lead to mitigation techniques designed to thwart incidents and manage the risk to eliminate or minimize the consequences.

The degradation of the physical plant, economic status, or national confidence could justify mitigation.

For an ICS, a very important aspect of the risk assessment is to determine the value of the data that is flowing from the control network to the corporate network.

In instances where pricing decisions are determined from this data, the data could have a very high value. The fiscal justification for mitigation

has to be derived by the cost benefit compared to the effects of the consequence. However, it is not possible to define a one-size-fits-all set of security

requirements.

A very high level of security may be achievable but undesirable in many situations because of the loss of functionality and other associated costs.

A well-thought-out security implementation is a balance of risk versus cost. In some situations the risk may be safety, health, or environment-related rather than purely economic.

The risk may result in an unrecoverable consequence rather than a temporary financial setback .

* Planning

A security plan is a formal document that provides an overview of the security requirements for an information system and describes the security controls in place or planned for meeting those requirements. The security controls that fall within the NIST SP 800-53 Planning (PL) family provide the basis for developing a security plan. These controls also address maintenance issues for periodically

updating a security plan.

A set of rules describes user responsibilities and expected behavior regarding

information system usage with provision for signed acknowledgement from users indicating that they have read, understand, and agree to abide by the rules of behavior before authorizing access to the information system.

GUIDE TO SUPERVISORY CONTROL AND DATA ACQUISITION (SCADA) AND INDUSTRIAL CONTROL SYSTEMS SECURITY (DRAFT)

Supplemental guidance for the PL controls can be found in the following documents:

NIST SP 800-12 provides guidance on security policies and procedures [39].

NIST SP 800-18 provides guidance on preparing rules of behavior [17].

ICS Specific Recommendations and Guidance, a security plan for an ICS should build on appropriate existing IT security experience, programs, and practices. However, the critical differences between IT and ICS addressed will influence how security will be applied to the ICS. A forward-looking plan is needed to provide a method for continuous security improvements.

ICS security is a rapidly evolving field requiring the security planning process to constantly explore emerging ICS security capabilities as well as new threats that

identified by organizations such as the US-CERT Control Systems Security Center (CSSC).

* System and Services Acquisition

The security controls that fall within the NIST SP 800-53 System and Services Acquisition (SA) family provide the basis for developing policies and procedures for acquisition of resources required to adequately protect an information system.

These acquisitions are based on security requirements and security specifications.

As part of the acquisition procedures, an information system is managed using a

system development life cycle methodology that includes information security considerations.

As part of acquisition, adequate documentation must be maintained on the information system and constituent components.

The SA family also addresses outsourced systems and the inclusion of adequate security controls by vendors as specified by the supported organization. Vendors are also responsible for configuration management and security testing for these outsourced information systems.

Supplemental guidance for the SA controls can be found in the following documents:

NIST SP 800-12 provides guidance on security policies and procedures [39].

NIST SP 800-23 provides guidance on the acquisition and use of ested/evaluated information technology products [42].

NIST SP 800-27 provides guidance on engineering principles for information system security [43].

NIST SP 800-35 provides guidance on information technology security services

[44].

NIST SP 800-36 provides guidance on the selection of information security products [45].

NIST SP 800-64 provides guidance on security considerations in the system development life cycle [46].

NIST SP 800-65 provides guidance on integrating security into the capital planning and investment control process [47].

NIST SP 800-70 provides guidance on configuration settings for information technology products [25].

#SCADA

SCADA system

Recent Posts

Comments

Subscribe Form