Industrie 4.0 und die Sicherheit

Transkript

1 Trend Micro WhitePaper Industrie 4.0 und die Sicherheit Ist der Zug bereits abgefahren? Autor: Udo Schneider, Security Evangelist bei Trend Micro

2 Inhalt Einleitung Sicherheit: Safety, Security, Verfügbarkeit Risikobewertung Risikobewertung: Safety Risikobewertung: Security Risikobewertung: Safety + Security = Industrie Risikobewertung: Kombinierte Bewertung Risikominderung Der Heilige Gral: Security by Design Nutzung von Standard IT-Security-Komponenten Nutzung von angepassten IT-Security-Komponten Zusammenfassung

3 Einleitung In letzter Zeit beherrscht kaum ein anderes Thema so konsequent die Medien wie Industrie 4.0, und das gilt sowohl für die Industrie- als auch die IT-Presse. Der Einsatz von Industrie 4.0-Konzepten verspricht immense Vorteile durch die Integration und Automatisierung über Prozessgrenzen hinweg. Doch im Rahmen solcher Konzepte werden immer häufiger Systeme auch firmenübergreifend vernetzt. Und da kommt unweigerlich das Thema Sicherheit ins Spiel. Security wird dabei primär als diffuse Bedrohung beschrieben, und nur selten werden wirklich fundierte Werkzeuge zur Beurteilung oder Adressierung der Bedrohungslage vorgestellt. Daher ist es nicht verwunderlich, dass sich häufig eine ebenso diffuse Angst einstellt - bei den Amerikanern FUD (Fear, Uncertainty and Doubt) genannt. Und dieses ungute Bauchgefühl bewirkt leider häufig, dass die Einführung von Industrie 4.0-Konzepten lieber nicht weiter verfolgt wird, trotz der Tatsache, dass der Einsatz wirtschaftlich sinnvoll wäre, unddas Risiko mit vertretbarem Aufwand adressiert werden könnte. Wirtschaftliche Vorteile für den Standort Deutschland werden damit auch unnötig und grundlos verspielt. Darüber hinaus gibt es eine gewisse Verwirrung, wenn es um den Begriff Sicherheit geht: Auf der einen Seite stehen Forderungen der Industrie nach Sicherheit - auf der anderen Seite Lösungen von IT-Herstellern, die Sicherheit versprechen. Diese Verwirrung ist nicht zuletzt der Tatsache geschuldet, dass Sicherheit in der Industrie anders besetzt ist als in der IT. Diese Diskrepanz ist ein weiterer Grund für eine schleppende Akzeptanz von Projekten im Kontext Industrie 4.0. Es sind einfach zu viele, auf den ersten Blick nicht überlappende Definitionen und Lösungsmöglichkeiten im Umlauf. Auch die Fragestellung, ob sich Industrie 4.0 in allen Branchen und Firmengrößen lohnt, wird kaum neutral behandelt. Immerhin bedingt eine zunehmende Vernetzung der Systeme auch zwangläufig eine größere Angriffsfläche. Es gilt also, die wirtschaftlichen Vorteile gegenüber der Gefahr durch (mögliche) Bedrohungen abzuwägen. Die möglichen Risiken lassen sich nur nach einer ausführlichen Risikobewertung einschätzen. Den Schritt der Risikoanalyse aber lassen viele oft komplett aus. Stattdessen führen Anwender technische und organisatorische Lösungen ein, deren Nutzen zuweilen fragwürdig und häufiger mangels Risikobewertung nicht nachweisbar ist. Forciert wird dies auch häufig von Herstellern bzw. Systemhäusern, die auf der Angst-Marketing -Welle im Fahrwasser von Sicherheit in der Industrie 4.0 mitschwimmen und einfach Produkte verkaufen ob diese nun passen oder nicht. Vor dem Schritt der Risikominimierung muss also zuerst die Risikoanalyse und -bewertung stehen. In einem iterativen Prozess werden dabei Risiken dokumentiert und möglicherweise Verfahren zur Minderung evaluiert. Verbleibende Risiken werden letztendlich nachvollziehbar dokumentiert. Lassen sich Risiken nicht ausreichend minimieren, bzw. ist dies wirtschaftlich nicht sinnvoll, fällt am Ende auch eine Entscheidung gegen Industrie 4.0. Dies aber ist dann ein bewusster, dokumentierter und nachvollziehbarer Entschluss und nicht einer aus einem diffusen Unsicherheitsgefühl heraus. 3

