IT security of field devices - atpinfo.de · word assignment for several thousand field ... The IEEE 802.3 Ethernet Working Group is ... Bluetooth, NFC, interface for memory cards)

1 atp edition12 / 2017

HAUPTBEITRAG

The IT security of production plants is a challenge for manufacturers, integrators and plant owners. Cyber-attacks with malware like WannaCry, Havex, Black-Energy not only target office IT, but also increasingly threaten production plants, energy distribution networks and other infrastructure. In the context of Industry 4.0, exis-ting IT security protection measures, like the separation of the production systems, are no longer sufficient. The article considers what the future contribution of field devices in highly connected production plants will be.

KEYWORDS IT security / cyber security / production / transmitter / field device / Industry 4.0 / IOT / IIOT / threat analysis

IT security of field devicesContributions to the IT security of production plant networks

2atp edition12 / 2017

The IT security of production facilities is rap-idly becoming more important in light of growing threats. The following paper deals with field devices used primarily in the pro-cess industry. The basic concepts, however,

apply to other areas of application as well. In order to ensure comprehensive protection of production facilities against cyber attacks, industry standards are under development. The German Federal Office for Information Security (BSI) recently presented a Community Draft for the basic protection of sensors [1]. Comprehensive IT security is based on the combi-nation of various organizational and technical meas-ures and focusses on networks, servers, computers and control systems. Little to no consideration is given to field devices due to their presumed lower level of relevance. Systems designed for Industry 4.0 will change this because both the degree of networking in the field and the flow of data from the field will increase. This means equipment like field devices will be connected to the automation network via Industrial Ethernet protocols more frequently in the future. This paper addresses the required changes to be applied to current and traditional field devices and, from them, derives future IT security requirements for use in an Industry 4.0 environment.

1. OPERATING CONDITIONS FOR THE FIELD DEVICES OF TODAY AND TOMORROW

A field device (transmitter) is defined in [2] as a “device that uses a specified relationship to convert the meas-ured variable or a relationship already derived from this value into an electrical value with a defined level of precision.” While analog signal transmission has been the standard in the past, today an increasing number of field devices is on the market that process the sensor signals digitally and submit the measurement and diag-nostics data in digital format. Today’s smart field devic-es offer additional functions such as signal monitoring for alarm limits, alarm generation, self-monitoring, and reporting of errors or deviations, etc.

The operating conditions of field devices in the pro-cess industry, on the other hand, have only changed slightly over the past few decades:

■ Usage for a period of 10 to 20 years. ■ Power supply of the devices via the 4 to 20 mA signal line with/without HART (2 or 4-line trans-mitter) or the fieldbus cable (e.g. PROFIBUS PA or Foundation Fieldbus H1).

■ Optimization for low power consumption, especial-ly in areas subject to explosion hazards.

■ Use for applications with functional safety (SIL).Developments in the context of Industry 4.0 are already having tangible effects on field devices. The devices become “smart”, i.e. their intrinsic intelli-gence is increased. The devices do not just commu-nicate over the analog interface; to an increasing extent, they also use Bluetooth, WirelessHART, WiFi or wired Ethernet. Field devices are also expected to be equipped with an administrative shell [3] in accordance with the Reference Architecture Model for Industry 4.0 [4]. Functions on levels above pro-cess control can use this to access field device data via protocols such as OPC UA [5] [6] or MQTT [8], e.g. for asset management and energy management. The field device becomes a cyber physical system (CPS) [7]. The following sections describe the evolution of the traditional field device into a CPS and the related effects on IT security.

1.1 Traditional operating conditionsFigure 1 shows the traditional system architecture in accordance with the automation pyramid with sensors and actuators at the field level.

The field devices communicate via a 4 to 20 mA interface using the HART protocol. They are often connected via the remote I/O modules of the automa-tion system or, alternatively, via a sensor/actuator bus, such as PROFIBUS PA. Figure 2 shows a hypothetical traditional transmitter with its interfaces.

It is assumed that the field device has four interfaces.

KARL-HEINZ NIEMANN, Hochschule Hannover MARKUS HOH, Endress+Hauser Flowtec


HAUPTBEITRAG

1 | Local display with operation elements (e.g. buttons) for device configuration.

2 | DIP switches inside of the housing to con-figure basic functions or specific functions such as fieldbus addressing.

3 | Service interface for activities such as firm-ware update (flashing).

