Industrie 4.0 und die Sicherheit

Transcrição

Trend Micro WhitePaper
Industrie 4.0 und die Sicherheit
Ist der Zug bereits abgefahren?
Autor: Udo Schneider,
Security Evangelist bei Trend Micro
Trend Micro | Industrie 4.0 und die Sicherheit
Inhalt
Einleitung....................................................................................................................................... 3
1 Sicherheit: Safety, Security, Verfügbarkeit.................................................................................. 4
2. Risikobewertung........................................................................................................................ 4
2.1 Risikobewertung: Safety.......................................................................................................... 4
2.2 Risikobewertung: Security....................................................................................................... 7
2.3 Risikobewertung: Safety + Security = Industrie 4.0................................................................. 9
2.4 Risikobewertung: Kombinierte Bewertung............................................................................ 10
3. Risikominderung.......................................................................................................................11
3.1 Der Heilige Gral: Security by Design......................................................................................11
3.2 Nutzung von Standard IT-Security-Komponenten..................................................................11
3.3 Nutzung von angepassten IT-Security-Komponten............................................................... 12
4. Zusammenfassung.................................................................................................................. 14
2
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
1 Sicherheit: „Safety“, „Security“, „Verfügbarkeit“?
Leider steckt bei einer solchen Risikobewertung der Teufel im Detail, nicht zuletzt aufgrund
verschiedener Definitionen 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
(Level 5:
Lieferkettenebene)
ERP
Level 4:
Unternehmensebene
MES/MOMS
Level 3: Betriebsebene
SPS (PLC/RTU)
Fertigung /
Produktionsprozess
Level 2: (Prozess-)
Leitebene
Level 1: Feld/Steuerungsebene
Safety
SCADA
Level 0: Prozessebene
Abbildung 1: „Safety“ in der Automatisierungspyramide
4
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 13849 beschäftigt sich beispielsweise mit
der Definition (S - Schwere der Verletzung; F - Frequenz/Häufigkeit/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äuﬁgkeit/Dauer der Gefährdung Möglichkeit der Vermeidung oder Begrenzung des Schadens Niedriges Risiko P1 a F1 P2 S1 b P1 F2 P2 Ausgangspunkt c P1 F1 P2 S2 d P1 F2 P2 d Hohes Risiko Abbildung 2: Risikograph nach DIN EN ISO (Quelle: BGIA-Report 2/2008 - Funktionale Sicherheit von
Maschinensteuerungen)
5
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
Identiﬁzierung der
Gefährdungen
Risikoeinschätzung
Risikobewertung
Ist die
Anlage oder
Maschine
sicher?
ja
Ende
nein
Risikominderung
Risikoanalyse
Risikobewertung
Abbildung 3: Risikobewertung nach EN ISO 14121
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
2.2 Risikobewertung Security
SCM
(Level 5:
Lieferkettenebene)
ERP
Level 4:
Unternehmensebene
MES/MOMS
SCADA
SPS (PLC/RTU)
Fertigung /
Produktionsprozess
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).
Level 2: (Prozess-)
Leitebene
Abbildung 4: „Security“ in der Automatisierungspyramide
Auch bei (IT-)Security haben sich im Laufe der Zeit verschiedene Normen und
Rahmenwerke etabliert. Diese definieren die Modellierung und Risikobewertung von ITSystemen. 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
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
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.
SCM
(Level 5:
Lieferkettenebene)
ERP
Level 4:
Unternehmensebene
MES/MOMS
SCADA
SPS (PLC/RTU)
Fertigung /
Produktionsprozess
Level 2: (Prozess-)
Leitebene
Industrie 4.0
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.
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-throughObscurity“ 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)
http://www.trendmicro.de/media/wp/tm-wp-ics-scada-praxistestpumpstation-de.pdf
2. Wer steckt tatsächlich hinter den Angriffen auf ICS-Ausrüstung? (Teil 2)
http://www.trendmicro.de/media/wp/ics-scada-praxistest-pumpstation-teil-2-whitepaper-de.pdf
9
ERP
Level 4:
Unternehmensebene
MES/MOMS
SCADA
SPS (PLC/RTU)
Fertigung /
Produktionsprozess
Level 2: (Prozess-)
Leitebene
LÜCKE
(Level 5:
Lieferkettenebene)
Industrie 4.0
SCM
Industrie 4.0
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
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 DesignGesichtspunkten. Dies ist aber weder wirtschaftlich noch aus Security-Sicht sinnvoll.
Auch wird im Zusammenhang mit Security by Design häufig ISO 27034-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 27034 is not:
a) a software application development standard;
Security by Design nach ISO 27034 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 OfficeNetzen ü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 übernehmen3.
3. Maßnahmen für mehr Sicherheit bei ICS-Systemen
http://www.trendmicro.de/media/wp/wp-ics-security-de.pdf
11
Abbildung 8: Nutzung von Office 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 OfflineSystemen ohne Installation von Software ermöglicht. Insbesondere Steuerungssysteme
sind häufig noch nicht ans Internet angebunden bzw. die Veränderung der Konfiguration,
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
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
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
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 Unterstützung gedacht. Die Genauigkeit der Übersetzung wird weder
garantiert 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 Umfang um die Bereitstellung genauer und aktueller Informationen,
übernimmt jedoch hinsichtlich Genauigkeit, Aktualität und Vollstä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 stillschweigend. 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 Unmö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
Ü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 1.000 weltweit tätigen Sicherheits-Experten. Trend Micro ist ein transnationales Unternehmen
mit Hauptsitz in Tokio und bietet seine Sicherheitslösungen über Vertriebspartner weltweit an.
http://www.trendmicro.de/
http://blog.trendmicro.de/
http://www.twitter.com/TrendMicroDE
TREND MICRO Deutschland GmbH
Zeppelinstrasse 1
85399 Hallbergmoos
Germany
Tel. +49 (0) 811 88990–700
Fax +49 (0) 811 88990–799
TREND MICRO Schweiz GmbH
Schaffhauserstrasse 104
8152 Glattbrugg
Switzerland
Tel. +41 (0) 44 82860–80
Fax +41 (0) 44 82860–81
TREND MICRO (SUISSE) SÀRL
World Trade Center
Avenue Gratta-Paille 2
1018 Lausanne
Switzerland
www.trendmicro.com
©2015 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.

Industrie 4.0 und die Sicherheit

Transcrição

Documentos relacionados

Vertriebsingenieur (m/w) - MA micro automation GmbH

Risikobewertung nach DIN 18650

Richtlinien und Spezifikationen

Virenschutz der Extraklasse

CosmosDirekt Social Media im Unternehmen

Fachhan SOKO e Im Rahm die SOK Das Wi zielgrup Münche und zu

usd Security Awareness Plattform

Pressemitteilung - Nordwest-Funk

Nios micro

Intra2net Business Server

Die güterrechtliche Teilung – praktisches Beispiel

4574) Pilotstudie zum Vorkommen von Salmonella spp. bei Herden