Functional Safety and System Security in Automation Systems –

A Life Cycle Model

Thomas Novak Albert Treytl

Vienna University of Technology, Austrian Academy of Sciences
Institute of Computer Technology Research Unit for Integrated Sensor Systems
Gusshausstrasse 27-29 Viktor-Kaplan-Strasse 2
1040 Vienna, Austria 2700 Wiener Neustadt, Austria
[email protected] [email protected]

Abstract threats concerning safety and security and set new

challenges to the safety and security measures in existing
Industrial and building automation systems are more systems. Concerning security today’s automation
and more important in industry and buildings. New systems and networks are in general lacking efficient
services and novel fields of application call for security features. If available security is an extensions
dependable systems. Two very important properties of that is seldom used and often has non-negligible
such a system are functional safety and system security. drawbacks (e.g. [1],[2]). In the same way automation
In the opposite of today’s development where safety and systems lack native support for safety and have been
security are treated separately, investigating security enhanced with safety features on application level (e.g.
together with safety leads to a reduction of effort in the [3]). What is in common is that dependencies between
different phases of system life. That is because they have different operation modes, and safety and security in
some similar objectives, but realized by different particular are not considered. Safety and security are
measures. The intention of the paper is to present a way examined independently not considering potential
of developing a safe and secure system as well as to hazardous side effects on each other.
show the associated benefit with special focus on In a first approach embedding security measures are
building automation. to guarantee the correct execution of all safety relevant
operations in a mixed operation environment.
This goal requires that the systems offer a flexible
1. Introduction security framework that on the one hand handles the
correct usage of resources needed by safety, e.g. QoS
Historically, safety and security issues have been parameters like keep alive intervals, communication
treated separately. Especially, safety systems are setup times, the implicit access control demanded by the safety
and operated totally disjoined from other systems. That application, and on the other hand also offers the same
is, each domain has its own physically separated system and other services like access rights or authentication to
and gateways are required to connect them. For safety other applications.
systems additionally absence of reaction is required and This paper introduces a possible common approach
has to be proven usually resulting in a limited read-only investigating security together with safety throughout the
access to the safety system. whole system life that on the one hand leads to a
Upcoming trends such as remote access via the reduction of effort in the different phases of development
Internet, advanced control operations or cost reduction and on the other hand aims at the design of systems
by using shared networks, not limited but obvious in the which have security and safety in their core. The
area of building automation, advise to rethink this intention of the paper is to present a life cycle approach
separation and setup concepts for systems that allow based on ideas mentioned in [12] – using existing
common usage by safety, security, HVAC (heating, international standards, IEC 61508 [7] and IEC 15408
ventilation and air conditioning), and lighting and also known as Common Criteria (CC) [11], and their
shading. Using redundancies in building automation methodologies – that allows for a combined approach
control systems by integrating safety critical, security towards security and safety. The particular focus is set
relevant and standard operation into a single on safety and security in building automation.
communication system would allow for big savings. The remainder of the paper is structured as follows:
But these trends break up the isolated structure of Section 2 describes security and safety goals with their
existing networks and therefore introduce new risks and commonalities. Section 3 introduced the safety-security
life cycle model. Finally, section 4 presents rules for

Proceedings of ETFA 2008 - 13th IEEE Conference on Emerging Technologies & Factory Automation
2008, 311-318, (C) IEEE 2008
conflict resolution and a measure assessment. The SAFETY MESSAGE SECURITY MESSAGE
practical examples given to illustrate the concepts are
taken from SafetyLon-Project [3] that strives for making Message income

LonWorks safe, from the authors activities related to

secure industrial and building automation systems and
the standardization of safe and secure systems in CEN. CRC Integrity check MAC/Signature

2. Common Procedure: Integrity,

Authentication and Authorization
Sender
Source Address Source Address
Authentication
Looking at the goals of safety and security similarities
can be identified that show potential for a combined
synergetic approach. In particular the common procedure
Plausibility Access Control
of integrity check, authentication and authorization is a checks
Authorization
Lists
main building block for applications in both areas.

