
P19673		Security in Building Automation

Project

Abstract

Scientists/Scholars

Project Publications

Deliverables

	seBAN
	DoS in BAS
	SecApp

Cooperations

Final Report

Secure Customizable Automation Applications

While an overall device security deals with software, side-channel, and physical attacks, this article focuses on software attacks.

Requirements for securing devices

Any (malicious) software, irrelevant whether it originates from trusted or non-trusted sources, being run on BAS devices may exploit weaknesses in security schemes and system implementation, intentionally or unintentionally. Accidental programming flaws shall not be present just like software being infected by Trojans. Therefore, security mechanisms need to be included that ascertain the operational correctness of protected code and data before and at runtime.
While the software architecture of management devices and interconnection devices is rather fixed and tailored to the device's functionality, a sensors, actuator, or controller typically comprises of a generic "template" network node with application specific hardware. Universally designed base platforms consisting of microcontrollers and network interfaces are used in conjunction with application specific components (e.g., switches, temperature sensors) to form a particular system. Similarly, the software is split into a generic operating system or system software providing basic functionality and (customizable) control applications dealing with the specific hardware. On the one hand, such a two level concept allows rapid innovation and implementation. On the other hand, it may impose security risks, which a security concept has to deal with: While malicious, erroneous or compromised control applications may be uploaded long after device deployment, they shall not interfere with the concerning device software and thus violate the device security.

	method	compile-/runtime	attack types	updates required	scalability	sensors, actuator, or controller	ICD	MD
static software methods	static code analysis	ct	known	yes	-	~	+	+
	code-signing	ct	n/a	no	~	~	-	+
	proof-carrying code	ct	all	no	-	-	~	-
dynamic software methods	signature based IDS	rt	known	yes	-	-	-	-
	anomaly based IDS	rt	all	no	+	+	+	~
	software monitoring	rt	all	no	+	~	~	~
	sandboxing	rt	all	no	+	~/+	~/+	+
	self-checking code	both	all	no	+	~	~	~
	operating system	rt	all	yes	+	-	-	~
	attack specific	both	specific	no	-	~	~	~
hardware supported	coprocessor	rt	all	no	-	-	~	+
	physical partitioning	rt	all	no	-	-	~	+
	system architecture	rt	specific	no	~	+	+	~
	CPU extension	rt	specific	no	-	~	~	+
human	inspection and certification	ct	all	n/a	-	-	~	~

Table 1: Comparison of described software methods to improve application security

Available software protection techniques

Commonly used state of the art techniques can be categorized into static software methods, dynamic software methods, hardware supported methods, and human assisted methods.
Within the context of security, static code analysis (SCA) is used to detect programming flaws that result in vulnerabilities. Using code-signing (CS), executables are signed by the developers to confirm both origin and non-modification. The user can thus decide about the trustworthiness of a program with respect to its origin. Software watermarking can be used to embed additional, non-removable information into a piece of data, usually to assure that the rights of the creator are not violated (digital rights management). Proof-carrying code (PCC) is a technique where a code developer provides a proof along with a program that allows to check with certainty that the code can be securely executed (e.g., does not to contain buffer overflows).
IDS observe the behavior of a system and use the collected information to detect malicious behavior or actions. Signature based IDS (SIDS) detect malicious actions by comparing observed information to a collection of signatures describing known attacks. Anomaly based IDS (AIDS) use representations of the trained, normal behavior of a system to detect abnormal activities. Software monitoring techniques (SMTs) observe the execution of specific programs. By identifying and reacting to certain security relevant events they can check if programs behave according to a given (manually specified or automatically generated) security policy. A sandbox (SB) is a technique where programs are executed in a controlled way, often with restricted permissions. The essential benefit is that the executing host is protected from direct attacks of the software running in the SB. Self checking code (SCC) checks itself for modifications at runtime, assuming that modifications are undesirable and probably malicious. In addition, a number of attack specific countermeasures (ASC) which target only specific types of vulnerabilities (e.g., buffer overflows) exist.
Hardware supported methods may form an extra security barrier. A common approach is to use a coprocessor which performs security checks at runtime. The increased spreading of multicore architectures allows their use for security mechanisms. Physical partitioning may be used to improve a system's reliability as well as its resistance against security attacks. Processors implementing the Harvard Architecture provide resistance against code injection attacks by design through the separation of instruction and data memory. A recent security technique is the no execute (NX) bit in modern CPUs, allowing memory regions to be designated as being non executable.
Manual inspection and certification performed by humans may eliminate a lot of possible attacks, but requires extensive knowledge by the auditing person, is time consuming and error-prone.