4 | Current output 4 to 20 mA using the HART protocol.

If you now consider the threats that affect this kind of device from the standpoint of IT security, you get the results shown in Table 1. Basic threats like water, fire and mechanical damage are not considered here.

Table 1 shows that even a simple, traditional device is subject to certain threats. It should be noted that the HART protocol was created a few decades ago when IT security was practically irrelevant. The measures derived in Table 1 are predominantly of organizational nature. However, additional meas-ures are required to achieve a good protection, such as access protection or increased robustness of the HART implementation. Let us look at the password assignment as an example: The password assignment can be enforced by the operator (procedural instruc-tion) or by the manufacturer of the device (forcing a password change upon initial start-up). Usually, users prefer to change the password at their own discretion, since it is not very practical to require custom pass-word assignment for several thousand field devices. One conceivable solution is to assign passwords for groups of devices or even for areas of the production plant. It is important that a new password be set after

commissioning. Additionally, device protection can be achieved by robust implementation of the software that cannot be negatively affected by malformed data packets or an overload of the HART interface. A major challenge here is presented by the fact that certain limits, such as power consumption, exist for tradi-tional field devices.

The situation with respect to traditional field devic-es can be summarized as follows:

■ Traditional field devices can be attacked in differ-ent ways.

■ Using the automation network, they can only be reached through the following path: Controller -> Fieldbus -> Remote I/O or through direct access to the device or the IO wiring.

■ The communication via HART, the fieldbus and the system bus is not secure.

■ Protection measures can be taken primarily through access regulations (access to the configuration tool, access to the wiring cabinets) and procedural regu-lations (setting passwords) and minimum require-ments for robustness.In terms of IT security, this means that basic attack

methods (local display) should be handled by organi-zational measures. A more complex attack (importing falsified HART commands) requires corresponding equipment and direct access to the device or IO chan-nel. An attack from a higher level (e.g. the automation network) may take a lot of effort but it is possible (e.g. by using falsified FDT data packets). The probability of an attack on field devices was rated as “low” by past risk assessments. In the future, however, attacks

1

Technical process

Plant management

Operator console

Controller

field devices

Process

......

......

Controller

Engi- neering

Operator console

Operator console Server

Plant management level

Control level

System bus

Controller

Bus coupler

PROFIBUS DP

......

PROFIBUS PA

...

Remote I/O

Remote I/O

Corporate network

FIGURE 1: Traditional operating environment of field devices


involving more targeted methods are expected on the presumably “simple” devices (the weakest link). Protection against these attacks must extend beyond organizational measures and include technical means as well.

The considerations of this section apply as well to actuators such as valve positioners.

1.2 Changes to the system structure for Industry 4.0The following section addresses the impact of Indus-try 4.0 on the system structure of automation systems. In [9], Kagermann et al. define essential concepts and ideas of Industry 4.0. General approaches include, but are not limited to, horizontal and vertical inte-gration and the ubiquitous networking of all system components. For the field devices addressed here, this has the following implications: The devices will no longer return just measured values, but also status information, operating data, event data, etc. This will generate an additional communication flow (admin-istrative shell) in parallel to transfer of the measured values. An example of this is described by NAMUR in the concept of the “NAMUR Open Architecture” [10] [11]. The device also needs to have a unique iden-tity. Essential requirements for products, ready for Industry 4.0, are described in [12]. Figure 3 shows a system architecture that considers the requirements of Industry 4.0. This image shows a simplification of the situation in which field devices can be connected to an automation backbone to which many other auto-mation components are also connected. Measures for segmentation of the network for availability reasons or

IT security reasons (e.g. zones and conduits in accord-ance with IEC 62443) are possible, but not addressed here. The structure discussed here can be seen as a worst-case scenario with respect to IT security.

One important change is the flat or networked sys-tem architecture implemented through communica-tion interfaces such as Ethernet. Since all components and field devices are connected directly to Industrial Ethernet, direct access and thus data flow is enabled for all components of the system without a hierarchy or intermediate stations such as remote I/O. In [13] the suitability of an Ethernet connection for real-time requirements in the field area is described. In [14], Hähniche and Kessler describe an innovative “Advanced Physical Layer (APL)” as the basis for using the Ethernet protocol for the field level with the fol-lowing properties:

