n engineering approach for secure and safe

8/13/2019 n Engineering Approach for Secure and Safe

http://slidepdf.com/reader/full/n-engineering-approach-for-secure-and-safe 1/8

An Engineering Approach for Secure and SafeWireless Sensor and Actuator Networks for Industrial Automation Systems

Steffen Peter and Oliver Stecklina and Peter LangendoerferIHP GmbH

Im Technologiepark 2515236 Frankfurt (Oder); Germany

{peter,stecklina,langend }@ihp-microelectronics.com

Abstract

Wireless communication and smart sensors and actua-

tors pose means to sustainably improve automation tech-nology. Unfortunately they also cause an abundance of new challenges regarding security and safety of the sys-tem. After introducing the security concepts, this paper discusses an engineering methodology to cope with secu-rity requirements in context of industrial automation. Two practical examples demonstratehow the solutions even for pretty similar scenarios can differ signicantly. The proposed development ow promises a reliable objective en-gineering of proper system solutions. Key concepts of the ow are a holistic goal description and an iterative composition algorithm that inherently applies and extends ex-isting knowledge.

1 Introduction/Motivation

From the aspect of security engineering two relativelynew tendencies in the domain of automation systems areextremely relevant. The rst is that more and more fab-rication sites are connected to each other via public ac-cessible networks such as the Internet. This approach ismotivated by reducing cost for monitoring with a central-ized control center. The result is that the formerly isolatedfabrication networks are now accessible from everywhere

in the world, and by that all Internet-based attacks can berun against fabrication networks. The second tendency isto use wireless communication to a larger intent than upto now. The idea here is to allow more exible set-upsof manufacturing sites and reduce cost for monitoring of difcult-to-reach devices. Using wireless communicationhas a similar effect as connecting the fabrication network to the Internet, i.e. the system becomes accessible fromoutside. From a security engineering approach the ex-change of wired communication by wireless is much moresevere than going for Internet access. This is due to thefact that wireless connections can be accessed from anyposition within the transmission range of the used wireless

technology. Thus, potential attackers are no longer forcedto enter the fabrication network at a well dened entrypoint - as it is for wired Internet connections. Such entry

points are normally powerful machines running strict re-walls. In contrast to those machines the new entry pointsmight even be small sensor nodes, which have limited en-ergy resources, limited processing power etc. Deployingstandard protection means on sensor nodes might for ex-ample increase the processing time that much that depend-ability constraints will be violated. So, a straight forwardre-use of those concepts on sensor nodes is infeasible.

When designing new security solutions for automationnetworks it must be ensured that the core functionality i.e.controlling a manufacturing site is not inuenced by thesecurity solution. This means constraints such as depend-ability issues and the current set-up of the system - con-sisting of software, protocols etc.- need to be taken intoaccount. Especially the latter is difcult to obey whileengineering a system since a lot of information is not ex-plicitly modeled but must be inferred. We reect this byintroducing an additional engineering constraint into oursemi-automatic approach, which we call environment .

The contribution of this paper is the introduction of aholistic but still easy to implement approach which allowsengineering security solutions for automation networks.Our approach considers formerly not modeled constraints(i.e. environment) and dependability issues as well as theidea of economically secure systems. By this term we de-

note the fact that a security solution must ensure that thecost of an attacker to break the security solution is higherthan his/her potential benet. We use a real life examplesfrom the RealFlex project[8] to introduce the security en-gineering challenges and to illustrate our own solution.

The rest of this paper is structured as follows. Sec-tions 2 we provide a fundamental overview of informa-tion security and introduce our examples used throughoutthe rest of the paper. Our security engineering method-ology is presented in section 3. In section 4 we map ourapproach onto the previously introduced used cases. Thenwe present related work. The paper concludes with a shortsummary and an outlook on future work.



Figure 1. CIA triad: Condentiality, Integrityand Availability are three key security prin-ciples in any kind of information system

2 General Security Terms

In this section we rst introduce a general overview of information security, which we will focus on in the fol-lowing. Then we show why standard solutions are notalways suitable for WSANs and in particular in the con-text of industrial automation. Since even two instancesof wireless implementations of automation systems candiffer substantially, we nally conclude that rst, there isno one-ts-all solution and second, that a clearly distin-guished denition of the requirements is needed in orderto nd a suitable system architecture.

2.1 Information SecurityInformation security describes the properties of infor-