Approach for software security in BAS

Table 1 discusses the characteristics of the presented techniques relevant for the BAS domain and evaluates the applicability of the methods for sensors, actuator, or controllers, interconnection devices, and management devices. Column "compile time (ct) / runtime (rt)" describes whether the method is applied at compile time or before execution, at run time, or both. Column "attack types" discusses the effectiveness against known, specific or all attack types. Column "updates required" states whether the method requires continuous updates and column "scalability" evaluates the method with respect to its costs and maintainability in BAS.
SCA, CS, and PCC are assumed to be easily applicable with respect to resources of the target system because they are only used at compile time. A problem of SCA is that for typical programming languages some fundamental questions are undecidable or uncomputable. CS can also be effective to prevent the installation of malicious programs by simply refusing to execute not properly signed ones and thus trusting the signee. However, CS does not prevent accidental flaws. The universal applicability of PCC is questionable since the generation and encoding of proofs for complex security policies is a non-trivial task. A combination of the static PCC approach with dynamic execution monitoring, however, seems to be practically feasible. Besides, SCA, CS and PCC have to be performed on every code change. SIDS is not well suited as it depends on a usually large database and requires constant updates which would be difficult in case of sensors, actuator, or controllers and interconnection devices. AIDS, SMT as well as SCC may be efficiently implemented and could therefore be quite appropriate. SMT at least requires hardware support for context switches. ASCs can also work well, but are not generally applicable due to differing processor and memory architectures. The applicability of sandboxes strongly depends on the overhead imposed by its feature set. While a reduced and lightweight SB could easily be deployed to sensors, actuator, or controllers, an architecture like the full Java VM with its vast execution and security mechanisms imposes high overhead. The targeted hardware of sensors, actuator, or controllers and interconnection devices does not provide the necessary hardware support for operating systems. Besides, such operating systems cannot provide comparable protection or are not even designed to provide security measures. Hardware supported methods requiring additional components cannot be cost effectively deployed to sensors, actuator, or controllers. Manual inspection and certification do not scale at all and may only be applied to code which does not change frequently.
As can be seen, all methods have one aspect in common: They are not able to offer full protection against the security threats in building automation systems. Therefore, the approach is to combine the techniques to make them - along with some human preparation or interaction - useful in practice.
The software of a MD typically consists of an OS and the management software. The security of the OS has to be provided by the system administrator. The security of the management software itself can be established using SCA, sandboxing and up-to-date development tools. Since the software of interconnection devices is rather fixed, SCA and hardware supported methods may be used.
To ease the development of secure control applications hosted on sensors, actuator, or controllers, a software environment being able to deal with the discussed attacks is required. Protection basically against software attacks shall be provided, but with other attack scenarios such as physical or side channel attacks in mind.

Fig.1 Secure control applications

As outlined in Fig. 1 the software of a sensors, actuator, or controller consists of three major components, each imposing an additional security barrier to the overall security and limiting possible attack points:

A simple, tight, and secure system software provides controlled access to system resources. Its security is analyzed using human being based inspection, SCA using automated tools as well as formal verification.
A sandbox restricts the execution of customizable control applications. Basically, this uploadable code shall be allowed to perform any desired action. However, to prevent security flaws it is under continuous control of the system software during runtime, determining whether it is allowed to execute a desired function or not. The sandbox is also designed to support the rapid development of control applications. It provides a clear abstraction of the underlying hardware and offers interfaces to the system software. The developer is thus relieved of any hardware or device specific details and can focus on the application development itself. This allows portability of applications between devices offering the same sandbox.
A configuration has to be provided to the system software during upload of a control application that defines its basic policy (i.e., normal behavior). Any abnormal behavior can then be detected by the system software using an AIDS. Thus, limits to e.g., network or processing resources may be defined, which are enforced at runtime.

To further limit possible attack scenarios, the use of a Harvard Architecture based hardware is recommended.

With support from