2.1. Definitions
Message execution
“Functional safety is part of the overall safety that
depends on a system or equipment operating correctly in
response to its inputs” [7]. Figure 1 Common procedure:
Security is concerned with the protection of assets integrity, authentication and
from threats, where threats are categorized as the authorization
potential for abuse of protected assets” [11] In the
domain of security there are two main subdomains: 4. Authentication, allowing to determine the
network security or internet security, and system security sender/creator of a message
or computer security [15]. 5. Authorization, defining access rights.
6. Non-Repudiation, giving evidence that the
2.2. Safety and Security Goals sender/creator of a message issued the message.
In order to understand the potential of synergies given Looking at the security goals relevant for automation
between safety and security the goals of the two areas systems confidentiality and non-repudiation1 can be
should be analyzed: neglected for the systems of interest in automation
Safety goals are ([1],[2],[4]). Hence, comparing the remaining important
1. Integrity, which demands the correct operation of security goals with the safety procedure a common
the system under all defined circumstances with in a pattern between safety and security can be identified.
fixed period of time. It is usually divided into A chain starting with integrity verification,
stochastic (hardware) integrity and systematic authentication followed by an authorization is given (see
integrity. Figure 1). Measures in this chain are differently
2. Authentication, which demands that a message is implemented in safety and security since they aim at
coming from the correct source. A common different sources of failures, but pursue the same goals;
approach is source based addressing. Security aims at protection and defense of threats from
3. Availability is not necessarily a direct safety goal intentional attacks, safety measures are a protection
since a non-available system can find a simple fail- against malfunction of the system itself including fault
safe state by going to no-operation, yet for practical tolerance, safety integrity and fault resistance [5].
reasons this trivial solution is not desired. E.g., safety authorization is based on maximum
4. Authorization is usually implemented implicitly by plausibility, i.e. is the value within a fixed range, or even
allowing authenticated operation. Additionally, a simpler allows everything that passes the authorization
check for maximum plausibility is sometimes stage. In contrast, security demands fixed access control
applied, for example to check timing values. lists (white or black lists). Similar for the integrity, CRC
(cyclic redundancy check) codes computable by
Security goals are everyone are sufficient against stochastic failures, whilst
1. Confidentiality, meaning that only authorized
security necessitates cryptography that requires the
entities must be able to read confidential data,
knowledge of a secret key to properly verify the integrity
2. Integrity, stating that no unauthorized entity must be
of a message. Looking at this example replacing the
able to change data without being detected,
3. Availability, mandating that data is on-hand when it
is needed 1 Non-repudiation is of big importance and rarely used in actual
operation. It is only used as posterior measure for tracking, e. g.
billing or making lists of accesses of maintenance personal.
individual measures for integrity protection Development
(cryptographic message authentication code (MAC) and
CRC) with a jointly used MAC fulfills the requirements
1 Definition of concept
for both domains.
Yet, finding these commonalities is not that straight
forward since measures can need different efforts or 2 Safety requirements specification

even find no common equivalent. Optimization goes

much beyond simple replacements; they need a holistic 3 Security requirements specification
analysis that requires considerations of safety and
security in the complete life cycle from development, to
4 Conflict resolution
operation and disposal.

3. Life Cycle Model 5 Safety-security requirements specification

A life cycle model is a structured and systematic Realization of safe-secure BACS entity
model covering the development and use phase of a
6.1 6.2
system. Within the paper a life cycle model is used as
Hardware Software
generic term for every procedure starting with a
product’s conception and ending with its disposal. Or, in
other words a life cycle model specifies a logical activity 7 Overall installation and commissioning
flow of a project.

3.1. Life Cycle Approaches 8 Overall safety-security evaluation

A life cycle approach has become ‘best practice’ in