■ Two-wire connection for supply and communication ■ Trunk length of 1000 m, spur length of 200 m ■ Use in areas with explosion hazards (Zone 1 and Zone 2) permitted

■ Up to 50 field devices with 500 mW power con-sumption per trunk

The IEEE 802.3 Ethernet Working Group is already working on standardizing „10 Mbps Single Twist-ed Pair Ethernet,“ which is intended to have the aforementioned properties [15]. If this type of APL is available, even simple field devices can be integrated directly in these automation networks and, as such, measurement and diagnostics data can be provided for both control system as well as new IoT applications such as monitoring and maintenance optimization (e.g. big data).

1

1. DIP switches

2.  Display/buttons

User Network/ communication

Field device

3. Service interface

4. Measured value for 4 to 20 mA + HART

BILD 2: Traditional field device with interfaces


HAUPTBEITRAG

1.3 Future operating conditionsIn addition to integration into the automation network, it is conceivable that field devices will be equipped with additional interfaces (WiFi, Bluetooth, NFC, interface for memory cards) in the future, to ensure comprehensive usage of the devices and process data for IoT applications. In doing so, field devices will provide multiple communication connections, oper-ated in parallel if necessary, and multiple services in parallel. In addition to communicating process data, this makes it possible to provide additional servic-es such as energy management, asset management, remote storage or data evaluation through big data applications [16].

From the perspective of IT security, these outlined changes put field devices on the network at the same level as controllers, PCs, servers and other automa-tion components. But this also exposes them to the same threats.

1.4 Conclusions in regards to the operating condi-tions in the IoT environment

The statements so far can be summed up as follows: ■ The availability of Industrial Ethernet in field devic-es will increase in the future. This also applies to two-wire devices supplied with power in an Ex zone.

■ Field devices are no longer placed as a sub sys-tem below the remote I/O systems and controllers, instead they are connected directly to the automa-tion network.

■ In addition to communicating pure process data to the automation system, field devices now com-municate data for other services and applications at higher levels using the “administrative shell”.

■ Additional interfaces and protocols that also offer wireless support are used for the new communi-cation needs.

We can draw the following conclusions about the IT security of such future field devices:

TABLE 1: IT security threats for traditional field devices

Interface Threat Effect of an attack Measure

1. Local display with push buttons

Unauthorized access to the device is possible because the password is not set, only the default password is set or the master password is known.

Tampering with the device configuration. Device returns incorrect measured values. Device cannot be operated.

Regulate access to the pro-duction plant/device. Assign a custom password. Only use devices without fixed master passwords. Fixed master passwords are permanent passwords built in by the manufacturer that cannot be changed by the user.

2. DIP switches Unauthorized changes to the switch settings.

Device cannot be operated. The device does not return any measured values.

Regulate access to the production plant/device. Seal the device in order to detect unauthorized opening.

3. Service interface Unauthorized access to the service interface. Installation of compromised software. Change of device configura-tion.

Tampering with the device configuration. Device returns incorrect measured values. Device cannot be operated.

Protect the service interface with a password. Assign an individual password. Only use devices without secret master passwords.

4. Current output of 4 to 20 mA + HART

Unauthorized transmission of HART commands to the field device. Flooding the HART interface with invalid queries. Intentional flooding of device with malformed data packets.

Overload of communication interfaces. Device cannot be operated.

Regulate access to the HART configuration tool. Regulate access to the production plant. Increase robustness of the HART interface against denial-of-service attack. Increase robustness against malformed data packets.


■ Field devices are directly accessible from the auto-mation network (even for potential attackers).

■ The addition of wireless interfaces allows further communication possibilities with higher-level applications and systems in addition to the wired communication.

■ Now it is possible to communicate with additional nodes across production areas (IoT applications), even outside the company if applicable, such as remote access for maintenance purposes.

2. THREAT ANALYSIS OF A FIELD DEVICE UNDER FUTURE OPERATING CONDITIONS

Chapter 1 demonstrated the change in technology and operating conditions for field devices. It showed how future communication architectures will change. In order to estimate risks and to determine the necessary measures, a sample threat analysis for a fictitious Industry 4.0-compliant field device is carried out in this section. A description of the object under exam-ination is followed by a description of the procedure and then the actual analysis.

2.1 Object under examinationA fictitious field device that meets the future require-ments for Industry 4.0-compliant products provides the basis for this threat analysis.

