Unrestricted Siemens AG 2018

Transkript

1 Sebastian Dännart Fabiola Constante Moyón Dr. Kristian Beckers Dr. Holger Dreger Kontinuierliche IT-Sicherheitskonformität in industrieller, agiler Produktentwicklung Scaled Agile Software Development compliant to IEC

2 Security Lifecycle (SEL) research group SIEMENS Corporate Technology Enable Siemens System Hardening Threat & Risk Analysis Security Consulting Unterstützung der SIEMENS Business Units bei der Entwicklung, Auslieferung und Wartung sicherer Produkte und Lösungen Security Requirements Security Lifecycle Secure Development Analyse bestehender IT-Sicherheitsaktivitäten innerhalb der Business Units und deren Prozessen Optimierung der Organisation durch Einführung oder Erweiterung von IT-Sicherheitsaktivitäten Security Standards Training IT-Sicherheitsfähigkeiten in den Organisationen durch Trainings und Workshops aufbauen Page 2 Group Lead Dr. Holger Dreger

3 Security Lifecycle (SEL) research group SIEMENS Corporate Technology Enable Siemens Threat & Risk Analysis Secure Scaled Agile Research Team System Hardening Security Consulting Security Requirements Security Lifecycle Secure Development Dr. Kristian Beckers Eng. Fabiola Moyón, M.Sc. Dipl.-Wirt.-Inf. Sebastian Dännart Security Standards Training Supervisor CT-RDA-ITS-SEL-DE Researcher CT-RDA-ITS-SEL-DE Researcher / MBA Student CT-RDA-ITS-SEL-DE Page 3 Group Lead Dr. Holger Dreger

4 Was sagt der IT-Grundschutz zur Produktentwicklung im Bereich industrieller Systeme? ICS-Security-Kompendium verweist auf Maßnahmen in Standards Fordert eine Berücksichtigung von IT- Sicherheitsaspekten in der Produktentwicklung M1 Einführung eines Entwicklungszyklus für sichere Software in Komponenten Direkter Verweis auf die IEC Page 4

5 Was sagt der IT-Grundschutz zur Produktentwicklung im Bereich industrieller Systeme? Maßnahmenkatalog M 2 Organisation M Geeignete Steuerung der Anwendungsentwicklung M Auswahl eines Vorgehensmodells zur Software-Entwicklung Umsetzungshinweise zum Baustein IND.1 Betriebs- und Steuerungstechnik IND.1.M11 Sichere Beschaffung und Systementwicklung Baustein CON.8 Software-Entwicklung Anforderungen an sichere Software-Entwicklung Status: Community Draft Page 5 Quelle: DKE (2017)

6 Agilität versus Sicherheit Page 6 Quelle: scrum.org

7 Agilität versus Sicherheit Security Safety Page 7 Quelle: scrum.org

8 Analogie zum Händewaschen, dass Händewaschen ein wesentlicher Teil unseres, nicht nur medizinischen, Alltags geworden ist. Page 8 Quelle: Anna Durnová, In den Händen der Ärzte: Ignaz Semmelweis, 2015

9 IT-Security Hygiene muss zum Alltag werden IT-Sicherheit muss genauso elementarer Bestandteil des täglichen Lebens werden wie Händewaschen. Erst recht in Unternehmen. IT-Sicherheit als Bestandteil der täglichen Prozesse trägt dazu bei. Page 9

10 Agilität versus Sicherheit 4.5 Page 10 Quelle: scrum.org IEC

11 Page 11 Quelle: Scaled Agile (2018)

12 Scope der IEC Page 12 Quelle: DKE (2017)

13 Agilität versus Sicherheit 4.5 Page 13 Quelle: scrum.org IEC

14 IEC Product development requirements Prozessanforderungen Integration von Security in die Entwicklung von Produkten Security Entwicklungslebenszyklus (Secure Development Lifecycle, SDL) 8 Practices mit 47 Requirements + Security-issue management + Security update management Page 14 Quelle: nach DKE (2017)