4 1 Sicherheit: Safety, Security, Verfügbarkeit? Leider steckt bei einer solchen Risikobewertung der Teufel im Detail, nicht zuletzt aufgrund verschiedener Defi nitionen von Sicherheit. Der deutsche Begriff ist (leider) mehrdeutig belegt. Die englische Sprache trennt wesentlich deutlicher zwischen Safety und Security. Die Sicherheit/Sicherung des Bedieners und der Umgebung im Zusammenhang mit einer Maschine, einem Ablauf bzw. Produktionsprozess bezeichnet man als Safety. Security wiederum benennt die Sicherheit von (IT)-Systemen, also z.b. den Schutz vor Angreifern oder vor Sabotage des IT-Systems. Im Folgenden soll daher deutlich zwischen Safety und Security getrennt und auf eventuelle Überlappungen explizit hingewiesen werden. Natürlich muss auch die Verfügbarkeit eines Prozesses gewährleistet sein. Doch geht das Whitepaper darauf nicht ein. 2 Risikobewertung 2.1 Risikobewertung: Safety Safety beschäftigt sich primär mit der physischen Sicherheit von Maschinen, Prozessen und deren Bedienern bzw. der Umwelt. In der Automatisierungspyramide ist Safety entsprechend in den Ebenen 0 bis 3 angesiedelt (siehe Abbildung 1). SCM ERP (Level 5: Lieferkettenebene) Level 4: Unternehmensebene MES/MOMS SCADA SPS (PLC/RTU) Fertigung / Produktionsprozess Level 3: Betriebsebene Level 2: (Prozess-) Leitebene Level 1: Feld- /Steuerungsebene Level 0: Prozessebene Safety Abbildung 1: Safety in der Automatisierungspyramide 4

5 Die Sicherheit unter Safety-Gesichtspunkten ist ein gut dokumentierter Prozess, für den es einige Normen gibt. Folgende Beispiele stellen nur einen Bruchteil der verfügbaren Normen für verschiedene Prozessbereiche (Elektronik, chemische/mechanische Prozesse usw.) dar: IEC 61508: Sicherheitsfunktionen bei elektrischen, elektronischen und programmierbar elektronischen (E/E/PE) Systemen IEC 61511: Sichere (Sicherheits-)Anzeigen (Instrumente) DIN EN ISO 13849: Gestaltungsleitsätzen zu sicherheitsbezogenen Teilen von Steuerungen Diese Klasse von Normen schafft das Rahmenwerk zum Bau und Betrieb sicherere Systeme (Safety). Insbesondere DIN EN ISO beschäftigt sich beispielsweise mit der Defi nition (S - Schwere der Verletzung; F - Frequenz/Häufi gkeit/dauer der Exposition; P- Wahrscheinlichkeit/Probability zur Vermeidung der Gefährdung/des Schadens ) und Minderung von Risiken für den Bediener durch den Aufbau entsprechender Steuerungen. Der Fokus liegt also auf dem Bereich Safety als Sicherheit für den Bediener bzw. die Umgebung (siehe Abbildung 2)! Schwere der Verletzung Häufigkeit/Dauer der Gefährdung Möglichkeit der Vermeidung oder Begrenzung des Schadens Niedriges Risiko P 1 a F 1 P 2 S 1 b P 1 F 2 P 2 Ausgangspunkt c P 1 F 1 P 2 S 2 d P 1 F 2 P 2 d Hohes Risiko Abbildung 2: Risikograph nach DIN EN ISO (Quelle: BGIA-Report 2/ Funktionale Sicherheit von Maschinensteuerungen) 5