Figure 4 shows an Industry 4.0-compliant field device with its interfaces as the object under exam-ination. The interfaces, 1 (DIP switches), 2 (display/button) and 3 (service interface), were examined back in Chapter 1.1 and are displayed in grey for this rea-son. In addition to interfaces 1, 2 and 3, additional interfaces are shown.

4 | The 4 to 20 mA current output with HART protocol shown as number 4 in FIGURE 2 is replaced by an Ethernet interface with Advanced Physical Layer (APL). This is a wired Ethernet interface. Other services in addition to real-time communication of meas-ured values are provided via this interface. This means, for example, that the administra-tive shell can be implemented by an OPC-UA server communicating over the interface, or a web server can be used for configuration and diagnostics, etc.

5 | In addition to the wired connection, the device can feature wireless communication. This can be used for purposes such as diag-nostics or, alternatively, for real-time data [17].

6 | Interface for portable data storage. Over this interface, configuration data, as well as pro-tocol data, can be stored for simple device replacement.

It is worth noting that, compared to the traditional field device in Figure 2, the device in Figure 4 has a

3

Technical process

Operatorconsole

......

Engi-neering

Operatorconsole

Operatorconsole Server...

Control room

Field

Controller Controller

Industrial Ethernet

FIGURE 3: Potential future system architecture in the process industry


HAUPTBEITRAG

series of additional interfaces that could be used as a potential gateway for attacks.

2.2. Procedure for risk/threat analysisThe threat analysis described here focuses on the field device and its interfaces. Please note: The connection of multiple components to form a system leads to addi-tional threats that are not covered here. The procedure for the threat analysis follows VDI/VDE 2182 part 1 [18]. The procedure for the analysis is described in this guideline as follows: Identify the assets, Analyze the threats, Establish relevant protection goals, Analyze and evaluate risks, Record protective measures and evaluate effectiveness. The DIN IEC 62443-3-3 [19] and DIN EN 62443-4-2 [20] standards offer further important reference for implementing the analysis and planning of measures. These standards define several aspects, including the foundational requirements (FR) for components of automation systems. In terms of the analysis, this also makes it possible to examine the extent to which the FRs are met after implementation of the protective measures.

It is also possible to apply the recommendations of official agencies such as the German Federal Office for Information Security (BSI) [21] [22] [23]. Presently, the BSI is adding sections for automation components [24] and field devices (“sensors”) [25] to its basic pro-tection catalog.

As part of the described procedure, all interfac-es of the device are analyzed by using the STRIDE approach. STRIDE is an abbreviation consisting of

the threat types spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privilege. A description of the procedure during a threat analysis can be found in [26].

As part of the analysis, all interfaces and associated services are described and possible attack scenari-os on those services are documented. Afterwards, the risk is determined from the severity of the threat and the probability of occurrence. Risk minimization measures, if necessary, are defined depending on the risks. Note that a risk analysis always represents a snapshot. Even after just a short time, the threat situ-ation can change or components may be added to the production plant. Therefore, this sort of risk analysis needs to be repeated on a regular basis or upon new findings. It is important to be diligent and to follow defined processes while doing so in order to achieve the highest possible quality.

2.3 Results of the threat analysisAn excerpt of the threat analysis is shown as an exam-ple below in Table 2. The excerpt on display covers a web server for a fictitious field device and represents only a specific selection of weak spots in order to better illustrate the process and the corresponding protective measures.

In addition to the examined web server, all of the interfaces shown in Figure 4 and the assigned services have to be checked in the following steps. In addition to measures implemented by the manufacturer of the field device, there are also protective measures that

1

1. DIP switches 4. Ethernet/APL

6. Portable data storage

2.  Display/button

3.1 Process data via Ethernet protocol + acyclic communication

3.2 Web server using HTML protocol 3.3 IoT Protocols such as OPC UA or

MQTT, etc. 3.4 Other services

5.  Wireless communication (WLAN, Bluetooth, NFC)

User Network/ communication

3. Service interface Field

device

FIGURE 4: Industry 4.0-compliant field device with interfaces


have to be provided by the plant operators and the integrators.

The threat analysis conducted here as an example provides three catgories of measures:

■ Category 1: Measures that the plant operator or inte-grator have to implement. As an example here, con-sider a standard operation procedure ensuring that default passwords are changed to device-specific or area-specific ones. Of course, the feature to change a password has to be integrated by the manufacturer up front, meaning that these types of criteria need to be considered during the procurement phase.