15 Zusammenführung von Agilität und Sicherheit Continuous Delivery Pipeline Define Roadmap Epic Epic Practice 5. Security verification and validation testing (SVV) Prepare and Maintain the Agile Release Train SVV-1 SVV-5 Independence of testers Build a cross-functional organization Support DevOps capabilities Define Roadmap Backlog Business Owners Value Stream is defined Roadmap Cadence Definit ions Started Plan No Agile Project Management Tool Repository Team Back log Team Progr am Increm ent Objectives Execute Were the established number of execution iterations performed? Progr am Planning Board Perform execution iteration Back log Documentation Code Repository Yes Perform innovation and planning iteration System Demo Acti on Items or issues Ended Inspect and Adapt PI System Demo Quantitative Measurement Retrospective and Problem Solving Release on Demand Ensure testers comply with the independent person criteria ( SVV-t2 ) Split Epic into potential features Approve and add features or enablers to Backlog SVV-3 Perform testing ( SVV-g1) Document testing ( SVV-g2) SVV-4 Practice 8 SG Roadmap Distribute features into program increments PI Prioritized features or enablers for implementation SVV-2 Ensure testers comply with the independent organization criteria ( SVV-t3) SM to Practice 5 SVV Define Epic story point by adding feature story points Product Management Standard Dev elopment Pract ices Define Roadmap Issues and problems Execute PI Planning Event Practice 5 SVV Ensure testers comply with the independent department criteria ( SVV-t1) Features& Enablers Establish: number of execution iterations per PI, duration of an iteration Define enablers that build architectural runway Required level of Independence of testers from developers ( SVV-a1) Starts Backlog Estimate features in story points System Architects Prepare for the PI Planning event Contains features and enablers for current PI and next two PIs Release Train Engineer Business, Product and Architectural Vision Planning scope and context Portfolio Kanban Analysis Cadence Definit ions + Security Requirements ( SR-a7) SVV-1 Security requirements testing Conduct functional testing of security requirements ( SVV-t4) Conduct performance and scalability testing ( SVV-t5) Conduct boundary condition, stress and invalid input testing ( SVV-t6) Industryrecognized public source of known vulnerabilities ( SVV-a2) Security requirements testing report ( SVV-a4*) SVV-2 Threat mitigation testing Create and execute plans to ensure mitigations were tested ( SVV-t7) Create and execute plans to attempt to thwart mitigations ( SVV-t8) Spoofing Tampering Repud iation Information disclosure Denial of service Elevation of privileges Threat Mitigation Plans ( SVV-a5) SVV-3 Vulnerability testing Conduct abuse case, malformed or unexpected input testing ( SVV-t9) Conduct attack surface analysis ( SVV-t10) Conduct black box known vulnerability scanning ( SVV-t11) SVV-4 Penetration testing Discover vulnerabilities in product, defense in depth or product documentation ( SVV-t14) Security-related Issues detected ( SM-e6) Security -related Issues ( SM-a4 Exploit chained vulnerabilities ( SVV-t15) Summarize detected security-related issues ( SVV-t16*) Conduct sw composition analysis on executables ( SVV-t12) Test dynamic runtime resource management ( SVV-t13) Vulnerability Testing Report ( SVV-a6*) Penetration Testing Report ( SVV-a7*) Security testing documentation ( SVV-a3) To Value streams Management Security-Standard Compliant Scaled Agile Framework Define Roadmap Features& Enablers Define Epic story point by adding feature story points Approve and add features or enablers to Backlog Define enablers that build architectural runway Roadmap Distribute features into program increments PI Prioritized features or enablers for implementation Split Epic into potential features System Architects Product Management Contains features and enablers for current PI and next two PIs Portfolio Kanban Analysis Release Train Engineer Define Roadmap Business Owners Epic Starts Backlog Estimate features in story points Establish: number of execution iterations per PI, duration of an iteration Cadence Definit ions Seurity Expert Determine appropriate secure design best practices for the type of product (SD-t1) Industry accepted secure des ign best practices (SD-a1) Page 15 Selected secu re design best practices (SD-a2) 2 S CSAFe S2CSAFe besteht derzeit aus: 13 Modelle für das SAFe 15 Modelle für die IEC integrierte Einzelmodelle Evaluation der Modelle durch Experten zur Nutzung Überführung in ein Tool

16 Execute PI Planning Event se Train gineer curity Expert Release Train Engineer System Architects Agile Teams Security Expert Security Expert Security Expert Release Train Engineer Agile Teams Agile Teams Execute PI Planning Event Security Expert Release Train Engineer Review Draft Plan System Architectis Security Expert Product Management System Architects Release Train Engineer Release Train Engineer Execute PI Planning Event Execute PI Planning Event Release Train Engineer System Architects System Architects Review Draft Plan Review Draft Plan Release Train Engineer Product Management System Architectis Product System Architectis management Product management Business Owners Business Owners Review Draft Plan System Architectis Product Management Product Management Product management Business Owners Business Owners Product management Business Owners Business Owners Business Owners Business Owners Page 16 Beispiel Prozess Execute PI Planning Event Artefaktdefinition Execute bereitspi Planning Event im Prozess Present business context Prozessintegration und Zuordnung zu Rollen Facilitate the PI Execute PI Planning Event Backlog Present Product s vision and solution Present business context Backlog Present Product s vision and solution Review and update list of selected Facilitate secure design the PI best Planning practices Meeting (SD-t2) Zusätzliche Rolle nur bei Bedarf beratende Funktion (SD-a2) Present business context Present Product s vision and solution Facilitate Apply selected the PI secure design Planning best Meeting practices (SD-t3) Backlog Selected secure design best practices Review and update list of selected secure design best practices (SD-t2) Support with security expertise Selected secure design best practices (SD-a2) Business, Product and Architectural Vision Business, Product and Architectural Vision Present architecture vision and development practices Issues and problems Design defense layers applying secure design principles and assign Execute Team responsibilities Planning Breakouts (SD-t8) Team Objectives Execute PI Planning Event Issues and problems Analyse security risks Review Present architecture based on threat model Draft Plan Review and update Apply selected vision and (SD-t7) secure design best including list of selected practices development Secure secure design best (SD-t3) practices Design defense layers Design practices applying secure design (SD-t2) principles and assign responsibilities Analyse security risks (SD-t8) Apply selected secure design best practices (SD-t3) Selected secure design best practices (SD-a2) Support with security expertise Business, Product and Architectural Vision based on threat model (SD-t7) Present architecture vision and development practices Analyse security Execute Team risks Planning based on threat model Breakouts (SD-t7) Design defense layers Standard applying Development secure design Practices principles and assign responsibilities (SD-t8) Issues and problems Review Draft Plan including Secure Design Review Draft Plan including Secure Design Present business context Perform a management review and problemsolving session Perform a management review and problemsolving session Backlog Present Product s vision and solution Analyze program Apply selected Review risks secure design best Final Plan practices (SD-t3) Facilitate the PI Planning Meeting Perform a management review and problem- Continue Team Planning solving Breakouts Selected secure design best practices (SD-a2) Planning Board Standard Development Practices Business, Product and Architectural Vision Analyze Present architecture Review and update program Perform vision and list Review of selected risks planning development secure Final design Plan best retrospecti practices practices ve and moving (SD-t2) forward Continue Team Planning Support with Breakouts security expertise Team Backlog session Review Final Plan Execute Execute Analyse security risks based Perform on threat model planning (SD-t7) retrospecti ve and Design moving defense layers applying forward secure design principles and assign responsibilities (SD-t8) Commit to Commit to Analyze program Execute Team risks Planning Breakouts Agile Project Management Team Tool Repository Objectives Issues and problems Execute Review Draft Plan including Secure Design Perform planning retrospecti ve and moving forward Team Backlog Execute PI Planning Event Execute PI Planning Event Perform a management review and Review problemsolving Draft Plan Review session Final Plan Continue Team Planning Breakouts Review Draft Plan Analyze program risks Planning Board Execute Execute PI Planning Event Perform planning retrospecti ve and Not followed design moving best practice forward (SD-a7) Review design best practices are followed (SD-t9) Commit to Agile Project Management Tool Repository Security -related Issues (SM-a4) Review design best practices are followed Security -related Issues (SM-a4) Secure Design Review Not addressed Requirement (SD-a8) Execute PI Planning Event Support with security expertise Execute PI Planning Event IEC Practice 1 - SM Security management Practice Review 2 - SR Draft Plan Specification of security requirements Practice Threat capable 3 to - SD breach defense in Secure by design Depth (SD-a9) P Not fo desig best p (SD-a No Review security Examine Practice threats 4 - SI Review design best requirements are and Secure ability to Design Review practices are adequately address breach Secure defense in implementation Yes followed by defense in Not followed depth (SD-t9) depth (SD-t11) Are there design Practice Not addressed 5 - SVV Threat Security-related capable to (SD-t10) Requirement security-related best practice breach issues defense in issues (SD-a7) Security (SD-a8) varification Depth Detected (SD-a9) and (SD-g6) (SM-e6) No Review security validation testing Examine threats requirements are Practice and 6 ability - DMto adequately address breach defense in Yes by defense Management in depthof security (SD-t9) depth Review (SD-t11) Are there (SD-t10) security-related Draft Plan Support with issues security expertise (SD-g6) related issues Practice 7 SUM Security update mangagement Practice 8 SG Security guidelines Review design best practices are followed (SD-t9) Not followed design best practice (SD-a7) Secu -rela Issu (SM Securit is Det (SM Review requirem adequate by def de (SD-

17 Security-Standard Compliance Assessment Model (S 2 CAM) Wie macht man Compliance messbar?

18 Security-Standard Compliance Assessment Model (S 2 CAM) Compliance = Erfüllung der Anforderungen einer Norm The processes specified by this practice [ ] A process shall be employed [that/to] [ ] Page 18 [ ] that defines [ ] [ ] that identifies, characterizes and tracks [ ] [ ] to create [ ] documentation [ ]

19 Security-Standard Compliance Assessment Model (S 2 CAM) Business-orientiert Compliance als Ziel COBIT 5 & Balanced Scorecard Kaskadierung ermöglichen Ziele KPI Maßnahmen ISO/IEC (SPICE) CMMI-Dev +SECURE COBIT 5 PAM Struktur Vollständigkeit Aktualität Prozess-orientiert Artefakt-orientert Page 19

20 S 2 CAM Process Maturity Viele etablierte Reifegradmodelle CMMI-Dev als Referenz in IEC Schwer erfassbar / messbar Level IEC Description CMMI-Dev 1 Initial 2 Managed 3 Defined (Practiced) 4 Improving [ ] perform product development in an adhoc and often undocumented [ ] manner [ ] [ ] capability to manage the development of a product according to written policies [ ] [ ] can be shown to be repeatable across the supplier s organization. [ ] [ ] suitable process metrics, product suppliers control the effectiveness and performance [ ] demonstrate continuous improvement [ ] 1 - Initial 2 - Managed 3 - Defined 4 - Quantitavely Manged 5 - Optimizing Page 20

21 S 2 CAM Artefact Quality Keine Reifegradmodelle etabliert Zwei Dimensionen: Vollständigkeit und Aktualität Qualitätsgrad Erklärung 0 None Es existiert keine Dokumentation. 1 Partial Auf diesem Level existieren Dokumente und Ergebnisse aus Prozessen, die bestimmte Anforderungen des Standards erfüllen. Möglicherweise sind die Informationen bereits in unterschiedlichen Artefakten vorhanden und müssen konsolidiert und den richtigen Anforderungen zugeordnet werden. Möglicherweise sind einige Artefakte nicht auf dem neuesten Stand. 2 Complete Auf diesem Level sind alle nötigen Artefakte zum Nachweis der Konformität zum Standard vorhanden und liegen in strukturierter Form vor. Möglicherweise sind einige Artefakte nicht auf dem neuesten Stand. 3 Up-to-date Um dieses Level zu erreichen hat der Product Supplier die Erstellung und Pflege der Artefakte jeweils in die eingeführten S 2 CSAFe-Prozesse integriert. Die Prozesse werden gelebt und die regelmäßige Aktualisierung der Artefakte ist nachweislich gewährleistet. Bemerkung: Um dieses Level zu erreichen ist in der Regel die Prozessreife 3 Defined (Practiced) Voraussetzung. Page 21

22 Vollständigkeit S 2 CAM Artefact Quality - Dimensionen Qualitätsgrad 0 None 2 Complete Complete Up-to-date 1 Partial 1 Partial Partial Partial 2 Complete 0 None None None 3 Up-to-date Aktualität Page 22

23 Process Maturity S 2 CAM-Matrix Improving Defined (Practiced) Managed Initial None Partial Complete Up-to-date Artefact Quality Page 23

24 Integration in bestehende Management-Werkzeuge Anforderungen der IEC lassen sich als Ziele in COBIT 5 integrieren Integration und Kaskadierung in weitere Balanced Scorecards und COBIT 5 Zielkaskade möglich Kommunikation und Darstellung im Fokus Page 24 Quelle: u.a. ISACA (2012)

25 Integrierte Darstellung einer Subpractice als S 2 CAM-Card Page S 2 CAM-Cards S 2 CAM - Guide

26 Security Expert Security Expert Identify and characterize the features interfaces Agile Teams Characterize the selected interface ( SD-t5) System Architects Product Management System Architects Business Owners Backlog Business, Execute Team Product and Planning Breakout Integrierte Darstellung einer Subpractice als S 2 CAM-Card Architectural Vision Identify and c epic s physical and l (SD-t btain better rstanding about eatures assigned to the Team btain better rstanding of the ct of architectural initiatives Identify and aracterize the tures interfaces Identify stories that relate to the features Identify stories that relate to the architectural enablers Identify dependencies within the team and other teams Incorporate improvement backlog items (when exist) Team Backlog Identify features physical and logical interfaces (SD-t4) No Choose one interface (SD-e1) Support with security expertise Characterize the selected interface (SD-t5) Secure design for all interfaces? (SD-g1) Yes Compile security design for all interfaces (SD-t6) Secure design of selected interface (SD-a4) Secure design of all interfaces (SD-a5) Secure design (SD-a3) ate velocity of the for each iteration Estimate the stories and distribute into iterations Capture the backlog of things that should be postponed due to out of capacity Team Objectives isks Team Velocity Stories Meet with Scrum Masters to review planning status Draft Team Planning Boards Consolidate Teams planning into a Board Planning Board Execute Planning Event Execute Team Planning Breakout Hourly Page S 2 CAM-Cards S 2 CAM - Guide

27 Process Maturity S 2 CAM-Matrix mit Zielanalyse Improving SD-2 SD-4 Defined (Practiced) SD-3 Managed SD-1 Initial None Partial Complete Up-to-date Artefact Quality Page 27

28 Process Maturity S 2 CAM-Matrix Baseline mit S 2 CSAFe Minimum Artefaktqualität nach Umsetzung von S 2 CSAFe Improving Defined (Practiced) Managed Prämissen Prozesse sind gemäß S 2 CSAFe integriert Artefakte werden gemäß Prozessdefinition erstellt Initial Minimum Prozessreife nach Umsetzung von S 2 CSAFe None Partial Complete Up-to-date Artefact Quality Page 28

29 Process Maturity Improving Defined (Practiced) Managed Initial None Partial Complete Up-to-date Artefact Quality Beispiel einer Kaskadierung ins Business Unternehmensziel Sichere Produkte Unternehmensziel IEC Ziel Finanzielle Secure Transparenz Design COBIT 5 (angepasst an Product Supplier) kaskadiert zu IT-bezogenes Ziel Sichere SW/HW-Produkte kaskadiert zu Enabler Ziel / Prozess Sichere SW/HW-Produktentwicklung IT-bezogenes IEC Ziel Ziel IT-Compliance Secure Design Enabler IEC Ziel Ziel Sichere Secure IT-Infrastruktur Design kaskadiert zu Page 29 Schnittstellen und Kommunikation IEC Ziel S 2 CAM Secure Design kaskadiert zu IEC Practice Ziel Product s interfaces are characterized IEC IEC Ziel Ziel Secure Secure Implementation Design IEC IEC Practice Ziel Ziel Review of consequent use of Secure Design secure design best practices

30 Steuerungsinstrument für das Management zur Identifikation von Handlungsmöglichkeiten Verfeinerung der Anforderungen des Standards und Übertragung auf Ziele Detaillierte Metriken zur Messung der Compliance bereits während der Entwicklung S 2 CAssessment Model Page 30

31 Process Maturity Vielen Dank für ihre Aufmerksamkeit! Haben Sie Fragen? Improving Defined (Practiced) Managed Initial None Partial Complete Up-to-date Artefact Quality S 2 CSAFe Page 31 S 2 CAM

32 Just in case Dipl.-Wirt.-Inf. Sebastian Dännart MBA Student Siemens CT RDA ITS SEL-DE Otto-Hahn-Ring Munich sebastian.daennart.ext@siemens.com Dipl.-Wirt.-Inf. Sebastian Dännart IT Security Consultant Infodas GmbH Rhonestraße Köln s.daennart@infodas.de Wenn nicht anders gekennzeichnet, sind alle Bilder und Fotos in dieser Präsentation (ausgenommen das Siemens Logo) auf Sebastian Dännart persönlich lizensiert oder aus dessen privatem Archiv. Weitere Bildquellen: Scrum Grafik: SAFe Logo und Übersichtsgrafik: IEC Logo, Grafik zur Einordnung 4-1 und Grafik zur Defense-in-Depth: IEC COBIT 5 IT-bezogene Ziele: Page 32

33 IEC Practices und Requirements Practice 1 Practice 2 Practice 3 Practice 5 Practice 6 Practice 7 Practice 8 SM-1 Development process SM-2 Identifications of Responsibilities SM-3 Identification of responsibilities SM-4 Security expertise SM-5 Process scoping SM-6 File integrity SM-7 Security Management SM-8 Control for private keys SM-9 Sec. req. for ext. provided comp. SM-10 Custom dev. com. fr. 3rd-p. suppliers SM-11 Assess. and adress. sec.-rel. issues SM-12 Process verification SM-13 Continous improvement Development environm. sec. Page 33 Specification of security requirements SR-1 Product security context SR-2 Threat model SR-3 Product security requirements SR-4 Product sec. req. content SR-5 Security req. review Secure by design SD-1 Secure design principles SD-2 Defense in depth design SD-3 Security design review SD-4 Secure design best practices Practice 4 Secure implementation SI-1 Security implem. review SI-2 Secure coding standards Security verification and validation testing SVV-1 Securtiy req. testing SVV-2 Threat mitigation testing SVV-3 Vulnerability testing SVV-4 Penetration testing SVV-5 Independence of testerd Management of security related issues DM-1 Receiving notifications of sec.-rel. issues DM-2 Reviewing sec.-rel. issues DM-3 Assessing sec.-rel. issues DM-4 Adressing sec.-rel. issues DM-5 Disclosing sec.-rel. issues DM-6 Periodic review of sec. Defect management practice Security update management SUM-1 Securtiy update qualification SUM-2 Security update documentation SUM-3 Depend. comp. or OS sec. update doc. SUM-4 Security update delivery SUM-5 Timely delivery of security patches Security guidlines SG-1 Product DiD SG-2 DiD measures expect. in t. env. SG-3 Sec. hardening guidelines SG-4 Sec. disposal guidelines SG-5 Sec. operation guidelines SG-6 Account management guidel. SG-7 Documentation review

34 Evaluationspartner Profil Anzahl Interviews SAFe Contributor, Senior Experts Agile development 1 8 IEC62443 Contributor, Senior Experts IT security standards 2 16, 17 Senior Experts IT security in management position 5 9, 10, 13, 18, 21 Senior Experts Experts IT security infrastructure 2 14, 15 Senior Experts IT security governance 3 1, 2, 20 Senior Experts IT security processes 3 4, 5, 19 Senior Experts Agile development 4 3, 7, 11, 12 Expert IT security 1 6 Gesamtanzahl 21 Page 34

35 Manage Suppliers Manage Changes Secure SW/HW Product development Secure Infrastructure Integration in bestehende Management-Werkzeuge Enabler Ziele / Prozesse IEC Ziele APO10 BAI06 BAI.. DSS.. Practice 1 Security Management S P Practice 2 Security Requirements S P Practice 3 Secure Design S S P Practice 4 Secure Implementation S P Practice 5 Security verification and validation testing P S Practice 6 Security-issue management P S Practice 7 Security update management P P S Practice 8 Security guidelines S S P Page 35 Quelle: u.a. ISACA (2012)

36 Security Management Security requirements Secure Design Secure Implementation Security Verification and Validation Testing Security-issue management Security update management Security Guidelines Integration in bestehende Management-Werkzeuge IEC Ziele IEC Practice Ziele P1 SM P2 SR P3 SD P4 SI P5 SVV P6 DM P7 SUM P8 SG SD-1-G1 Product s interfaces are characterized P P S S P SD-1-G2 Identification of relevant interface data per interface P SD-1-G3 Mitigation of vulnerability of interfaces P S SD-2-G1 SD-2-G2 SD-3-G1 Page 36 Quelle: u.a. ISACA (2012)