mation systems, which ensure condentiality, integrityand availability. In WSAN based automatic systems isthe information security particularly an economic factor.It denes the cost for an attacker to get important busi-ness information or to disturb the error-free operation of an industrial plant.

The three terms –known as CIA triad, Figure 1– con-dentiality, integrity and availability are the core principlesof information security. In this section we present a shortdescription for these principles.

Condentiality is the ability to ensure that informationis accessible only to authorized people or systems tohave access.

Integrity is the ability to ensure that data is an accurateand unchanged representation of the original secureinformation.

Availability is the ability to ensure that data are readilyaccessible to the authorized all times.

For an error-free operation of a facility it is very im-portant that information are trustable and accessible alltimes, since measured data and controlling informationregulate the workow in sensor and actuator based indus-trial plants. If data regarding the facility’s workow can be

easily obtained by an attacker, it would pose the feasibilityto gather important business information with a minimalinvestment. That would imply a maximal benet for him.

The authors of [3] described four additional key secu-rity concepts we will also follow in our evaluation, sincethere are as well of some importance to automation sys-

tems.

Authentication concerns the verication of the peer’sidentity.

Authorization checks whether the peer has permission toconduct some action.

Accountability makes sure the actions can be assigned tothe corresponding communicating participants.

Non-Repudiation is the undeniably of an action.

In the automation environment it can be the questionwhether a received sensor reading or controlling com-mand is actually from the right sender and not a forged

message. For modern computer system the principle of least privilege more and more takes hold. The authoriza-tion is an instrument to enforce this principle. For sensornodes in addition it can reduce data processing efforts be-cause invalid packets do not need to processed in higherlayers.

Accountability and non-repudiation are very importantfor e-commerce and e-business systems. In WSANs theseproperties can be mostly covered with the mechanismused to ensure integrity.

Table 1. Standard mechanisms for the sevenprotection goals

Protection Goal Mechanismcondentiality encryptionavailability redundancy, lteringauthorization passwords, lteringauthentication signaturesintegrity secure hashesaccountability audit, loggingNon-Repudiation signatures, logging

For all security goals mechanisms have been developedin the past. Table1 gives a short overview of these mech-

anisms. For instance a standard means that is supposed toprovide condentiality is encryption. However, that sucha mechanism satises the specic goal does not mean thatit works under all circumstances. Most approaches haveinitial assumptions regarding the communication channel,the peers and the environment. If and how a mechanismworks depends heavily on environment and application.For example it is common knowledge that cryptographyprovides condentiality over an insecure communicationchannel, but it does not provide condentiality for measur-ing on the sensor device. The problem becomes even moreapparent for ubiquitous devices that theoretically can bepicked up by everyone[11]. On the other side conden-

2



Figure 2. Wireless waterworks infrastructure

an existing solution or a distribution in hardware and soft-ware becomes necessary. Identifying the ideal trade-off isa non-trivial issue.

In both examples the new components will be con-nected by wireless links and hence will be vulnerable andcan be miss-used as point of entrance. In this section wewill explain why a good embedded security solution forthe waterworks is not a good solution for the robot cell.

In both examples the nal link to the sensors should bereplaced by a wireless connection. The data transferredover these links are controlling and measure data. Ac-cessing or overtaking a sensor node by an attacker cancompromise the operation of both plants. Capturing datacan gain a benet in an imaginable industrial or nationalcompetition. It would be necessary to cover the secu-rity goals condentiality, authenticity and authorization inthose wireless architectures.

A potential solution for waterworks is using standardencryption for the controlling and measured data. Thesensor nodes and the access points are powerful enoughand have no problems with power consumption. Becauseof the easy accessible location of the sensor nodes espe-cially at the wells, we need also good authentication, in-

tegrity and authorization. This can be done by signaturealgorithm like SHA1[4] or RipeMD and a light weightrewall [6]. To ensure the availability we can use a backupcommunication link, with lower performance or use an-other hop-by-hop route.

All these solutions do not work for the robot cell. Herewe have a very small set of data in a high frequency whichhave to be processed by a faint sensor node. Data encryp-tion with block size padding and additional header infor-mation will extend the packet to an inadmissible size. Itwould be better to use algorithm without block size bind-ing like RC4 or a modied AES [7]. High level packetltering in real-time will not be a feasible, the needed cal-

culation power and caused latency are not acceptable. Au-thentication and authorization should be solved while reg-istering of the new tool set. A more physical solution likea bar code would be feasible. Availability can be coveredby a power down in any case of an error. A human ad-ministrator would be in the near of the system and caninterfere in real time.

