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

Softwaretechnik. Vertretung von Prof. Dr. Blume Fomuso Ekellem WS 2011/12

Softwaretechnik. Vertretung von Prof. Dr. Blume Fomuso Ekellem WS 2011/12 Vertretung von Prof. Dr. Blume WS 2011/12 Inhalt Test, Abnahme und Einführung Wartung- und Pflegephase gp Vorlesung Zusammenfassung Produkte und Recht (Folien von Prof. Blume) 2 , Abnahme und Einführung

Mehr

Validierung und Verifikation

Validierung und Verifikation Martin Glinz Harald Gall Software Engineering Kapitel 7 Validierung und Verifikation Universität Zürich Institut für Informatik 2005, 2009 Martin Glinz. Alle Rechte vorbehalten. Speicherung und Wiedergabe

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

Funktionale Sicherheit Testing unter

Funktionale Sicherheit Testing unter Funktionale Sicherheit Testing unter den Bedingungen der Safety Integrity Levels Präsentation auf dem Neu-Ulmer Test-Engineering Day Sebastian Stiemke, MissingLinkElectronics, Neu-Ulm 1 Inhalt Idee hinter

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

Universität Paderborn Die Universität der Informationsgesellschaft. Validierung und Verifikation (inkl. Testen, Model-Checking, Theorem Proving)

Universität Paderborn Die Universität der Informationsgesellschaft. Validierung und Verifikation (inkl. Testen, Model-Checking, Theorem Proving) Universität Paderborn Die Universität der Informationsgesellschaft Analyse, Entwurf und Implementierung zuverlässiger Software und (inkl., Model-Checking, Theorem Proving) Torsten Bresser torbre@uni-paderborn.de

Mehr

Prozessanforderungen bei der Entwicklung von sicherheitsrelevanten Funktionen. Tina Heimer, Carmeq GmbH

Prozessanforderungen bei der Entwicklung von sicherheitsrelevanten Funktionen. Tina Heimer, Carmeq GmbH Prozessanforderungen bei der Entwicklung von sicherheitsrelevanten Funktionen Tina Heimer, Carmeq GmbH Carmeq GmbH Carmeq konzipiert, entwickelt und integriert softwarebestimmte Systeme für die Automobilindustrie.

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

Softwaretechnikpraktikum SS 2004. Qualitätsmanagement I. 1. Überblick. Qualität. Qualitätsmerkmal

Softwaretechnikpraktikum SS 2004. Qualitätsmanagement I. 1. Überblick. Qualität. Qualitätsmerkmal Softwaretechnikpraktikum SS 2004 Qualitätsmanagement I 5. Vorlesung 1. Überblick Planungsphase Definitionsphase Entwurfsphase Implem.- phase Fragen Was ist Qualität? Wie kann man Qualität messen? Wie kann

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

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

Agile Software-Entwicklung im Kontext der EN50128 Wege zum Erfolg

Agile Software-Entwicklung im Kontext der EN50128 Wege zum Erfolg Herzlich willkommen Agile Software-Entwicklung im Kontext der EN50128 Wege zum Erfolg Heike Bickert Software-/Systemingenieurin, Bereich Quality Management Braunschweig // 17.11.2015 1 Agenda ICS AG Fragestellungen

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

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

Modellbasierte Software- Entwicklung eingebetteter Systeme

Modellbasierte Software- Entwicklung eingebetteter Systeme Modellbasierte Software- Entwicklung eingebetteter Systeme Prof. Dr. Holger Schlingloff Institut für Informatik der Humboldt Universität und Fraunhofer Institut für offene Kommunikationssysteme FOKUS Folie

Mehr

Entwicklung Safety-relevanter Steuergeräte auf Basis des V-Modells

Entwicklung Safety-relevanter Steuergeräte auf Basis des V-Modells AUTOMOTIVE INFOKOM MOBILITÄT, ENERGIE & UMWELT LUFTFAHRT RAUMFAHRT VERTEIDIGUNG & SICHERHEIT Entwicklung Safety-relevanter Steuergeräte auf Basis des V-Modells Stephen Norton VMEA 12.11.2015 CoC SAFETY

