Ringvorlesung: Forum Software und Automatisierung

Größe: px
Ab Seite anzeigen:

Download "Ringvorlesung: Forum Software und Automatisierung"

Transkript

1 INFORMATIK CONSULTING SYSTEMS AG Ringvorlesung: Forum Software und Automatisierung Softwareprüfung für sichere (Safety + Security) Systeme Name Dr. Thomas Liedtke Funktion R&D Datum 15. Januar 2015 Agenda Vorstellung Motivation Einführung Einordnung - Methoden Safety - Besonderheiten Safety vs. Security Security - Besonderheiten Zusammenfassung/ Ausblick 2 1

2 Vorstellung wer bin ich? Dr. Thomas Liedtke Seit 01. Dezember 2007 bei der ICS AG tätig als Leiter Research & Development Senior Projektleiter sicherheitsgerichteter Projekte Leiter Competence Center Implementierung Software Reifegradmodelle Davor: Studium der Informatik mit Nebenfach Mathematik an der Universität Stuttgart Promotion Informatik/ Mathematik an der Universität Stuttgart 14 Jahre bei Alcatel/ Alcatel Lucent Bereich Vermittlungssysteme: Qualitätsabteilung/ SPI/ SEPG (CMM)/ Projektleiter für MOD-Projekte der DTAG Bereich Mobilfunk: Abteilungsleiter in der Entwicklung Oberprojektleiter für Mobilfunkprojekte (GPRS/ UMTS/ GSM/ ) Bereich Übertragungssysteme: Leiter Supply Chain OND Leiter des RSLC (Repair Service Logistic Center) Weilimdorf 3 Das Unternehmen Rechtsform Aktiengesellschaft Grundkapital 2,4 Mio. EUR Vorstand Franz-Josef Winkel, Cid Kiefer Aktionäre Die Familien: Hämer, Winkel und Kiefer Hauptstandort Stuttgart Geschäftsstellen Berlin, Braunschweig, Ingolstadt, Immenstaad, Leipzig, München, Rüsselsheim, Ulm Anzahl der Mitarbeiter 150+ Umsatz EUR Handelsregister Amtsgericht Stuttgart HRB Nr.: UST. Id.Nr: DE ,0 10,0 8,0 6,0 4,0 2,0 0, Umsatz in Mio. Euro Anzahl der Mitarbeiter

3 Kunden nach Domänen Automotive Industrial Solutions Transportation Aero Space & Defence 5 Philosophie Partner für den gesamten Produkt Life Cycle Vordenken Beraten Umsetzen Betreuen Machbarkeitsstudien, Evaluierungen Technologien Methoden Werkzeuge Standards Prozesse Systems und Safety Engineering Produkt Design und Entwicklung Kapazitäts- und Kompetenzergänzung Test und Validierung RAM und Safety Management Assessment Maintenance von Software und Systemen V 6 3

4 Agenda Vorstellung Motivation Einführung Einordnung - Methoden Safety - Besonderheiten Safety vs. Security Security - Besonderheiten Zusammenfassung/ Ausblick 7 Motivation gestern: Spektakulärer Eisenbahnunfall am Gare Montparnasse (Dienstag, ) -> Systemgedanke! 8 Bildquelle: Wikipedia 4

5 Motivation - heute -> Virtualität/ Modellierung Der Wert von Sicherheit wird oft erst dann erkannt, wenn sie nicht mehr gewährleistet ist 9 Komplexität der Anforderungen an technische Systeme steigt Industrie 4.0*)-Anwendungen (u.a. [SESAMO14, Svo10, Bau14]): Dezentralisierung von Steuerungen: z.b.: Energiegewinnung/ -verteilung, wachsender Einsatz "SMARTer"/ unterschiedlichster Endgeräte, MES, Car2x, einfachste Funktionen werden über mehrere Steuergeräte verteilt, Steuergeräte kommunizieren über immer mehr Kommunikationskanäle/ Busse miteinander,... Neuartige unterschiedlichste Endgeräte und Bedienungskonzepte: z.b.: Flexible Tablet-/ Touch-Steuerung einer begehbaren Maschine, Bessere Integration des Menschen (analog Automotive), WLAN an Maschinen, Aktoren und Sensoren werden immer leistungsfähiger und intelligenter Erhöhte Anzahl von Sicherheitslücken: Jede neue Technologie, die Sicherheitslücken schließt, bringt neue mit sich. *) Industrie 4.0 hier: Vernetzung von CPS, Anlagen, Fabriken, Steuergeräten zur intelligenten Fabrik im Internet der Dinge. Massenindividualisierte Produkte: Konsument gestaltet das Produkt, Produktionsanlagen richten sich danach (autonom) 10 5

6 Komplexität der Entwicklungsprozesse steigt Anlagenlebenszeiten (Investitionsgüter) werden länger; umgekehrt zu Lebenszyklen von Software und Betriebssystemen Embedded-Systeme sind die Dinge : Mehrere Standards für jede Anforderung macht Entwicklungsprozesse komplex Mögliche Marktsegmentierung macht Economy-of-Scale unsicher (Konsumgütermarkt, Industrieanwendungen, Cloud-Computing, Telecom- Infrastrukturen, ) Standardisierung/ Player vs. Kosten Trust : richtige Technologien zeitnah und vertrauenswürdig liefern Infrastruktur für die smarte Fabrik Statische Produktionsabläufe entwickeln sich zu dynamischen Prozessketten Vernetzung horizontal und vertikal: Flexibilität, Autonomie, Teleservices (z.b. Visual Online Support), 11 Motivation/ Begriffe Verschiedene Begriffe sind in verschiedenen Domänen unterschiedlich belegt Verifikation: oft: überprüfen, ob Dinge richtig gemacht wurden (vertikal/ unten im V-Modell), meist direkte Verknüpfung mit der Testdurchführung Validierung: oft: überprüfen, ob die richtigen Dinge gemacht wurden (horizontal/ oben im V- Modell), nachweisen u.u. ohne direkte Testdurchführung Integration/ Testen/ Prüfen Wozu Prüfung? Softwaresysteme spielen in einem zunehmend großen Teil des Lebens eine wichtige Rolle: Steuerung von Transportmitteln, Steuerung von Kraftwerken, Assistenzsysteme in Autos, Smart Grid, IoT, Industrie 4.0 Relativ neu: Security! Gefahr für Leib und Leben, Umwelt, Personenschäden, Sachschäden, finanzielle Schäden, Imageschäden und Katastrophen sind möglich 12 6

7 Berühmte Softwarepannen -> Notwendigkeit Fast der 3. Weltkrieg Ozonloch Ziviles Flugzeug als Kampfjet interpretiert 13 [DZGSP08] Prüfen und Testen sind Vorschrift Beispiele: DIN EN :2001 Anhang A - Leitfaden für die Auswahl der Verfahren und Maßnahmen EN 50128:2011 Anhang A5 Verifikation und Testen 14 [IEC-61508] [EN-50128] 7

8 Systematischer Ausfall nach IEC Im Folgenden geht es beim Testen/ Prüfen um systematische Ausfälle: Systematischer Ausfall (sind zu vermeiden): Systematisches Versagen/ Ausfall, bei dem eindeutig auf eine Ursache geschlossen werden kann, die nur durch eine Modifikation des Entwurfs oder des Fertigungsprozesses, der Art und Weise des Betreibens, der Bedienungsanleitung oder anderer Einflussfaktoren beseitigt werden kann. Zufälliger Hardwareausfall (unvorhergesehenes Verhalten ist sicher zu machen): Ausfall, der zu einem zufälligen Zeitpunkt auftritt und der aus einem oder mehreren möglichen Mechanismen in der Hardware resultiert, die zu einer Verschlechterung der Eigenschaften der Bauteile führen. Klassifizierung der Fehler anhand folgender Fragen: War der Fehler zum Zeitpunkt der Inbetriebnahme bereits eingebaut? Ist der Ausfall prinzipiell reproduzierbar? Wichtiges Unterscheidungsmerkmal: Systemausfallraten, die aus zufälligen Hardwareausfällen herrühren, können mit vernünftiger Genauigkeit statistisch quantifiziert werden, jene die durch systematische Ausfälle entstehen nicht, weil die Ereignisse, die zu diesen führen, nicht leicht vorausgesagt werden können. 15 Anforderungen an die Softwareprüfung Fehlervermeidung: Fehler wie die auf den vorigen Folien beschriebenen sollten so weit wie möglich ausgeschlossen werden oder gefunden werden, bevor sie sich auswirken Fehlervorhersagen Aussagen der Form in welchem Teil der Software sind anteilsmäßig wie viele Fehler zu erwarten? sollen gemacht werden können Risiko = Wahrscheinlichkeit seines Eintretens x Schaden im Falle seines Eintretens Risiko soll minimiert werden Risikoreduktion durch Verringerung der Wahrscheinlichkeit mit der ein Fehler auftritt und durch die Begrenzung der Konsequenzen von unvermeidbaren Fehlern 16 8

9 Was sind Softwarefehler? Genaue Unterscheidung, was mit Fehler gemeint ist Fehlhandlung (error): Mensch verursacht einen Fehler in der Software Fehlerzustand (defect oder fault): im Code einer Software, in einem System oder in einem Dokument (z.b. inkorrektes Teilprogramm, inkorrekte Anweisung oder inkorrekte Datendefinition), verursacht durch eine Fehlhandlung, kann zu einer Fehlerwirkung führen Fehlerwirkung/ Fehlverhalten (failure): Wenn der Defekt im Code ausgeführt wird, kann das System nicht das tun, was es tun sollte (oder etwas tun, was es nicht tun sollte) und dabei eine Fehlerwirkung hervorrufen oder ausfallen. Im Englischen weitere Begriffe: mistake, bug, malfunction, issue, incident, flaw, vulnerability, error-prone, Beispiel: Telefon funktioniert nicht <- kein Freizeichen <- Codefehler 17 Bringt Testen Vertrauensgewinn? Ausführung des Programms 18 Verhalten (Semantik) [Lie14] 9