the safety domain. Examples of safety life cycles can be 9 Overall operation, maintenance and repair
found in [6] or in the international standard for
functional safety IEC 61508 [7]. There has been a
11 Overall Decommissioning
common understanding that activities such as fault
avoidance and fault control must be applied at different
Use
stages of the life cycle. Often safety assessment work has
been confined to assessing whether the proposed
architecture meets the target failure probabilities [8]. Figure 2 Safety and security life
Less attention was paid to the installation, maintenance cycle model
and disposal phase [9]. Therefore, a lot of serious safety
The basic idea of the safety-security lifecycle
problems occurred during that phases.
presented in Figure 2 is to use the safety lifecycle from
Similar approaches, albeit less detailed and accepted,
IEC 61508 and integrate the security approach specified
have been development in the security domain. In [10] it
in Common Criteria (CC). Requirements how to proceed
is outlined that building any type of software securely is
are given for every phase of the system life. Moreover,
only possible if security issues are considered during all
activities are added to consider safety and security
phases of the life cycle. Hence, seven so-called
dependences resulting from integrating safety and
touchpoints (a set of best practices) are introduced, each
security.
of them applicable to a different life cycle phase. In the
The two international standards IEC 61508 and CC
international standard IEC 15408 [11], also known as
are not application specific. They are providing a set of
Common Criteria (CC), security related activities for the
requirements and procedures to be used in different
various life cycle phases are specified. They are
applications. They are chosen as basis of the proposed
organized in classes such as activities for requirement
life cycle model because they have a good coverage of
specification or installation. Additionally, CC specifies a
functional safety and security aspects. And the standards
way of how to receive security requirements. In general,
are considered to be well-accepted in their domains. In
the trend to ensure security during the various stages of a
addition, both make a classification and a comparison of
product life is clearly perceptible. Its importance is
systems possible by specifying different levels: four
growing due to the increasing complexity and
safety integrity levels for safety related and seven
connectivity of security critical systems
evaluation assurance levels for security related systems.
Whereas in the safety domain life cycle models are
The rigor and amount of requirements increases with
specified, the security domain very often determines
higher levels.
activities relating to security, but does not define a
The safety-security life cycle model is divided into
model, i.e. the flow or order of activities.
two major parts:
1. The first part includes activities related to the the output of the safety dependent part comprised in the
development of an entity in an automation system, safety requirements specification.
e.g. a node. The development phase includes safety
dependent and security dependent activities. In 3.2.3. Security Requirement Specification
addition, an approach to deal with conflicts resulting Results from the safety investigation and definition of
from contradicting safety and security requirements the concept are input to the security dependent part of
is integrated into the development phase. the safety-security life cycle model. First, the security
2. The second block is related to the use of the environment is examined: the physical environment and
automation system and refers to all activities during assets, i.e. information and resources that require
the use of the complete system. protection. Typical examples of assets in automation
Although activities of both phases are shown in a
systems are sensor or actuator data. Next, the assets are
sequential way in Figure 2, the life cycle model only
valued and threats to them are specified. A typical threat
intends to show that activity n+1 requires input of
to sensor data is deliberate manipulation. Moreover, the
activity n. For the sake of readability recursions that will
risk resulting from a threat is estimated. The measures to
occur with the life cycle are not included in this figure
reduce the risk or in other words requirements on the
and activities may be required to be redone during
security functions required to protect the assets are
system life to receive a safe-secure system, e.g., conflict
specified according to the value of the asset and the risk
resolution (discussed later in the paper) may reveal a
of threat to the asset. E.g., to detect manipulation of
conflict that has an impact on the hardware environment.
sensor data a message authentication code (MAC) needs
Hence, safety and security requirements have to be
to be integrated.
investigated again.

3.2. Development Phase 3.2.4. Conflict Resolution:

