Final Report Summary - ESCORTS (European network for the Security of Control and Real-Time Systems)
ESCORTS is a project with participation from European Union (EU) process industries, utilities, leading manufacturers of control equipment and research institutes to foster progress towards cyber security of control and communication equipment in Europe. Its main objective is to assist European stakeholders in developing informed positions and in shaping current and future efforts related to control systems security standardisation. The project makes a number of recommendations in relation to future standardisation as well as research activities.
These recommendations for future standardisation as well as research activities were based on initial surveys of stakeholder needs, of the SCADA security market's expectations and of existing standards and guidelines. A more in depth evaluation of half a dozen selected standards and guidelines was performed. Some important standards and guidelines were applied in three security process evaluation 'experiments' at the location of the ESCORTS user companies to evaluate their usefulness in real situations.
The above surveys were complemented by reports showing a comprehensive overview of what has to be secured (delivered as a taxonomy of security vulnerabilities, threats and solutions) and how to measure the security level of installations (delivered as a metrics for cyber security assessment). These metrics were tested on a replicated live environment, providing feedback on where the industry current practise stands against these metrics.
Recommendations resulting from these activities were brought together in a research and development (R&D) and standardisation roadmap. The main conclusions and recommendations from this roadmap are:
- awareness of the breadth and fast evolution of cyber security threats is the most important;
- ISA99/IEC 62443 is the most promising standard with the largest coverage with respect to control systems. This was confirmed in our targeted experiments. Also, there is no need to wait for a final version to use it for enhancing overall security.
[Note: a technical incompatibility between IEC 62443-2-1 and ISO/IEC 27001:2005 was reported to CEN after the closure of ESCORTS which may have to be clarified].
- IEC 62351 is the most comprehensive technical specification addressing security of automation systems for the energy sector;
- CEN workshop agreements (CWAs) are suggested on the following subjects: metrics, security processes best practices, skills and competences and the exchange of security information;
- a research project is needed to identify key performance indicators for the monitoring of security level and behaviour;
- additional studies are needed (economic cost, a decision support system for CEOs, a testing methodology for verifying security assurance) as well the development of training material for use by staff having access to the control system.
Other reports produced (in addition to the reports indicated above) were a report on requirements for future cyber security laboratories and a report on requirements for a secure information and communication technologies (ICT) platform for the exchange of relevant data among the stakeholders.
ESCORTS being set up as a 'European network for the security of control and real-time systems', it is not only the technical contents of its reports that is important. Equally important are the plans for action beyond the project's completion. CEN will seek to launch with the support of the stakeholders a CEN workshop to deliver some of the CWAs as defined in the standardisation roadmap. This CEN workshop will also enable the community of stakeholders to continue and meet during 2011 and beyond.
Public information on the project is at:
http://www.escortsproject.eu(si apre in una nuova finestra)
http://www.cen.eu/cen/Sectors/Sectors/ISSS/Focus/Pages/FG-ESCORTS.aspx(si apre in una nuova finestra)
Project context and objectives:
Networked computers reside at the heart of critical infrastructures and systems on which people rely, such as the power grid, the oil and gas infrastructure, water supply networks etc. Today these systems are far too vulnerable to cyber attacks that can inhibit their operation, corrupt valuable data, or expose private information. Attacks compromising security of monitoring and control systems may also have wide negative impact on the safety of personnel, the public and the environment, by causing severe accidents like blackouts, oil spills, release of pollutants in the air, water and soil.
The foundations for the ESCORTS were laid in a JRC-survey performed during 2006, where the protection against external deliberate disruptions, e.g. terrorist attacks, organised crime, information warfare, were addressed.
From the survey, the following conclusions appeared to outstand:
- Currently, the United States (US) harbours a cyber security culture with reference to control and communication systems. Several industry sectors - electricity, oil, gas etc. have issued guidelines and have set up a common platform, the process control systems forum. National facilities, where to test the security of control and communication components, do exist and are used on a routine basis.
- Europe appears to lag behind with respect to the US. There is less awareness about cyber security risks and a lack of expertise among technicians in the process control sector. Europe also lacks facilities where to test equipment resilience against cyber attacks, so that EU manufacturers and operators currently need to resort to US cyber security facilities to test their products and services.
- Although several standardisation efforts, coordinated by different bodies, exist, standardisation proceeds at a slow pace - also because the effort contributed by stakeholders appears to be sub-critical. So far, the US approach based on sector guidelines appears more pragmatic and productive.
- In particular, the IEC TC 65 and ISA SP-99 are leading current efforts to ensure security of control equipment, while IEC TC 57 is addressing cyber security of electrical communication equipment, e.g. for substations. As some power system communications have more specific and stringent requirements than most of the other process control areas, IEC TC 57 recommendations appear somewhat diverging from the mainstream.
ESCORTS was thus proposed to address the main recommendations emerging from the above survey:
- Encourage best practice, possibly in a joint endeavour between manufacturers and end users. Develop and establish test platforms for SCADA and other process control equipment in Europe.
- Try to reduce the divergence between current standardisation efforts, especially between process control in general and power system control.
- Liaise with the US.
- Promote awareness on security risks by the stakeholders' personnel like plant and security managers, researchers, process operators, information technologies (IT) specialists, and the general public.
The ESCORTS proposal was submitted in May 2007 under topic SEC-2007-7.0-02 European Security Research Network (inclduing for standardisation), as a joint endeavour among EU process industries, utilities, leading manufacturers of control equipment and research institutes to foster progress towards cyber security of control and communication equipment in Europe. The objective of ESCORTS was to be a leading force for disseminating best practice on supervisory control and data acquisition (SCADA) security implementation and to assist stakeholders in developing informed positions and in shaping current and future efforts related to control systems security standardisation
The ESCORTS project had its kick-off meeting on 17 June 2008 in Brussels. The ESCORTS consortium is inter-sector, and involves the main EU manufacturers of SCADA equipment (ABB, Areva T&D - now Alstom Grid, Siemens) under CEN lead, and important SCADA end-users in different processes: power generation (Enel), electricity transmission (Transelectrica), and water management (Mediterranea delle Acque).
A stakeholder advisory board including partners from several process areas (power, gas, oil, water, chemicals and petrochemicals, pharmaceuticals) was established to ensure coherence between, and across, the different stakeholders and activities, and to comment on the various reports created by ESCORTS.
In order to make it clear that any standardisation discussions resulting from ESCORTS should take place in an open standardisation environment, there was created a CEN focus group consisting of the stakeholders involved in the stakeholder advisory board, but with the possibility to grow during the entire process duration. In line with the CEN procedures, secretariat support to this focus group was given by a national standards organisation, in this case by UNINFO from Italy.
Project results:
Further defining the ESCORTS environment
Survey on stakeholders needs
The project started by verifying the context as it had originally led to the creation of ESCORTS and produced the 'survey on stakeholders needs' report which confirmed the assumptions underlying the need for the ESCORTS activities:
- EU industry awareness and readiness lags behind US initiatives.
- There is a growing feeling in Europe that security issues are crucial for reliable critical control system operation, so vendors and users are trying to keep the pace with what emerges as best practice security.
- There seems to be the lack of European explicit demand for comprehensive security solutions. Two related issues emerge as decisive. On the one hand, there is the potential cost of security measures, which might weigh considerably on the overall control equipment cost. On the other hand, there is the lack of adoption in Europe of common security reference or baseline (be them formal or de facto standards, guidelines, or accepted best practices accepted and applicable across all countries).
- Certification is necessary for ensuring the cyber security of industrial processes, but not sufficient. The organisational dimension is the key one in a longer term perspective. To that aim, a long term strategy is to be instantiated. Impact assessment is very important. In that respect process security is definitely the key prospect: no business case of a comparable size can be quoted when looking to disruptions of the mere IT business network.
The 'survey on stakeholders needs' report concludes by stating that 'although ESCORTS, alike many similar endeavours, may play a role in increasing the awareness of European stakeholders and in the harmonisation of the European market place, by fostering adoption of more uniform security guidelines EU wide, it is evident that Europe must substantially increase its efforts to urgently secure mission critical systems.'
Market for SCADA security services
A second deliverable setting the scene evaluated the market for SCADA security services. This study concentrated on three important aspects of security related services:
- Security assessments help to find deficiencies with respect to the security organisation of an operator and with respect to the implementation of technical security measures.
- Security testing which can be regarded as (the technical) part of a security assessment (for an infrastructure operator), but it is also relevant for the vendors of control system components or systems.
- Security training and awareness can be seen as an important part of the security assessment with respect to organisational aspects and is the precondition that the implemented technical security measures will have the intended effects. Adequate training is the most important factor to discriminate a security induced event from an everyday operational fault.
Security testing
With respect to security testing the study concluded that there are two aspects to be considered.
The first aspect is the testing of critical infrastructure installations and of their critical components. This usually is done in relation to a security assessment of the system. Testing of real-live systems is possible but has to be performed with extreme caution in order to avoid discontinuation or breakdown of the system. On the other hand testing of a reference system in a test range would be less dangerous. But building up such facilities for realistically emulating industrial systems would require important investment. The results of these tests have to be interpreted correctly, but a capable test range can provide the possibility of testing systems before their deployment.
The second aspect is security testing of the components by the vendors themselves. Some vendors (at least the larger ones) already perform security tests of their equipment as part of the quality assurance processes. Special test-beds for evaluating equipment can be justified as a centralised placed for operators, vendors and government agencies to collaborate in the search for appropriate security solutions against a full range of threats and security scenarios
Training and awareness
The study suggested that Security training, for example on awareness, does not need necessarily to be provided by special teaching companies; governmental organisations can also raise awareness.
As the awareness level for cyber security issues increases, more companies will organise 'cyber-security training' for their employees. There are already providers delivering 'training sessions' to control system owners. A number of actors address the market for security training: specialised training institutes, universities, public authorities (US-CERT, US-NIST, NL-NICC, UK-CPNI, etc.), IT firms, software vendors, control system vendors (linked to product installation), control system consultants, independent experts/trainers. But these activities also seem to be limited to the security aware industrial sectors (e.g. energy, chemical or pharmaceutical industry). However, this is unsurprising as security training often is an initiative accompanying previous security assessments.
Conclusion of the study
The study concluded that there is, beside managed security services, definitely a market also for other security services, especially for security consulting, which includes security assessments, testing, and training. But the readiness of the actors (mainly the operators of critical infrastructure) depends on the sector to which they appertain. There are some sectors -such as energy, chemical or pharmaceutical industry- with a significant security awareness, who are already performing security assessments. However these are often enforced by specific regulations rather than being intrinsically motivated. In addition different methodologies / guidelines are used for these assessments and different amount of effort is spent, which makes a comparison of the security levels achieved very difficult.
The overall conclusion of the study is that the security service market in the area of critical infrastructure is in an early phase. As the awareness to cyber security issues increases continuously the dimension of the security service market will grow accordingly. However, missing commonly accepted guidelines or standards for security testing and/or security assessments currently hinder the providing of such security services.
Solutions, standards and guidelines for SCADA security
A second strand of activities of ESCORTS related to solutions, standards and guidelines (to be) used for assisting security of the control systems.
Taxonomy of security solutions for the SCADA sector
The report on a taxonomy of security solutions for the SCADA sector describes the more typical cybersecurity problems encountered by industrial control systems, and the solutions that can be put in place for countering them. It classifies and lists security vulnerabilities, threats and solutions, but it does not recommend best practices or possible options. This could be the aim of further work, but the effort demand is beyond the possibilities of this project.
Following an overview of SCADA architectures and a discussion on SCADA protocols, the taxonomy report lists and classifies security vulnerabilities, threats and solutions.
SCADA vulnerabilities were classified into:
1. architectural vulnerabilities
2. security policy vulnerabilities
3. software vulnerabilities
4. communication protocol vulnerabilities
4.1 MODBUS vulnerabilities
4.2 DNP3 vulnerabilities
4.3 summary of the vulnerabilities of protocol and relevant threats.
Attack scenarios were classified into:
1. SCADA protocol oriented attacks
1.1 SCADA malware DOS scenario
1.2 SCADA unauthorised command execution scenario
1.3 SCADA system data poisoning
2. Process network attacks
2.1 OPC DOS
2.2 OPC corruption poisoning
2.3 OPC protocol corruption
2.4 SCADA server DOS
2.5 SCADA server corruption
2.6 SCADA server data flow corruption
2.7 HMI corruption
3. exchange network attacks
3.1 real-tima databases attacks
3.2 Diagnostic server attacks.
Finally, a number of SCADA security countermeasures were proposed, describing a (limited) set of security countermeasures for the above listed vulnerabilities. The potential countermeasures that are and can be implemented in the real world obviously exceed this list. The cases presented are further representative of one potential approach, without the aim of prescribing or suggesting their use.
SCADA security countermeasures:
1. Communication protocol countermeasures (addressing the 2 kinds of communication protocols in plant networks)
1.1 TCP/IP countermeasures
1.2 SCADA protocol (Modbus, DNP3 etc.) countermeasures
2. Filtering and monitoring countermeasures (list is illustrative, not exhaustive)
2.1 multi-homed PC
2.2 multi-homed server with software firewall
2.3 layer 3 switch network filtering
2.4 two port firewall
2.5 dual filtering (router firewall)
2.6 multi-port firewall with demilitarised zone
2.7 paired firewall and multiple DMZ
2.8 firewall / VLAN architecture
2.9 firewall / VLAN / VPN architecture
2.10 monitoring
2.11 limits of intrusion detection in SCADA systems
3. Architectural good practices include
3.1 firewall and network segregation
3.2 domain name system (DNS)
3.3 hyper text transfer protocol (HTTP)
3.4 FTP and trivial file transfer protocol (TFTP)
3.5 telnet
3.6 simple mail transfer protocol (SMTP)
3.7 simple network management protocol (SNMP)
3.8 distributed component object model (DCOM)
3.9 SCADA and industrial protocols
3.10 antivirus and malware detection
3.11 backup, restore and disaster recovery
3.12 remote access and data transfer services
3.13 system hardening
3.14 wireless connectivity
3.15 account management
3.16 software management and update
4. Organisational countermeasures.
The report here summarises some of the NERC's requirements for critical infrastructure protection. NERC developed these standards specifically for the North American bulk electric system; however, many of these standards are valid guidelines and suggestions for designing and operating many other industrial systems.
The consortium found security for control systems to be a complex subject due to at least the three following reasons:
- the architecture of control systems, while getting complex for functional and topological reasons, is rarely designed with security goals in mind;
- the technologies employed (such as most prominently the SCADA protocols) are often insecure by nature;
- because the business benefits from security are not immediately evident, the practices employed by the companies, rarely consider security among their goals.
Survey of existing methods
A survey of existing methods, procedures and guidelines in support of secure SCADA applications was produced. The survey lists existing methods, procedures and guidelines in the area of control system (cyber) security, addressing activities of international organisations, important national activities in Europe and the US, as well as the most important branch specific activities (international and national).
The following standards, guidelines or regulations relevant for operators or manufacturers in the area of control system (cyber) security, were identified and commented upon:
1. AGA Report No. 12, Cryptographic Protection of SCADA Communications, Part 1: Background, Policies and Test Plan, American Gas Association, March 2006
2. American Chemistry Council Cyber Security Guideline: Guidance for Addressing Cybersecurity in the Chemical Industry, Version 3.0 May 2006
3. API Standard 1164, Pipeline SCADA Security, September 2004
4. API Security Guidelines for the Petroleum Industry, April 2005
5. CIGRE - Management of Information Security for an Electric Power Utility - On Security Domains and Use of ISO/IEC17799 Standard
6. CPNI - A good practice guide: Process Control and SCADA Security
7. CPNI - Firewall Deployment for SCADA and Process Control Networks
8. DHS - Catalog of Control Systems Security: Recommendations for Standards Developers
9. DoE / DHS Roadmap to Secure Control Systems in the Energy Sector
10. DoE / ESISAC - Energy Infrastructure Risk Management Checklists for Small and Medium Sized Energy Facilities
11. DoE / ESISAC - Vulnerability Assessment Methodology
12. DoE / TSWG - 21 Steps to improve Cyber Security for SCADA systems
13. DoE / TSWG - Securing Your SCADA and Industrial Control Systems
14. IEC 61400-25 - Communications for monitoring and control of wind power plants
15. IEC 61784-4 - Industrial Communications - Fieldbus Profile - Part 4: Profiles for secure communications in industrial networks
16. IEC 62210 - Power system control and associated communications - Data and communication security
17. IEC 62351 - Data and communication security
18. IEC 62443 - Security for industrial process measurement and control - Network and system security
19. IEEE 1402 - IEEE Guide for Electric Power Substation Physical and Electronic Security
20. IEEE P1686 - Draft Standard for Substation IED Cyber Security Standards
21. IEEE P1689 - Trial Use Standard for Cyber Security of Serial SCADA Links and IED Remote Access
22. IEEE P 1711 - Trial Use Standard for SCADA Serial Link Cryptographic Modules and Protocol
23. ISA -99 series - Security of industrial automation and control systems
24. ISO 13335 - Information Technology - Guidelines for the Management of IT-Security
25. ISO 15408 - Common Criteria
26. ISO 17799 - Code of practice for information security management
27. ISO 2700x - Information technology - Security techniques - Information security management systems - Requirements
28. NAMUR NA 115 - IT-Security for Industrial Automation Systems: Constraints for measures applied in process industries
29. NERC CIP-002-009 - Cyber Security Standard
30. NERC - DoE / ESISAC Security Guidelines for the Electricity Sector
31. NIST PP ICC - Protection Profile for Industrial Control Centres
32. NIST SP 800-53 - Recommended Security Controls for Federal Information Systems
33. NIST SP800-82 - Guide to Industrial Control Systems (ICS) Security
34. NIST/PCSRF - Field Device Protection Profile For SCADA Systems In Medium Robustness Environments
35. OLF Guideline No. 104 - Information Security Baseline Requirements for Process Control, Safety and Support ICT Systems
36. SEMA Guide to Increased Security in Process Control Systems for Critical Societal Functions
37. VDEW M-07/2005 - Zehn Schritte zur VEDIS-Sicherheit
38. VDI 2182 - Informationssicherheit in der industriellen Automatisierung - Allgemeines Vorgehensmodell
39. VGB-R 175 - IT Sicherheit für Erzeugungsanlagen
Targeted experiments
Some of the above standards / guidelines were used in targeted experiments at the location of the ESCORTS user companies (Enel, Transelectrica and Mediterranea delle Acque) where the companies' security processes were evaluated against the standards/guidelines that were chosen.
Areva (now Alstom Grid) / Transelectrica experiment
A first experiment was done by a vendor/user team consisting of Areva (now Alstom Grid) / Transelectrica. The standards which were taken as a reference in this targeted experiment were ISO 27002 (ISO 27001) (focusing on confidentiality) and the NERC - CIP standards 2-9 (focusing on availability).
The following learning points were reported from this targeted experiment:
- ISO 27000 audit process oversized for critical systems
- Focus on ISO 27002 more than on ISMS
- Adaptation required for self-assessment
- Target is not compliance but awareness
- Part of the security measures are embedded for availability
- Advantage in an ISO 27001 certified environment
- Critical assets must be managed internally (technically)
- System availability is a shared responsibility when maintenance is provided by vendor (cyber security-wise)
- NERC CIP is less subject to interpretation
-NERC CIP audit process need to be analysed.
ENEL/ABB experiment
A vendor / user team consisting of ENEL/ABB conducted a second experiment. ABB and ENEL jointly selected the ISA 99 standard (at its current draft status) as a basis for this assessment, as it was commonly agreed that - given the joint efforts between ISA and IEC to parallelise the editorial procedures for co-publishing as ANSI/ISA 99 and IEC 62443 - this standard is a promising candidate for a global, cross-industry security standard.
During the experiment between ABB and ENEL, the following findings or types of findings were achieved:
- The ISA 99 standard used as a reference framework is in general very applicable to the operation of power plants and the control systems involved therein. However, there were some gaps identified in the standard and in general, it was noted that the standard is very comprehensive. Thus, it takes some time to be acquainted with it. Once it is completed, published and more experience is available, this will become less of an issue.
- An open analysis of system design, deployed configurations and policies and procedures for operations increased the awareness of existing security controls (both technical and organisational ones) among the different organisational units of ENEL and between ABB and ENEL. Especially the complementary nature of physical and cyber security as well as operational and technical security controls could only be discovered by a cross-disciplinary team, as it was present in the assessment.
- ISA99 reflects and links risk assessment to security planning
- Operational security requirements (policies, procedures) comprehensive and easy to evaluate
- ISA-99 well structured
- Identification of 'zones' and 'conduits' difficult
- ISA-99 imposes several requirements for zone definitions, but currently leaves a lot of discretion for asset owners. Here is room for improvement.
- Detailed requirements in terms of security controls for each zone are present, but difficult to use
- Determination of system security assurance levels (SAL) is difficult, as the link between 'impact' and 'SAL' is missing
- To implement and maintain ISA99 compliance is very difficult and expensive for an electric utility:
i. several devices, complex infrastructure, many people involved
ii. different organisation units must cooperate, creation of new organisation units could be necessary, entire life cycle requires continuous effort, etc.
and for an IACS vendor:
iii. security must be embedded the design of the IACS system
iv. IACS integration in a customer owned infrastructure is challenging.
The costs for becoming ISA99 compliant could not be estimated. This is a recommended task for future projects:
- Compliance metrics monitoring (ISA-99.01.03) is important for certification, but the value of certification is considered controversial. Risk assessment guidelines and vulnerability tests seem to be necessary, too.
The ISA 99 standard was concluded to be very comprehensive but maintaining ISA 99 compliance was considered to be difficult and expensive.
There were also identified a number of suggestions for ISA-99 revision, which were taken due notice of by Dennis Holstein of OPUS, lead editor of ISA99 working group 4.
Mediterranea delle Acque experiment
This third experiment evaluated the risk of the control systems for a water utility (Mediterranea delle Acque). The security analysis of the control system was split into two main activities:
1. Definition and application of a control check list based on the selected ISO/IEC 2700x standards (The analysis was based on two of them: ISO/IEC 27001, the core standard of the series that is related to the definition of an information security management system, and ISO/IEC 27002, which provides specifications for the implementation of security controls).
2. Evaluation of the applicability of the standards to the Mediterranea delle Acque infrastructure.
It was concluded that the standard ISO/IEC 27001 is fully applicable to the Mediterranea delle Acque control network, but there are some issues in the real application. Regarding ISO/IEC 27002, some controls could not be applied to a control network analyzed (for example, the section about electronic commerce) or to the specific control network under analysis, like the specifications regarding third party collaborations
This third experiment confirmed the findings of the 1st experiment and concluded that the ISO/IEC 27000 standard family is quite generic and mainly focused on people behaviour, thus the adoption of its specifications is necessary but not sufficient to guarantee the complete security of a critical infrastructure against cyber threats. In many cases, the major vulnerabilities come from user behaviour, and ISO/IEC 27000 could help in mitigating the effects; however, more technical solutions could be required (e.g. network architecture design, communication protocols, etc.) in order to provide an adequate security level.
R&D and standardisation road map
Standards extending to the right in x-axis direction have relevance for manufacturers. Typically, such standards have detailed technical requirements up to the definition of special security protocols, which must be implemented by the manufacturers. In contrast, the more a standard extends to the left of the x-axis, the more it is focused on a secure operation. NERC-CIP, for example, prescribes specific actions for operators to do.
Standards extending to the top of the y-axis list precise design details and leave little room for interpretation. IEC 62351, for instance, is intended to list design details in such extend that device interoperability between various manufacturers is guaranteed. Standards extending to the bottom of the y-axis are covering a broad range of various security areas and thus can be consulted in order to get estimation on the overall security level.
The project performed a more detailed study on a subset of the 39 identified standards, focussing on the most relevant and comprehensive standards, namely:
- NERC CIP (Recommendation relevant for bulk energy system operators in the US);
- ISO 27000 (Generic standard defining a information security management system);
- ISA 99 / IEC 62443 (Generic standard defining among others a cyber security management system taking into account best practices from industrial automation) (note, that ISA and IEC negotiated, that the ISA 99 standards will be adopted as IEC standards as well).
In addition the project focussed on:
- CPNI/NISCC: Good practice guides (Best practice recommendations, UK)
- NIST 800-53, Recommended security controls for federal information systems and organisations (US).
- IEC 62351 (Technical standard designed to secure the control communication within energy automation systems)
- IEEE 1686 (Technical standard defining security requirements for intelligent electronic devices)
This way, there were included a guideline and a standard addressing industrial information systems in general, as well as standards which mainly define technical measures to be used in control system design.
These seven selected standards were evaluated with respect to topics which have to be addressed when designing secure SCADA or control systems (manufacturer point of view) or which have to be addressed when operating such a system (operator point of view).
An appraisal of:
- 0 means that the topic is either not appropriately addressed in this standard, or there are no clear statements how to address this topic or it is even not addressed at all;
- 1 means that the standard includes clear statements, so that the audience (manufacturer or operator) at least can derive actions with respect to this topic.
However, detailed statements on the completeness of each standard go beyond the scope of the project.
This gap and overlap analysis led to the following main findings (MF):
(MF1)
No single standard covers all aspects (necessary to design, build and operate secure control systems); in Europe there is in addition the issue of many national languages. It is therefore recommended to (REC1) define a CEN workshop agreement (CWA) to carry out a thorough assessment of gaps regarding a common terminology and conceptual base (possibly taking as reference ISA 99).
(MF2)
Standards partly have large overlaps and will be used in parallel. It is therefore recommended to (REC2) start an experiment with respect to the assessment of the joint use of standards.
(MF3)
Missing security requirements for tool sets used for configuration leads the following recommendation (REC3) Define a CEN workshop agreement with the goal to develop what security aspects need to be addressed with respect to the definition of tool sets used for configuration. The outcome of this CWA could then be used as a basis for a new work item proposal (NWIP) within IEC.
(MF4)
The observation that general purpose standards (by nature) do not take into account use case specific requirements leads to the recommendation: (REC4) to promote (e.g. within ISO/IEC SC27) the production of technical guidelines for the application of general purpose standards to the different technical fields.
These recommendations from the gap and overlap analysis were added to a number of other recommendations that did follow from the work on the other reports and led to the following overall conclusions for a R&D and standardisation road map:
- Awareness of the breadth and fast evolution of cyber security threats is the most important.
- ISA99/IEC 62443 is the most promising standard with the largest coverage with respect to control systems. This was confirmed in our targeted experiments. Also, there is no need to wait for a final version to use it for enhancing overall security.
- IEC 62351 is the most comprehensive technical specification addressing security of automation systems for the energy sector.
- It was concluded in the near term the need for CWAs on the following subjects: metrics, security processes best practices, skills and competences and the exchange of security information
- A research project is needed to identify key performance indicators for the monitoring of security level and behaviour.
- Additional studies are needed (economic cost, a decision support system for CEOs, a testing methodology for verifying security assurance) as well the development of training material for use by staff having access to the control system.
Measuring and testing
Metrics for cyber security assessment and testing
There is no commonly accepted definition of security metrics. The term, as used in practice, appears to represent several different notions: metric (in the sense of quantitative standard function based on process and / or product measures), measurement, score, rating, rank, or assessment. The definition used for the ESCORTS report is the one adopted by the Workshop on Information Security System Rating and Ranking (WISSRR): 'A metrics is a value, selected from a partially ordered set by some assessment process that represents a quality of some object of concern in the ICT system.'
The report makes proposals for specific metrics that can be applied for assessing SCADA systems, and categorises them in the 3 following categories:
1. Organisational metrics, including security program metrics and security process metrics. For example: Access control effectiveness (e.g. percentage of access points where unauthorised could be gained).
2. Operational metrics, including the operational readiness/security posture of the organisation, their risk management support measures, the threat environment, and the incident response and vulnerability management practices. For example: metrics with reference to best practices (such as NIST's practices and checklists / implementation guides).
3. Technical metrics, including those metrics based on standards of reference, or other ad-hoc metrics defined for the specific application. For example: attack surface (ATS), a metric defining the percentage of nodes of a target system / subsystem that is susceptible to a certain type of attack.
The report suggests that the proposed metrics can be used for different purposes:
- The organisational metrics can be used for the evaluation of the effectiveness of the security programs, and for the evaluation of the management, operational and technical controls in place in a given installation as well as for the evaluation of the relevant management and technical processes.
- The operational metrics can be used for measuring the readiness of all the SCADA security controls and their compliance with standards of reference.
- The technical metrics can be used to enable the user answering questions such as: 'Which nodes of my system appear to be subject to specific attack mechanisms?', 'How fast can a certain attack proceed?' Or 'What is the potential downtime resulting from a certain attack? How fast can the system recover?'
The metrics however cannot answer a question such as 'Is my system secure?' Indeed, without reference to specific threat scenarios this is not a meaningful question. And, in addition the analyst would have to explain that any answer will depend on the assumptions, criteria and procedures used, which are a function of the metrics chosen.
The report suggests as a next step the application of the proposed metrics in case studies for their validation and adjustment. Such an assessment was undertaken as part of the ESCORTS project. A test was performed but the details of the tested environments are confidential between the participating entities.
Requirements for future cyber security laboratories
This report presents a first consideration of the requirements for a laboratory for conducting security experiments with SCADA systems. The main consideration has been that the laboratory would be used by all potential stakeholders, and not only by the SCADA system manufacturers. This puts special conditions, mainly from the standpoint of the target system for the experiments. The field of experimental security of information and communication technologies is just emerging in the last years, and there is a lot to learn yet. Mainly from the methodological perspective, it is clear that there are many gaps. The report highlights some of them.
The report suggests that the development in the future of SCADA security labs will have to pay particular attention to the following:
- the extension and details of the target system: more details will result in more complexity, but the realism of certain reproductions of incidents might require a rather thorough consideration of components, as the only means for reaching an acceptable level of fidelity;
- the capacity of the attack resources and sophistication of the attack mechanisms: here the opposition is between the manageability of the experiment, versus the reproduction of realistic conditions;
- the capacity of control and observation of the experiments: the ambition to have powerful experimental facilities will require to develop complex settings, with control of the evolution of the experiment, and the extended collection of data;
- the repeatability and comparison of results: more value will be derived from the possibility to confront different experiments.
A secure ICT platform for data exchange
Europe will benefit from having an information exchange framework for SCADA security in place, with procedures and guarantees that provide incentives and instruments for the interaction among all interested stakeholders.
A pilot implementation of a secure ICT platform for the exchange of relevant data among the stakeholders is running in the JRC at ISPRA.
The ESCORTS report discusses from the communication and technical point of view, the basic elements that should be taken into account in the implementation of such information exchange.
The report identifies various problems that should be resolved by any developer of an information exchange, based on the experience obtained when developing the prototype.
These are listed in two categories:
Factors affecting interoperability
- Numerous autonomous agencies will take part of information exchanges, each one with their own expectations and requirements, primary language and background, etc. There is an inherent difficulty in synthesising a common view. The requirements, design and development processes will require extensive iteration, and foresee long and complicated steps for the verification and validation of the final product.
- Multiple trust domains are the natural consequence of the numerous autonomous organisations coming from many countries. The agreement on a common specification of the basis for trust among all actors appears as a fundamental initial point.
- Heterogeneous computing environments in use by the various actors, which will require the development of a system that could be compatible with all of them.
- Varied governance structures (i.e. different ways for making decisions about the process for gathering, vetoing, sanitising, distributing, etc., all data). This should result in a structure of requirements that satisfy all these different structures.
- Significant investment in legacy environments, which preclude the introduction of new hardware / software systems (such as databases) unless they are seamlessly compatible with existing applications, and do not impose any hard restraint on future decisions
Primary impediments to information sharing
- Incompatible terminologies and technologies (such as formats) used for the description and storing of data. Each industrial actor, or at items sector, uses their own approach, and at times standard. Much can be gained from common, standardised approaches for the specification of security-related information (not unique, but at least compatible), including taxonomies, protocols for handling contents and for other tasks (e.g. validation).
- Identification, authentication and authorisation policies for personal users in different organisations, which prevent the immediate recognition of those users in different organisations.
- Disparate and incompatible security mechanisms and policies across organisations.
Potential impact:
Networked computers reside at the heart of critical infrastructures and systems on which people rely, such as the power grid, the oil and gas infrastructure and power, oil and chemical process plants.
The impact of a major failure or a well targeted and successful attack on the electrical system (physical as well as presumed cyber attack) could be a major regional or national blackout possibly with cross-border ramifications. In recent years, both Europe and America have experienced a significant number of major blackouts. Based on known facts and publicly available investigation reports, these blackouts were usually not caused by malicious attacks but nevertheless the current international scene calls for increased vigilance for the malicious risk factor.
Today, many of the systems are vulnerable to cyber attacks that can inhibit their operation, corrupt valuable data, or expose private information. Exposure to malicious threats is massively growing, and intelligence sources estimate today a disruptive attack more likely to target Europe than the US.
Vulnerabilities due to design and technology flaws may be exploited by malicious antagonist actors, who can gain access to the systems through external and internal connections. These threats menace industry in the whole industrial process spectrum, as their supervisory control and data acquisition systems are based on similar technologies and are deployed using analogous architectures.
Standards can help in the protection of SCADA in different ways:
- helping in setting a common conceptual basis between all stakeholders: operators, vendors, certifiers, authorities, etc.;
- supporting all engineering processes: from specification to procurement, and from operation to maintenance;
- fostering the development of a market for security products and services, with verifiable levels of assurance.
The project concluded that the main issue is not a shortage of standards and guidelines but rather the need to increase awareness and the need to promote existing standards and guidelines among the users of industrial control systems.
Dissemination
The final open conference was attended by 31 people of 11 European countries, EC and US, representing main SCADA manufacturers, security bodies, critical infrastructures like electricity and water, standardisation bodies, users associations.
At this open conference it was presented how the ESCORTS recommendations in the roadmap will help in combating targeted attacks to SCADA systems.
The early detection of (targeted) attacks in critical infrastructures was added as an additional recommendation to combat targeted attacks (bearing in mind for instance the time line of Stuxnet).
Some other main findings of the project were presented at the open conference, including the following reports:
- Surveys of stakeholder needs and of the market for SCADA security in the EU
- Conclusions from security assessment experiments at Transelectrica, ENEL and Mediterranea-delle-Acque, with regard to the use of specific standards
- Metrics for cyber security assessment and testing, and Verification of these metrics on a replication of a live control system
- A R&D and standardisation roadmap containing recommendations suggesting next steps for the security of SCADA and critical structures using SCADA.
Considering that the ESCORTS project made in its standardisation roadmap several proposals for CEN workshop agreements, efforts were made to keep the CEN and CENELEC standardisation community well informed on these proposals. This was done through regular emails to the CEN/CENELEC ICT forum which consists of representatives of national standards bodies and national committees (these representatives are mostly active in a CEN context, CENELEC national committees are not well represented). Feed-back from a participant in the CEN/CENELEC ICT forum provided an additional information that had not been identified during the ESCORTS project itself, namely an alleged technical incompatibility between IEC 62443-2-1 and ISO/IEC 27001:2005 (as a result ISA99/IEC 62443 was voted down from becoming a European Standard). Working towards resolving this incompatibility could be the part of the guidance material that ESCORTS has recommended to be produced.
ESCORTS being created as a network of stakeholders, proactive efforts were made from the start to have the stakeholders participating in the stakeholder board. More than 30 members signed up for the stakeholder board after the 1st meeting in Baden-Daetwill, February 2009. The stakeholder board was later mirrored in the form of a CEN focus group to stress the openness of the activities that related to standardisation.
In order to ensure that any follow-up action will reach out to the stakeholders, ESCORTS collected a list of the stakeholders for inviting when the proposed work on the CEN workshop agreements will start. (Participation in CEN workshops is based on direct participation, and not based on national representation as in technical committees in CEN, CENELEC, ISO or IEC.) The list can also be used to inform the stakeholders on other relevant messages such as the ENISA questionnaire on industrial control systems security.
These recommendations for future standardisation as well as research activities were based on initial surveys of stakeholder needs, of the SCADA security market's expectations and of existing standards and guidelines. A more in depth evaluation of half a dozen selected standards and guidelines was performed. Some important standards and guidelines were applied in three security process evaluation 'experiments' at the location of the ESCORTS user companies to evaluate their usefulness in real situations.
The above surveys were complemented by reports showing a comprehensive overview of what has to be secured (delivered as a taxonomy of security vulnerabilities, threats and solutions) and how to measure the security level of installations (delivered as a metrics for cyber security assessment). These metrics were tested on a replicated live environment, providing feedback on where the industry current practise stands against these metrics.
Recommendations resulting from these activities were brought together in a research and development (R&D) and standardisation roadmap. The main conclusions and recommendations from this roadmap are:
- awareness of the breadth and fast evolution of cyber security threats is the most important;
- ISA99/IEC 62443 is the most promising standard with the largest coverage with respect to control systems. This was confirmed in our targeted experiments. Also, there is no need to wait for a final version to use it for enhancing overall security.
[Note: a technical incompatibility between IEC 62443-2-1 and ISO/IEC 27001:2005 was reported to CEN after the closure of ESCORTS which may have to be clarified].
- IEC 62351 is the most comprehensive technical specification addressing security of automation systems for the energy sector;
- CEN workshop agreements (CWAs) are suggested on the following subjects: metrics, security processes best practices, skills and competences and the exchange of security information;
- a research project is needed to identify key performance indicators for the monitoring of security level and behaviour;
- additional studies are needed (economic cost, a decision support system for CEOs, a testing methodology for verifying security assurance) as well the development of training material for use by staff having access to the control system.
Other reports produced (in addition to the reports indicated above) were a report on requirements for future cyber security laboratories and a report on requirements for a secure information and communication technologies (ICT) platform for the exchange of relevant data among the stakeholders.
ESCORTS being set up as a 'European network for the security of control and real-time systems', it is not only the technical contents of its reports that is important. Equally important are the plans for action beyond the project's completion. CEN will seek to launch with the support of the stakeholders a CEN workshop to deliver some of the CWAs as defined in the standardisation roadmap. This CEN workshop will also enable the community of stakeholders to continue and meet during 2011 and beyond.
Public information on the project is at:
http://www.escortsproject.eu(si apre in una nuova finestra)
http://www.cen.eu/cen/Sectors/Sectors/ISSS/Focus/Pages/FG-ESCORTS.aspx(si apre in una nuova finestra)
Project context and objectives:
Networked computers reside at the heart of critical infrastructures and systems on which people rely, such as the power grid, the oil and gas infrastructure, water supply networks etc. Today these systems are far too vulnerable to cyber attacks that can inhibit their operation, corrupt valuable data, or expose private information. Attacks compromising security of monitoring and control systems may also have wide negative impact on the safety of personnel, the public and the environment, by causing severe accidents like blackouts, oil spills, release of pollutants in the air, water and soil.
The foundations for the ESCORTS were laid in a JRC-survey performed during 2006, where the protection against external deliberate disruptions, e.g. terrorist attacks, organised crime, information warfare, were addressed.
From the survey, the following conclusions appeared to outstand:
- Currently, the United States (US) harbours a cyber security culture with reference to control and communication systems. Several industry sectors - electricity, oil, gas etc. have issued guidelines and have set up a common platform, the process control systems forum. National facilities, where to test the security of control and communication components, do exist and are used on a routine basis.
- Europe appears to lag behind with respect to the US. There is less awareness about cyber security risks and a lack of expertise among technicians in the process control sector. Europe also lacks facilities where to test equipment resilience against cyber attacks, so that EU manufacturers and operators currently need to resort to US cyber security facilities to test their products and services.
- Although several standardisation efforts, coordinated by different bodies, exist, standardisation proceeds at a slow pace - also because the effort contributed by stakeholders appears to be sub-critical. So far, the US approach based on sector guidelines appears more pragmatic and productive.
- In particular, the IEC TC 65 and ISA SP-99 are leading current efforts to ensure security of control equipment, while IEC TC 57 is addressing cyber security of electrical communication equipment, e.g. for substations. As some power system communications have more specific and stringent requirements than most of the other process control areas, IEC TC 57 recommendations appear somewhat diverging from the mainstream.
ESCORTS was thus proposed to address the main recommendations emerging from the above survey:
- Encourage best practice, possibly in a joint endeavour between manufacturers and end users. Develop and establish test platforms for SCADA and other process control equipment in Europe.
- Try to reduce the divergence between current standardisation efforts, especially between process control in general and power system control.
- Liaise with the US.
- Promote awareness on security risks by the stakeholders' personnel like plant and security managers, researchers, process operators, information technologies (IT) specialists, and the general public.
The ESCORTS proposal was submitted in May 2007 under topic SEC-2007-7.0-02 European Security Research Network (inclduing for standardisation), as a joint endeavour among EU process industries, utilities, leading manufacturers of control equipment and research institutes to foster progress towards cyber security of control and communication equipment in Europe. The objective of ESCORTS was to be a leading force for disseminating best practice on supervisory control and data acquisition (SCADA) security implementation and to assist stakeholders in developing informed positions and in shaping current and future efforts related to control systems security standardisation
The ESCORTS project had its kick-off meeting on 17 June 2008 in Brussels. The ESCORTS consortium is inter-sector, and involves the main EU manufacturers of SCADA equipment (ABB, Areva T&D - now Alstom Grid, Siemens) under CEN lead, and important SCADA end-users in different processes: power generation (Enel), electricity transmission (Transelectrica), and water management (Mediterranea delle Acque).
A stakeholder advisory board including partners from several process areas (power, gas, oil, water, chemicals and petrochemicals, pharmaceuticals) was established to ensure coherence between, and across, the different stakeholders and activities, and to comment on the various reports created by ESCORTS.
In order to make it clear that any standardisation discussions resulting from ESCORTS should take place in an open standardisation environment, there was created a CEN focus group consisting of the stakeholders involved in the stakeholder advisory board, but with the possibility to grow during the entire process duration. In line with the CEN procedures, secretariat support to this focus group was given by a national standards organisation, in this case by UNINFO from Italy.
Project results:
Further defining the ESCORTS environment
Survey on stakeholders needs
The project started by verifying the context as it had originally led to the creation of ESCORTS and produced the 'survey on stakeholders needs' report which confirmed the assumptions underlying the need for the ESCORTS activities:
- EU industry awareness and readiness lags behind US initiatives.
- There is a growing feeling in Europe that security issues are crucial for reliable critical control system operation, so vendors and users are trying to keep the pace with what emerges as best practice security.
- There seems to be the lack of European explicit demand for comprehensive security solutions. Two related issues emerge as decisive. On the one hand, there is the potential cost of security measures, which might weigh considerably on the overall control equipment cost. On the other hand, there is the lack of adoption in Europe of common security reference or baseline (be them formal or de facto standards, guidelines, or accepted best practices accepted and applicable across all countries).
- Certification is necessary for ensuring the cyber security of industrial processes, but not sufficient. The organisational dimension is the key one in a longer term perspective. To that aim, a long term strategy is to be instantiated. Impact assessment is very important. In that respect process security is definitely the key prospect: no business case of a comparable size can be quoted when looking to disruptions of the mere IT business network.
The 'survey on stakeholders needs' report concludes by stating that 'although ESCORTS, alike many similar endeavours, may play a role in increasing the awareness of European stakeholders and in the harmonisation of the European market place, by fostering adoption of more uniform security guidelines EU wide, it is evident that Europe must substantially increase its efforts to urgently secure mission critical systems.'
Market for SCADA security services
A second deliverable setting the scene evaluated the market for SCADA security services. This study concentrated on three important aspects of security related services:
- Security assessments help to find deficiencies with respect to the security organisation of an operator and with respect to the implementation of technical security measures.
- Security testing which can be regarded as (the technical) part of a security assessment (for an infrastructure operator), but it is also relevant for the vendors of control system components or systems.
- Security training and awareness can be seen as an important part of the security assessment with respect to organisational aspects and is the precondition that the implemented technical security measures will have the intended effects. Adequate training is the most important factor to discriminate a security induced event from an everyday operational fault.
Security testing
With respect to security testing the study concluded that there are two aspects to be considered.
The first aspect is the testing of critical infrastructure installations and of their critical components. This usually is done in relation to a security assessment of the system. Testing of real-live systems is possible but has to be performed with extreme caution in order to avoid discontinuation or breakdown of the system. On the other hand testing of a reference system in a test range would be less dangerous. But building up such facilities for realistically emulating industrial systems would require important investment. The results of these tests have to be interpreted correctly, but a capable test range can provide the possibility of testing systems before their deployment.
The second aspect is security testing of the components by the vendors themselves. Some vendors (at least the larger ones) already perform security tests of their equipment as part of the quality assurance processes. Special test-beds for evaluating equipment can be justified as a centralised placed for operators, vendors and government agencies to collaborate in the search for appropriate security solutions against a full range of threats and security scenarios
Training and awareness
The study suggested that Security training, for example on awareness, does not need necessarily to be provided by special teaching companies; governmental organisations can also raise awareness.
As the awareness level for cyber security issues increases, more companies will organise 'cyber-security training' for their employees. There are already providers delivering 'training sessions' to control system owners. A number of actors address the market for security training: specialised training institutes, universities, public authorities (US-CERT, US-NIST, NL-NICC, UK-CPNI, etc.), IT firms, software vendors, control system vendors (linked to product installation), control system consultants, independent experts/trainers. But these activities also seem to be limited to the security aware industrial sectors (e.g. energy, chemical or pharmaceutical industry). However, this is unsurprising as security training often is an initiative accompanying previous security assessments.
Conclusion of the study
The study concluded that there is, beside managed security services, definitely a market also for other security services, especially for security consulting, which includes security assessments, testing, and training. But the readiness of the actors (mainly the operators of critical infrastructure) depends on the sector to which they appertain. There are some sectors -such as energy, chemical or pharmaceutical industry- with a significant security awareness, who are already performing security assessments. However these are often enforced by specific regulations rather than being intrinsically motivated. In addition different methodologies / guidelines are used for these assessments and different amount of effort is spent, which makes a comparison of the security levels achieved very difficult.
The overall conclusion of the study is that the security service market in the area of critical infrastructure is in an early phase. As the awareness to cyber security issues increases continuously the dimension of the security service market will grow accordingly. However, missing commonly accepted guidelines or standards for security testing and/or security assessments currently hinder the providing of such security services.
Solutions, standards and guidelines for SCADA security
A second strand of activities of ESCORTS related to solutions, standards and guidelines (to be) used for assisting security of the control systems.
Taxonomy of security solutions for the SCADA sector
The report on a taxonomy of security solutions for the SCADA sector describes the more typical cybersecurity problems encountered by industrial control systems, and the solutions that can be put in place for countering them. It classifies and lists security vulnerabilities, threats and solutions, but it does not recommend best practices or possible options. This could be the aim of further work, but the effort demand is beyond the possibilities of this project.
Following an overview of SCADA architectures and a discussion on SCADA protocols, the taxonomy report lists and classifies security vulnerabilities, threats and solutions.
SCADA vulnerabilities were classified into:
1. architectural vulnerabilities
2. security policy vulnerabilities
3. software vulnerabilities
4. communication protocol vulnerabilities
4.1 MODBUS vulnerabilities
4.2 DNP3 vulnerabilities
4.3 summary of the vulnerabilities of protocol and relevant threats.
Attack scenarios were classified into:
1. SCADA protocol oriented attacks
1.1 SCADA malware DOS scenario
1.2 SCADA unauthorised command execution scenario
1.3 SCADA system data poisoning
2. Process network attacks
2.1 OPC DOS
2.2 OPC corruption poisoning
2.3 OPC protocol corruption
2.4 SCADA server DOS
2.5 SCADA server corruption
2.6 SCADA server data flow corruption
2.7 HMI corruption
3. exchange network attacks
3.1 real-tima databases attacks
3.2 Diagnostic server attacks.
Finally, a number of SCADA security countermeasures were proposed, describing a (limited) set of security countermeasures for the above listed vulnerabilities. The potential countermeasures that are and can be implemented in the real world obviously exceed this list. The cases presented are further representative of one potential approach, without the aim of prescribing or suggesting their use.
SCADA security countermeasures:
1. Communication protocol countermeasures (addressing the 2 kinds of communication protocols in plant networks)
1.1 TCP/IP countermeasures
1.2 SCADA protocol (Modbus, DNP3 etc.) countermeasures
2. Filtering and monitoring countermeasures (list is illustrative, not exhaustive)
2.1 multi-homed PC
2.2 multi-homed server with software firewall
2.3 layer 3 switch network filtering
2.4 two port firewall
2.5 dual filtering (router firewall)
2.6 multi-port firewall with demilitarised zone
2.7 paired firewall and multiple DMZ
2.8 firewall / VLAN architecture
2.9 firewall / VLAN / VPN architecture
2.10 monitoring
2.11 limits of intrusion detection in SCADA systems
3. Architectural good practices include
3.1 firewall and network segregation
3.2 domain name system (DNS)
3.3 hyper text transfer protocol (HTTP)
3.4 FTP and trivial file transfer protocol (TFTP)
3.5 telnet
3.6 simple mail transfer protocol (SMTP)
3.7 simple network management protocol (SNMP)
3.8 distributed component object model (DCOM)
3.9 SCADA and industrial protocols
3.10 antivirus and malware detection
3.11 backup, restore and disaster recovery
3.12 remote access and data transfer services
3.13 system hardening
3.14 wireless connectivity
3.15 account management
3.16 software management and update
4. Organisational countermeasures.
The report here summarises some of the NERC's requirements for critical infrastructure protection. NERC developed these standards specifically for the North American bulk electric system; however, many of these standards are valid guidelines and suggestions for designing and operating many other industrial systems.
The consortium found security for control systems to be a complex subject due to at least the three following reasons:
- the architecture of control systems, while getting complex for functional and topological reasons, is rarely designed with security goals in mind;
- the technologies employed (such as most prominently the SCADA protocols) are often insecure by nature;
- because the business benefits from security are not immediately evident, the practices employed by the companies, rarely consider security among their goals.
Survey of existing methods
A survey of existing methods, procedures and guidelines in support of secure SCADA applications was produced. The survey lists existing methods, procedures and guidelines in the area of control system (cyber) security, addressing activities of international organisations, important national activities in Europe and the US, as well as the most important branch specific activities (international and national).
The following standards, guidelines or regulations relevant for operators or manufacturers in the area of control system (cyber) security, were identified and commented upon:
1. AGA Report No. 12, Cryptographic Protection of SCADA Communications, Part 1: Background, Policies and Test Plan, American Gas Association, March 2006
2. American Chemistry Council Cyber Security Guideline: Guidance for Addressing Cybersecurity in the Chemical Industry, Version 3.0 May 2006
3. API Standard 1164, Pipeline SCADA Security, September 2004
4. API Security Guidelines for the Petroleum Industry, April 2005
5. CIGRE - Management of Information Security for an Electric Power Utility - On Security Domains and Use of ISO/IEC17799 Standard
6. CPNI - A good practice guide: Process Control and SCADA Security
7. CPNI - Firewall Deployment for SCADA and Process Control Networks
8. DHS - Catalog of Control Systems Security: Recommendations for Standards Developers
9. DoE / DHS Roadmap to Secure Control Systems in the Energy Sector
10. DoE / ESISAC - Energy Infrastructure Risk Management Checklists for Small and Medium Sized Energy Facilities
11. DoE / ESISAC - Vulnerability Assessment Methodology
12. DoE / TSWG - 21 Steps to improve Cyber Security for SCADA systems
13. DoE / TSWG - Securing Your SCADA and Industrial Control Systems
14. IEC 61400-25 - Communications for monitoring and control of wind power plants
15. IEC 61784-4 - Industrial Communications - Fieldbus Profile - Part 4: Profiles for secure communications in industrial networks
16. IEC 62210 - Power system control and associated communications - Data and communication security
17. IEC 62351 - Data and communication security
18. IEC 62443 - Security for industrial process measurement and control - Network and system security
19. IEEE 1402 - IEEE Guide for Electric Power Substation Physical and Electronic Security
20. IEEE P1686 - Draft Standard for Substation IED Cyber Security Standards
21. IEEE P1689 - Trial Use Standard for Cyber Security of Serial SCADA Links and IED Remote Access
22. IEEE P 1711 - Trial Use Standard for SCADA Serial Link Cryptographic Modules and Protocol
23. ISA -99 series - Security of industrial automation and control systems
24. ISO 13335 - Information Technology - Guidelines for the Management of IT-Security
25. ISO 15408 - Common Criteria
26. ISO 17799 - Code of practice for information security management
27. ISO 2700x - Information technology - Security techniques - Information security management systems - Requirements
28. NAMUR NA 115 - IT-Security for Industrial Automation Systems: Constraints for measures applied in process industries
29. NERC CIP-002-009 - Cyber Security Standard
30. NERC - DoE / ESISAC Security Guidelines for the Electricity Sector
31. NIST PP ICC - Protection Profile for Industrial Control Centres
32. NIST SP 800-53 - Recommended Security Controls for Federal Information Systems
33. NIST SP800-82 - Guide to Industrial Control Systems (ICS) Security
34. NIST/PCSRF - Field Device Protection Profile For SCADA Systems In Medium Robustness Environments
35. OLF Guideline No. 104 - Information Security Baseline Requirements for Process Control, Safety and Support ICT Systems
36. SEMA Guide to Increased Security in Process Control Systems for Critical Societal Functions
37. VDEW M-07/2005 - Zehn Schritte zur VEDIS-Sicherheit
38. VDI 2182 - Informationssicherheit in der industriellen Automatisierung - Allgemeines Vorgehensmodell
39. VGB-R 175 - IT Sicherheit für Erzeugungsanlagen
Targeted experiments
Some of the above standards / guidelines were used in targeted experiments at the location of the ESCORTS user companies (Enel, Transelectrica and Mediterranea delle Acque) where the companies' security processes were evaluated against the standards/guidelines that were chosen.
Areva (now Alstom Grid) / Transelectrica experiment
A first experiment was done by a vendor/user team consisting of Areva (now Alstom Grid) / Transelectrica. The standards which were taken as a reference in this targeted experiment were ISO 27002 (ISO 27001) (focusing on confidentiality) and the NERC - CIP standards 2-9 (focusing on availability).
The following learning points were reported from this targeted experiment:
- ISO 27000 audit process oversized for critical systems
- Focus on ISO 27002 more than on ISMS
- Adaptation required for self-assessment
- Target is not compliance but awareness
- Part of the security measures are embedded for availability
- Advantage in an ISO 27001 certified environment
- Critical assets must be managed internally (technically)
- System availability is a shared responsibility when maintenance is provided by vendor (cyber security-wise)
- NERC CIP is less subject to interpretation
-NERC CIP audit process need to be analysed.
ENEL/ABB experiment
A vendor / user team consisting of ENEL/ABB conducted a second experiment. ABB and ENEL jointly selected the ISA 99 standard (at its current draft status) as a basis for this assessment, as it was commonly agreed that - given the joint efforts between ISA and IEC to parallelise the editorial procedures for co-publishing as ANSI/ISA 99 and IEC 62443 - this standard is a promising candidate for a global, cross-industry security standard.
During the experiment between ABB and ENEL, the following findings or types of findings were achieved:
- The ISA 99 standard used as a reference framework is in general very applicable to the operation of power plants and the control systems involved therein. However, there were some gaps identified in the standard and in general, it was noted that the standard is very comprehensive. Thus, it takes some time to be acquainted with it. Once it is completed, published and more experience is available, this will become less of an issue.
- An open analysis of system design, deployed configurations and policies and procedures for operations increased the awareness of existing security controls (both technical and organisational ones) among the different organisational units of ENEL and between ABB and ENEL. Especially the complementary nature of physical and cyber security as well as operational and technical security controls could only be discovered by a cross-disciplinary team, as it was present in the assessment.
- ISA99 reflects and links risk assessment to security planning
- Operational security requirements (policies, procedures) comprehensive and easy to evaluate
- ISA-99 well structured
- Identification of 'zones' and 'conduits' difficult
- ISA-99 imposes several requirements for zone definitions, but currently leaves a lot of discretion for asset owners. Here is room for improvement.
- Detailed requirements in terms of security controls for each zone are present, but difficult to use
- Determination of system security assurance levels (SAL) is difficult, as the link between 'impact' and 'SAL' is missing
- To implement and maintain ISA99 compliance is very difficult and expensive for an electric utility:
i. several devices, complex infrastructure, many people involved
ii. different organisation units must cooperate, creation of new organisation units could be necessary, entire life cycle requires continuous effort, etc.
and for an IACS vendor:
iii. security must be embedded the design of the IACS system
iv. IACS integration in a customer owned infrastructure is challenging.
The costs for becoming ISA99 compliant could not be estimated. This is a recommended task for future projects:
- Compliance metrics monitoring (ISA-99.01.03) is important for certification, but the value of certification is considered controversial. Risk assessment guidelines and vulnerability tests seem to be necessary, too.
The ISA 99 standard was concluded to be very comprehensive but maintaining ISA 99 compliance was considered to be difficult and expensive.
There were also identified a number of suggestions for ISA-99 revision, which were taken due notice of by Dennis Holstein of OPUS, lead editor of ISA99 working group 4.
Mediterranea delle Acque experiment
This third experiment evaluated the risk of the control systems for a water utility (Mediterranea delle Acque). The security analysis of the control system was split into two main activities:
1. Definition and application of a control check list based on the selected ISO/IEC 2700x standards (The analysis was based on two of them: ISO/IEC 27001, the core standard of the series that is related to the definition of an information security management system, and ISO/IEC 27002, which provides specifications for the implementation of security controls).
2. Evaluation of the applicability of the standards to the Mediterranea delle Acque infrastructure.
It was concluded that the standard ISO/IEC 27001 is fully applicable to the Mediterranea delle Acque control network, but there are some issues in the real application. Regarding ISO/IEC 27002, some controls could not be applied to a control network analyzed (for example, the section about electronic commerce) or to the specific control network under analysis, like the specifications regarding third party collaborations
This third experiment confirmed the findings of the 1st experiment and concluded that the ISO/IEC 27000 standard family is quite generic and mainly focused on people behaviour, thus the adoption of its specifications is necessary but not sufficient to guarantee the complete security of a critical infrastructure against cyber threats. In many cases, the major vulnerabilities come from user behaviour, and ISO/IEC 27000 could help in mitigating the effects; however, more technical solutions could be required (e.g. network architecture design, communication protocols, etc.) in order to provide an adequate security level.
R&D and standardisation road map
Standards extending to the right in x-axis direction have relevance for manufacturers. Typically, such standards have detailed technical requirements up to the definition of special security protocols, which must be implemented by the manufacturers. In contrast, the more a standard extends to the left of the x-axis, the more it is focused on a secure operation. NERC-CIP, for example, prescribes specific actions for operators to do.
Standards extending to the top of the y-axis list precise design details and leave little room for interpretation. IEC 62351, for instance, is intended to list design details in such extend that device interoperability between various manufacturers is guaranteed. Standards extending to the bottom of the y-axis are covering a broad range of various security areas and thus can be consulted in order to get estimation on the overall security level.
The project performed a more detailed study on a subset of the 39 identified standards, focussing on the most relevant and comprehensive standards, namely:
- NERC CIP (Recommendation relevant for bulk energy system operators in the US);
- ISO 27000 (Generic standard defining a information security management system);
- ISA 99 / IEC 62443 (Generic standard defining among others a cyber security management system taking into account best practices from industrial automation) (note, that ISA and IEC negotiated, that the ISA 99 standards will be adopted as IEC standards as well).
In addition the project focussed on:
- CPNI/NISCC: Good practice guides (Best practice recommendations, UK)
- NIST 800-53, Recommended security controls for federal information systems and organisations (US).
- IEC 62351 (Technical standard designed to secure the control communication within energy automation systems)
- IEEE 1686 (Technical standard defining security requirements for intelligent electronic devices)
This way, there were included a guideline and a standard addressing industrial information systems in general, as well as standards which mainly define technical measures to be used in control system design.
These seven selected standards were evaluated with respect to topics which have to be addressed when designing secure SCADA or control systems (manufacturer point of view) or which have to be addressed when operating such a system (operator point of view).
An appraisal of:
- 0 means that the topic is either not appropriately addressed in this standard, or there are no clear statements how to address this topic or it is even not addressed at all;
- 1 means that the standard includes clear statements, so that the audience (manufacturer or operator) at least can derive actions with respect to this topic.
However, detailed statements on the completeness of each standard go beyond the scope of the project.
This gap and overlap analysis led to the following main findings (MF):
(MF1)
No single standard covers all aspects (necessary to design, build and operate secure control systems); in Europe there is in addition the issue of many national languages. It is therefore recommended to (REC1) define a CEN workshop agreement (CWA) to carry out a thorough assessment of gaps regarding a common terminology and conceptual base (possibly taking as reference ISA 99).
(MF2)
Standards partly have large overlaps and will be used in parallel. It is therefore recommended to (REC2) start an experiment with respect to the assessment of the joint use of standards.
(MF3)
Missing security requirements for tool sets used for configuration leads the following recommendation (REC3) Define a CEN workshop agreement with the goal to develop what security aspects need to be addressed with respect to the definition of tool sets used for configuration. The outcome of this CWA could then be used as a basis for a new work item proposal (NWIP) within IEC.
(MF4)
The observation that general purpose standards (by nature) do not take into account use case specific requirements leads to the recommendation: (REC4) to promote (e.g. within ISO/IEC SC27) the production of technical guidelines for the application of general purpose standards to the different technical fields.
These recommendations from the gap and overlap analysis were added to a number of other recommendations that did follow from the work on the other reports and led to the following overall conclusions for a R&D and standardisation road map:
- Awareness of the breadth and fast evolution of cyber security threats is the most important.
- ISA99/IEC 62443 is the most promising standard with the largest coverage with respect to control systems. This was confirmed in our targeted experiments. Also, there is no need to wait for a final version to use it for enhancing overall security.
- IEC 62351 is the most comprehensive technical specification addressing security of automation systems for the energy sector.
- It was concluded in the near term the need for CWAs on the following subjects: metrics, security processes best practices, skills and competences and the exchange of security information
- A research project is needed to identify key performance indicators for the monitoring of security level and behaviour.
- Additional studies are needed (economic cost, a decision support system for CEOs, a testing methodology for verifying security assurance) as well the development of training material for use by staff having access to the control system.
Measuring and testing
Metrics for cyber security assessment and testing
There is no commonly accepted definition of security metrics. The term, as used in practice, appears to represent several different notions: metric (in the sense of quantitative standard function based on process and / or product measures), measurement, score, rating, rank, or assessment. The definition used for the ESCORTS report is the one adopted by the Workshop on Information Security System Rating and Ranking (WISSRR): 'A metrics is a value, selected from a partially ordered set by some assessment process that represents a quality of some object of concern in the ICT system.'
The report makes proposals for specific metrics that can be applied for assessing SCADA systems, and categorises them in the 3 following categories:
1. Organisational metrics, including security program metrics and security process metrics. For example: Access control effectiveness (e.g. percentage of access points where unauthorised could be gained).
2. Operational metrics, including the operational readiness/security posture of the organisation, their risk management support measures, the threat environment, and the incident response and vulnerability management practices. For example: metrics with reference to best practices (such as NIST's practices and checklists / implementation guides).
3. Technical metrics, including those metrics based on standards of reference, or other ad-hoc metrics defined for the specific application. For example: attack surface (ATS), a metric defining the percentage of nodes of a target system / subsystem that is susceptible to a certain type of attack.
The report suggests that the proposed metrics can be used for different purposes:
- The organisational metrics can be used for the evaluation of the effectiveness of the security programs, and for the evaluation of the management, operational and technical controls in place in a given installation as well as for the evaluation of the relevant management and technical processes.
- The operational metrics can be used for measuring the readiness of all the SCADA security controls and their compliance with standards of reference.
- The technical metrics can be used to enable the user answering questions such as: 'Which nodes of my system appear to be subject to specific attack mechanisms?', 'How fast can a certain attack proceed?' Or 'What is the potential downtime resulting from a certain attack? How fast can the system recover?'
The metrics however cannot answer a question such as 'Is my system secure?' Indeed, without reference to specific threat scenarios this is not a meaningful question. And, in addition the analyst would have to explain that any answer will depend on the assumptions, criteria and procedures used, which are a function of the metrics chosen.
The report suggests as a next step the application of the proposed metrics in case studies for their validation and adjustment. Such an assessment was undertaken as part of the ESCORTS project. A test was performed but the details of the tested environments are confidential between the participating entities.
Requirements for future cyber security laboratories
This report presents a first consideration of the requirements for a laboratory for conducting security experiments with SCADA systems. The main consideration has been that the laboratory would be used by all potential stakeholders, and not only by the SCADA system manufacturers. This puts special conditions, mainly from the standpoint of the target system for the experiments. The field of experimental security of information and communication technologies is just emerging in the last years, and there is a lot to learn yet. Mainly from the methodological perspective, it is clear that there are many gaps. The report highlights some of them.
The report suggests that the development in the future of SCADA security labs will have to pay particular attention to the following:
- the extension and details of the target system: more details will result in more complexity, but the realism of certain reproductions of incidents might require a rather thorough consideration of components, as the only means for reaching an acceptable level of fidelity;
- the capacity of the attack resources and sophistication of the attack mechanisms: here the opposition is between the manageability of the experiment, versus the reproduction of realistic conditions;
- the capacity of control and observation of the experiments: the ambition to have powerful experimental facilities will require to develop complex settings, with control of the evolution of the experiment, and the extended collection of data;
- the repeatability and comparison of results: more value will be derived from the possibility to confront different experiments.
A secure ICT platform for data exchange
Europe will benefit from having an information exchange framework for SCADA security in place, with procedures and guarantees that provide incentives and instruments for the interaction among all interested stakeholders.
A pilot implementation of a secure ICT platform for the exchange of relevant data among the stakeholders is running in the JRC at ISPRA.
The ESCORTS report discusses from the communication and technical point of view, the basic elements that should be taken into account in the implementation of such information exchange.
The report identifies various problems that should be resolved by any developer of an information exchange, based on the experience obtained when developing the prototype.
These are listed in two categories:
Factors affecting interoperability
- Numerous autonomous agencies will take part of information exchanges, each one with their own expectations and requirements, primary language and background, etc. There is an inherent difficulty in synthesising a common view. The requirements, design and development processes will require extensive iteration, and foresee long and complicated steps for the verification and validation of the final product.
- Multiple trust domains are the natural consequence of the numerous autonomous organisations coming from many countries. The agreement on a common specification of the basis for trust among all actors appears as a fundamental initial point.
- Heterogeneous computing environments in use by the various actors, which will require the development of a system that could be compatible with all of them.
- Varied governance structures (i.e. different ways for making decisions about the process for gathering, vetoing, sanitising, distributing, etc., all data). This should result in a structure of requirements that satisfy all these different structures.
- Significant investment in legacy environments, which preclude the introduction of new hardware / software systems (such as databases) unless they are seamlessly compatible with existing applications, and do not impose any hard restraint on future decisions
Primary impediments to information sharing
- Incompatible terminologies and technologies (such as formats) used for the description and storing of data. Each industrial actor, or at items sector, uses their own approach, and at times standard. Much can be gained from common, standardised approaches for the specification of security-related information (not unique, but at least compatible), including taxonomies, protocols for handling contents and for other tasks (e.g. validation).
- Identification, authentication and authorisation policies for personal users in different organisations, which prevent the immediate recognition of those users in different organisations.
- Disparate and incompatible security mechanisms and policies across organisations.
Potential impact:
Networked computers reside at the heart of critical infrastructures and systems on which people rely, such as the power grid, the oil and gas infrastructure and power, oil and chemical process plants.
The impact of a major failure or a well targeted and successful attack on the electrical system (physical as well as presumed cyber attack) could be a major regional or national blackout possibly with cross-border ramifications. In recent years, both Europe and America have experienced a significant number of major blackouts. Based on known facts and publicly available investigation reports, these blackouts were usually not caused by malicious attacks but nevertheless the current international scene calls for increased vigilance for the malicious risk factor.
Today, many of the systems are vulnerable to cyber attacks that can inhibit their operation, corrupt valuable data, or expose private information. Exposure to malicious threats is massively growing, and intelligence sources estimate today a disruptive attack more likely to target Europe than the US.
Vulnerabilities due to design and technology flaws may be exploited by malicious antagonist actors, who can gain access to the systems through external and internal connections. These threats menace industry in the whole industrial process spectrum, as their supervisory control and data acquisition systems are based on similar technologies and are deployed using analogous architectures.
Standards can help in the protection of SCADA in different ways:
- helping in setting a common conceptual basis between all stakeholders: operators, vendors, certifiers, authorities, etc.;
- supporting all engineering processes: from specification to procurement, and from operation to maintenance;
- fostering the development of a market for security products and services, with verifiable levels of assurance.
The project concluded that the main issue is not a shortage of standards and guidelines but rather the need to increase awareness and the need to promote existing standards and guidelines among the users of industrial control systems.
Dissemination
The final open conference was attended by 31 people of 11 European countries, EC and US, representing main SCADA manufacturers, security bodies, critical infrastructures like electricity and water, standardisation bodies, users associations.
At this open conference it was presented how the ESCORTS recommendations in the roadmap will help in combating targeted attacks to SCADA systems.
The early detection of (targeted) attacks in critical infrastructures was added as an additional recommendation to combat targeted attacks (bearing in mind for instance the time line of Stuxnet).
Some other main findings of the project were presented at the open conference, including the following reports:
- Surveys of stakeholder needs and of the market for SCADA security in the EU
- Conclusions from security assessment experiments at Transelectrica, ENEL and Mediterranea-delle-Acque, with regard to the use of specific standards
- Metrics for cyber security assessment and testing, and Verification of these metrics on a replication of a live control system
- A R&D and standardisation roadmap containing recommendations suggesting next steps for the security of SCADA and critical structures using SCADA.
Considering that the ESCORTS project made in its standardisation roadmap several proposals for CEN workshop agreements, efforts were made to keep the CEN and CENELEC standardisation community well informed on these proposals. This was done through regular emails to the CEN/CENELEC ICT forum which consists of representatives of national standards bodies and national committees (these representatives are mostly active in a CEN context, CENELEC national committees are not well represented). Feed-back from a participant in the CEN/CENELEC ICT forum provided an additional information that had not been identified during the ESCORTS project itself, namely an alleged technical incompatibility between IEC 62443-2-1 and ISO/IEC 27001:2005 (as a result ISA99/IEC 62443 was voted down from becoming a European Standard). Working towards resolving this incompatibility could be the part of the guidance material that ESCORTS has recommended to be produced.
ESCORTS being created as a network of stakeholders, proactive efforts were made from the start to have the stakeholders participating in the stakeholder board. More than 30 members signed up for the stakeholder board after the 1st meeting in Baden-Daetwill, February 2009. The stakeholder board was later mirrored in the form of a CEN focus group to stress the openness of the activities that related to standardisation.
In order to ensure that any follow-up action will reach out to the stakeholders, ESCORTS collected a list of the stakeholders for inviting when the proposed work on the CEN workshop agreements will start. (Participation in CEN workshops is based on direct participation, and not based on national representation as in technical committees in CEN, CENELEC, ISO or IEC.) The list can also be used to inform the stakeholders on other relevant messages such as the ENISA questionnaire on industrial control systems security.