10 Grundsätze der Softwareprüfung Softwareprüfung kann nur gegen Vorgaben (Anforderungen/ Vergleichsresultate) erfolgen Prüfverfahren müssen definiert sein und reproduzierbare Ergebnisse liefern Prüfergebnisse müssen dokumentiert werden (Nachvollziehbarkeit) Erkannte Fehler müssen (üblicherweise) anschließend korrigiert werden, indem die Fehlerursachen erkannt und behoben werden Systematisch prüfen Prüfung planen Prüfungen nach Vorschriften durchführen (am besten automatisiert ausführen) Nicht nur die Software selbst prüfen, sondern auch alle Dokumente im Umfeld (zum Beispiel Anforderungen! Siehe Reviews) Testen ist: der überprüfbare und jederzeit wiederholbare Nachweis der Korrektheit eines Softwarebausteines relativ zu vorher festgelegten Anforderungen [Den91] 19 Testen: Ziele und Probleme -1 Fehlerzustände und wirkungen nachweisen Durch Fehlerhandlungen Fehlerzustände provozieren Vertrauen in das Programm erhöhen Je weniger gefundene Fehler, desto höheres Vertrauen in die Software (manche nennen das Qualität ) Fehlerwirkungen vorbeugen Aber: Je früher Fehler entdeckt werden, desto billiger die Fehlerkorrektur desto weniger Folgefehler -> vgl. Methoden, die durch Konstruktion in frühen Phasen Fehler so unwahrscheinlich wie möglich machen (Abstrakte Spezifikation, Modellierung, Generierung der Testspezifikation...) Vollständiges Testen ist nicht möglich Vorsicht vor der Fehlermaskierung keine Fehler heißt noch nicht brauchbares System Korrelation zum Lebenszyklusmodell. Z.B.: Wie verträgt sich der Anspruch mit dem agilen Manifest? 20 10

11 Testen: Ziele und Probleme -2 Wann ist man fertig mit Testen? Aufwand verbraucht? Es werden wenige/ keine Fehler mehr gefunden? Termin für Auslieferung steht an? Tester fallen keine neuen Testfälle mehr ein? Nie? Umfang/ Abdeckungskriterium Anforderungsabdeckung Äquivalenzklassenabdeckung Komponentenabdeckung Strukturabdeckung (Instruktionsüberdeckung ; C0, C1, ) Integrationsschritteüberdeckung Traceabiltiy (Rück-)verfolgbarkeit von Anwendungsforderung -> Implementierung (Sourcecode-Funktion) -> Testfall und zurück Keine Anwendung darf vergessen werden (zu implementieren, zu testen, ) Kein Sourcecode ohne Funktion 21 Bewährte Vorgehensweise beim Test Rollen beachten (z.b. Testmanager, Testanalyst, Testspezialist, Test- Automatisierer, Testsupport) Personaltrennung (besonders zwischen Entwickler und Tester!) Anforderungen/ Testspezifikation: Möglichst formal Mit dem Testen so früh wie möglich beginnen Nutzung des Pareto-Prinzips (Fehler sind nicht gleichverteilt, sondern häufen sich) Nutzung von Regressiontests und Ergänzung durch neue Tests der Testresistenz entgegenwirken Testsautomatisierung um Häufigkeit von Regressionstests erhöhen zu können Anpassung der Tests an das System und die grundlegenden Anforderungen Tests sind nicht die einzige Maßnahme im Qualitätsmanagement der Softwareentwicklung, aber oft die letztmögliche. Je später Fehler entdeckt werden, desto aufwändiger ist ihre Behebung [Spi04] 22 11

12 Sichten auf Programmanalyse Überblick Analysemethoden 4 Schichten Modell Dynamische Programmanalyse Experimente Induktion Beobachtung Deduktion Statische Programmanalyse 23 [Zel03] 23 Methoden statisch vs. dynamisch Review Feststellung von Mängeln, Fehlern, Inkonsistenzen, Unvollständigkeiten, Verstößen gegen Vorgaben, Richtlinien, Standards, Pläne Code-Inspektion Formalisiertes Review zur Qualitätseinschätzung Statische Analyse Werkzeuggestütztes Auffinden von Fehlern ohne direkte Ausführung des Systems 24 Walkthrough Designer/ Programmierer führt Teammitglieder und andere Stakeholder durch ein Software- Produkt, Teilnehmer stellen Fragen und geben Kommentare ab Symbolische Ausführung, Simulation Testen Intensives Testen von Systemen und Dokumentation kann helfen, das Risiko, dass Probleme im operativen Betrieb auftreten, zu reduzieren Fehler vor der Freigabe in der operativen Verwendung finden und beheben Softwaretesten kann auch notwendig sein, um vertragliche oder gesetzliche Vorgaben oder spezielle Industrienormen zu erfüllen. 12

13 Unterscheidung Prüf- und Testverfahren Dynamischer Test Symbolischer Test Formale Verifikation Statische Analyse Testende Verfahren Verifizierende Verfahren Spezielle Analysen Analysierende Verfahren 25 Agenda Vorstellung Motivation Einführung Einordnung - Methoden Safety - Besonderheiten Safety vs. Security Security - Besonderheiten Zusammenfassung/ Ausblick 26 13

14 Beschreibung von Safety Safety: Schutz vor (unbeabsichtigter) Fehlfunktion Realisierte Ist-Funktionalität entspricht spezifizierte Soll-Funktionalität Funktionalität unter allen (normalen) Betriebsbedingungen Dependabilty (Verlässlichkeit), RAMS (Reliability (Zuverlässigkeit), Availability (Verfügbarkeit), Maintainability, Safety), FuSi (Funktionale Sicherheit) Safety braucht Security Gesicherte Nachrichtenübermittlung Stellwerk zu Weiche 27 Funktionale Sicherheit in diversen Szenarien Verkehrsführung, Wetter, Human Factor Systemversagen, Vogelschlag Material Konzeption, Common Cause 28 Systematischer Ausfall vs. Zufälliger Ausfall Bildquelle: Wikipedia 14

15 Risikograph: Implizites Risikoakzeptanzkriterium 29 Beispiel ASIL-Einstufung - Automotive 30 [Sch12] 15

16 Entwicklungsprozesse und deren Wechselwirkungen 31 Automotive Safety Standard ISO V V V 32 [ISO26262] 16

17 Vereinfachte Darstellung einer beispielhaften Struktur von Abhängigkeiten Modulprüfbericht Software- Validierung Technische Anforderungen Validierungs- Testspezifikation Software- Architektur Integrations- Prüfspezifikation Modell- Prüfspezifikation Modelle Validierungstestprotokoll Integrationsprüfbericht Modellprüfbericht Modell- Dokumentation Modul- Spezifikation Modul- Prüfspezifikation 33 C-Code Statischer Analysebericht Teststufen im Beispiel V-Modell 34 Modultest: Aufdeckung aller Abweichungen der Implementierung von der Modulspezifikation Integrationstest: Aufdeckung von Fehlern in Schnittstellen und im Zusammenspiel zwischen integrierten Modulen Systemtest: Aufdeckung aller Abweichungen des Systemverhaltens in Bezug auf das in der Anforderungsdefinition spezifizierte Systemverhalten Abnahmetest: Aufdecken aller Fehler, die auf Missverständnissen bei Absprachen zwischen Benutzer und Entwickler, falschen Schätzungen von Datenmengen, unrealistischen Annahmen bezüglich der realen Systemumgebung beruhen 17

18 Testvorgehensweise - Beispiel 1. Vorbereitung des Testobjekts 2. Bereitstellung einer Testumgebung Simulation der realen Einsatzbedingungen für ein Testobjekt Ggf. auch (noch) nicht vorhandener Ressourcen oder Daten oder Nachrichten 3. Testfallermittlung Blackbox-Ansätze: Spezifikationsbasiert (Äquivalenzklassenbildung, Grenzwertanalyse, Ursachen-Wirkungsanalyse, Error Guessing) Whitebox-Ansätze: Implementierungsbasiert (Anweisungs- / Zweig- / Pfadüberdeckung, Datenflussanalyse, Symbolischer Test) Erfahrungsbasierte Verfahren 4. Auswahl geeigneter Testfälle und Testdaten Meist stichprobenartig, um mit möglichst wenigen Tests möglichst viele Fehler finden zu können, idealerweise (zum Teil) automatisierbar welche Abläufe sind wichtig /häufig / typisch, wichtig auch Randfälle 5. Testausführung 6. Testauswertung 35 Testdokumentation nach der IEEE 829 Übersicht - Testplan Testplan: Umfang, Vorgehensweise, Terminplan, Testgegenstände Testspezifikation (test specification) Testdesignspezifikation: Die im Testplan genannten Vorgehensweisen im Detail. Testfallspezifikationen: Die Umgebungsbedingungen, Eingaben und Ausgaben eines jeden Testfalls. Testablaufspezifikationen: In Einzelschritten, wie jeder Testfall durchzuführen ist. Test-(Ergebnis-) Beschreibung (test reporting) Testobjektübertragungsbericht: Wann wurden welche Testgegenstände an welche Tester übergeben Testprotokoll: Chronologisch alle relevanten Vorgänge bei der Testdurchführung Testvorfallbericht: Alle Ereignisse, die eine weitere Untersuchung erforderlich machen. Testergebnisbericht: Beschreibt und bewertet die Ergebnisse aller Tests