The development phase is the first phase of the Safety requirements and security requirements are
safety-security lifecycle model. Stages 1 and 2 are investigated in the conflict resolution activity.
following IEC 61508, stage 3 is following the Common Interaction between the different kinds of requirements
Criteria. Stages 4 to 5 are additional new activities to is examined. Conflicts between safety and security
handle dependencies between safety and security. These requirements need to be resolved. Section 4 introduces a
stages are of great importance since the steps defined conflict resolution policy for this.
here set the base for the second use phase. In the end,
stage 6 deals with the realization of an entity. 3.2.5. Realization of a Safe-Secure Entity
This activity is separated into hardware and software
3.2.1. Definition of the Concept: realization as it is common practice and suggested in
As mentioned in [12], the development phase begins IEC 61508. Very often realization means to enhance a
with definition of the concept that is input to the safe standard automation system with safety-security
dependent and the security dependent part. First of all functionality ([2],[3]). Hardware realization deals with
the purpose and the scope of the automation system in the design of a hardware architecture including standard
general and its entities in particular must be defined. It is components such as a standard network access unit on a
important to know what the BACS is used for, its field of node, and the development of programmable and non-
application. Additionally, it is required to specify the programmable hardware. For example, a node in an
scope: Are there 10000 or only 100 nodes in the automation system uses a two channel architecture
automation system? Are they connected to an intranet or ([3],[13]). Safe-secure software to be integrated into the
even to the Internet? software of an existing automation system is located
above layer 7 (application layer) of the ISO/OSI
3.2.2. Safety Requirements Specification reference model [13]. Examples are PROFIsafe and
The safety dependent part starts with a safety scope SafetyLon, or an approach presented in [1] to secure
definition where the boundaries of the entity in an LonWorks. Such approaches have the advantage that
automation network are determined. Next a hazard and they do not require to change the layers of the standard
risk analysis is performed within the aforementioned protocol stack and allows for interoperability aspects.
boundaries. The hazards can result from failures on the In general, hard- and software realization applies
network such as delay of messages or result from standard mechanism in development. However, the
failures on the entity like memory failures. The hazards requirements on the quality are higher compared to
are identified and the risk coming from the hazards is standard development. E.g., software artifacts have to be
assessed. If the risk is not acceptable, i.e. higher than the tested with a great amount of test cases to reach a high
target safety level, safety functions must be specified to testing coverage.
reduce the risk, e.g., a CRC implemented to detect
stochastic failures. Requirements on such functions are
3.3. Use Phase 3.3.4. Decommissioning
The use phase is concerned with the installation, It is the last stage of the safety-security lifecycle.
commissioning, operation, maintenance and disposal of There are three ways of understanding decommissioning:
the automation system. In opposite to the development The whole system, an entity or a logical communication
phase which is unique for every entity of the system such path between two entities can be decommissioned.
as the node or gateway, in the use phase activities are Similar to maintenance a ordered decommissioning
relating to the whole automation system and must needs to be performed to maintain the safety-security of
consider the overall interaction among all entities the system.
installed in a particular installation. An important fact of the presented parts of the use
phase is that it can only facilitate measures that are
3.3.1. Overall Installation and Commissioning planned and implemented in the development phase. If
In this activity the different entities are integrated into new (safety-security) requirements arise, an appropriate
the automation system. Therefore, the safe-secure return to the development phase is required in order to
entities must be identified clearly in order to transfer the solve the conflict.
communication parameters to the designated nodes. The
parameters like timing values are used to handle the 4. Conflict Resolution Approach
safe-secure communication. Cryptographic keys applied
to perform cryptographic operations like calculating a Integrating safety and security causes more or less
MAC must be distributed to the various entities. interaction in every stage of the life cycle – both
coincident goals and conflicts. Identity (coincident)
3.3.2. Overall Safety-Security Validation means that safety and security strive for the same with
In the field of safety (IEC 61508) the summary of equal or different effort. In opposite to identity, conflict
safety requirements is considered to be the specification indicates that safety and security pursue contradicting
of intended use and system requirements. Hence, safety things. Of course, there are also areas where they do not
validation is the process of comparing system behavior interact. These requirements are then considered to be
with the safety requirements specification(s). In the independent.
context of security (IEC 15408), security objectives are a Conflicts or identities between safety and security are
statement of intent. Seen from a more general point of always are result of conflicting or identical requirements
view, safety-security validation is concerned with or conflicting measures due to identical requirements.
investigating if risks have been mitigated properly and Consequently, to figure out and resolve conflicts
the risk mitigation strategy is working. E.g., validation between safety and security requirements, it is necessary
means checking if integrity of the node is ensured to examine interdependencies. That is why an activity
constantly. for conflict resolution is integrated into the development
phase (Figure 2).
3.3.3. Overall Operation, Maintenance and Repair After activity 3 of the development phase safety
Operation covers all activities required to operate the requirements were specified that are part of the security
BACS in a safe-secure way. As a consequence, the environment. Additionally, a set of security requirements
issues like the ones mentioned next should be addressed: is available already considering safety requirements.
how to test that the data transferred during What is still missing at this point is a cross-checking of
commissioning was successfully stored on the both sets of requirements. Are the safety and security
designated entity; how to switch from commissioning to requirements complementary? Do security requirements
operation of the system; how to update cryptographic contradict safety requirements and vice versa? Therefore
keys; and finally how to recover from network failures the conflict resolution approach at the requirement level
due to stochastic or systematic failures, or intentional is applied. The result is a conflict-free set of
attacks. requirements.
Maintenance and repair comprises activities such as Next, the measures implemented to satisfy the
how to gather diagnostic information in order to react to conflict-free requirements are checked. Only these
failures. Another topic is the replacement of a safe- measures are cross-checked that are different although
secure entity, or modification of communication they result from the same requirement, stated once
parameters. Maintenance regarding reconfiguration of an during safety and a second time during security
automation system in general is a very challenging task. requirement specification (Figure 3). After measures
Just think of an airport with ten thousands of nodes. It is assessment has been performed, a threat-hazard and risk
not acceptable to shut down the complete system when a analysis is carried out to verify the correctness of the
node shall be replaced or configuration parameters shall decisions made during conflict resolution and measure
be changed, just because safety and security ought not to assessment. Especially, the conflict resolution policy is
be endangered. Sophisticated management of checked if it delivers the appropriate result with regard
maintenance is a necessity. to the field of application of the automation system.
4.1. Requirement Level measures will prevent the occurrence of the failure, e.g.
Even though safety and security have the same major corrupted messages are filtered, the requirement must be
goals as mentioned in section 2, they reduce risk to the categorized preventive. Finally if the system reacts on
goals because of different reasons. Put succinctly, safety the violation by, e.g., going to a safe state or actively
is concerned with reducing risk to the system itself, correct the value the requirement is of the category
whilst security strives for minimizing risk to information correcting.
and resources referred to as assets resulting from In practical applications detective requirements are a
malicious attacks. Accordingly, it is very likely that 'last resort' to detect faults or attacks that have not been
requirements how to minimize risk differ. Even worse, it or could not have been prevented by measures derived
is almost inevitable that these requirements contradict from preventive and corrective requirements.
each other. Hence, a methodology has to be specified
that presents a clear and concise, and easy to handle way 4.1.3. Perform Conflict Resolution
of conflict resolution. It requires a specification of a Third, the conflict resolution itself is performed. Each
conflict resolution first, a separation of requirements into requirement is evaluated regarding its action item. That
two groups next to perform the conflict resolution itself is, the action and the reaction to a failure or attack is
afterwards. evaluated. The action item is checked against the other
action items of corrective or preventive requirements. If
4.1.1. Conflict Resolution Policy there is no conflict, the requirement is considered to be a
A conflict resolution policy must be specified. It is a final safety-security requirement. Otherwise, the conflict
set of rules that enables the developer to allow for the resolution policy is applied and one of the requirements
particular point of view. The rules specify which is discarded. In the end, a conflict-free set of
requirement has to be preferred in a particular situation. requirements is setup.
A conflict resolution can be unique for the complete
automation system, a subsystem like a node, or even for Table 1 Corrective safety and security
a part of an entity in the system (e.g. the firmware). requirements
Within the paper the policy consists of two rules Failure/incident Safety Security requirement
applicable to a (sub)system: requirement
1. Prefer safety requirements to security requirements
Hardware failure Fail-safe state Fail-secure state of
if security has a negative impact on safety (see also
of node single microcontroller
section 4.1.3).
Integrity failure Discard Discard message; after
2. Otherwise, use security
message 5 successive incidents
Yet very simple, this policy reflects today’s best
send message to
practice and (legal) requirements for general (building)
network management
control applications.
device to signal attack.
Message lost Fail-safe state none
4.1.2. Categorization of Requirements
of consumer
The requirements are categorized into three groups: a
Disclosure of key none Stop communication
list of detective, and a list of preventive as well as
until new key available
corrective requirements. Detective requirements aim at
only detecting faults and attacks, e.g. ‘Integrity of
system data is detected’. Preventive requirements have The following example is given to get an idea of the
the goal to prevent faults or attacks. In the safety domain conflict resolution process. Table 1 shows four
such requirements are specified to avoid faults (fault corrective safety and security requirements, respectively.
avoidance). Finally, corrective requirements additionally The first failure is a ‘Hardware failure’. For instance, the
specify the corresponding response to a fault or an online volatile memory test revealed a fault in a sector of
attack. Preventive and especially corrective requirements the RAM resulting in a failure of the first safety chip.
may influence processes or systems and are therefore From the safety point of view it is required that the
subject to investigation in the conflict resolution safety chip switches to fail-safe state immediately. Since
approach. Detective requirements must not influence the both chips absolutely must agree on every task that
system and therefore require no conflict resolution. should be executed (two channel architecture), fail-safe
The particular consequences of a requirement state of one results in fail-safe state of the complete
determine its characterization as can be seen from the node. Security requirement says that the first chip has to
following industrial control example. A security as well go to fail-secure state and the second one takes over. The
as safety requirement is to check the message regarding conflict is solved according to the given policy (section
data integrity. If the system only provides reporting the 4.1.1) by taking the safety and discarding the security
violation to a monitoring station and do not influence the requirement, since security has a negative impact on
process the requirement is detective. In case the taken safety.
 The second failure ‘Integrity failure’ results in similar recalculated without the knowledge of the appropriate