Mehr

Praxisgerechte Validierung von Sicherheitsapplikationen

Praxisgerechte Validierung von Sicherheitsapplikationen Praxisgerechte Validierung von Sicherheitsapplikationen Dr. Michael Huelke, FB Unfallverhütung Produktsicherheit, BGIA Institut für Arbeitsschutz der Deutschen Gesetzlichen Unfallversicherung, Sankt Augustin

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

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

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

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

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

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

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

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

Embedded Systems. Sicherheit und Zuverlässigkeit in einer automatisierten und vernetzten Welt

Embedded Systems. Sicherheit und Zuverlässigkeit in einer automatisierten und vernetzten Welt Embedded Systems Sicherheit und Zuverlässigkeit in einer automatisierten und vernetzten Welt Intelligente Embedded Systems revolutionieren unser Leben Embedded Systems spielen heute in unserer vernetzten

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

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

Prozess-Modelle für die Softwareentwicklung

Prozess-Modelle für die Softwareentwicklung Prozess-Modelle für die Softwareentwicklung Prof. Dr. Andreas Spillner Institut für Informatik und Automation Hochschule Bremen Übersicht Softwareentwicklungs-Modelle Wasserfall-Modell Vorgehensmodell

Mehr

Qualitätsmanagement im Projekt

Qualitätsmanagement im Projekt Software-Engineering Qualitätsmanagement im Projekt Vorlesung im Wintersemester 2008/2009 Fakultät Wirtschaftsinformatik Klaus Mairon, M.Sc. Inhalte Messen und Bewerten: Metriken in der Qualitätssicherung

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

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

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

T.I.S.P. Community Meeting 2014 Berlin, 03. - 04.11.2014 Wie können wir sichere Systeme entwickeln?

T.I.S.P. Community Meeting 2014 Berlin, 03. - 04.11.2014 Wie können wir sichere Systeme entwickeln? T.I.S.P. Community Meeting 2014 Berlin, 03. - 04.11.2014 Wie können wir sichere Systeme entwickeln? Dr. Yun Ding Secorvo Security Consulting Ingenieurs-Ansatz für Sicherheit 06.11.2014 2 Bildquelle: khunaspix,

Mehr

IT-Grundschutz nach BSI 100-1/-4