6 Zusätzlich sind noch Normen und Richtlinien erwähnenswert, die sich übergeordnet und auch explizit mit der Risikobewertung beschäftigen: DIN EN ISO 12100:2010 Richtlinie 2006/42/EG (Maschinenrichtlinie) CE-Norm Diese übergeordneten Normen und Richtlinien definieren allgemeine Regelwerke für die Risikobewertung. Konkrete Maßnahmen zur Umsetzung finden sich wiederum in der vorher genannten Klasse der Normen. Dabei gestaltet sich Risikobewertung als ein iterativer Prozess, der einschließlich der entsprechenden Risikominderung so lange durchläuft, bis das Risiko ausreichend gemindert ist (siehe Abbildung 3). Start Bestimmung der Grenzen der Maschine oder Anlage Identifizierung der Gefährdungen Risikoeinschätzung Risikobewertung Ist die Anlage oder Maschine sicher? ja Ende nein Risikominderung Risikoanalyse Risikobewertung Abbildung 3: Risikobewertung nach EN ISO Für die Unterstützung der eigentlichen Risikobewertung und Dokumentation der Restrisiken wiederum gibt es erprobte und ausgereifte Softwarelösungen, so etwa die folgenden: SICK Safexpert 8.0 WEKA Manager CE ce konform CE SAFE Im Bereich Safety finden sich also viele Normen und Richtlinien mit konkreten Anweisungen und auch Rahmenwerken zur Risikobewertung. Die Vorgehensweise beim (sicheren) Design von Maschinen und Prozessen ist folglich ausreichend dokumentiert und hat sich in der Praxis bewährt. Im Vergleich zu Security ist die Risikobewertung allerdings irgendwann beendet sei es, weil das Restrisiko genügend gemindert wurde, sei es weil es nicht genügend gemindert werden kann. 6

7 2.2 Risikobewertung Security Security beschreibt im Gegensatz zu Safety die Sicherheit von IT-Systemen. In der Automatisierungspyramide ist Security entsprechend in den Leveln 3 bis 4 (5) angesiedelt (siehe Abbildung 4). SCM ERP (Level 5: Lieferkettenebene) Level 4: Unternehmensebene Security MES/MOMS SCADA SPS (PLC/RTU) Fertigung / Produktionsprozess Level 3: Betriebsebene Level 2: (Prozess-) Leitebene Level 1: Feld- /Steuerungsebene Level 0: Prozessebene Abbildung 4: Security in der Automatisierungspyramide Auch bei (IT-)Security haben sich im Laufe der Zeit verschiedene Normen und Rahmenwerke etabliert. Diese defi nieren die Modellierung und Risikobewertung von IT- Systemen. Stellvertretend für eine ganze Reihe von Normen sind hier zwei zu nennen: ISO 27XXX Normen: Aufbau/Betrieb eines Information Security Management System (ISMS). Im deutschsprachigen Bereich ist das i.d.r. ein Bestandteil einer Vorgehensweise nach BSI IT-Grundschutz. ITIL (Information Technology Infrastructure Library): Eine Sammlung von Best Practices COBIT: Wurde ursprünglich als Grundlage zur Prüfung von IT-Systemen entwickelt. In der Zwischenzeit ist sie aber auch zur Steuerung der IT, insbesondere im Hinblick auf verschiedene Compliance Anforderungen im Einsatz. Vor allem ISO27XXX und der IT-Grundschutz liefern ein umfassendes Rahmenwerk zur Modellierung und Umsetzung sicherer IT-Systeme. Dies umfasst sowohl die Bereiche Risikobewertung als auch entsprechende konkrete Maßnahmen (Best-Practices). 7

8 Abbildung 5: Regelkreis der Risikobewertung für IT-Security Auch in der IT-Security sind daher Modelle und Werkzeuge zur Risikobewertung seit langer Zeit vorhanden und haben sich in der Praxis bewährt. Als Software zur Modellierung und Dokumentation wären hier exemplarisch zwei, im deutschsprachigen Raum verbreitete Lösungen zu nennen: BSI GS-Tool verinice Auffällig ist aber eine andere Art der Risikobewertung als im Bereich Safety. Auch der Prozess der Risikoanalyse unterscheidet sich deutlich. Bei einer Safety-Risikobewertung ist der Prozess beendet, sobald eine ausreichende Minderung des Risikos stattgefunden hat. Bei einer Risikobewertung für Security ist die Analyse und Minimierung des Risikos ein kontinuierlicher Prozess (siehe Abbildung 5). 8