safety and security requirements. Such a failure is key. According to the node address and only in case of a
detected due to CRC or MAC mismatches. Here, the verified message CRC or MAC, data can be read or
safety requirement is included in the security written.
requirement, since the MAC cryptographically protects To gain a synergy, a proper solution is to replace the
the integrity (stronger measure) . As security does not CRC by the MAC since the security measure also
influence safety in a negative way, the security withstands safety attacks to the integrity of data. If such
requirement is chosen – rule two of the conflict a replacement can take place, it is evaluated by the
resolution approach applies. Failure 3 and incident 4 measure assessment. First, safety integrity must not be
have no cross impact on security and safety, jeopardized, i.e. the same safety integrity level (SIL)
respectively. Consequently, the safety requirement as a must be reached as it was before the replacement of the
reaction to ‘Message lost’ and the security requirement safety measure. In other words, a MAC must be selected
to ‘Disclosure of key’ is determined to be a final safety- that grants the same level of integrity than the non-
security requirement. secure CRC does. Second, according to the evaluation
assurance level (EAL) a minimum strength of function is
4.2. Function Level specified in order that the MAC chosen cannot be
Conflict resolution at the function level or also called defeated. Third, software and hardware environment has
measure assessment is the second part of the conflict to be considered. Using a cryptographic algorithm being
resolution approach. Measures are derived from the implemented in hardware, results in less computational
conflict-free set of safety-security requirements resulting time than calculating the same algorithm in software.
from the first part of the conflict resolution. One of the Furthermore, memory resources of embedded devices
many motivations to design a common approach is to are low compared to PCs and have also to be considered.
benefit from synergies on applying measures. Finally, performance of measures and the impact on field
Consequently, safety and security measures and of application are examined: Generating and verifying a
synergies gained are classified in three groups: (1) such 8 byte MAC on a smartcard takes about 50 ms of time
that directly match (i.e. safety and security measure are whereas the process of calculating a CRC lasts about
equal), (2) such that are unique for safety and security, 300-500 µs. In some applications such as fire alarm
(3) and such that require different efforts [12]. systems the difference in execution time is acceptable,
Measure assessment has to be only performed when but for applications like emergency push buttons with an
safety and security measures are classified to be of required overall reaction time, i.e. time from pressing the
group 3: different measures with different effort are button on Node A and stopping a machine connected to
derived from the same requirement. Just that group of Node B, of less than 150 ms [13] 100ms (50ms for
measures exhibit conflicts regarding e.g., computational message protection and 50ms for message verification)
power, throughput, computation time, memory resources is a none acceptable delay. According to the conflict
or application constraints. Measures of the other groups resolution policy a final decision about the usage of the
are either identical or unique and thus cannot cause measure is taken.
conflicts per definition. The conflict resolution on
function level uses six factors as shown in Figure 4 to 5. Application Synergies
assess the safety and security measure. In the following
an example of a measure assessment is given. A main application focus at the moment is the
In a safe system the requirement ‘Ensure integrity of combination of fire alarm systems and general building
data on a node or data in a message’ is granted by means control. In particular application synergies could be
of a CRC. In a secure system similar measures are used. achieved by a combination of fire system ventilation and
Instead of the CRC a cryptographic message HVAC. On the one hand fire dampers and ventilation
authentication code (MAC) is used that cannot be flaps could be integrated and on the other hand the air
condition can be used to exhaust smoke. A main
Field of Safety integrity level requirement is that the HVAC must be turned off as soon
application (Safety)
as smoke is detected to prevent spreading of smoke and
that the safety system gains full control of the HVAC
Hardware
Measure Performance
system. Security is an enabler for the combined approach
environment
since it allows to distinguish between nodes of the safe
and the secure system. Proper message authentication
Software
Evaluation
assurance level
and integrity protection is required. For the combination
environment
(Security) fire system and HVAC the conflict resolution is rather
simple since on the requirement level the safety
Figure 3 Measure assessment functionality is always dominant compared to the
comfort functionality of HVAC and on the measure
assessment also timing constraints in both applications on Emerging Technologies and Factory Automation,
are also very relaxed. Volume 1, pp. 398-406, 2003.
But synergies can go further: in restricted areas the [2] A. Treytl, T. Sauter, C. Schwaiger. Security Measures in
access control service can be integrated into the system Automation Systems - a Practice-Oriented Approach. In
also setting security demands. E.g., the fire system must Proceedings of 10th IEEE International Conference on
be able to open doors only in escape direction and the Emerging Technologies and Factory Automation, Volume
security measures must be increased in strength to avoid 2, pp. 847-855, 2005
attacks. Also dual use of systems that detect the presence [3] T. Novak, T. Tamandl. Architecture of a Safe Node for a
of persons are thinkable, but it is questionable if they Fieldbus system. In Proceedings of the 5th IEEE
fulfill the requirements for human safety not to lock a International Conference on Industrial Informatics,
person in case of fire. Vol. 1, pp. 101-106, 2007.
[4] M. Naedele. Standardizing industrial IT security - a first
6. Conclusion look at the IEC approach. In Proceedings of Emerging
Technologies and Factory Automation ETFA 2005,
The possibilities to gain synergies by taking a Volume 2, pp. 19-22, 2005.
common approach towards safety and security in [5] U. Baumgarten, C. Eckert. Mobil und trotzdem sicher?.
building automation systems is given in many areas: at it+ti 5/2001, pp. 254-263, Oldenbourg Verlag, 2001.
the non-functional measure level like verification and [6] W.F. Bates. Safety-related system design in power system
validation tools, risk analysis techniques, or testing control and management. In Proceedings of the 4th
techniques. However, it is not well-known that synergies International Conference on Power System Control and
can be gained at the requirement level or at the Management, pp. 15-20, 1996.
functional measure level (e.g. CRC vs. MAC) as [7] International Electrotechnical Commission. IEC 61508 –
presented in the paper. Gaining synergies is possible Functional safety of electric/electronic/programmable
since safety and security strive for some identical goals. electronic safety-related systems. IEC, 1998.
This fact is often honored, yet little effort to combine the [8] D. J. Smith, K. G. L. Simpson. Functional Safety – A
fields is given because applications are thought to be straightforward guide to applying IEC 61508 and related
either safety or security critical. standards, Elsevier Butterworth-Heinemann, Oxford, 2nd
As a consequence, the paper presents a life cycle edition, 2004.
model trying to integrated safety and security in an [9] P. Wratil, M. Kieviet. Sicherheitstechnik für Komponenten
automation system. In particular, a strategy is given how und Systeme. Hüthig Verlag, Heidelberg, 2007.
to resolve conflicts between safety and security. To [10] G. McCraw. Software Security – Building Security In.
address conflicts due to requirements and different Addison-Wesley, Boston, 2006.
implementations of measures a two step conflict [11] International Electrotechnical Commission. IEC 15408 –
resolution framework is presented, resolving conflicts at Information technology – Security technique – Evaluation
the requirement and at the function level. Such a life criteria for IT security. IEC, 2nd edition, 2005.
cycle model and its included conflict resolution are the [12] T. Novak, A. Treytl, P. Palensky. Common Approach to
basis of combining formerly separated networks for Functional Safety and System Security in Building
safety, e.g., fire alarm system, and for security, e.g., Automation and Control Systems. In Proceedings of the
access control, and operation, e.g. heating, ventilation 12th IEEE International Conference on Emerging
and air condition, or lighting and shading. Technologies and Factory Automation, pp. 1141-1148,
Some ideas presented in the paper have already been 2007.
submitted to standardization as a working draft. Since [13] D. Reinert, M. Schaefer (Publisher). Sichere Bussysteme
2007 the topic is treated as a working item in European in der Automation. Hüthig Verlag, Heidelberg, 2001.
Standardization CEN, Technical Committee (TC) 247, [14] A. Burns, J. McDermid, J. Dobson. On the meaning of
Working Group (WG) 4, called “Building Automation, Safety and Security. The Computer Journal, Vol. 35,
Controls and Building Management”. The goal is to No. 1, pp. 3-15, 1992.
create an European and later on international standard [15] W. Stallings. Cryptography and Network Security.
for functional safety and system security in building Prentice Hall, 2003.
automation and control systems. The standard ought to [16] B. Schneier. Secrets and Lies – Digital Security in a
be application independent and a generic standard for Networked World. John Wiley & Sons, Inc., New York,
safety and security in building automation systems. 2000.

References

[1] C. Schwaiger, A. Treytl. Smart Card Based Security for

Fieldbus Systems. In Proceedings of 9th IEEE Conference