IT-Grundschutz nach BSI 100-1/-4 IT-Grundschutz nach BSI 100-1/-4 Marko Rogge www.marko-rogge.de www.leiner-denzer.com 100-1, 100-2, 100-3, 100-4 100-1 100-2 Managementsysteme für Informationssicherheit (ISMS, Information Security Management

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

Praxiswissen Softwaretest - Testmanagement

Praxiswissen Softwaretest - Testmanagement Andreas Spillner Thomas Roßner Mario Winter Tilo Linz Praxiswissen Softwaretest - Testmanagement Aus- und Weiterbildung zum Certified Tester Advanced Level nach ISTQB-Standard 2., überarbeitete und aktualisierte

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

2014 PRINCE 2 Foundation PRINCE 2 Practitioner

2014 PRINCE 2 Foundation PRINCE 2 Practitioner Personalprofil Thomas Scherzinger Senior Consultant E-Mail: thomas.scherzinger@arcondis.com AUSBILDUNG BERUFLICHE WEITERBILDUNG BESONDERE TÄTIGKEITEN 2010 Bachelor of Sciences in Wirtschaftsinformatik

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

How to Survive an Audit with Real-Time Traceability and Gap Analysis. Martin Kochloefl, Software Solutions Consultant Seapine Software

How to Survive an Audit with Real-Time Traceability and Gap Analysis. Martin Kochloefl, Software Solutions Consultant Seapine Software How to Survive an Audit with Real-Time Traceability and Gap Analysis Martin Kochloefl, Software Solutions Consultant Seapine Software Agenda Was ist Traceability? Wo wird Traceability verwendet? Warum

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

Abbildung 1: Tool-Qualification-Kits für Testwell CTC++ Test Coverage Analyser

Abbildung 1: Tool-Qualification-Kits für Testwell CTC++ Test Coverage Analyser Qualification-Kit für Testwell CTC++ In der sicherheitskritischen Softwareentwicklung müssen die im Projekt eingesetzten Werkzeuge zunächst klassifiziert werden (Tool Classification). Diese Klassifizierung

Mehr

Testen. SEPR Referat: Testen - Oliver Herbst

Testen. SEPR Referat: Testen - Oliver Herbst Testen Inhalt 1. Grundlagen des Testens 2. Testen im Softwarelebenszyklus 3. Statischer Test 4. Dynamischer Test 5. Besondere Tests 2 1. Grundlagen des Testens 3 Grundlagen des Testens Motivation erfüllt

Mehr

IT-Security Portfolio

IT-Security Portfolio IT-Security Portfolio Beratung, Projektunterstützung und Services networker, projektberatung GmbH ein Unternehmen der Allgeier SE / Division Allgeier Experts Übersicht IT-Security Technisch Prozesse Analysen

Mehr

SRE-Methodenleitfaden

SRE-Methodenleitfaden Root Cause Analysis liefert SRE-Methodenleitfaden (Root Cause Analysis as a Guide to SRE Methods) Timm Grams Fachhochschule Fulda Fachbereich Elektrotechnik und Informationstechnik Timm Grams, Fulda, 09.03.04

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

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

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

Praxiswissen Softwaretest Test Analyst und Technical Test Analyst

Praxiswissen Softwaretest Test Analyst und Technical Test Analyst Graham Bath Judy McKay Praxiswissen Softwaretest Test Analyst und Technical Test Analyst Aus- und Weiterbildung zum Certified Tester - Advanced Level nach ISTQB-Standard 2., durchgesehene Auflage 2011

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

Praxiswissen Softwaretest - Testmanagement

Praxiswissen Softwaretest - Testmanagement Praxiswissen Softwaretest - Testmanagement Aus- und Weiterbildung zum Certified Tester Advanced Level nach ISTQB-Standard dpunkt.verlag 1 Einleitung 1 1.1 Basiswissen - komprimiert 4 1.2 Praxiswissen Testmanagement

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

Hauptseminar Automotive Software Engineering Testen, Rapid Prototyping und x in the loop

Hauptseminar Automotive Software Engineering Testen, Rapid Prototyping und x in the loop Hauptseminar Automotive Software Engineering Testen, Rapid Prototyping und x in the loop Christoph Niedermayr 20.01.2005 Überblick 1 2 X in the loop Rapid Prototyping Begriffe Was versteht man unter statischem

Mehr

Testen Prinzipien und Methoden

Testen Prinzipien und Methoden Testen Prinzipien und Methoden ALP 2 SS2002 4.7.2002 Natalie Ardet Definition Im folgenden gilt: Software = Programm + Daten + Dokumentation Motivation Software wird immer mehr in Bereichen eingesetzt,

Mehr

Einbinden der Why-Because-Analyse bei der Untersuchung von Produktsicherheitsmängeln

Einbinden der Why-Because-Analyse bei der Untersuchung von Produktsicherheitsmängeln Einbinden der Why-Because-Analyse bei der Untersuchung von Produktsicherheitsmängeln Ernesto De Stefano Untersuchung von Produktsicherheitsmängeln Wann wird die Why-Because-Analyse eingesetzt? 1 Sicherheitsmangel

Mehr

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert

The Rational Unified Process. Eine Einführung von T. Langer und A. Nitert The Rational Unified Process Eine Einführung von T. Langer und A. Nitert Übersicht Einleitung Probleme der SW-Entwicklung, Best Practices, Aufgaben Was ist der Rational Unified Process? Struktur des Prozesses

Mehr

MISRA bzw. Programmierstandards steigern die Softwarequalität! - Ist das überhaupt möglich?

MISRA bzw. Programmierstandards steigern die Softwarequalität! - Ist das überhaupt möglich? MISRA bzw. Programmierstandards steigern die Softwarequalität! - Ist das überhaupt möglich? Andreas Sczepansky - Geschäftsführer Tel.: + 49 (0) 711 138183-0 www.qasystems.de V-Modell für Softwaretests

Mehr

Auf dem Weg zu Industrie 4.0 - Safety, Security und Privacy in Produktionsnetzen

Auf dem Weg zu Industrie 4.0 - Safety, Security und Privacy in Produktionsnetzen Software Factory www.sf.com - Safety, Security und Privacy in Produktionsnetzen Thomas Trägler, traegler@sf.com Software Factory - Geschäftsfelder CAD/CAM process automation with PTC Creo PLM process automation

Mehr

T1 - Fundamentaler Testprozess

T1 - Fundamentaler Testprozess AK 2 am Armin Beer, Support Center Test der Software- Entwicklung 1 für einen erfolgreichen Test? Projektteam strebt nach Qualität Aufwände sind eingeplant (Richtwerte) 20 bis 30% des Gesamtaufwandes In

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

T2 Fundamentaler Testprozess

T2 Fundamentaler Testprozess T2 Fundamentaler Siemens AG Österreich 2005 All Rights Reserved Institut f. Software Technology, TU-Graz Armin Beer, PSE Support-Center Test Overview der Software- Entwicklung 2 1 Wasserfall-Modell Analyse

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

Entwurf. Anwendungsbeginn E DIN EN 62304 (VDE 0750-101):2013-10. Anwendungsbeginn dieser Norm ist...

Entwurf. Anwendungsbeginn E DIN EN 62304 (VDE 0750-101):2013-10. Anwendungsbeginn dieser Norm ist... Anwendungsbeginn Anwendungsbeginn dieser Norm ist.... Inhalt Einführung... 13 1 Anwendungsbereich... 16 1.1 *Zweck... 16 1.2 *Anwendungsbereich... 16 1.3 Beziehung zu anderen Normen... 16 1.4 Einhaltung...

Mehr

Sicherheit / Sicherung - unterschiedliche Begriffsbestimmung, gemeinsame Fachaspekte

Sicherheit / Sicherung - unterschiedliche Begriffsbestimmung, gemeinsame Fachaspekte Sicherheit / Sicherung - unterschiedliche Begriffsbestimmung, gemeinsame Fachaspekte F. Seidel, BfS Salzgitter (Juli 2002) 1) Begriffsbestimmung (Vergleich unter Nutzung nationaler und internationaler

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

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

Aus Liebe zu Sicherheit und Qualität.

Aus Liebe zu Sicherheit und Qualität. Aus Liebe zu Sicherheit und Qualität. ECO Verband Frankfurt 30.01.2015 1 2013 - Auf allen Kontinenten zuhause. Überblick TÜV Rheinland Ca. 600 Standorte in 65 Ländern ca. 1,6 Mrd. Umsatz ca. 18.000 Mitarbeiter

Mehr

Risiko- und Gefahrenanalyse und deren Berücksichtigung beim Entwurf von Sicherheitskritischen Systeme. Kelen-Yo Rodrigue

Risiko- und Gefahrenanalyse und deren Berücksichtigung beim Entwurf von Sicherheitskritischen Systeme. Kelen-Yo Rodrigue Risiko- und Gefahrenanalyse und deren Berücksichtigung beim Entwurf von Sicherheitskritischen Systeme Kelen-Yo Rodrigue Überblick Einleitung Präsentation des Neigemoduls des Shuttles Systemanforderungen

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

Einführung von Test-Prozessen laut TMMi. Egon Valentini 1. März 2010

Einführung von Test-Prozessen laut TMMi. Egon Valentini 1. März 2010 Einführung von Test-Prozessen laut TMMi Egon Valentini 1. März 2010 Agenda NXP Testumfeld CMMi, TMMi TMMi QualityPolicy, TestPolicy, TestStrategy, TestPlan Lessons Learned 2 Warum brauchen wir Testmethoden

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

Sicherheitsnachweise für elektronische Patientenakten

Sicherheitsnachweise für elektronische Patientenakten Copyright 2000-2011, AuthentiDate International AG Sicherheitsnachweise für elektronische Patientenakten Christian Schmitz Christian Schmitz Copyright 2000-2011, AuthentiDate International AG Seite 2 Systemziele

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-Sicherheit mit System

IT-Sicherheit mit System Klaus-Rainer Müller IT-Sicherheit mit System Sicherheitspyramide und Vorgehensmodelle - Sicherheitsprozess und Katastrophenvorsorge - Die 10 Schritte zum Sicherheitsmanagement Mit 26 Abbildungen vieweg

Mehr

Funktionale Sicherheit und Cyber Security

Funktionale Sicherheit und Cyber Security Funktionale Sicherheit und Cyber Security Unterschiede, Schnittstellen und Lösungen V0.05 2015-10-20 Agenda Keine Funktionale Sicherheit ohne Cyber Security Prozesse und Methoden Safety Mechanismen Security

Mehr

Fachhochschule für Technik und Wirtschaft Berlin FB4: Wirtschaftsinformatik

Fachhochschule für Technik und Wirtschaft Berlin FB4: Wirtschaftsinformatik Fachhochschule für Technik und Wirtschaft Berlin FB4: Wirtschaftsinformatik Entwicklung und Evaluation eines Vorgehensmodells zur Optimierung des IT-Service im Rahmen eines IT-Assessment Framework Oliver

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

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

Cyber Security in der Stromversorgung

Cyber Security in der Stromversorgung 12. CIGRE/CIRED Informationsveranstaltung Cyber Security in der Stromversorgung Manuel Ifland Ziele dieses Vortrags Sie können sich ein Bild davon machen, welche Cyber Security Trends in der Stromversorgung

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

Service Virtualisierung

Service Virtualisierung Service Virtualisierung So bekommen Sie Ihre Testumgebung in den Griff! Thomas Bucsics ANECON Software Design und Beratung G.m.b.H. Alser Str. 4/Hof 1 A-1090 Wien Tel.: +43 1 409 58 90 www.anecon.com office@anecon.com

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

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

ITIL V3 zwischen Anspruch und Realität

ITIL V3 zwischen Anspruch und Realität ITIL V3 zwischen Anspruch und Realität Christian Lotz, Dipl.-Inform. Med. certified IT Service Manager & ISO 20000 Consultant 9. März 2009 IT-Service Management ISO 20000, ITIL Best Practices, Service

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

Software EMEA Performance Tour 2013. Berlin, Germany 17-19 June

Software EMEA Performance Tour 2013. Berlin, Germany 17-19 June Software EMEA Performance Tour 2013 Berlin, Germany 17-19 June Change & Config Management in der Praxis Daniel Barbi, Solution Architect 18.06.2013 Einführung Einführung Wer bin ich? Daniel Barbi Seit

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

IT-Prüfung nach dem COBIT- Ansatz. Erfahrungen des oö. Landesrechnungshofes

IT-Prüfung nach dem COBIT- Ansatz. Erfahrungen des oö. Landesrechnungshofes IT-Prüfung nach dem COBIT- Ansatz Erfahrungen des oö. Landesrechnungshofes Oö. Landesrechnungshof Landesrechnungshof ist zuständig für die Prüfung von IT-Organisationen des Landes und von Beteiligungsunternehmen

Mehr

SW-Tests bei Siemens Med MR

SW-Tests bei Siemens Med MR SW-Tests bei Siemens Med MR Testprozess eines großen Embedded Systems 2 SIEMENS AG Medical Solutions GG MR Das Geschäftsgebiet MR Ca. 600 Beschäftigte Ca. 700 Systeme pro Jahr Ca. 1 Mrd. Euro Umsatz 3

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

Funktionale Sicherheit in Automotive und Luftfahrt (ISO26262 und DO 178BC) Otto Alber, Peter Wittmann 09.10.2013

Funktionale Sicherheit in Automotive und Luftfahrt (ISO26262 und DO 178BC) Otto Alber, Peter Wittmann 09.10.2013 Funktionale Sicherheit in Automotive und Luftfahrt (ISO26262 und DO 178BC) Otto Alber, Peter Wittmann 09.10.2013 Einleitung Modell-basierte Entwicklung bei Silver Atena Erfahrung mit Modell-basierter Entwicklung

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

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

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