■ Category 2: Measures that the device manufacturer has to provide. The ability to replace a master pass-word with individual passwords is an example of this.

■ Category 3: Measures that require a company neu-tral standard. An example for this is the use of cryptographic measures in order to protect the communication.

Even today, protecting a field device requires meas-ures at different points and from various stakeholders. Always note that future field devices with the latest functionality can only be operated securely by means of careful risk analysis and targeted implementation of measures. In the future, it could even be possible to use technologies such as Ethernet or wireless itself in order to implement more effective and efficient measures than today on the basis of technologies like HART. This inherently requires adjustments in today’s technologies, processes and organizations on the part of manufacturers, integrators and operators.

3. REQUIREMENTS FOR A FIELD DEVICE UNDER FUTURE OPERATING CONDITIONS

It has to be considered that there are areas where the standardization of security functions is not yet con-cluded. Examples include the IEC 62443, where parts are not yet released or approved. Bluetooth encryp-tion or a specification regarding the integrity and authentication of Ethernet protocols in a real-time environment are further examples. As an example, the commonly used real-time protocols do not offer any protection against tampering with measured values by a man-in-the-middle attack. On a short time scale, this type of attack can be mitigated only by organizational measures (regulating access to wiring cabinets, regu-lating access to distribution cabinets). The real-time protocols in use must be secured in the long run using cryptographic functions as described, for example, in [27] [28]. The security layer described in both sources meets the real-time requirements for an Industrial Ethernet system. The authenticity and integrity of the communication is secured through a cryptographic checksum in the data packets. At the same time the devices identify themselves through certificates which are provided in a public key infrastructure.

Multiple organizations, such as VDI working com-mittee FA 5.22, work on recommendations for imple-menting these requirements. In addition to that there are several guidelines and activities where manu-facturers or plant operators are currently defining requirements. An example from the process industry: NAMUR defines the requirements for components and systems of automation technology in its recom-mendation NE 153 „Automation Security 2020“ [29] in accordance with the following scheme:

■ Secure by default ■ Secure by design ■ Secure by implementation ■ Secure by deployment

As known from many other standards, this is anoth-er area where the mentioned requirements not only affect manufacturers, integrators and operators, but everyone involved in the process. Comprehensive adherence to all process-related, organizational and technological requirements along the value creation chain is required to establish a secure production system.

CONCLUSIONEven today, the traditionally installed basic field devices can theoretically be attacked from an IT standpoint. In the future, however, the “protected status” of the devices behind controllers and behind remote I/Os, as well as good accessibility of other potential attack targets at the level of the higher sys-tem, will not be enough to prevent an attack on field devices via the automation network. The risk of an attack on field devices via the network may be consid-ered relatively low for the time being, but the number of weak points in the system will increase with time.

Future changes, induced by the introduction of Industry 4.0, will cause additional threats. The rea-sons for this include, in addition to the direct connec-tion of the field devices to the automation network, additional interfaces and services providing the abil-ity to meet the requirements of Industry 4.0.

Future devices must be subjected to threat analyses during their development and, to a certain extent, dur-ing the life cycle in order to draw conclusions about device weak points. These measures, in combination with system-related and organizational measures, will then enable secure operation in the world of Industry 4.0 and its promising applications.

MANUSKRIPTEINGANG15.09.2017Im Peer-Review-Verfahren begutachtet


HAUPTBEITRAGId

enti

fier

Ass

et

Thre

at

Cau

se

Exam

ple

Wea

k po

int

Dir

ect c

onse

quen

ces

3. Ethernet interface

3.1 Web server using HTTP

3.1.1. Web server using HTTP

Unauthorized access to the device via the web server. Access using a predefined and unchanged default password.

Remote attacker

Access using the web interface with a default password that has not been changed

Default password without mandatory change

Changed configuration of the device, return of incorrect measured values

3.1.2 Web server using HTTP

Unauthorized access to the device with custo-mer password set

Remote attacker

Access using the web interface with a “password cracker” for guessing the cus-tomer password

Missing protection against repeated entry of incorrect passwords



Unauthorized access to the device by inter-cepting the password sequence

Remote attacker

Replay attack with intercepted pass-word sequence

Recording communica-tion. Weak point in case of weak passwords



Elevation of privileges due to unauthorized activation of the service or production rights

Remote attacker