9 2.3 Risikobewertung: Safety + Security = Industrie 4.0? Ein erster Versuch einer Risikobewertung für Industrie 4.0 liegt in der Zusammenführung der Risikobewertungen aus Safety - und Security -Gesichtspunkten. Da diese sich zumindest auf der Betriebsebene überlappen, sollte doch alles ganz einfach sein -- eigentlich. Leider sieht die Realität anders aus: Eine Risikobewertung für Industrie 4.0 umfasst alle Ebenen - auch jene, die durch die Beurteilungen für Safety und Security schon abgedeckt sind (siehe Abbildung 6). Hinzu kommen unterschiedliche Optimierungsziele der Risikobewertung bei Safety und Security. Auch die Dauer/Kontinuität des Risikobewertungsprozesses unterscheidet sich grundlegend. Darüber hinaus kann ein Risiko, das aus Safety-Sicht zu vernachlässigen ist, aus Security-Sicht unter Umständen ein unüberwindbares Hindernis darstellen. Umgekehrt gilt dies natürlich genauso. SCM ERP MES/MOMS SCADA SPS (PLC/RTU) Fertigung / Produktionsprozess (Level 5: Lieferkettenebene) Level 4: Unternehmensebene Level 3: Betriebsebene Level 2: (Prozess-) Leitebene Level 1: Feld- /Steuerungsebene Level 0: Prozessebene Industrie 4.0 Abbildung 6: Industrie 4.0 Sicherheit in der Automatisierungspyramide Ein Beispiel dafür sind Fernwartungsmechanismen. Während diese in der Vergangenheit häufig über dedizierte (Einwahl-)Verbindungen realisiert wurden, ist heute der Zugriff über das Internet üblich. 1 Die Security dieser Mechanismen wird i.d.r. durch Passwörter und das Prinzip des Nicht-Wissens sichergestellt. Leider macht hier die IT-Security einen großen Strich durch die Rechnung. Security-through- Obscurity ist nachweislich keine gute Strategie. Und wie verschiedene Studien zeigen, ist es bei öffentlich zugänglichen Systemen, nur eine Frage der Zeit, bis jemand anklopft. 2 Es existiert also eine Lücke zwischen der Risikobewertung aus Safety-Sicht und der aus Security-Sicht. Die Zielsetzung bzw. die Definition von Risiko der beiden Beurteilungen ist nicht deckungsgleich. Im Gegenteil - in einigen Fällen kann ein erhebliches Risiko auf der einen Seite von der anderen völlig ignoriert werden (siehe Abbildung 7). 1. Wer steckt tatsächlich hinter den Angriffen auf ICS-Ausrüstung? (Teil 1) 2. Wer steckt tatsächlich hinter den Angriffen auf ICS-Ausrüstung? (Teil 2) 9

