S4 stands for the SCADA Security Scientific Symposium. For the first four years of S4, S4x07 – S4x10, it was held in a 60 seat case room and every session required a technical paper. We published those papers in a S4 Proceedings Book that was provided to each attendee.
While the books are out of print, we are happy to provide the papers below.
OPC (OLE for Process Control) is a mechanism for interconnecting process control applications running on Microsoft platforms. It is layered on top of DCOM which in itself presents a wide range of security considerations. OPC is defined in a series of specifications, although the best known and more widely implemented is the Data Access (DA) specification.
We present a security analysis of the DA specification, identifying theoretical weaknesses that implementers should take into consideration when developing OPC clients and servers. To validate our findings a vulnerability group test has been conducted against several OPC servers, discovering a number of previous unknown vulnerabilities.
Although MSRPC services have been widely tested for security vulnerabilities, the tests have centered around the transport layer and not on the application layer that DCOM implements. OPC testing revolves around the study of the protocol and the identification of weaknesses, identifying various new vulnerabilities in the process. The main innovation in this paper is in analyzing DCOM from the interface point of view and automating discovery and testing of OPC servers.
It is well known that OPC does not include effective security controls and relies on DCOM. Well, the problem is much larger than that. In this paper, several DoS attacks that have proven effective against OPC servers are discussed that could be carried out by attackers with no technical background or by malware. In addition, a man-in-the-middle attack is explained that could be used by an aggressive attacker to have a SCADA system assume normal operation while the process is running wild. Last but not least, suggestions for remedies are presented.
ICCP server applications are much more than the implementation of the ICCP protocol. In fact, ICCP servers implement a set of protocols we refer to as the “Utility Stack”. These protocols are not exclusive to ICCP, but they are not commonly tested by the security community. In this paper, we review the Utility Stack, discuss the details of two published vulnerabilities in implementations of the Utility Stack, and identify areas where additional vulnerabilities are likely to be found. The paper finishes with a discussion of a Utility Stack vulnerability testing tool that mimics the approach attackers have taken to identify exploits in IT protocols.
Testing is an important part of the Quality Assurance (QA) process, and the security portion of QA can detect potential vulnerabilities prior to exploitation. This paper begins by presenting background information on protocol testing and the available tools. We then discuss our experience in developing blackPeer, the testing framework for SCADA1 protocols in Achilles, including lessons learned and key design decisions. The paper includes detail on the employment of blackPeer in vulnerability and conformance testing SCADA devices and the Achilles test methodology. We end with a discussion on common device errors and observations regarding the communication of these errors to the client
This paper describes the issues and solution options associated with providing anonymity to an authorized group of users who share digital information with a central collection/analysis/distribution center. Sharing of information within the SCADA and process control community is important for understanding threats and early detection of coordinated attacks, but anonymity and authentication of communication is crucial to enabling and maintaining trust in information sharing within the community. A complete solution addresses anonymization on three fronts: cryptographic message preparation, message communication, and message content. With our approach to cryptographic anonymity, the receiving center can ensure that an arriving message is from a member of the group, but neither the center nor an electronic eavesdropper can determine which member of the group sent the message. The sharing of sensitive information attributable to a particular user has risks that our cryptographic solution can mitigate. The network communication element of an anonymity solution incorporates the ability to anonymize the communication route of a message transmitted over the Internet. Since anonymous communication opens the door for untraceable system abuse, our approach to cryptographic anonymity employs a multi-level communication structure that mitigates abuse by allowing message revocation, yet retains true anonymity at the highest level. The use of operational procedures and/or filtering techniques to anonymize or sanitize message content is an equally important element to any solution. Anonymous, authenticated communication is an enabling technology to secure sharing of SCADA and process control system information.
This paper describes a defensive approach referred to as SCADA protocol obfuscation. Such an approach counters network attacks which remotely exploit vulnerabilities in target SCADA systems through malicious messages structured in compliance with an actually used SCADA protocol. SCADA protocol obfuscation is built in the form of a proactive structural intervention which we defined upon information provided by a new conceptual structure called attack requirements trees. An attack requirements tree is a structured means of providing conditions which must hold for a given attack to be feasible. The root node of this tree is the attack itself, while each other node is an attack requirement. We built the attack requirements tree for a SCADA protocol-based attack and identified a node whose denial could make such an attack unfeasible. This node represents the requirement that attack messages should be built according to the SCADA protocol in use, therefore we decided to introduce diversity into a SCADA protocol in order to deny to the attacker the knowledge required for building correct attack messages. While a strong cryptographic algorithm would accomplish this task, we had to investigate another solution as common SCADA field devices such as PLC’s or RTU’s have limited computational power. Consequently they have considerable difficulties running strong cryptographic algorithms. In this paper we propose SCADA protocol obfuscation as a candidate solution and describe it as applied to the Modbus TCP/IP protocol.
This paper presents a new approach to authentication for SCADA communications using a computationally light-weight encryption protocol which is capable of resisting most major cyber attacks including distributed, denial of service attacks against a SCADA network. In addition this protocol can be implemented in an extended form which will permit either multiple levels of authentication for various system threat levels, or multiple levels of authentication to support a hierarchy of privileged operations at the RTU.
The ability to efficiently compare differing security solutions for effectiveness is often considered lacking from a management perspective. To address this we propose a methodology for estimating the mean time-to-compromise (MTTC) of a target device or network as a comparative metric. A topological map of the target system is divided into attack zones, allowing each zone to be described with its own state-space model (SSM). We then employ a SSM based on models used in the biological sciences to predict animal behavior in the context of predator prey relationships. Markov chains identify predominant attacker strategies which are used to build the MTTC intervals and can be compared for a broad range of mitigating actions. This allows security architects and managers to intelligently select the most effective solution, based on the lowest cost/MTTC ratio that still exceeds a benchmark level
Honeynets are a useful research tool to better understand attacks and attackers, and a useful early attack warning tool for network owners. In this paper we detail the design and implementation of a SCADA Honeynet that appears to an attacker to be a popular PLC. The SCADA Honeynet described in this paper relies on Open Source software and VMware server images so there is no software cost and it is easy to deploy. The paper concludes with a description of two different SCADA Honeynet deployment scenarios and an analysis of attack data observed in those scenarios.
Potential security events are logged in a variety of systems and locations such as SCADA application logs, firewall logs, IDS logs, infrastructure system logs and operating system logs. Solutions exist from Tenable Network Security and other vendors to correlate security events from multiple sources to detect attacks, but the meta events and correlation methods must be defined and developed. This paper discusses and provides TASL scripts to detect three different attack scenarios: SCADA server compromises, malicious SCADA server failover and DNP3 unsolicited response flood. Ideas for the detection through event correlation are presented for four other control system meta events.
In a model-based intrusion detection approach for protecting SCADA networks, we construct models that characterize the expected/acceptable behavior of the system, and detect attacks that cause violations of these models. Process control networks tend to have static topologies, regular traffic patterns, and a limited number of applications and protocols running on them. Thus, we believe that model-based monitoring, which has the potential for detecting unknown attacks, is more feasible for control networks than for general enterprise networks. To this end, we describe three model-based techniques that we have developed and a prototype implementation of them for monitoring Modbus TCP networks.
SCADA systems directly influence the lives and wellbeing of all civilians in almost any modernized country. The best site for an attacker to compromise in order to cause maximum damage is the control center. Much like Aikido, an attacker can use your strengths (centralized management of assets, multiple control applications) to his benefit. In the whitepaper we will show twp possible attack scenarios on the control center: 1. Attack from the field – how to study the weaknesses and exploit the control server software 2. Attack from the corporate network – research and vulnerability assessment of Proficy software to use it to take over the only authorized connection to the control center As the aim of the whitepaper is to be as realistic as possible, we will demonstrate all three vectors on a very common target – an oil distribution company running GE Fanuc software: Cimplicity 6.1 for their control system and Proficy Information Portal 2.6 for reports.
Microsoft’s NetDDE protocol is used in many control system applications to exchange data between two disparate systems, such as populating an Excel spreadsheet from data on a historian. NetDDE clients and servers are found in asset owner written programs and free or low cost utility programs. NetDDE interfaces are also still found in popular SCADA and DCS systems. This paper provides a brief overview of NetDDE server configuration with emphasis on the access control features available in NetDDE shares. With that background, a vulnerability resulting from poor NetDDE share configuration in Wonderware’s InTouch HMI version 8.0 default installation is described. A tool, nbDDE, is introduced and demonstrates how an attacker could exploit the InTouch vulnerability and other misconfigured NetDDE shares in a variety of methods. The paper also includes a discussion on how the NetDDE shares could be modified to reduce the risk to prevent or limit the exploit. The paper concludes with a discussion of how integrating security, particularly threat modeling, into the software development lifecycle could have identified and addressed this vulnerability prior to the release of vulnerable code.
The Department of Homeland Security National Cyber Security Division supported the development of a small set of security ideals as a framework to establish measurable control systems security. Based on these ideals, a draft set of proposed technical metrics was developed to allow control systems owner-operators to track improvements or degradations in their individual control systems security posture. The technical metrics development effort included review and evaluation of over thirty metrics-related documents. On the bases of complexity, ambiguity, or misleading and distorting effects the metrics identified during the reviews were determined to be weaker than necessary to aid defense against the myriad threats posed by cyber-terrorism to human safety, as well as to economic prosperity. Using the results of our metrics review and the set of security ideals as a starting point for metrics development, we identified thirteen potential technical metrics – with at least one metric supporting each ideal. Two case study applications of the ideals and thirteen metrics to control systems were then performed to establish potential difficulties in applying both the ideals and the metrics. The case studies resulted in no changes to the ideals, and only a few deletions and refinements to the thirteen potential metrics. This led to a final proposed set of ten core technical metrics. To further validate the security ideals, the modifications made to the original thirteen potential metrics, and the final proposed set of ten core metrics, seven separate control systems security assessments performed over the past three years were reviewed for findings and recommended mitigations. These findings and mitigations were then mapped to the security ideals and metrics to assess gaps in their coverage. The mappings indicated that there are no gaps in the security ideals and that the ten core technical metrics provide significant coverage of standard security issues with 87% coverage. Based on the two case studies and evaluation of the seven assessments, the security ideals demonstrated their value in guiding security thinking. Further, the final set of core technical metrics has been demonstrated to be both usable in the control system environment and provide significant coverage of standard security issues.
The threat of cyber security failures in industrial automation and SCADA is ever present and even increasing, but there is often little understanding as to what the threat actually may be. While engineers and security professionals can often measure the vulnerabilities in a system, and can apply quantitative logic to the impact analysis, one of the key components to understanding risk often goes ignored. The challenge is that the threat is a key component of risk. Understanding the threat is tantamount to creating awareness, without which a business case and justification for security expenditures cannot be developed. Most organizations exist happily in the thought that, “this could never happen to us,” but to those informed about security, it is not a matter of if, but when. Without sufficient threat data, however, developing threat models and attack trees are a matter of academic interest with often low perceived value to the business community. This paper takes an alternate approach to building threat data. Leveraging past known cases of cyber security failures as well as recent research and development into the areas of industrial cyber security, this paper adopts an approach of creating scenarios that explain the why, how, and consequences of various attack vectors and compromise scenarios. The paper begins with expressing the traditional based approaches to understanding risk, the various strengths and weaknesses in ascertaining risk, and then tours various threat scenarios that can be used or extended by the industrial automation and SCADA community to help create an accurate picture of risk and utilize in business case development for security countermeasures
A Safety Integrity Level (SIL) is a statistical representation of the reliability of the Safety Instrumented System (SIS) when a process demand occurs. SIL’s are correlated to the probability of failure of demand (PFD), which is equivalent to the unavailability of a system at the time of a process demand. Given the de facto acceptance of SIL and the widely recognized interrelationships and interdependencies between safety and security, many have pushed for the adoption of a security level concept similar to safety in the security environment. Several efforts have been directed at this including security assurance levels defined in documents such as NIST 800-53. This paper takes a critical look at the SIL concept, its overall strengths and weaknesses as applied to security, and proposes general models for use within the security arena.
In this paper we provide a mathematical approach to detection of attacks on relays in electrical substations speaking IEC 61850, an abstract industrial protocol devised by the Technical Committee 57 of the International Electrotechnical Commission as a standard for substation communications. Our contribution regards those electrical transmission substations which interface with the generators of a power plant through step-up transformers. In this paper we take as an instance power plants which use nuclear reactors as a source of energy. The basis of the proposed approach is formed by structural equations which semantically model the relations between operational variables of substation and nuclear power plant components as monitored by the respective control systems. Causality relations investigated via structural equations are reflected on Bayesian belief networks to probabilistically characterize the legitimacy and abnormality of IEC 61850 traffic. We then employ the stochastic activity network formalism to construct composed models of substation operation from which we derive intrusion detection rules.
The stereotypical behavior of most control systems lends itself to modeling the system and detecting anomalies that could be cyber attacks or other dangerous network activity. In this paper we will discuss and demonstrate how the flow information available from routers and other network devices can be used in an anomaly detection system (ADS) to detect attacks from the communication flows from a source / destination / service perspective. We will also use this flow information to identify anomalies in the volume of communication on the network as a whole or between any two hosts. Finally, the paper will discuss the potential to model control system protocol usage to detect anomalies caused by cyber attacks.
Advanced Metering Infrastructures (AMI’s) have limitations that require unique information security approaches. Some of the characteristics addressed in this paper include the mixture of one-way broadcast and two-way communication, the limited processing power found in organizational issues in managing cryptographic credentials, the sheer number of endpoints (in the millions), and the expected type and frequency of message traffic to be addressed. This paper describes in detail the currently proposed authentication mechanism for broadcasting controls to Programmable Communicating Thermostats (PCT’s) in the state of California. PCT’s are a key component of the advanced metering and demand response infrastructure being deployed there. It discusses the alternatives that were considered in developing this mechanism. This paper goes on to discuss some of the ideas currently under consideration for securing the two-way AMI networks, and how they might relate to this PCT solution.
Field devices essential for the monitoring and control in DCS and SCADA systems are increasingly being deployed with Ethernet cards to connect these devices to local and wide area IP networks. Many of the Ethernet cards have their own CPU, memory, operating system and applications. Field device vendors are also providing the capability to upgrade or replace the firmware in these Ethernet cards. Unfortunately in most cases there is no effective security on the firmware upload to the field device Ethernet cards. In this paper the authors demonstrate how using commonly available tools an attacker can learn how firmware is loaded into two different field device Ethernet cards, write his own malicious firmware, and load that malicious firmware into the field device Ethernet cards. After this proof of concept malicious firmware load, the authors discuss different classes of attacks that could be launched against the process being controlled, other field devices and other systems on the control system network. The paper concludes with a brief discussion and examples of vulnerabilities in common management services, such as HTTP, FTP and SNMP, found on many field device Ethernet cards.
This paper documents a denial of service attack using only primitive concepts and inexpensive hardware against IEEE 802.15.4 low power networks. The efficacy of swept frequency attacks, dead-carrier attacks, and Bipolar Phase Shift Keying with square waves is documented. This paper will also document the ease and inexpensive nature of the components needed to conduct these attacks, and the technical proficiency required. We express significant concerns of the ramifications of the Clear Channel Assessment feature of the IEEE 802.15.4 specification in a jamming context. Designs can be hardened against such attacks by using directional antennas, by ensuring paths have a physical line of sight, and monitoring signal strength. Recommendations for mesh networking include keeping track of hop counts, as well as noise floor and eye closure monitoring. We recommend obtaining direction finding equipment and practicing with it to find stray signal sources. While Part 15 users may not act against other signal sources, they can at least identify where these sources come from and take measures to avoid them.
Control systems elements like Advanced Metering Infrastructure (AMI) networks fully field wireless sensors and controls outside a utility’s physical security perimeter, placing them at a high risk of compromise. System attackers have every opportunity to damage, sniff, spoof, or tamper communications hardware platforms for malicious, hobbyist, or incidental reasons. This paper demonstrates the relevance of common control systems communications hardware vulnerabilities that lead to direct control systems compromise. The paper describes several enabling vulnerabilities exploitable by an attacker, the design principles that causing them to arise, the economic and electronic design constraints that restrict their defense, and ideas for vulnerability avoidance. Topics include design induced vulnerabilities such as the extraction and modification of communications device firmware, man-in-the-middle attacks between chips of a communications devices, circumvention of protection measures, bus snooping, and other attacks. Specific examples are identified in this report, ranked by attack feasibility. Each attack was investigated against actual IEEE 802.15.4 radio architectures.
Traditional IT firewalls are used in control systems to provide a security perimeter and offer important protection. However, two new directions in control system perimeter security are now available and claim to provide a higher level of security: namely, one-way communication technologies and control system protocol deep packet inspection. In this paper, we will present these technologies and purported benefits, analyze their effectiveness against a variety of attacks, and consider architecture options where these new classes of security products may offer the most benefits. Finally, the paper discusses how this new technology can be extended and further tailored for the control system security challenge.
Critical infrastructure utilities are beginning to use wireless mesh networks in their monitoring, and sometimes control, networks. Establishing secure, distinct communication links between nodes within wireless mesh networks is important to avoid compromise of the entire network when a single node is compromised. In addition, first responders must be allowed authorized access to the network in a way that maintains security during and after emergencies. This paper describes key management protocols to support 1) distinct medium access control (MAC) layer link encryption and authentication and 2) time-limited credentialing of first responders within wireless mesh networks. Secure communication in the wireless mesh network is dependent upon the secrecy and strength of the keys used in cryptographic algorithms for confidentiality and integrity of data and for authentication of authorized users. Trust in network security is rooted in a central trust authority (CTA) that is responsible for a) verifying the credentials of authorized wireless mesh nodes, b) generating and maintaining certificates for mesh nodes, and c) generating and maintaining time-limited credentials for first responders. Leveraging trust in the CTA, we use public key techniques to exchange a unique symmetric key between network neighbors. For first responder credentialing, we take advantage of the Remote Authentication Dial-In User Service (RADIUS) protocol to terminate sessions after a specified time has elapsed. The goal of this work was to provide another layer of communication security in mesh networks and to enable a new capability for first responders by leveraging existing cryptographic protocols.
We define a 0Day vulnerability to be any vulnerability, in deployed software, which has been discovered by at least one person but has not yet been publicly announced or patched. These 0Day vulnerabilities are of particular interest when assessing the risk to well managed control systems which have already effectively mitigated the publicly known vulnerabilities. In these well managed systems the risk contribution from 0Days will have proportionally increased. To aid understanding of how great a risk 0Days may pose to control systems, an estimate of how many are in existence is needed. Consequently, using the 0Day definition given above, we developed and applied a method for estimating how many 0Day vulnerabilities are in existence on any given day. The estimate is made by: empirically characterizing the distribution of the lifespans, measured in days, of 0Day vulnerabilities; determining the number of vulnerabilities publicly announced each day; and applying a novel method for estimating the number of 0Day vulnerabilities in existence on any given day using the number of vulnerabilities publicly announced each day and the previously derived distribution of 0Day lifespans. The method was first applied to a general set of software applications by analyzing the 0Day lifespans of 491 software vulnerabilities and using the daily rate of vulnerability announcements in the National Vulnerability Database. This led to a conservative estimate that in the worst year there were, on average, 2,500 0Day software related vulnerabilities in existence on any given day. Using a smaller but intriguing set of 15 0Day software vulnerability lifespans representing the actual time from discovery to public disclosure, we then made a more aggressive estimate. In this case, we estimated that in the worst year there were, on average, 4,500 0Day software vulnerabilities in existence on any given day. We then proceeded to identify the subset of software applications likely to be used in some control systems, analyzed the associated subset of vulnerabilities, and characterized their lifespans. Using the previously developed method of analysis, we very conservatively estimated 250 control system related 0Day vulnerabilities in existence onany given day. While reasonable, this first order estimate for control systems is probably far more conservative than those made for general software systems since the estimate did not include vulnerabilities unique to control system specific components. These control system specific vulnerabilities were unable to be included in the estimate for a variety of reasons with the most problematic being that the public announcement of unique control system vulnerabilities is very sparse. Consequently, with the intent to improve the above 0Day estimate for control systems, we first identified the additional, unique to control systems, vulnerability estimation constraints and then investigated new mechanisms which may be useful for estimating the number of unique 0Day software vulnerabilities found in control system components. To make a 0Day estimate for control system specific devices and applications requires a modified approach for a variety of reasons including that vulnerability research in control systems is being performed by a smaller and apparently different set of security researchers, the control system specific applications are not as pervasive, and up to this time the vulnerabilities are generally not being reported publicly. Given these and other constraints, we proceeded to identify a number of new mechanisms and approaches for estimating and incorporating control system specific vulnerabilities into an improved 0Day estimation method. These new mechanisms and approaches appear promising and will be more rigorously evaluated during the course of the next year.
ISA (International Society of Automation) and others are struggling mightily to develop quantitative cyber security assurance metrics. All metrics proposed to date are at best qualitative and highly subjective. They are certainly without mathematical rigor; and clearly, they do not conform to the guidelines recommended by Andrew Jaquith in his book “Security Metrics – Replacing Fear, Uncertainty and Doubt” . Papers by Kube, Langer and Singer [2,3] presented in the 2008 S4 Conference address the difficulty in developing quantitative metrics. This paper follows the Jaquith model which requires that good metrics must be capable of being consistently measured (without subjective criteria), the measurement of these metrics must be collectable by automated systems, the metrics must be expressed as cardinal number or percentage using at least one unit of measure, and they must be meaningful to the asset owner. The approach begins by using the ISA’s mapping of NIST 800-53  (ISA99WG04TG2, 2009 (Work in Progress) ) to the seven foundational requirements as defined in ISA99.01.01 . The next step, described in this paper, offers the mathematical formulas for quantifying security assurance for the system and for the components of the system under consideration (SuC). These formulas do not rely on minimizing the risk-based based formula R = (1-Pe)*C*Po. Rather, a consequence-based analysis is used to establish weighting coefficients for contributing security mechanisms that are used in the proposed formulas. Thus, we can build a “score card” to collect measurements of the security metrics that can then be used to assess the implemented security assurance of the system under consideration.
Off the shelf security products such as firewalls, encryption equipment and IDS can be configured for a specific vendor application and protocol implementation to protect internal control system communication and detect attacks. This paper discusses how a set of IDS rules are written and deployed to check the SCADA protocol used by the application, and detect traffic patterns that should not occur during normal operation through the HMI of that application. The rules must be tailored to the particular vendor application, which demands a deep knowledge of the application behavior, but will also yield better results in detecting suspicious traffic aimed specifically at that SCADA application. This paper describes the IDS settings with scenarios such as multiple successive control commands and consecutive commands in a short period of time. The internal firewall and encryption equipment add layers of security to the system, and by filtering out obviously malformed traffic, they also relieve the IDS of superfluous computation. However, unlike the IDS, they are installed within the communication path and add a certain amount of latency, which may become an issue in a SCADA system demanding real-time processing. This paper presents some evaluation results concerning the latency introduced by encryption and a firewall.
Timely detection of cyber attacks can limit or prevent adverse affects to a control system. Security events that can help detect attacks are located throughout the system in computers, field devices, network infrastructure equipment, security devices and other sources. Information Technology (IT) security vendors have developed Security Event Manager products that aggregate and correlate security events from a variety of sources to detect attacks. However these products lack interfaces to aggregate security events from control system applications and devices, and the Security Event Manager products do not exist today on most control system networks. In this paper, we describe the how a control system Historian can be used to aggregate and correlate security events from both traditional IT sources and control system sources. An Event Taxonomy is described that is based on a composite approach. The aggregation and correlation for the Event Taxonomy is then implemented in a popular Historian, OSIsoft’s PI server.
Bandolier Security Audit Files provide a means for control system owners to determine if all of the operating system and application security parameters are in their optimal, most secure configuration. However, the best possible security configuration for one application may be dramatically more or less secure than the best possible configuration for another application. How does an asset owner considering a purchase of a new DCS or SCADA system evaluate the security of systems from different vendors? This paper offers one possible approach. In this paper, the authors take the Bandolier Security Audit File data and security controls from standard and guideline documents, such as ISA 99 and NIST SP800-53, to identify desired security configuration categories and elements in these categories. These categories and elements are then used in proposed metrics to put a number on the security configuration for comparison purposes. With the detailed application information available in Bandolier, we are able to quantify a range for a security configuration setting rather than a simple yes/no measure typically found in a standard or guideline documents.
Cost justifying security improvements persists as a challenge to improving Industrial Control Systems (ICS) Security. Low rates of reported incidents and vulnerabilities for ICS as compared to similar electronic systems in IT leaves many to question whether or not cyber security for ICS is truly a challenge. The quest for Return on Investment (ROI) and business justification for improved security controls persists as an impediment to reducing risk despite increasing awareness, vulnerability discovery and reporting, and attack trends. This paper explores another potential vector to justify security expenditures through the identification, measurement, and improvement of process trends that are affected by improved security controls
Wireless LAN technology offers some important benefits for control systems including easier and lower cost deployment and topology changes. However this wireless LAN technology can be more accessible to an attacker than wired LAN technology. To address this potential increased risk, industry groups have been working on wireless security standards. One of the more popular efforts is ISA 100.11a. Most of the discussions regarding hacking and protecting ISA 100.11a and other wireless LAN efforts have focused on source and data integrity and confidentiality in the form of detailed cryptographic protocols. The third leg of the security triad, availability, has received less attention particularly from malicious attempts to affect availability of the wireless signal, such as jamming. ISA 100 and other wireless standards leverage IEEE 802.15.4 for the layer two protocol. Brodsky and McConnell showed in a 2009 S4  paper that the Clear Channel Assessment (CCA) feature in IEEE 802.15.4 made this signal easy to jam using very low cost equipment. However, that test only occurred on one channel and not on ISA 100.11a radios. After the paper was released, there was uncertainty on whether this jamming attack would be prevented by some measures in the ISA 100.11a protocol stack. This year, the authors expanded the jamming equipment and testing to include all 16 channels in the 2.4GHz range, and the authors tested an actual ISA 100.11a radio. The Nivis ISA 100.11a  protocol stack, the only stack for that protocol available at the time of the testing, was obtained and deployed for testing. The results from the jamming were mixed and discussed in the paper. The radios were more resistant than the IEEE 802.15.4 radios tested last year, but there performance and reliability issues remained, especially in establishing connections when jamming was taking place.
A great deal of effort has been spent on finding vulnerabilities and securing operating systems commonly used on workstations and servers. Embedded devices such as RTU’s, PLC’s and other field devices used in SCADA and DCS also have an operating system, but the security of these operating systems has been largely ignored. Embedded OS are rarely patched and security mechanisms available in the processors are rarely used. In this paper the authors review the processors and embedded operating systems commonly used in control system field devices. The available security features and situation with security patching is also discussed. A variety of field device platforms are then subjected to very old attacks that were first used against many workstation and server operating systems more than ten years ago. The results from this legacy attack testing are provided and analyzed
The use of wireless networks in control systems offers some different challenges from a traditional corporate wireless network, and this paper will address two of those challenges. The first is the relatively low capability CPU’s found in controllers and instruments can be vulnerable to denial of service attacks if computation intensive public key functions are repeatedly required by attackers. To counteract this threat, the author proposes a polynomial-based weak authentication scheme to mitigate potential denial of service attacks against public key protocols. A secret key established by the polynomial-based weak authentication is used to authenticate the exchanged messages of public key protocols. Each node verifies the messages before running the expensive public key operations. The second challenge addressed in this paper is recovering from a loss of a crypto key, which could occur if a security enabled controller or instrument is stolen. In many schemes, a key manager must update the group key to revoke the compromised nodes from the whole network. This paper proposes and describes the use of stateless group key update schemes to update the group key in wireless networks, especially when the wireless communication channel is unreliable. Stateless group key update schemes have two nice properties. First, a legitimate node can get the more recent group key as long as the node receives the corresponding key update message, even if the node is offline for a while, or misses several previous rounds of key update messages. Second, no coalition of revoked nodes, of an arbitrary size, can decrypt the new group key
The last few years have seen considerable investment in the security of industrial control systems. In the power sector, there has been a focus on operational measures directed by NERC, while technical solutions have been proposed through the IEC and the ISA. Many of these proposals use cryptography to secure communications, so that some of the defensive effort can be moved from the perimeter to the end systems. However the security mechanisms need to take into account implementation costs as well as operational challenges. In this paper, we discuss these challenges in the context of protecting communications within substations. Proposals to use digital signatures are impractical because of both performance and cost. We analyse the complexities of these solutions both from security economics as well as engineering perspectives and argue that the right technology for this application is shared-key, namely message authentication codes: it gives the necessary performance at a fraction of the cost
Whitelisting is described by its advocates as “the next great thing” that will displace anti-virus technologies as the host intrusion prevention technology of choice. Anti-virus has a checkered history in operations networks and control systems – many people have horror stories of how they installed anti-virus and so impaired their test system that they simply couldn’t trust deploying it in production. While anti-virus systems detect “bad” files that match signatures of known malware, whitelisting technologies identify “good” executables on a host and refuse to execute unauthorized or modified executables, presumably because such executables may contain malware. This is a least privilege approach of denying everything that is not specifically approved. In this paper the Industrial Defender team performs an independent analysis of a variety of whitelisting solutions for their applicability to control systems. The paper closes with some recommendations related to this technology and areas for further research.
Leveraging Determinism in Industrial Control Systems for Advanced Anomaly Detection and Reliable Security Configuration by Hadeli Hadeli, Ragnar Schierholz, Markus Braendle, Cristian Tuduce, Sebastian Obermeier
Today, industrial automation and control systems (IACS) are more and more based on common IT technologies, leveraging open standards. Because of that IT security has become an important issue and a key challenge. This paper presents an approach that leverages the unique characteristics of IACS, in particular the formal system description and the deterministic behavior. This allows reliably detecting anomalies and reproducibly generating configurations for security mechanisms such as firewalls. In particular, this paper elaborates how to extend common IDS technology to also detect an IACS specific anomaly, the missing of required traffic, for two exemplary applications: electrical substation automation and process automation.
Security is often discussed in terms of layers of protection. One of the challenges is to decide what is appropriate in terms of implementing specific countermeasures at specific layers. This paper discusses the appropriateness of implementing Host Intrusion Prevention (HIP) at the workstation and server levels within a distributed control system (DCS). Because of its potential overhead in terms of installation, configuration and runtime load, this type of protection has been done at the boundary of the DCS with the “outside” world, including other networks within an organization. However, the technology has been advancing along with the capacities of computing platforms such that it has become viable, as well as desirable, to deploy HIP in a DCS. In addition to providing the conceptual background and reasons for employing HIP in a DCS, information will be shared about the practical aspects and challenges experienced during a project where this was done for an actual commercially available DCS.
Critical industrial infrastructures face two contradictory requirements. On one hand, operators are responsible and sometimes liable for their security. The cybersecurity requirements and regulatory context lead the operators to define strict security levels and ensure information system segmentation. On the other hand, operators need more information exchange in order to be able to take advantage of the sophistication of new digital systems thereby improving the overall safety and performance of the industrial process. The solutions available today don’t meet these needs in a convenient way. Electricité de France (EDF) R&D work on a new kind of security device called “DESIIR”, designed to overcome this dilemma and favourably exchange information in a more secure way with built-in defence-in-depth. This innovative device makes it possible to transfer data from a lower security level, e.g. corporate network, to a higher security level, e.g. SCADA network, while remaining compliant with an operator’s highest security policy level. This paper discusses the security principles, presents the prototype, and proposes use cases showing what could be the benefits of the solution provided by DESIIR.