Unauthorized usage of service or pro-duction rights

Fixed master pass-word to access service and production func-tions



Resetting the field device

Remote attacker

Using the reset function through the web server

Access to the device Password is reset to factory setting. This means free access to all parameter functions.


Overloading the device through a denial-of-ser-vice attack or malfor-med data packets

Remote attacker

Sending a flood of packets to the device, sending malformed data pa-ckets to the device

Lack of robustness of the web server software against over-loading and therefore compromised measu-ring function

The device no longer returns measured valu-es due to overload


Overload of the device due to the parallel esta-blishment of numerous connections to the device

Remote attacker

Connecting multiple browser sessions in parallel to one device

Uncontrolled establish-ment of connections

The device no longer returns measured valu-es due to high resource consumption

TABLE 2: Result of the threat analysis for a web server of a field device


Pro

tect

ion

obje

ctiv

es

Sev

erit

y

Prob

abili

ty o

f occ

ur-

renc

e in

the

sens

e of

a

“hur

dle”

for

atta

cker

s

Ris

k

Acc

epte

d ri

sk

Red

ucti

on r

equi

red

Pro

tect

ive

mea

sure

Cos

t of t

he m

easu

re

Availability, integrity

3 3 9 6 required Forcing a change to the default password or prompting a password change in the documentation

low


3 3 9 6 required Limit the maximum number of incorrect password entries

medium


3 1 3 6 not required but recom-mended

Challenge response mechanism, possibly in combination with enc-ryption of the password sequence

high


3 1 3 6 required No fixed master passwords for service or production

low


3 3 9 6 required Changed reset behavior with protec-tion against unauthorized resetting

high

Availability 3 3 9 6 required Verification of a minimum robust-ness against overload. Stress test with malformed data packets. Definition of limit values. Automatic restart after discontinuation of over-load situation. Add test scenarios to release test of the manufacturer

medium

Availability 3 3 9 6 required Limit number of connections. Automatic restart after loss of load. Add test scenario to release test of manufacturer

low


HAUPTBEITRAG

REFERENCES[1] German Federal Office for Information Security: IND:

Industrielle IT IND.2.3. Sensoren (IND: Industrial IT IND.2.3. Sensors) - Community Draft. https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/IT-Grundschutz-Modernisierung/BS_ICS_Sensoren.pdf?__blob=publicationFile&v=3.

[2] No author, IEV Wörterbuch der DKE (IEV Dictionary of the DKE). https://www2.dke.de/de/Online-Service/DKE-IEV/Seiten/IEV-Woerterbuch.aspx.

[3] ZVEI – Zentralverband Elektrotechnik- und Elektronik-industrie (German Electrical and Electronic Industry), Beispiele zur Verwaltungsschale der Industrie 4.0-Komponente – Basisteil: Fortentwicklung des Referenzmodells für die Industrie 4.0-Komponente (Examples of the administrative shell for Industry 4.0 components – Base part: Further development of the reference model for Industry 4.0 components). https://www.zvei.org/fileadmin/user_upload/Presse_und_Medien/Publikationen/2016/November/Beispiele_zur_Verwaltungsschale_der_Industrie_4.0-Komponente_-_Basisteil/Beispiele-Verwaltungsschale- Industrie-40- Komponente-White-Paper-Final.pdf.

[4] Reference Architecture Model for Industry 4.0 (RAMI4.0), DIN SPEC 91345, 2016.

[5] OPC Foundation, OPC unified architecture: Interoperabilität für Industrie 4.0 und das Internet der Dinge (Interoperability for Industry 4.0 and the Internet of Things). https://opcfoundation.org/wp-content/uploads/2016/05/OPC-UA-Interoperability-For-Industrie4-and-IoT-DE-v5.pdf.

[6] J. Lange, F. Iwanitz, and T. J. Burke, OPC: Von Data Access bis Unified Architecture (From Data Access to Unified Architecture), 4th ed. Berlin, Germany: VDE-Verl, 2013.

[7] VDI/VDE Association for Measurement and Automation Technology, Industrie 4.0 CPS-basierte Automation: Forschungsbedarf anhand konkreter Fallbeispiele (Industry 4.0 CPS-based Automation: Need for research based on concrete case examples). http://www.vdi.de/fileadmin/vdi_de/redakteur_dateien/gma_dateien/Statusreport_07-2014_Industrie_4.0_CPS-basierte_Automation_Forschungsbedarf_anhand_Fallbespiele.pdf.