10 SCM ERP (Level 5: Lieferkettenebene) Level 4: Unternehmensebene Industrie 4.0 MES/MOMS SCADA SPS (PLC/RTU) Fertigung / Produktionsprozess Level 3: Betriebsebene Level 2: (Prozess-) Leitebene Level 1: Feld- /Steuerungsebene Level 0: Prozessebene Industrie 4.0 LÜCKE Abbildung 7: Lücke in der Risikobewertung für Industrie 4.0 in der Automatisierungspyramide Ziel einer durchgängigen Risikobewertung für Industrie 4.0 ist es, diese Lücke zu überbrücken. Dabei gibt es verschiedene Problemfelder, die gelöst sein wollen: Verschiedene Zielsetzungen der Risikobewertung: Die Ziele und Schlussfolgerungen einer Risikobewertung müssen die Verantwortlichen in der jeweils anderen Risikobewertung aufgreifen und zumindest bis zu einem gewissen Grad fortführen. Dokumentation: Die Dokumentation der durchgängigen Risikobewertung muss in einem einheitlichen Format stattfinden. Keine der bestehenden Rahmenwerke oder Werkzeuge (Software) deckt im Moment beide Welten ab. Ausbildung: Noch gibt es kaum Experten, die in beiden Welten zuhause sind. Es ist daher umso wichtiger, die Experten für die jeweils andere Seite zu sensibilisieren. Es gibt kein richtig oder falsch. Nur wenn beide Seiten adressiert werden, lässt sich eine sinnvolle Risikobewertung für das Gesamtsystem erstellen. Mangels verfügbarer Werkzeuge ist die Schließung dieser Lücke heute noch mit manuellem Aufwand verbunden. Der wichtigste Aspekt ist hier sicherlich die strukturierte Dokumentation. Spätestens mit der breiten Einführung von Industrie 4.0-Konzepten ist aber auch hier mit entsprechenden Werkzeugen zu rechnen. 2.4 Kombinierte Bewertung Erst wenn eine kombinierte Risikobewertung erstellt wurde, lässt sich sinnvoll entscheiden, ob die Einführung von Industrie 4.0-Konzepten im Einzelfall sinnvoll ist. Sie enthält auch Konzepte und Lösungen zur Risikominderung. Die Modellierung des Risikos stellt dabei sicher, dass keine Lösung über das Ziel hinausschießt - weder funktionell noch monetär. Stellt sich z.b. heraus, dass die Kosten zur Minderung der Risiken die des Gewinns durch die Integration übersteigen, ist zumindest die wirtschaftliche Entscheidung eindeutig. 10

11 3 Risikominderung 3.1 Der Heilige Gral: Security by Design Security by Design wird zurzeit häufig als DIE Lösung aller Security-Probleme im Industrie 4.0-Umfeld herausgestellt. Dabei schießen aber viele über das Ziel hinaus und propagieren das komplette Neu-/Wiedererfinden sämtlicher Funktionalitäten unter Security by Design- Gesichtspunkten. Dies ist aber weder wirtschaftlich noch aus Security-Sicht sinnvoll. Auch wird im Zusammenhang mit Security by Design häufig ISO Norm angeführt Die Norm enthält explizit folgende Aussagen: ISO/IEC 27034: a) applies to the underlying software of an application and to contributing factors that impact its security, such as data, technology, application development life cycle processes, supporting processes and actors; and Und: ISO/IEC is not: a) a software application development standard; Security by Design nach ISO definiert also mitnichten die sichere (Neu-) Entwicklung aller Softwaresysteme. Vielmehr definiert die Norm die Entwicklung sicherer Designs. Dies beinhaltet auch die Nutzung existierender Komponenten, die durch entsprechende Maßnahmen gesichert werden. Es zählt also das sichere Design des Gesamtsystems - nicht ausschließlich die sichere Neuentwicklung aller Komponenten! Hinzu kommt natürlich auch, dass die Nutzung existierender Komponenten i.d.r. deutlich günstiger ist, als die komplette Neuentwicklung. 3.2 Nutzung von Standard IT-Security Komponenten Security by Design im Industrie 4.0-Umfeld gilt also auch für die Nutzung von Standard-/Office IT-Komponenten! Natürlich hat Office IT Grenzen. Es gibt z.b. keine Security-Lösungen für SPS-Komponenten in der Office IT. Aber bei SCADA-Systemen oder nachgelagerten Systemen kommen Standardbetriebssysteme und Standardsoftwarekomponenten zum Einsatz. Diese können natürlich auch mit Office IT-Security Lösungen abgesichert werden. Ob nun eine Gateway-Lösung die Inhaltssicherheit beim Übergang zwischen Office- Netzen überwacht oder den Übergang zwischen Prozessleitsystemnetzwerk und Office Netzwerk, die zugrunde liegende Technik ist identisch. Der einzige Unterschied besteht, wenn überhaupt, in den Einstellungen und Richtlinien. Salopp formuliert: Je näher man dem Prozess kommt, umso weniger/unwahrscheinlicher können Office IT-Security Lösungen genutzt werden. Je weiter man sich entfernt, desto mehr kann man auf Standard IT-Security-Lösungen zurückgreifen (siehe Abbildung 8). Und Standard ist hier nicht auf technische Lösungen beschränkt. Auch Best Practices lassen sich oft unverändert übernehmen Maßnahmen für mehr Sicherheit bei ICS-Systemen 11