19 Agenda Vorstellung Motivation Einführung Einordnung - Methoden Safety - Besonderheiten Safety vs. Security Security - Besonderheiten Zusammenfassung/ Ausblick 37 Safety versus Security 38 19

20 Sichere Systeme Safety Betriebssicherheit Zuverlässigkeit, Verlässlichkeit Security Angriffssicherheit Schutz vor Angriffen Ausfallsicherheit Verhinderung v. Schäden (Personen, Sachen, Umwelt) Schutz der Sicherheitsziele gegen Bedrohungen Vertraulichkeit, Integrität, Verfügbarkeit, Verbindlichkeit 39 Safety vs. Security Safety Mensch/ Umwelt M/U darf durch TS nicht gefährdet werden Technisches System Gefährdung des TS durch M/U darf keine Konsequenzen haben Mensch/ Umwelt 40 Security TS = Technisches System M/U = Mensch und Umwelt 20

21 Agenda Vorstellung Motivation Einführung Einordnung - Methoden Safety - Besonderheiten Safety vs. Security Security - Besonderheiten Zusammenfassung/ Ausblick 41 Beschreibung (IT-) Security (IT-) Security: Schutz vor (absichtlichen) Angriffen Stellt Funktionale Korrektheit bei aktiven Attacken sicher (System, Kontrolle, Zugriffsschutz, ) Security darf Safety nicht stören Performance: Codierte vs. chiffrierte Nachrichten bei ABS Maintainability vs. Obfuscation Umso mehr fortgeschrittene computer-kontrollierte Safety-Features verwendet werden, desto anfälliger sind Safety-critical Aktionen gegenüber Angriffe (s.z.b. CAN-Message-Injection [MiVa2014]) Security will i.g. zu Safety geschlossene Türen: Geschlolssene Türen zw. Cockpit und Passagieren vs. einfachem Luftdruckausgleich Automatisches Türschließen beim Anfahren im Auto vs. einfaches Retten beim Unfall 42 21

22 Bemerkungen/ Beispiele Security Störfälle können die Verlässlichkeit von Systemen beeinträchtigen Konsequenz: Limitierung von Nutzbarkeit und Safety bis hin zu (D) Denial of Service Verlässlichkeit bestimmt die Wahrscheinlichkeit für den Verlust von Security SCADA: Attacke durch ungesicherte Kommunikationskanäle (Australien Maroochy Abwasserunfall, [SM08]) Automotive: Angriff über ungesicherte Schnittstellen, [CMK+11] 43 (IT-) Security -1 Schutzziele (Assets): schützende Güter: Informationen, Daten, Budget Zugriff ist zu beschränken/ kontrollieren. Nur frei für eindeutig identifizierte (zu verifizieren!) und autorisierte Subjekte Authentizität von Subjekten (Echtheit/ Glaubwürdigkeit). Bsp.: Benutzername (account) + Passwort/ biometrische Merkmale, (Credentials) Kryptografische Verfahren notwendig bei unsicheren Transportmedien Verfügbarkeit: autorisierten und berechtigten Subjekten ist Zugriff zu ermöglichen Verbindlichkeit/ Zuordenbarkeit: Urheberschaft eines Zugriffs/ Aktion ist im Nachhinein möglich Datenintegrität (integrity): zu schützende Daten können nicht unbemerkt/ unautorisiert manipuliert werden (Rechtefestlegung, Methoden) Informationsvertraulichkeit (confidentitiality): keine unautorisierte Informationsgewinnung Ausführliche Definitionen: Basiswerk: [Eck11] 44 22

23 (IT-) Security -2 Schutzziele müssen zunächst definiert werden. Diese sind nicht automatisch gleich Mensch, Leib, Leben und Umwelt Eine Sicherheitslücke in der IT-Sicherheit wird einmal bekannt mit großer Wahrscheinlichkeit auch ausgenutzt werden. Bekannte Lücken müssen also schnell geschlossen werden und können nicht statistisch erfasst werden Fehlverhalten sind meist Ergebnisse von Angriffen über mehrere (Zwischen-) Stufen und nicht unabhängig. Sie können deshalb mit konventionellen Safety- Methoden nicht offenbart werden [Svo10] Stuxnet: Schadprogramm um das SCADA-System Simatic S7 (Siemens) zu stören. Eingesetzt in Teheran in finnischen Geräten um Atomprogramm/ Urananreicherungsanlage oder Kernkraftwerk zu stören. 10 Jahre Entwicklungszeit mit 5-10 Entwicklern 1 Jahr um von Experten System nachzubauen Kenntnisse über unbekannte Sicherheitslücken mehrere Firmen Komplexer Verbreitungsweg 45 Common Criteria für IT Security Evaluation: ISO/ IEC International harmonisierte Kriterien zur Sicherheits-Evaluierung von IT-Technik EAL 7 Formal verifizierter Entwurf und getestet Katalog zur Spezifikation von Sicherheitsanforderungen Vergleichbarkeit der Ergebnisse von Evaluierungen Stufen der Vertrauenswürdigkeit (EAL) Gefährdungsfaktoren: Höhere Gewalt (Blitzschlag, Feuer, Überschwemmung, ) Fahrlässigkeit (Irrtum, Fehlbedienung, unsachgemäße Bedienung, ) Vorsatz (Manipulation, Einbruch, Hacking, Spionage, Sabotage, ) EAL 6 EAL 5 EAL 4 EAL 3 EAL 2 Semi-formal verifizierter Entwurf und getestet Semi-formal entworfen und getestet Methodisch entwickelt, getestet und durchgesehen Methodisch getestet und überprüft Strukturell getestet 46 Technisches Versagen (Stromausfall, HW- Ausfall, ) Organisatorische Mängel (unberechtigter Zugriff, Raubkopie, ungeschultes Personal, ) EAL 1 Funktionell getestet 23