[8] OASIS Open, MQTT Specification Version 3.1.1. http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.pdf.

[9] Kagermann, Henning et al., Umsetzungsempfehlungen für das Zukunftsprojekt Industrie 4.0: Abschlussbericht des Arbeitskreises Industrie 4.0 (Implementation Recommendations for the Future Industry 4.0 Project: Final Report for the Industry 4.0 Working Group). https://www.bmbf.de/files/Umsetzungsempfehlungen_Industrie4_0.pdf.

[10] C. Diedrich et al., “NOA – NAMUR Open Architecture,” in 79th NAMUR Main Meeting – Solution for optimization in the glo b al process industry), Bad Neuenahr, 2016, no page count.

[11] T. Tauchnitz and C. Klettener, “NOA - NAMUR Open Archi tecture,” in 79th NAMUR Main Meeting - Solution for optimization in the global process industry), Bad Neuenahr, 2016, no page count.

[12] ZVEI – Zentralverband Elektrotechnik und Elektronikindustrie e. V. (German Electrical and Electronic Industry), Welche Kriterien müssen Industrie-4.0-Produkte erfüllen? (What criteria do Industry 4.0 products have to fulfill?) Guideline. http://www.zvei.org/Publikationen/Welche-Kriterien-muessen-Industrie-4.0-Produkte-erfuellen-Leitfaden.pdf.

[13] J. Jasperneite and M. Schumacher, Echtzeit-Ethernet für die Sensor-/Aktorvernetzung: Schlussbericht für das Forschungsprojekt ESANA (Real-time Ethernet for sensor/actuator networking: Final report for the ESANA research project). http://www.hs-owl.de/init/uploads/tx_initdb/esana_f.pdf.

[14] J. Hähniche and M. Kessler, “Neuer Standard für Ethernet im Feld der Prozessanlage: IEEE 802.3-10SPE (New Standard for Ethernet in the field for the process plant: IEEE 802.3-10SPE),” in VDI Reports, vol. 2293, Automation 2017: Technology networks processes: 18th Leading congress for measurement and automation technology: The Kongresshaus Baden-Baden, June 27 and 28, 2017, Düsseldorf, Germany: VDI Verlag GmbH, 2017.

[15] IEEE 802.3 Ethernet Working Group, 10Mb/s Single Twisted Pair Ethernet Call for Interest. http://www.ieee802.org/3/cfi/0716_1/CFI_01_0716.pdf.

[16] Heinze S. et. al, “Big Data in der Prozessindustrie: Frühzeitige Erkennung und Entscheidungsunterstützung (Big data in the process industry: Early detection and decision-making support),” in VDI Reports, vol. 2293, Automation 2017: Technology networks processes: 18th Leading congress for measurement and automation technology: The Kongresshaus Baden-Baden, June 27 and 28, 2017, Düsseldorf, Germany: VDI Verlag GmbH, 2017, no page count.

[17] T. Stein, J. Kiesbauer, J. Fuchs, and U. Konigowski, “Bluetooth als Übertragungsprotokoll für Prozessregelungen (Bluetooth as a transfer protocol for process regulations),” in VDI Reports, vol. 2293, Automation 2017: Technology networks processes: 18th Leading congress for measurement and automation technology: The Kongresshaus Baden-Baden, June 27 and 28, 2017, Düsseldorf, Germany: VDI Verlag GmbH, 2017, no page count.

[18] Informationssicherheit in der industriellen Automatisierung - Allgemeines Vorgehensmodell (IT security for industrial automation - General model), VDI/VDE 2182 Part 1, 2011.

[19] Industrial communication networks - Network and system security - Part 3-3: System security requirements and security levels (IEC 62443-3-3:2013 + Cor.:2014) Draft, DIN IEC 62443-3-3 (VDE 0802-3-3), 2015.

[20] Industrial communication networks – Security for industrial automation and control systems – Part 4-2: Technical security requirements for IACS components (IEC 65/663/CDV:2017); German version prEN 62443-4-2:2017, DIN EN 62443-4-2:2017-10; VDE 0802-4-2:2017-10 - Draft, 2017.


MARKUS HOH (born 1971) is wor-king in Product Management at Endress+Hauser Flowtec AG, a company of the Endress+Hauser Group and a leading supplier of industrial process technology and automation, since 2007. He is spe-cialised as a Product Manager for human machine interface design, usability and Industrial IT secu-rity. After completing engineering