In this short example you can see, that the solutions fortwo systems with nearly the same protection goals need tobe extremely different. That is mainly caused by the en-vironmental constraints. In the eld we have many more

factors not described here which additionally have to beobeyed. In the next section we introduce an approach tocovering this problem by a more tangible process.

3 Our Approach

Based on the perception that realizations of security-providing mechanisms usually cannot be delivered by aone-ts-all solution this section discusses a methodologythat does not only respects the security requirements of theapplication but integrates environmental properties andsafety-constraints. The result is a well-dened compo-

sition of system components that promise to satisfy thegiven requirements. The formalized categorization of so-lutions allows the establishment of a knowledge base thatcan be applied for the development of new systems. Theresults of each new engineering process will also extendthe knowledge base.

3.1 Development FlowThe fundamental idea of our approach is shown as Fig-

ure 3. The result of the system analysis process is a list of target properties (Security goals, dependability require-ments and environmental constraints). Driven by the re-quirements we start an iterative process that successively

4



Figure 3. Flow of the selection process: Def-inition of Security, Dependability and Envi-ronment are input for iterative selection pro-cess. The solution library allows reuse.

takes promising solutions out of a solution library andtries to attach them to the system under development. Anevaluation after each step tests the outcome of the incre-mentally extended system. If the extension is benecial,i.e. the test is passed, the system architecture will beadapted. The new system –even if it does not satisfy allgiven requirements– will be added to the solution library,so that the knowledge base is extended for the future. Af-ter updating the dependencies and solved requirements of the new system, a new iteration of the development willstart. That process will be repeated until a system archi-tecture is found that satises all given requirements. Thisarchitecture will be the blueprint for the actual system in-tegration.

3.2 Inputs of the Selection Process

As already introduced, it is the key that the goals areobjective and their fulllment can be veried.

The major problem of traditional assessment processof security requirements is an implicit fuzziness that con-cludes in wrong assumptions. Surveying operators of au-tomation facilities we often got requirement statementslike ‘condentiality is no problem because no one unau-thorized can enter our networks’. In that case it could bea miss-interpretation of the operator to conclude that con-dentiality is no issue for that facility. In fact, it can beassumed that it is an issue, but since that security relatedstatement already includes environment and an assump-tion of the solution, it is not clear.

The need for condentiality as security goal does notdepend on the environment. It depends on data and asort of degree characterizing the security strength. Con-sequently the requirement denition of concealment –justlike for the other requirements– must be dened isolatedfrom environmental aspects. For example the require-

ments regarding integrity of data in a facility are un-affected by the used network. If the facility switchesfrom wired to wireless, the security requirements will notchange, but just the environment. Indeed the eventual so-lution will change signicantly but the inputs to our pro-cess will change just slightly.

Due to the strict separation of security, dependabilityand environment in our denition process we are able topose questions that aim toward a precise and objectiveproblem denition. At this point the questions mostlyconcern whether specic properties (e.g. concealment, in-tegrity) are needed. For a precise denition process it isalso imperative to dene the degree of each feature. Po-tential metrics are the assumed cost or duration that areneeded to break the mechanism. However, in order to il-lustrate the general idea, in this paper we stress the pureexistence of specic requirement.

3.3 Mapping from Requirement to Practical SolutionThe center and brain of our approach is the mapping

and selection algorithm. Its task is to nd combina-tions of system components that satisfy the requirements.Straightforward said, we want to map the three require-ment descriptions into a single system.

3.3.1 The Solution Library

The solution library is a repository of potential solutions,which is used by the mapping process. The library storedentries that are very similar to classic security architec-tural patterns [12]. Such patterns usually describe imple-mentation aspects of software application programming.Our patterns additionally consider environmental map-ping and protocol selection so that each entry in the solu-tion library contains the data like description of the solu-tion including a problem statement, security and depend-ability implications (what do they solve), environmental

constraints and parameters, dependencies, and discussionsof benets and disadvantages.

The data will provide developers the means to assem-ble systems out of the basic building blocks that are theentries of the solution library. Additionally the clear struc-ture allows objective analysis of the resulting system. Al-though it is envisioned that the analysis can be performedin an automatic process, currently it is required that en-tries and structure can be handled by a human engineer.Description, motivation and discussion are part of eachentry mainly for that reason. For automated integration arather formal description of dependencies, constraint andproperties would be required.

5