12 Abbildung 8: Nutzung von Offi ce IT-Security Komponenten im Industrie 4.0 Kontext 3.3 Nutzung von angepassten IT-Security-Komponenten In manchen Fällen können sogar bestehende Standardkomponenten mittels einer kleinen Änderung deutlich an Attraktivität für den Industriebereich gewinnen. Als Beispiel dient hier Trend Micros Portable Security 2. Es ist ein USB Stick, der das Scannen von Offl ine- Systemen ohne Installation von Software ermöglicht. Insbesondere Steuerungssysteme sind häufi g noch nicht ans Internet angebunden bzw. die Veränderung der Konfi guration, einschließlich der Installation von Software, ist streng untersagt. Eine Besonderheit stellen die drei eingebauten LEDs dar, die Auskunft über den Status des Scanvorgangs geben (siehe Abbildung 9). 12

13 Status LEDs: Status und Ergebnis Alle drei LEDs blinken während des Scan-Vorgangs Rot: Schadsoftware gefunden (und ignoriert) Gelb:: Schadsoftware gefunden und bereinigt Blau: keine Schadsoftware gefunden Abbildung 9: Portable Security 2: Statusanzeige via LEDs Aus Sicht der IT-Security stellen die LEDs keinen Mehrwert der Kernfunktion dar. Denkt man jedoch an Wartungstechniker, die unter Umständen Systeme in Schalträumen scannen (lassen) müssen, werden die Vorteile schnell ersichtlich. Ohne Zugriff auf die Konsole ist der Status und das Ergebnis des Scanvorgangs auf einen Blick ersichtlich. Ein Beispiel, wie eine kleine Erweiterung außerhalb des Kernnutzens einer Lösung zu einem deutlich sekundären Nutzen führen kann. 13

14 4 Zusammenfassung Um die wirtschaftlichen Vorteile einer Industrie 4.0-Architektur für den Wirtschaftsstandort Deutschland sinnvoll ausschöpfen zu können, müssen die Produktions- und IT-Industrie zusammen an einer sicheren Einführung der Konzepte arbeiten. Dazu gehört auch, die Sprache und Sichtweise der anderen Seite zu verstehen. Dies zeigt sich unter anderem in der Nutzung des Begriffs Sicherheit, der in beiden Branchen unterschiedlich belegt ist: Safety vs. Security. Eine nicht koordinierte Einführung hat zur Folge, dass Security-Probleme übersehen werden und dann mit unpassenden Lösungen adressiert werden. Nur nach einer Risikobewertung, die sowohl Safety als auch Security betrachtet, lässt sich die Frage, ob die Einführung wirtschaftlich ratsam ist, sinnvoll beantworten. Die Risikobewertung ist also ein Schritt vor dem eigentlichen Ausrollen entsprechender Lösungen zur Risikominimierung. Ist die wirtschaftliche Entscheidung für die Einführung getroffen, gilt es, Lösungen zu evaluieren. Diese können bis zu einem gewissen Grad aus kostengünstigen Office IT-Komponenten bestehen, die basierend auf der Analyse in einem sicheren Gesamt-Design eingesetzt werden. Ab einer gewissen Nähe zum eigentlichen Prozess sind angepasste, aber dadurch auch teurere Lösungen nicht zu umgehen. Die Risikoanalyse zeigt aber auch hier Anknüpfungspunkte für eine sinnvolle Mischung der Lösungen auf. Der Zug für IT-Sicherheit im Industrie 4.0-Kontext ist noch nicht endgültig abgefahren. Vor dem unkoordinierten Ausrollen von Lösungen steht jedoch die Risikobewertung. Findet dieser erste Schritt der Risikobewertung vor dem zweiten der Produktinstallation statt, hat der Wirtschaftsstandort Deutschland noch gute Chancen, den Zug noch zu erwischen, ohne sich von diffusen Angstvorstellungen lähmen zu lassen. 14