degrees in Cologne and Basel and before working for Endress+Hauser, he gained experience in software engi-neering as well as project and technology management.

Endress+Hauser Flowtec AG,Kägenstrasse 7,4153 Reinach,Switzerland,Phone +41 (0) 61 715 70 67,E-Mail: [email protected]

Prof. Dr.-Ing. KARL-HEINZ NIE-MANN (born 1959) is working in the area of Industrial IT and Automation Technology at the University of Applied Sciences and Arts in Hannover since 2005. From 2002 to 2005 he worked in the area real-time data proces-sing at the University of Applied Sciences of Northeastern Lower Saxony (today Leuphana Uni-

versity). Before that, he held management positions in process control system development, including positions at ABB, Elsag Bailey and Hartmann & Braun.

Hochschule Hannover, Fakultät I – Elektro- und Informationstechnik, Postfach 92 02 61, 30441 Hannover, Phone +49 (0) 511 92 96 12 64,E-Mail: [email protected]

AUTHORS

[21] German Federal Office for Information Security, Anforderungen an netzwerkfähige Industriekomponenten (Requirements for network-ready industrial components). https://www.bsi.bund.de/ACS/DE/_downloads/techniker/hardware/BSI-CS_067.pdf;jsessionid=320A5E59D3035F5560291B16C049C738.2_cid286?__blob=publicationFile.

[22] German Federal Office for Information Security, ICS-Security-Kompendium: Testempfehlungen und Anforderungen für Hersteller von Komponenten (ICS Security Compendium: Test recommendations and requirements for manufacturers of components). Last updated 2014-11-19. https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/ICS/ICS-Security-Kompendium-Hersteller.pdf;jsessionid=DB019AA1A22E666BE17192033909CB6D.2_cid359?__blob=publicationFile.

[23] Bundesamt für Sicherheit in der Informationstechnik, Fernwartung im industriellen Umfeld (German Federal Office for Information Security, Remote maintenance in the industrial environment). https://www.allianz-fuer-cybersicherheit.de/ACS/DE/_/downloads/BSI-CS_108.pdf?__blob=publicationFile&v=3.

[24] German Federal Office for Information Security (BSI), BSI Grundschutz: IND.2.1: Allgemeine ICS Komponente: Community Draft (Basic BSI protection: IND.2.1: General ICS components: Community Draft). https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/IT-Grundschutz-

Modernisierung/BS_ICS_Komponente.pdf?__blob=publicationFile&v=2.

[25] German Federal Office for Information Security (BSI), BSI Grundschutz – IND.2.3 Sensoren: Community Draft (Basic BSI protection – IND.2.3. Sensors: Community Draft). https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/IT-Grundschutz-Modernisierung/BS_ICS_Sensoren.pdf?__blob=publicationFile&v=3.

[26] A. Shostack, Threat modeling: Designing for security. Indianapolis, in: Wiley, 2014.

[27] Runde, Markus, Tebbe, Christopher, Niemann, Karl-Heinz, Börgmann, Arne, “IT-Security in Automatisierungsnetzwerken unter Verwendung kryptografischer Maßnahmen (IT security in automation networks using cryptographic measures),” in Kommunikation in der Automation: 2012-11-14; 3. Jahreskolloquium Kommunikation in der Automation, J. Jasperneite and U. Jumar, Eds., Lemgo, 2012, pp. 156–165.

[28] M. Runde et al., SEC_PRO – Sichere Produktion mit verteilten Automatisierungssystemen: Schlussbericht für das FHprofUnt-Forschungsprojekt mit dem FKZ 1760A10 sowie 17060B10 (Secure production with distributed automation systems: Final report for the FHprofUnt research project with the FKZ 1760A10 and the 17060B10). http://nbn-resolving.de/urn:nbn:de:bsz:960-opus4-4995.

[29] Automation Security 2020 – Design, Implementierung und Betrieb industrieller Automatisierungssysteme (Automation Security 2020 – Design, implementation and operation of industrial automation systems), NE 153, 2015.

mailto:[email protected]

Documents

IT security of field devices - atpinfo.de · word assignment for several thousand field ... The IEEE 802.3 Ethernet Working Group is ... Bluetooth, NFC, interface for memory cards)