24 Normen/ Richtlinien -1 IT-Sicherheit für industrielle Leitsysteme Netz- und Systemschutz: ISA 99/ IEC (Industrial Automation and Control Systems (IACS) Security) Empfehlungen für die Entwicklung, den Betrieb und die Beschaffung von IT- Systemen in elektrischen, elektronischen und programmierbaren Bahnsignalanlagen Risiken aufgrund von böswilligen Angriffen Zusätzliche Anforderungen an Systeme die sich durch Bedrohungen der Security ergeben 47 Security Assurance Level SL 1 Bedeutung Angriffe Hilfsmittel Wissen Ressource Motivation zufällig/ gelegentlich SL 2 Absicht einfach allgemein niedrig gering SL 3 Absicht komplex spezifisch moderat moderat SL 4 Absicht komplex spezifisch groß hoch Normen/ Richtlinien -2 Reihe von Standards der IT-Sicherheit: ISO/ IEC 27k Erfüllungsgrad zur Konformität ISMS (Information Security Management System) kann nach beurteilt und zertifiziert werden Vorgaben für Risikoanalyse und bewältigung Ergänzbar durch den Grundschutzkatalog der BSI (Bundesamt für Sicherheit in der Informationstechnik, https://www.bsi.bund.de/de/home/home_node.html ) 48 [Wikipedia] 24

25 implizit initial Erhöhung Effizienz Umfassend Software Assurance Maturity Model (SAMM) Open Web Application Security Project (OWASP) Vier kritische Business Funktionen für Organisationen: Governance: managen von overall -SW-Aktivitäten Strategie, Metriken, Policy, Compliance, Schulung, Richtlinien, Construction: Definition von Zielen und SW-Entwicklung, Produktmanagement, Anforderungsanalyse, Risikomanagement, Security-Anforderungen, Sicherheitsarchitektur, Verification: Überprüfung und Test von bei der SW-Entwicklung produzierten Artefakten Design Reviews, Code Reviews, Security Testing, Deployment: Releaseverwaltung, Lieferung, Betrieb in Echtsystemen Schwächenmanagement, Umgebungen härten, Ermöglichen des Betriebs Startpunkt Verstehen von Security- Methoden Effektivität der Security- Methoden steigern Beherrschung der Security- Methoden 49 s. Auch BSIMM (Building Security In Maturity Model)/ SDL (Security Development Lifecycle) Lösungskonzepte Derzeit verstärkt verfolgt: Konsequente(re)s "Security by Design" (durch Norm geregelt) Standardisierung von Protokollen wie z.b. OPC UA Schulung/ Know-How- und Bewusstseinserhöhung/ Sensibilisierung Drang zur Zertifizierung Einsatz von security-proven IT-Komponenten; Security-Gateway, Chrypt-Module Beobachtung von Anomalien (Vorbeugung von Zero-Day-Exploits) 50 25

26 Beispiel 1 für Methoden: CORAS Prozess zur Security-Risiko-Analyse (basierend auf AS/ NZS 4360 (australische/ neuseeländische Risikomanagementnorm (erste international akzeptierte Risikomanagement-Norm)) Sprache/ Diagramme: grafische Sprache zur Unterstützung der Analyse Kommunikationsbasis/ Dokumentation Semantik: schematische Übersetzung vom Diagramm in Sprache Kalkül: Menge von Regeln für Diagramminterpretation Editor: Tool zur Unterstützung der Diagrammerstellung Freies Tool: Richtlinie zur optimalen Nutzung 51 Beispiel 1 für Methoden: CORAS : Risikomaßnahmen Gefahren Schwachstellen Unerwünschte Ereignisse Assets Angriffs-Szenario Konsequenzen 52 Risiko- Maßnahmen Wahrscheinlichkeiten p(ereignis) + Konsequenz -> Risiko 26

27 Beispiel 2: Model-Based Security Testing (MBST) ITEA2-Projekt DIAMONDS (Fraunhofer Institut FOKUS, Berlin) [SGS12] Validierung von Software System-Anforderungen bezogen auf Security- Eigenschaften (Vertraulichkeit, Datenintegrität, Authentizität, Verfügbarkeit, ) Systematische und effiziente Spezifikation und Dokumentation von Security-Test- Objekten, Security-Testfällen und Security-Testsuiten Bestandteile: Security Funktionale Tests Model-Based Fuzzing Risiko- und Gefahren-orientiertes Testen Security Test-Pattern Aussagen der Studie: 90% aller SW-Security Störfälle werden durch Angreifer, die Schwachstellen kennen verursacht Die meisten Schwachstellen entstehen durch Software-Fehler oder Design-Mängel Systematisches Testen erhöht die Wahrscheinlichkeit Fehler und Schwachstellen während Design aufzudecken. 53 Agenda Vorstellung Motivation Einführung Einordnung - Methoden Safety - Besonderheiten Safety vs. Security Security - Besonderheiten Zusammenfassung/ Ausblick 54 27

28 Zusammenfassung/ Ausblick Weitere Stichwörter: Error seeding Model based testing Design oriented testing Toolsqualifikation (normengefordert) Nichtfunktionale Anforderungen 55 Zusammenfassung - Ausblick Ausblick dimension Safety Security functional attack definition by functional safety/ RAMS definition of assets: access, authenticity, prevention of accidential failures intentional attacks standards well-known methods in preparation (domain dependent) kind of hazard technical systems harms people and people harms technical systems by environment without intention intention parameter to define risk level risk for life and body/ environment; risk attacker view: motivation, intention, graph; frequency x damage available tools, ressourced, skill, techniques FMEA, hazop, FTA, hazop, CRAMM, CORAS, ATA, failures are considered as independant not independant severity/ ranking according safety integrity level/ performance level/ security/ evaluation assurance design assurance level/ (confidence) operation mode safe under normal conditions further operation in case of attacks reaction on events redundancy/ switch into fail-safe state faile-secure, keep normal operation awareness high: safety first (to) low: security only for safety/ availability first (known) gaps in a system will have an impact randomly/ by accident will be exploited someday by someone implementation simple and easy to understand obfuscation; prevent re-engineering dependency safety needs security security needs no safety willingness to pay additionally existing for not existing 56 28

29 Literatur/ Referenzen -1 [Bau14] Vortrag Klaus Bauer, Sicherheit aus dem Blickwinkel einer Maschine ; Kongress Sicherheit und Automation 2014 [CMK+11] Stephen Checkoway, Damon McCoy, Brian Kantor, Danny Anderson, Hovav Shacham, and Stefan Savage University of California, San Diego; Karl Koscher, Alexei Czeskis, Franziska Roesner, and Tadayoshi Kohno University of Washington Comprehensive Experimental Analyses of Automotive Attack Surfaces (http://www.autosec.org/pubs/cars-usenixsec2011.pdf ) [Den91] Ernst Denert: Software-Engineering. Springer, Berlin 1991, 1992 [DZGSP08] CHIP, Markus Mandau, , 2008 [Eck11] Claudia Eckert: IT-Sicherheit: Konzepte Verfahren Protokolle ; Oldenbourg Wissenschaftsverlag; 2011 [IEC-61508] Standard Functional safety of electrical/electronic/programmable electronic safety-related systems [Lie14] Dynamische Programmanalyse Seminar: Verfahren zur Analyse von Programmcode. Julian Liedtke; [MiVa2014] A Survey of Remote Automotive Attack Surfaces ; Charlie Miller & Chris Valasek; Black Hat USA 2014, Las Vegas; August Literatur/ Referenzen -2 [Sch12] Vortrag D. J. Schwarz: Einführung der ISO in die Automobilindustrie Umfängliche Prozesse nachhaltig in eine laufende Entwicklung integrieren ; [SESAMO14] EU-ARTEMIS-Projekt (http://sesamo-project.eu/ ) [SGS11] Ina Schieferdecker, Jürgen Großmann, Martin Schneider (Fraunhofer FOKUS; Model-Based Security Testing (http://arxiv.org/pdf/ pdf ) [SM08] Jill Slay, Michael Mille, ifip, International Federation for Information Processing; Critical Infrastructure Protection; Chapter 6 LESSONS LEARNED FROM THE MAROOCHY WATER BREACH (http://www.ifip.org/wcc2008/site/ifipsamplechapter.pdf ) [Spi04] Basiswissen Softwaretest, Andreas Spillner, Tilo Linz, Dpunkt Verlag; Auflage: 2. überarb. A. (2004) [Sto09] Ketil Stolen, SINTEF & UiO, Security Analysis: The CORAS Approach [Svo10] Milos Svoboda; 8. Safetrans Industrial day; Safety and Security in Industrial environments [Zel03] A. Zeller. Program Analysis: A Hierarchy. Proceedings of ICSE Workshop on Dynamic Analysis, (WODA 2003),

30 Glossar 59 BSI = Bundesamt für Sicherheit in der Informationstechnik BSIMM = Building Security In Maturity Model CEN = European Committee for Standardization CRAMM = CCTA Risk Analysis and Management Method CPS = Cyber-physisches System DDoS = Distributed Denial of Service (Dienstverweigerung) EAL = Evaluation Assurance Level IEC = International Electrotechnical Commission FOKUS = Fraunhofer Institut für Offene Kommunikationssysteme ISMS = Information Security Management System ISA = International Society of Automation ISO = International Organization for Standardization ITEA = Information Technology for European Advancement MBST = Model Based Security Testing MES = Manufacturing Execution System OPC UA = OLE (Object Linking and Embedding) for Process Control Unified Architecture OWASP = Open Web Application Security Project SAMM = Software Assurance Maturity Modell SCADA = Supervisory Control and Data Acquisition (Überwachen und steuern technischer Systeme) SDL = Security Development Lifecycle SEI = Software Engineering Institute SIL = Safety Integrity Level S(A)L = Security (Assurance) Level Fragen/ Diskussion/ AOB 60 30

Validierung und Verifikation!

Validierung und Verifikation! Martin Glinz Thomas Fritz Software Engineering Kapitel 7 Validierung und Verifikation 2005-2013 Martin Glinz. Alle Rechte vorbehalten. Speicherung und Wiedergabe für den persönlichen, nicht kommerziellen

Mehr

CeBIT 17.03.2015. CARMAO GmbH 2014 1

CeBIT 17.03.2015. CARMAO GmbH 2014 1 CeBIT 17.03.2015 CARMAO GmbH 2014 1 HERZLICH WILLKOMMEN Applikationssicherheit beginnt lange bevor auch nur eine Zeile Code geschrieben wurde Ulrich Heun Geschäftsführender Gesellschafter der CARMAO GmbH

Mehr

Security for Safety in der Industrieautomation Konzepte und Lösungsansätze des IEC 62443

Security for Safety in der Industrieautomation Konzepte und Lösungsansätze des IEC 62443 Security for Safety in der Industrieautomation Konzepte und Lösungsansätze des IEC 62443 Roadshow INDUSTRIAL IT SECURITY Dr. Thomas Störtkuhl 18. Juni 2013 Folie 1 Agenda Einführung: Standard IEC 62443

Mehr

Qualitätssicherung von Software (SWQS)

Qualitätssicherung von Software (SWQS) Qualitätssicherung von Software (SWQS) Prof. Dr. Holger Schlingloff Humboldt-Universität zu Berlin und Fraunhofer FOKUS 20.6.2013: Sicherheitsnormen Folie 2 Fragen zur Wiederholung Wie funktioniert ein

Mehr

Testen - Konzepte und Techniken

Testen - Konzepte und Techniken Testen - Konzepte und Techniken Magdalena Luniak 21.11.2007 Magdalena Luniak () Testen - Konzepte und Techniken 21.11.2007 1 / 42 Übersicht 1 Motivation 2 Grundbegrie 3 Testen im Softwareentwicklungsprozess

Mehr

There is no security on this earth. Na und? General Douglas MacArthur. Alfred E. Neumann

There is no security on this earth. Na und? General Douglas MacArthur. Alfred E. Neumann There is no security on this earth. Na und? General Douglas MacArthur Alfred E. Neumann Anwendungen verursachen Unsicherheit Ca. ¾ aller Schwachstellen stammen aus Anwendungen. Cryptography 0% Application

Mehr

Teststrategie festlegen und Teststufen aufeinander abstimmen

Teststrategie festlegen und Teststufen aufeinander abstimmen Testen Teststrategie festlegen und Teststufen aufeinander abstimmen Bereich Projektplanung und -steuerung Aktivität Projekt planen Ziele Effiziente Testausführung Vermeidung von doppelter Arbeit schnell

Mehr

Security in der industriellen Automatisierung im aktuellen Kontext

Security in der industriellen Automatisierung im aktuellen Kontext Anna Palmin, Dr. Pierre Kobes /18 November 2014, KommA 2014 Security in der industriellen Automatisierung im aktuellen Kontext Restricted Siemens AG 20XX All rights reserved. siemens.com/answers Security

Mehr

Sicherheit und Qualität digitaler Leittechnik eine wesentliche Voraussetzung für Kraftwerke der Zukunft

Sicherheit und Qualität digitaler Leittechnik eine wesentliche Voraussetzung für Kraftwerke der Zukunft Sicherheit und Qualität digitaler Leittechnik eine wesentliche Voraussetzung für Kraftwerke der Zukunft Dr. Guido Rettig Chairman of the Board TÜV NORD AG 1 Vertikale und horizontale Kommunikation in der

Mehr

Secure SDLC für die Masse dank OpenSAMM? OWASP 17.11.2011. The OWASP Foundation. Dr. Bruce Sams. http://www.owasp.org

Secure SDLC für die Masse dank OpenSAMM? OWASP 17.11.2011. The OWASP Foundation. Dr. Bruce Sams. http://www.owasp.org Secure SDLC für die Masse dank OpenSAMM? Dr. Bruce Sams 17.11.2011 Copyright The Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the License. The Foundation

Mehr

Funktionale Sicherheit ISO 26262 Schwerpunkt Requirements Engineering,

Funktionale Sicherheit ISO 26262 Schwerpunkt Requirements Engineering, Funktionale Sicherheit ISO 26262 Schwerpunkt Requirements Engineering, Manfred Broy Lehrstuhl für Software & Systems Engineering Technische Universität München Institut für Informatik ISO 26262 Functional

Mehr

Fred Stay 2013-06-04/05. Management der Funktionalen Sicherheit KROHNE Academy Automatisierungstechnik in der Prozessindustrie

Fred Stay 2013-06-04/05. Management der Funktionalen Sicherheit KROHNE Academy Automatisierungstechnik in der Prozessindustrie Fred Stay 2013-06-04/05 Management der Funktionalen Sicherheit KROHNE Academy Automatisierungstechnik in der Prozessindustrie 1. Warum brauchen wir ein FSM 2. Vermeidung/Beherrschung von Fehlern 3. Praxisbeispiel:

Mehr

Einführung eines ISMS nach ISO 27001:2013

Einführung eines ISMS nach ISO 27001:2013 Einführung eines ISMS nach ISO 27001:2013 VKU-Infotag: Anforderungen an die IT-Sicherheit (c) 2013 SAMA PARTNERS Business Solutions Vorstellung Olaf Bormann Senior-Consultant Informationssicherheit Projekterfahrung:

Mehr

Beuth Hochschule BEUTH HOCHSCHULE FÜR TECHNIK BERLIN University of Applied Sciences

Beuth Hochschule BEUTH HOCHSCHULE FÜR TECHNIK BERLIN University of Applied Sciences Beuth Hochschule BEUTH HOCHSCHULE FÜR TECHNIK BERLIN University of Applied Sciences WISSENSCHAFTLICHE WEITERBILDUNG Fernstudium Industrial Engineering Produktions- und Betriebstechnik Kurseinheit 98 und

Mehr

Basiswissen Softwaretest

Basiswissen Softwaretest Andreas Spillner Tilo Linz Basiswissen Softwaretest Aus- und Weiterbildung zum Certified Tester Foundation Level nach ISTQB-Standard 3., überarbeitete und aktualisierte Auflage I Technische l'^vrau«! D~w.-iE*arit

Mehr

Security 4 Safety. Markus Bartsch, Christian Freckmann

Security 4 Safety. Markus Bartsch, Christian Freckmann Security 4 Safety Markus Bartsch, Christian Freckmann Internet der Dinge Samsung und Android Samsung Samsung TÜV Informationstechnik GmbH Member of TÜV NORD Group 1 Heise-Meldungen Industrieanlagen schutzlos

Mehr

Risikobasierte Software- Architektur für sicherheitskritische Systeme. Erik Steiner Matthias Seeland. Organized by:

Risikobasierte Software- Architektur für sicherheitskritische Systeme. Erik Steiner Matthias Seeland. Organized by: Di 2.4 January 22 th -26 th, 2007, Munich/Germany Organized by: Lindlaustr. 2c, 53842 Troisdorf, Tel.: +49 (0)2241 2341-100, Fax.: +49 (0)2241 2341-199 www.oopconference.com Architektur für Folie 1 Consulting

Mehr

CRAMM. CCTA Risikoanalyse und -management Methode

CRAMM. CCTA Risikoanalyse und -management Methode CRAMM CCTA Risikoanalyse und -management Methode Agenda Überblick Markt Geschichte Risikomanagement Standards Phasen Manuelle Methode Business Continuity Vor- und Nachteile Empfehlung! ""# # Überblick

Mehr

Automatisiertes Testen von Prüfplätzen

Automatisiertes Testen von Prüfplätzen EXCO. The Quality Company Solutions for Industry and R&D Automatisiertes Testen von Prüfplätzen Am Beispiel einer Prüfplatz-Software stellen wir einen toolgestützten Prozess zur Erstellung der erforderlichen

Mehr

den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015

den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015 Agile Methoden als Diagnose-Tool für den sicherheitskritischen Bereich Christoph Schmiedinger Frankfurter Entwicklertag 2015 24.02.2015 Über mich Berufliche Erfahrung 3 Jahre Projektabwicklung 2 Jahre

Mehr

Einführung in die ISO 26262

Einführung in die ISO 26262 Einführung in die ISO 26262 Herausforderungen für das Management von Verifikations- und Validationsdaten Dr. Ralf Nörenberg HighQSoft GmbH 19.08.2012 HighQSoft GmbH www.highqsoft.de Einführung in die ISO

Mehr

IV Software-Qualitätssicherung

IV Software-Qualitätssicherung Softwaretechnik- Praktikum: 12. Vorlesung Jun.-Prof Prof.. Dr. Holger Giese Raum E 3.165 Tel. 60-3321 Email: hg@upb.de Übersicht I II III IV V Einleitung Ergänzungen zur Software-Entwicklung Software Management

Mehr

Änderungen ISO 27001: 2013

Änderungen ISO 27001: 2013 Änderungen ISO 27001: 2013 Loomans & Matz AG August-Horch-Str. 6a, 55129 Mainz Deutschland Tel. +496131-3277 877; www.loomans-matz.de, info@loomans-matz.de Die neue Version ist seit Oktober 2013 verfügbar

Mehr

Leitfaden zum sicheren Betrieb von Smart Meter Gateways

Leitfaden zum sicheren Betrieb von Smart Meter Gateways Leitfaden zum sicheren Betrieb von Smart Meter Gateways Wer Smart Meter Gateways verwaltet, muss die IT-Sicherheit seiner dafür eingesetzten Infrastruktur nachweisen. Diesen Nachweis erbringt ein Gateway-

Mehr

Industrial IT Security in Embedded Systems - was leistet die Norm IEC 62443? von Dipl.-Ing. (FH) Sebastian Schmidt

Industrial IT Security in Embedded Systems - was leistet die Norm IEC 62443? von Dipl.-Ing. (FH) Sebastian Schmidt Industrial IT Security in Embedded Systems - was leistet die Norm IEC 62443? von Dipl.-Ing. (FH) Sebastian Schmidt Die Vernetzung von Computer Systemen macht auch vor industriellen Systemen nicht halt.

Mehr

Senior Consulting. Senior Consulting Strategical, Conceptual and Technical Consulting. 30.01.2011 Seite 1

Senior Consulting. Senior Consulting Strategical, Conceptual and Technical Consulting. 30.01.2011 Seite 1 30.01.2011 Seite 1 This flyer is exclusively for the use of client personnel. No part of it may be distributed, quoted or reproduced outside the client organisation without the prior written approval of

Mehr

Testen von Data-Warehouse- und Business-Intelligence-Systemen

Testen von Data-Warehouse- und Business-Intelligence-Systemen Edition TDWI Testen von Data-Warehouse- und Business-Intelligence-Systemen Vorgehen, Methoden und Konzepte von Herbert Stauffer, Beat Honegger, Hanspeter Gisin 1. Auflage Testen von Data-Warehouse- und

Mehr

Industrie 4.0 Frei verwendbar / Siemens AG 2015. Alle Rechte vorbehalten.

Industrie 4.0 Frei verwendbar / Siemens AG 2015. Alle Rechte vorbehalten. Mario Fürst, Siemens Schweiz AG Industrie 4.0 Das Internet revolutioniert die Geschäftswelt Seite 2 Industrie 4.0 ist eine Initiative der deutschen Industrie, die von der deutschen Bundesregierung unterstützt

Mehr

Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich

Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich Weiterentwicklung der EN 50128 (VDE 0831-128) 128) Umsetzung im Bahnbereich Andreas Armbrecht Siemens AG Darmstadt, 01. 02. Dezember 2009 Business Unit Rail Automation Systeme der Eisenbahnautomatisierung

Mehr

Simulation der SW-Systemzuverlässigkeit in Automatisierungssystemen auf Grundlage von SW-Komponenten

Simulation der SW-Systemzuverlässigkeit in Automatisierungssystemen auf Grundlage von SW-Komponenten Universität Stuttgart Institut für Automatisierungs- und Softwaretechnik Prof. Dr.-Ing. Dr. h. c. P. Göhner Simulation der SW-Systemzuverlässigkeit in Automatisierungssystemen auf Grundlage von SW-Komponenten

Mehr

Testautomatisierung. Lessons Learned. qme Software. Gustav-Meyer-Allee 25 13355 Berlin. Telefon 030/46307-230 Telefax 030/46307-649

Testautomatisierung. Lessons Learned. qme Software. Gustav-Meyer-Allee 25 13355 Berlin. Telefon 030/46307-230 Telefax 030/46307-649 Testautomatisierung Lessons Learned qme Software GmbH Gustav-Meyer-Allee 25 13355 Berlin Telefon 030/46307-230 Telefax 030/46307-649 E-Mail qme Software info@qme-software.de GmbH Testautomatisierung Lessons

Mehr

Sicherheit in Eingebetteten IP-basierten Systemen. TP 4: Security. Dr. Benjamin Glas Robert Bosch GmbH. Seite 1

Sicherheit in Eingebetteten IP-basierten Systemen. TP 4: Security. Dr. Benjamin Glas Robert Bosch GmbH. Seite 1 Sicherheit in Eingebetteten IP-basierten Systemen TP 4: Security Dr. Benjamin Glas Robert Bosch GmbH Seite 1 Security im Automobil zunehmend im Fokus Angriffsmotivation mehr als Diebstahl... Funktionsmanipulation

Mehr

Systematisches Testen von Software

Systematisches Testen von Software Programmierung Systematisches Testen von Software Markus Eckstein Systematika Information Systems GmbH Kurfürsten-Anlage 36 69115 Heidelberg markus.eckstein@systematika.com Zusammenfassung Die wichtigsten

Mehr

Industrial Control Systems Security

Industrial Control Systems Security Industrial Control Systems Security Lerneinheit 4: Risk Assessment Prof. Dr. Christoph Karg Studiengang Informatik Hochschule Aalen Wintersemester 2013/2014 20.1.2014 Einleitung Einleitung Das Thema dieser

Mehr

Leitfaden API. Testing und Debugging. Erstellt am 4.9.2014 Autor FG API, Rinaldo Lanza. Dokumentenstatus Freigegeben at work Version 1.

Leitfaden API. Testing und Debugging. Erstellt am 4.9.2014 Autor FG API, Rinaldo Lanza. Dokumentenstatus Freigegeben at work Version 1. Leitfaden API Erstellt am 4.9.2014 Autor FG API, Rinaldo Lanza Dokumentenstatus Freigegeben at work Version 1.0 Verteiler Fachgruppe API Änderungen Datum Version Autor Inhaltsverzeichnis 1 Beschreibung

Mehr

Absicherung von Automotive Software Funktionen

Absicherung von Automotive Software Funktionen GI Themenabend "Automotive" Absicherung von Automotive Software Funktionen 27.02.2013 Jürgen Schüling Überblick Berner & Mattner Gründung: 1979 Mitarbeiter: 400 Umsatz 2011: Standorte: Angebot: Branchen:

Mehr

Sicherheit im IT Umfeld

Sicherheit im IT Umfeld Sicherheit im IT Umfeld Eine Betrachtung aus der Sicht mittelständischer Unternehmen Sicherheit im IT Umfeld Gibt es eine Bedrohung für mein Unternehmen? Das typische IT Umfeld im Mittelstand, welche Gefahrenquellen

Mehr

4. Stuttgarter Sicherheitskongress: IT-Sicherheit in industriellen Anlagen

4. Stuttgarter Sicherheitskongress: IT-Sicherheit in industriellen Anlagen 4. Stuttgarter Sicherheitskongress: IT-Sicherheit in industriellen Anlagen Henning Sandfort Siemens AG, Sector Industry SIMATIC Produkt- & Systemmanagement Allgemeine Security-Bedrohungen in der Automatisierung

Mehr

Software-Qualität Ausgewählte Kapitel

Software-Qualität Ausgewählte Kapitel Martin Glinz Software-Qualität Ausgewählte Kapitel Kapitel 1 Einführung Universität Zürich Institut für Informatik 2009 Martin Glinz. Alle Rechte vorbehalten. Speicherung und Wiedergabe sind für den persönlichen,

Mehr

Aktuelle Herausforderungen der Automobil-Industrie beim Rollout der ISO 26262. Polarion Live User Conference 2013 Heiko Lerch, ITK Engineering AG

Aktuelle Herausforderungen der Automobil-Industrie beim Rollout der ISO 26262. Polarion Live User Conference 2013 Heiko Lerch, ITK Engineering AG Aktuelle Herausforderungen der Automobil-Industrie beim Rollout der ISO 26262 Polarion Live User Conference 2013 Heiko Lerch, ITK Engineering AG Auf einen Blick Expandierend Gründung: 1994 Zertifiziert

Mehr

Integrierte modellgestützte Risikoanalyse komplexer Automatisierungssysteme

Integrierte modellgestützte Risikoanalyse komplexer Automatisierungssysteme Universität Stuttgart Institut für Automatisierungs- und Softwaretechnik Prof. Dr.-Ing. Dr. h. c. P. Göhner Integrierte modellgestützte Risikoanalyse komplexer Automatisierungssysteme Dipl.-Ing. Michael

Mehr

Testmanagement in IT-Projekten

Testmanagement in IT-Projekten Teil 1: Projektmagazin 05/20009 Teil 2: Projektmagazin 06/2009 1 Test: Prozess, bei dem ein Programm oder ein Software-System ausgeführt wird, um Fehler zu finden Teil 1: Projektmagazin 05/20009 Teil 2:

Mehr

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015

Software Engineering mit Übungen. Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering mit Übungen Franz-Josef Elmer, Universität Basel, HS 2015 Software Engineering 2 Organisation Ort: Seminarraum 05.002, Spiegelgasse 5 Ablauf: 15:15 Vorlesung Prüfung: Schriftlich,

Mehr

Testphase. Das Testen

Testphase. Das Testen Testphase VIS Projekt Freie Universität Berlin N.Ardet - 17.4.2001 Das Testen Testen ist das Ausführen eines Software- (Teil)systems in einer definierten Umgebung und das Vergleichen der erzielten mit

Mehr

TESTPLAN

TESTPLAN <Projektname> Firma TESTPLAN ID Version Ersteller: ------------------- Vorgesetzter des Erstellers:

Mehr

AnyWeb AG 2008 www.anyweb.ch

AnyWeb AG 2008 www.anyweb.ch Agenda - BTO IT heute Was nützt IT dem Business? Die Lösung: HP Software BTO Q&A IT heute Kommunikation zum Business funktioniert schlecht IT denkt und arbeitet in Silos und ist auch so organisiert Kaum

Mehr

Wieviel Usability Engineering braucht das Software Engineering?

Wieviel Usability Engineering braucht das Software Engineering? Wieviel Usability Engineering braucht das Software Engineering? Prof. Dr. Institut für Informatik Neuenheimer Feld 348 69120 Heidelberg http://www-swe.uni-heidelberg.de paech@informatik.uni-heidelberg.de

Mehr

IT-Sicherheitsmanagement IT Security Management

IT-Sicherheitsmanagement IT Security Management Sommerakademie 2006, 28. August, Kiel Summer Conference 2006, 28th August, Kiel IT-Sicherheitsmanagement IT Security Management Dr. Martin Meints, ULD Dr. Martin Meints, ICPP Inhalt Allgemeine Überlegungen

Mehr

Safer Software Formale Methoden für ISO26262

Safer Software Formale Methoden für ISO26262 Safer Software Formale Methoden für ISO26262 Dr. Stefan Gulan COC Systems Engineering Functional Safety Entwicklung Was Wie Wie genau Anforderungen Design Produkt Seite 3 Entwicklung nach ISO26262 Funktionale

Mehr

Schulungen zur IEC 61508

Schulungen zur IEC 61508 Schulungen zur IEC 61508 Funktionale Sicherheit Automation, Software, Halbleiter und branchenübergreifend Komplettes Trainingsprogramm von TÜV SÜD Inhouse und/oder modular TÜV SÜD Automotive GmbH Warum

Mehr

1.1 Basiswissen komprimiert... 4 1.2 Praxiswissen Testmanagement Übersicht... 8. 2 Testprozess und Testwerkzeuge 11

1.1 Basiswissen komprimiert... 4 1.2 Praxiswissen Testmanagement Übersicht... 8. 2 Testprozess und Testwerkzeuge 11 xi 1 Einleitung 1 1.1 Basiswissen komprimiert.......................... 4 1.2 Praxiswissen Testmanagement Übersicht.............. 8 2 Testprozess und Testwerkzeuge 11 2.1 Fundamentaler Testprozess.........................

Mehr

Systemen - Testen im Softwarelebenszyklus

Systemen - Testen im Softwarelebenszyklus P r a k t I s c h e Entwicklung und Test Testen von Software-Systemen Systemen - Testen im Softwarelebenszyklus Entwickler erstellen ihr System bzw. ihre Software und testen es/sie zur Entwicklungszeit

Mehr

Software-Lebenszyklus

Software-Lebenszyklus Software-Lebenszyklus Inhalt Vorgehensmodell/Phasenplan Wasserfallmodell WAS-Beschreibung WIE-Beschreibung Weitere Phasenmodelle: Spiral-Modell, V-Modell, RUP Extreme Programming SW-Qualitätssicherung

Mehr

Softwarequalitätssicherung

Softwarequalitätssicherung Softwarequalitätssicherung Dipl. Inf. Andrea Meyer Medieninformatik (Bachelor), Wahlpflichtmodul: Softwareprojekt II, Dipl. Inf. Andrea Meyer Warum Softwarequalitätssicherung? 2 Fatale Softwarefehler Ariane

Mehr

1. Zweckdes Dokuments

1. Zweckdes Dokuments Testplanung Testplanung 1.Zweck des Dokuments 2.Testziele 3.Teststrategie 4. Inkrementeller Test 5. Dokumentation der Tests 6. Performance Test 7. Literaturreferenzen 1. Zweckdes Dokuments Dokumentation

Mehr

ISO & IKS Gemeinsamkeiten. SAQ Swiss Association for Quality. Martin Andenmatten

ISO & IKS Gemeinsamkeiten. SAQ Swiss Association for Quality. Martin Andenmatten ISO & IKS Gemeinsamkeiten SAQ Swiss Association for Quality Martin Andenmatten 13. Inhaltsübersicht IT als strategischer Produktionsfaktor Was ist IT Service Management ISO 20000 im Überblick ISO 27001

Mehr

Informations- / IT-Sicherheit Standards

Informations- / IT-Sicherheit Standards Ziele Informations- / IT-Sicherheit Standards Überblick über Ziele, Anforderungen, Nutzen Ingrid Dubois Grundlage zuverlässiger Geschäftsprozesse Informationssicherheit Motivation Angemessenen Schutz für

Mehr

Risikomanagement für IT-Netzwerke mit Medizinprodukten. FH-Prof. Dipl.-Ing. Alexander Mense, CISSP Ing. Franz Hoheiser-Pförtner, MSc, CISSP

Risikomanagement für IT-Netzwerke mit Medizinprodukten. FH-Prof. Dipl.-Ing. Alexander Mense, CISSP Ing. Franz Hoheiser-Pförtner, MSc, CISSP Risikomanagement für IT-Netzwerke mit Medizinprodukten FH-Prof. Dipl.-Ing. Alexander Mense, CISSP Ing. Franz Hoheiser-Pförtner, MSc, CISSP Agenda Ausgangssituation Herausforderungen Der erste Schritt als

Mehr

Security und Safety in der Eisenbahnsignaltechnik das Yin und Yang der Systemsicherheit?

Security und Safety in der Eisenbahnsignaltechnik das Yin und Yang der Systemsicherheit? Security und Safety in der Eisenbahnsignaltechnik das Yin und Yang der Systemsicherheit? Prof. Dr. Jens Braband Siemens AG Safety in Transportation, November 2011 Siemens AG 2008 2011 Einführung Yin und

Mehr

Testmanagement. Q-Day. Frank Böhr Fraunhofer IESE frank.boehr@iese.fraunhofer.de

Testmanagement. Q-Day. Frank Böhr Fraunhofer IESE frank.boehr@iese.fraunhofer.de Frank Böhr Fraunhofer IESE frank.boehr@iese.fraunhofer.de Agenda Warum Testmanagement? Was sind die wichtigsten Schritte beim Testmanagement? Wie funktioniert Testmanagement Toolunterstützung Page 1/15

Mehr

Konzeptentwicklung Akkreditierte Software Prüfstelle

Konzeptentwicklung Akkreditierte Software Prüfstelle Konzeptentwicklung Akkreditierte Software Prüfstelle Durchgeführt an der Betreuer Autoren Datum Naturwissenschaftlichen Fakultät der Universität Salzburg Fachbereich Computerwissenschaften Uni.-Prof. Dipl.-Ing.

Mehr

IT-Sicherheit in der Automation ein Missverständnis?

IT-Sicherheit in der Automation ein Missverständnis? Automationskolloquium 2012 IT-Sicherheit in der Automation ein Missverständnis? Prof. Dr. Frithjof Klasen Institut für Automation & Industrial IT FH Köln Ulm, 26.09.2012 Institut Automation & Industrial

Mehr

BSI ICS-SECURITY-KOMPENDIUM

BSI ICS-SECURITY-KOMPENDIUM BSI ICS-SECURITY-KOMPENDIUM SICHERHEIT VON INDUSTRIELLEN STEUERANLAGEN Andreas Floß, Dipl.-Inform., Senior Consultant Information Security Management, HiSolutions AG 1 HiSolutions 2013 ICS-Kompendium Vorstellung

Mehr

Arbeitskreis Sichere Smart Grids Kick-off

Arbeitskreis Sichere Smart Grids Kick-off Arbeitskreis Sichere Smart Grids Kick-off 30. Juli 2013, 16.30 bis 18.30 Uhr secunet Security Networks AG, Konrad-Zuse-Platz 2, 81829 München Leitung: Steffen Heyde, secunet Agenda: 16.30 Uhr Begrüßung

Mehr

Fachtagung Safety in Transportation Leitfaden für die IT Sicherheit auf Grundlage IEC 62443

Fachtagung Safety in Transportation Leitfaden für die IT Sicherheit auf Grundlage IEC 62443 Fachtagung Safety in Transportation Leitfaden für die IT Sicherheit auf Grundlage IEC 62443 DKE UK 351.3.7 Hans-Hermann Bock 1 Braunschweig, 06.11.2013 Anwendungsbereich der Vornorm (1) Diese Vornorm ist

Mehr

In der Entwicklung werden die Phasen Systementwurf, Projekten mit Funktionaler Sicherheit. Testen in TESTMETHODEN

In der Entwicklung werden die Phasen Systementwurf, Projekten mit Funktionaler Sicherheit. Testen in TESTMETHODEN MESSEN UND TESTENl AUTOMOTIVE 11.2011l43 TESTMETHODEN Testen in Projekten mit Funktionaler Sicherheit Die ISO 26262 beschreibt die Aktivitäten, Methoden und Maßnahmen zur Funktionalen Sicherheit für elektrische

Mehr

informiert Safety Integrity Level (SIL) Funktionale Sicherheit in der Anlageninstrumentierung Experience In Motion

informiert Safety Integrity Level (SIL) Funktionale Sicherheit in der Anlageninstrumentierung Experience In Motion informiert Safety Integrity Level (SIL) Funktionale Sicherheit in der Anlageninstrumentierung Mit Veröffentlichung der EN 12952 bzw. 53 im Dezember 2008 wurde auch für den Bereich der Ausrüstung von Dampf-

Mehr

Der Weg zu einem ganzheitlichen GRC Management

Der Weg zu einem ganzheitlichen GRC Management Der Weg zu einem ganzheitlichen GRC Management Die Bedeutung von GRC Programmen für die Informationsicherheit Dr. Michael Teschner, RSA Deutschland Oktober 2013 1 Transformationen im Markt Mobilität Cloud

Mehr

Thema: Testen von objektorientierter Software

Thema: Testen von objektorientierter Software Seminar Simulation und Bildanalyse mit Java Thema: Testen von objektorientierter Software Uta Dienst 1. Teil: Einführung in den Software-Test 2. Teil: JUnit-Einführung Uta Dienst 17.11.2003 2 1. Teil:

Mehr

Thomas Freitag achelos GmbH SmartCard-Workshop. 1 2012 achelos GmbH

Thomas Freitag achelos GmbH SmartCard-Workshop. 1 2012 achelos GmbH Thomas Freitag achelos GmbH SmartCard-Workshop 2012 1 2012 achelos GmbH Übersicht 1. 2. 3. 4. 5. 6. 7. Einführung / Motivation Historie des Testens Schnittstellen im Testbereich Eclipse Plugins Automatisierung,

Mehr

Qualifikationstests für Automotive-Komponenten

Qualifikationstests für Automotive-Komponenten AUTOMOTIVE INFOKOM MOBILITÄT, ENERGIE & UMWELT LUFTFAHRT RAUMFAHRT VERTEIDIGUNG & SICHERHEIT Qualifikationstests für Automotive-Komponenten Christoph Hauck emobility 17.03.2014 CoC SAFETY Agenda Nr. Thema

Mehr

Nürnberg, 25.11.2014 Kongress SPS/IPC/Drives 2014. Technische Sicherheitstests

Nürnberg, 25.11.2014 Kongress SPS/IPC/Drives 2014. Technische Sicherheitstests Nürnberg, 25.11.2014 Kongress SPS/IPC/Drives 2014 Technische Sicherheitstests von Industrial Control Systems (ICS) Autoren Heiko Rudolph heiko.rudolph@admeritia.de +49 2173 20363-0 +49 162 2414691 Aaron

Mehr

Kompromittierte IT? Wieder in Compliance überführen! Configuration Control. Uwe Maurer Senior Practice Leader Secure Operations 20.03.

Kompromittierte IT? Wieder in Compliance überführen! Configuration Control. Uwe Maurer Senior Practice Leader Secure Operations 20.03. Configuration Control Uwe Maurer Senior Practice Leader Secure Operations 20.03.2013 Kompromittierte IT? Wieder in Compliance überführen! www.integralis.com Agenda Vorstellung Ablauf eines komplexen Angriffs

Mehr

Massive Automatisierung von Software-Tests. In einem agilen Automotive Projekt

Massive Automatisierung von Software-Tests. In einem agilen Automotive Projekt Massive Automatisierung von Software-Tests In einem agilen Automotive Projekt Inhalt Die Projektziele Die Projektstruktur und die Rahmenbedingungen Automotive SPICE und Scrum Die Automatisierung der SW-Testfälle

Mehr

Systematische Software-Qualität mittels einer durchgängigen Analyse- und Teststrategie

Systematische Software-Qualität mittels einer durchgängigen Analyse- und Teststrategie Insert picture and click Align Title Graphic. Systematische Software-Qualität mittels einer durchgängigen Analyse- und Teststrategie Dr. Dieter Lederer, Geschäftsführer Vector Consulting Services GmbH

Mehr

3. Vorgehensmodelle Software Engineering. Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006

3. Vorgehensmodelle Software Engineering. Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006 3. Vorgehensmodelle Software Engineering Prof. Dr. Bernhard Humm Hochschule Darmstadt, 23. Oktober 2006 Agenda Agenda Übersicht V-Modell Rational Unified Process Extreme Programming Fazit, Literatur, Kontrollfragen

Mehr

Abweichungsmanagement. Probleme hat doch jeder

Abweichungsmanagement. Probleme hat doch jeder 1 Abweichungsmanagement Probleme hat doch jeder SEQIS Software Testing Know-how Veranstaltungen 2011 24.03.2011 16.06.2011 22.09.2011 24.10.2011 Nicht zuviel und nicht zuwenig: Testdokumentation Theorie

Mehr

Kommunikation im Internet der Dinge Sicherheit, Performance, Management,...

Kommunikation im Internet der Dinge Sicherheit, Performance, Management,... Software Factory www.sf.com Kommunikation im Internet der Dinge Sicherheit, Performance, Management,... Thomas Trägler Agenda Software Factory Kurzvorstellung Sicherheit (Security) und Industrie 4.0 Kommunikationsszenarien

Mehr

ISTQB Certified Tester Foundation Level Exam Übungsprüfung

ISTQB Certified Tester Foundation Level Exam Übungsprüfung BEMERKUG: Bitte nur eine Antwort auf jede Frage 1. Die statische Analyse kann höchstwahrscheinlich ICHT finden: (A) Die Verwendung einer Variablen bevor diese definiert wurde. (B) Unerreichbaren ( toten

Mehr

Sicherungskomponente für Autonome Mobile Serviceroboter

Sicherungskomponente für Autonome Mobile Serviceroboter Christoph Lüth: SAMS 1 [12] Sicherungskomponente für Autonome Mobile Serviceroboter Christoph Lüth Deutsches Forschungszentrum für Künstliche Intelligenz, Bremen SAMS Abschlusspräsentation, 13.10.09, Bremen

Mehr

Cyber-Sicherheit von Industrial Control Systems

Cyber-Sicherheit von Industrial Control Systems Cyber-Sicherheit von Industrial Control Systems Holger Junker Bundesamt für Sicherheit in der Informationstechnik Industrial IT Forum 2012-04-25 Agenda Das BSI Cyber-Sicherheit im ICS-Kontext Sicherheitsmaßnahmen

Mehr

INFORMATIK CONSULTING SYSTEMS AG. Firmenprofil ICS AG. Automotive Industrial Solutions Transportation Aerospace & Defence

INFORMATIK CONSULTING SYSTEMS AG. Firmenprofil ICS AG. Automotive Industrial Solutions Transportation Aerospace & Defence INFORMATIK CONSULTING SYSTEMS AG Firmenprofil ICS AG Automotive Industrial Solutions Transportation Aerospace & Defence Günther Trautzl Key Account Manager Industrial Solutions 20131028 ICS Präsentation

Mehr

Innovatives Risikomanagement für die (Software-) Entwicklung von Medizingeräten der Zukunft

Innovatives Risikomanagement für die (Software-) Entwicklung von Medizingeräten der Zukunft 1 Innovatives Risikomanagement für die (Software-) Entwicklung von Medizingeräten der Zukunft MedConf, München Dr. Henrik J. Putzer Marco Radzio Frühe Medizingeräte Trepanation des Schädels bereits bei

Mehr

Microsoft IT optimiert das Group Policy Management mit Lösungen von NetIQ

Microsoft IT optimiert das Group Policy Management mit Lösungen von NetIQ Microsoft IT optimiert das Group Policy mit Lösungen von NetIQ Bei Microsoft IT verantwortet das Identity Team die Implementierung und Wartung von Group Policy Objects (GPOs) im Active Directory - und

Mehr

Einführung Arten von Softwaretests Prinzipien Continuous Integration Tests in FLOSS-Projekten Quellen. Softwaretests. Christoph Betschart

Einführung Arten von Softwaretests Prinzipien Continuous Integration Tests in FLOSS-Projekten Quellen. Softwaretests. Christoph Betschart Softwaretests Christoph Betschart 27. Oktober 2014 Inhaltsverzeichnis Einführung Arten von Softwaretests Prinzipien Seven Principles of Software Testing Continuous Integration Tests in FLOSS-Projekten

Mehr

Peter Liggesmeyer. Software-Qualität. Testen, Analysieren und Verifizieren von Software. 2. Auflage. Spektrum k-/l AKADEMISCHER VERLAG

Peter Liggesmeyer. Software-Qualität. Testen, Analysieren und Verifizieren von Software. 2. Auflage. Spektrum k-/l AKADEMISCHER VERLAG Peter Liggesmeyer Software-Qualität Testen, Analysieren und Verifizieren von Software 2. Auflage Spektrum k-/l AKADEMISCHER VERLAG 1 Inhaltsverzeichnis 1 Einführung 1 1.1 Motivation 2 1.2 Terminologie

Mehr

Praktikum Software Engineering: Verfahren und Werkzeuge

Praktikum Software Engineering: Verfahren und Werkzeuge Praktikum Software Engineering: Verfahren und Werkzeuge Lehrstuhl für Software Engineering (Informatik 11) Verfahren und Werkzeuge Seite 1 Software Engineering Absichten, Aufgaben Systemnutzung Anforderungsspezifikation

Mehr

Innovatives Risikomanagement für die Entwicklung von Medizingeräten der Zukunft

Innovatives Risikomanagement für die Entwicklung von Medizingeräten der Zukunft 1 Innovatives Risikomanagement für die Entwicklung von Medizingeräten der Zukunft electronic goes medical, München Dr. Henrik J. Putzer Marco Radzio Frühe Medizingeräte Trepanation des Schädels bereits

Mehr

Software Assessments verhelfen zur effektiven Prozessverbesserung

Software Assessments verhelfen zur effektiven Prozessverbesserung Assessments verhelfen zur effektiven Prozessverbesserung Ein Erfahrungsbericht Dr. Gunter Hirche Gründe für ein Assessment Anforderungen: Probleme bei der Abwicklung von Projekten mit SW-Anteilen Termine,

Mehr

Trusted Network Connect. Networking Academy Day 19.04.2008

Trusted Network Connect. Networking Academy Day 19.04.2008 Trusted Network Connect Networking Academy Day 19.04.2008 Dipl.-Inf. Stephan Gitz Roadmap Ziele der Informationssicherheit Herausforderungen der Informationssicherheit Angriffsvektoren

Mehr

Seminar Simulation und Bildanalyse mit Java SS2004. Themenschwerpunkt: Tests in Informatik und Statistik

Seminar Simulation und Bildanalyse mit Java SS2004. Themenschwerpunkt: Tests in Informatik und Statistik Einführung in den Softwaretest Seminar Simulation und Bildanalyse mit Java SS2004 Themenschwerpunkt: Tests in Informatik und Statistik Arbeit von Christian Aich und Robert Reeb Thema 2: Einführung in den

Mehr

IT-Security Portfolio

IT-Security Portfolio IT-Security Portfolio Beratung, Projektunterstützung und Services networker, projektberatung GmbH Übersicht IT-Security Technisch Prozesse Analysen Beratung Audits Compliance Bewertungen Support & Training

Mehr

Taxonomy of Evolution and Dependability. Integration Engineering SS 2009 Andreas Landerer

Taxonomy of Evolution and Dependability. Integration Engineering SS 2009 Andreas Landerer Taxonomy of Evolution and Dependability Integration Engineering SS 2009 Andreas Landerer Agenda Informationen über Massimo Felici Definition zentraler Begriffe Inhalt des Artikels Kernaussagen des Artikels

Mehr

Safety Integrated for Process Automation. Siemens AG 2012. All Rights Reserved.

Safety Integrated for Process Automation. Siemens AG 2012. All Rights Reserved. Safety Integrated for Process Automation Safety Integrated for Process Automation Aufteilung der Fehler Safety-Lifecycle Kompetenz Analyse Failure root causes + Safety- Management + Technische Anforderung

Mehr

3. Klausurtagung Studiengang Automatisierungstechnik - AuTec. Sicherheit der Information 23. April 2015 Wildau Prof. Dr.-Ing.

3. Klausurtagung Studiengang Automatisierungstechnik - AuTec. Sicherheit der Information 23. April 2015 Wildau Prof. Dr.-Ing. 3. Klausurtagung Studiengang Automatisierungstechnik - AuTec Sicherheit der Information 23. April 2015 Wildau Prof. Dr.-Ing. Frank Gillert Logistik im Kontext der Sicherheit Prozessinhärente Vulnerabilitäten

Mehr

Sicherheit der industriellen Automatisierung in österreichischen Unternehmen

Sicherheit der industriellen Automatisierung in österreichischen Unternehmen Sicherheit der industriellen Automatisierung in österreichischen Unternehmen Ing. DI(FH) Herbert Dirnberger, MA, CISM Leiter der Arbeitsgruppe Sicherheit der industriellen Automation Verein zur Förderung

Mehr

Industrie 4.0 Predictive Maintenance. Kay Jeschke SAP Deutschland AG & Co. KG., Februar, 2014

Industrie 4.0 Predictive Maintenance. Kay Jeschke SAP Deutschland AG & Co. KG., Februar, 2014 Industrie 4.0 Predictive Maintenance Kay Jeschke SAP Deutschland AG & Co. KG., Februar, 2014 Anwendungsfälle Industrie 4.0 Digitales Objektgedächtnis Adaptive Logistik Responsive Manufacturing Intelligenter

Mehr

Lösungen die standhalten.

Lösungen die standhalten. Aufbau eines Information Security Management Systems in der Praxis 14.01.2010, München Dipl. Inform. Marc Heinzmann, ISO 27001 Auditor Lösungen die standhalten. plan42 GmbH Wir sind ein reines Beratungsunternehmen

Mehr

IT-Ausbildung für Wirtschaftsprüfer und deren Mitarbeiter. 2003 KPMG Information Risk Management 1

IT-Ausbildung für Wirtschaftsprüfer und deren Mitarbeiter. 2003 KPMG Information Risk Management 1 IT-Ausbildung für Wirtschaftsprüfer und deren Mitarbeiter 2003 KPMG Information Risk Management 1 Grundvoraussetzungen Grundsätzlich sollten alle Prüfer, die IT im Rahmen von Jahresabschlussprüfungen prüfen

Mehr