15 HAFTUNGSAUSSCHLUSS Die in diesem Dokument bereitgestellten Informationen sind lediglich allgemeiner Natur und für Aufklärungszwecke gedacht. Sie stellen keine Rechtsberatung dar und sind nicht als solche auszulegen. Die in diesem Dokument bereitgestellten Informationen finden womöglich nicht auf alle Sachverhalte Anwendung und spiegeln womöglich nicht die jüngsten Sachverhalte wider. Die Inhalte in diesem Dokument sind ohne eine Rechtsberatung auf der Grundlage der vorgestellten besonderen Fakten und Umstände nicht als verlässlich oder als Handlungsanweisungen zu verstehen und nicht in anderer Weise auszulegen. Trend Micro behält sich das Recht vor, die Inhalte dieses Dokuments zu jeder Zeit und ohne Vorankündigung zu ändern. Übersetzungen in andere Sprachen sind ausschließlich als Unter stützung gedacht. Die Genauigkeit der Übersetzung wird weder garan tiert noch stillschweigend zugesichert. Bei Fragen zur Genauigkeit einer Übersetzung lesen Sie bitte in der offiziellen Fassung des Dokuments in der Ursprungssprache nach. Diskrepanzen oder Abweichungen in der übersetzten Fassung sind nicht bindend und haben im Hinblick auf Compliance oder Durchsetzung keine Rechtswirkung. Trend Micro bemüht sich in diesem Dokument im angemessenen Um fang um die Bereitstellung genauer und aktueller Informationen, über nimmt jedoch hinsichtlich Genauigkeit, Aktualität und Voll ständigkeit keine Haftung und macht diesbezüglich keine Zusicherungen. Sie erklären Ihr Einverständnis, dass Sie dieses Dokument und seine Inhalte auf eigene Gefahr nutzen und sich darauf berufen. Trend Micro übernimmt keine Gewährleistung, weder ausdrücklich noch still schweigend. Weder Trend Micro noch Dritte, die an der Konzeption, Erstellung oder Bereitstellung dieses Dokuments beteiligt waren, haften für Folgeschäden oder Verluste, insbesondere direkte, indirekte, besondere oder Nebenschäden, entgangenen Gewinn oder besondere Schäden, die sich aus dem Zugriff auf, der Verwendung oder Un möglichkeit der Verwendung oder in Zusammenhang mit der Verwendung dieses Dokuments oder aus Fehlern und Auslassungen im Inhalt ergeben. Die Verwendung dieser Informationen stellt die Zustimmung zur Nutzung in der vorliegenden Form dar. 15

16 Über TREND MICRO Trend Micro, der international führende Anbieter für Cloud-Security, ermöglicht Unternehmen und Endanwendern den sicheren Austausch digitaler Informationen. Als Vorreiter bei Server-Security mit mehr als fünfundzwanzigjähriger Erfahrung bietet Trend Micro client-, server- und cloudbasierte Sicherheitslösungen an. Diese Lösungen für Internet-Content-Security und Threat-Management erkennen neue Bedrohungen schneller und sichern Daten in physischen, virtualisierten und Cloud-Umgebungen umfassend ab. Die auf der Cloud-Computing-Infrastruktur des Trend Micro Smart Protection Network basierenden Technologien, Lösungen und Dienstleistungen wehren Bedrohungen dort ab, wo sie entstehen: im Internet. Unterstützt werden sie dabei von mehr als weltweit tätigen Sicherheits-Experten. Trend Micro ist ein transnationales Unternehmen mit Hauptsitz in Tokio und bietet seine Sicherheitslösungen über Vertriebspartner weltweit an TREND MICRO Deutschland GmbH Zeppelinstrasse Hallbergmoos Germany Tel. +49 (0) Fax +49 (0) TREND MICRO Schweiz GmbH Schaffhauserstrasse Glattbrugg Switzerland Tel. +41 (0) Fax +41 (0) TREND MICRO (SUISSE) SÀRL World Trade Center Avenue Gratta-Paille Lausanne Switzerland Trend Micro Incorporated. Alle Rechte vorbehalten. Trend Micro und das Trend Micro T-Ball-Logo sind Marken oder eingetragene Marken von Trend Micro Incorporated. Alle anderen Firmen- oder Produktnamen sind Marken oder eingetragene Marken ihrer jeweiligen Eigentümer.