and analysis to avoid many common problems.

A tool that could be an example for a small solutionlibrary, entirely focuses on ’Security Through Usability’and has been published by the CRISIS project [1]. Theauthors categorized several key distribution schemes forsensor network applications. Based on the user inputs asuitable selection of protocols is presented. After enter-ing main and secondary properties, e.g. small memory,connectivity, scalability, resilience, the tool delivers a listof key distribution schemes that fulll the requirements.Additionally the tool lists specic advantages and disad-vantages of the algorithms, so that competent users havefurther information supporting the selection process.

Security architectural patterns are discussed in [12] and[9]. Though the context of the studies is not as broad onsystem level, studying the proposed terminology can helpimproving the denition of our solution library. For ex-ample the notion of a security degree as part of a pattern

description as described in [9] can be valuable for the objective security assessment process as it is required in ourselection algorithm.

Composition of security mechanisms is discussed in[2]. They propose a framework that breaks down the se-curity protocols in atomic cryptographic tasks that can becombined to composed protocols. An application of theidea inside the selection algorithm as well as an exten-sion of the described cryptographic task towards combin-able building blocks for safety and environment could bea promising approach.

6 Conclusions

In this paper we have presented a holistic approachfor engineering security solutions for automation net-works. One of the main innovations is the inclusionof non-security parameters such as dependability andengineering constraints resulting from existing systems,which we call environment . The latter is extremelyimportant since it allows to explicitly model implicitassumptions, e.g. about condentiality which is given if asystem is physically shielded from its environment, which

holds no longer true if wireless communication is used.The second innovative aspect is the semi-formal searchfor security solutions guided by the above mentionedconstraints. We have illustrated our approach usingreal life examples currently under development in theRealFlex project.

In our future research work we will focus on the fol-lowing issues: formal description of the system propertiesin all relevant categories i.e. security, dependability andenvironment. Then we will develop an automated test-ing functionality for checking system properties duringthe search for solutions.

Acknowledgment

The work presented in this article was supported bythe German Ministry of Education and Research undergrant 01BN0711D and by the European Community’sSeventh Framework Programme (FP7/2007-2013) under

grant agreement no

225186.

References

[1] C. Alcaraz, J. Lopez, and R. R. Castro. Choosinga key distribution protocol for your sensor network.http://www.lcc.uma.es/˜roman/KMSCRISIS/, Jan 2008.

[2] R. Canetti. Universally composable security: A newparadigm for cryptographic protocols. In IEEE Sympo-sium on Foundations of Computer Science , 2001.

[3] N. Daswani, C. Kern, and A. Kesavan. Foundations of Se-curity: What Every Programmer Needs to Know . Apress,Berkely, CA, USA, 2007.

[4] D. Eastlake 3rd and P. Jones. US Secure Hash Algorithm1 (SHA1), 09 2001. RFC 3174, Informational.

[5] M. Eby, J. Werner, G. Karsai, and A. Ledeczi. Integratingsecurity modeling into embedded system design. In Inter-national Conference and Workshop on the Engineering of Computer Based Systems . IEEE, 2007.

[6] P. Langendoerfer, K. Piotrowski, S. Peter, andM. Lehmann. Crosslayer rewall interaction as ameans to provide effective and efcient protection atmobile devices. Computer Communications , 30(7), 2007.

[7] National Institute of Standards and Technology. Advancedencryption standard. NIST FIPS PUB 197 , 2001.

[8] RealFlex Consortium. RealFlex: integration of reliablewireless communication systems within sensor/actuatornetworking in automation systems, http://www.realex-

projekt.de/, 2009.[9] D. G. Rosado, E. Fernandez-Medina, M. Piattini, and

C. Gutierrez. A study of security architectural patterns. Availability, Reliability and Security, International Con- ference on , 0, 2006.

[10] J. Stankovic, R. Zhu, R. Poornalingam, C. Lu, Z. Yu,M. Humphrey, and B. Ellis. Vest: An aspect-based com-position tool for real-time systems. In Proceedings of the IEEE Real-time Applications Symposium , 2003.

[11] D. Westhoff, J. Girao, and A. Sarma. Security solutionsfor wireless sensor networks. NEC Journal of Advanced Technology , 59(2), June 2006.

[12] J. Yoder and J. Barcalow. Architectural patterns for en-abling application security. In Fourth Conf. Pattern Lan-

guages of Programming (PLoP) , 1997.

n engineering approach for secure and safe

Documents