2011-04-29 - Risk management conference - Technische IT risico's in de praktijk
•
0 gefällt mir•671 views
Presentation about the risks associated with the silent introduction of embedded software.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Mehr von Jaap van Ekris
Mehr von Jaap van Ekris (20)
2011-04-29 - Risk management conference - Technische IT risico's in de praktijk
- 1. Technische IT Risico’s Wat zijn het, waar komen ze vandaan en hoe kom je er vanaf? Jaap van Ekris (j.vanekris@ieee.org) 29 april 2011
- 3. Onderwerpen
- 4. Wat zijn IT Risico’s?
- 5. IT problemen halen soms de krant…
- 6. De trieste realiteit Software krijgt meer de schuld van bedrijfsverstoringen dan welk product dan ook Geschatte schade is ongeveer $500 miljard per jaar
- 7. Een stereotype IT Risico… USS Yorktown Verloor alle kritische functies tijdens “oorlogsbewegingen” door uitval van één systeem “the control systems just had to be rebooted”, wat bijna 3 uur kostte
- 8. IT Risico ≠ systeem uitval Spontane/Verkeerde taakuitvoering Te laat gedrag Onbestuurbare systemen Integriteit van gegevens
- 9. Spontane/verkeerde taakuitvoering… Software maakt “denkfout” met spontaan of verkeerd gedrag tot gevolg Kan leiden tot spontaan ingrijpende systemen maar ook ernstige verstoringen werkproces Komt ook vaak voort uit programmeerfout, maar ook uit verkeerde samenwerking componenten
- 10. Responsetijden zijn soms cruciaal... Software heeft teveel rekentijd nodig, of moet vechten voor resources Taakuitvoering kan te laat komen om zinnig te zijn, maar kan ook overcompensatie van andere systemen triggeren Performance van systemen is afhankelijk van veel zaken van fundamentele ontwerpfouten tot configuratieproblemen en “lastige buren”.
- 11. Schaalbaarheid/bestuurbaarheid Geïsoleerd werken systemen goed, maar gecombineerd wordt het totale chaos Door verschillende systemen worden tegenstrijdige beslissingen genomen Komt vaak voort uit te weinig aandacht voor het grote plaatje Vaak niet meer te repareren...
- 12. Integriteit van gegevens... Informatie komt binnen, maar is onmogelijk te controleren op geldigheid Op ontraceerbare wijze kunnen systemen “spontaan” bestuurd worden Vereist vaak een goed ontwerp van je infrastructuur, maar ook goed ontwerp van applicaties Slide 1229 January 2015
- 13. Waar komen IT Risico’s vandaan?
- 14. Design/implementation errors Fout in eisen: 0,4 serieuze fout per 10.000 regels code Ontwerpfouten: 0,6 serieuze fout per 10.000 regels code Implementatiefouten: 1 serieuze fout per 10.000 regels code Nog verder verbeteren component helpt vaak maar erg beperkt 15
- 15. Onderschatting complexiteit Oplossingen worden soms ter plekke aan elkaar “geknutseld” Heeft Denver Airport 1,5 miljard gekost HSL Zuid had hierdoor ook zo zijn eigen problemen In technische automatisering meer regel dan uitzondering
- 16. Verkeerde risico “afwegingen”... Maatregelen worden niet genomen vanwege angst voor productieverstoringen Gemak staat voorop Risico’s van “nieuwe techniek” worden ernstig onderschat Heeft de neiging lang goed te gaan, totdat het grootschalig fout gaat
- 17. Hackers snappen embedded systemen... Embedded systemen zijn van nature open, onbeschermd Embedded systemen zijn zeer begrijpelijk voor hackers Veel gevallen bekend van geslaagde verstoringen: - 2009: Alle wegborden in Texas gehacked - 2008: 14 jarige verstoort tram netwerk en ontspoort 4 trams - 2001: Ex-medewerker loost riool in hotelwijk en rivier uit wraak - 2001: Alle electriciteits distributie systemen in California gehacked - 2000: Hackers hacken Russische management systemen gas distributie
- 18. Malware verstoort complexe systemen... Virussen zijn de sluipmoordenaars in de IT Door de complexiteit zijn veel besturingssystemen gevoelig voor kleine verstoringen Gebruikers zijn niet opgevoed problemen te voorkomen Veel serieuze gevallen bekend: - 2010: Stuxnet virus saboteert nucleaire verrijkingssystemen - 2008: Spanair maintenance systemen allen besmet met malware - 2003: Davis-Besse Kerncentrale geinfecteerd door Slammer worm - 2003: Alle treinsystemen in Washington DC plat door virus
- 19. Wat kun je tegen IT Risico’s doen?
- 20. Testen is niet voldoende... Testen worden vaak slecht uitgevoerd Het is fysiek onmogelijk alles te testen Testen kan foutloosheid zowieso niet aantonen
- 21. Eenvoudige redundantie helpt niet... Beschermt tegen hardware falen Problemen op logisch niveau propageren Biedt vals gevoel van zekerheid Vergroot soms alleen maar je probleem....
- 22. Wat vaak beter helpt... Eisen en ontwerpen reviewen Op architectuurniveau eisen borgen Gedegen risico-analyses voor bouw Toezien op implementatie, zowel op proces als implementatie Helpen met beheersprocessen
- 23. Conclusie IT kent veel eigen soorten risico’s De embedded IT component wordt in het algemeen flink onderschat Bewustwording klanten gebeurt door publieke scade en schande Meeste maatregelen zijn geen rocket science 24
Hinweis der Redaktion
- KEMAnees, daarna SERC omdat ik bij klein specialistisch bedrijf wilde werken SERC opgeslokt door CIBIT, CIBIT opgeslokt door DNV Waar de functie en IT bedrijfs of veiligheidskritische rol heeft…
- Het probleem met IT systemen is dat er in praktijk weinig ontwerp-marge is. Een enkele fout kan een systeem totaal onbetrouwbaar maken. Niet alleen in ontwerp, maar ook in gebruik. Voorbeeld van systemen waar een enkele bit het verschil is tussen werken en fundamenteel verkeerd werken.
- Naast je normale proces/project risico’s
- Toen ik begon bij KEMA zei mijn mentor: je levensdoel wordt nu om uit de kranten te blijven Niet helemaal gelukt...
- Capers-Jones
- Is een hoop voor te zeggen dat dit niet zou moeten kunnen….
- Zelfde als zeggen dat belangrijkste risico als dompteur is dat je leeuw zijn trucje niet doet Niet altijd is alles aan de orde, je moet soms keuzes maken.
- Fail-safe gedrag van componenten speelt hier ook een rol! Een van de vele voorbeelden: Air Lauda 004: spontane activering reverse thruster net na take-off Quantas 072 die spontaan stijle duik begon te maken
- Dit is een sluipmoordenaar die moeilijk te managen is in nieuwere IT omgevingen. Soms worden fundamentele IT wetten genegeerd: in test-omgeving werkt het toch? Denk aan een stuurknuppel in een vliegtuig: als die te traag zou reageren, dan eindigt een toestel in de greppel.
- Software kent fundamentele beperkingen
- Laatste Playstation Network Hack
- Dit zijn bekende problemen, ook voor mechanische ontwerpen Dit zijn de voor de hand liggende zaken, die op te lossen zijn door strakkere processen
- Core problem: too much focus on the details of getting a 3500 carts to move over 35KM track, without thinking about the big picture Logistics involved have proven to be too complex to be understood by any expert on the planet, system abandoned after 12 years. Some problems are not real-time solvable (basis of encryption…)
- Met eenvoudige maatregelen goed te voorkomen. Vaak is men te bang om maatregelen te nemen: stel je voor dat de firewall je buitensluit Propogatie van verkeerde projectie door heel Zwitserland....
- Tickles security: hard van buiten, boterzacht van binnen
- Malware kan als een razende om zich heen slaan. Grootschalige controlsystemen waar men gewoon van Unix naar grootschalig Windows netwerk overschakelt voor systeem-management, zonder virusscanners, zonder enige andere maatregel.
- Sommige problemen met systemen manifesteren zich pas na miljoenen draaiuren in exotische situaties Pas bij slijtage van de installatie (= ander gedrag gewenst)
- Duurste vuurpijl ooit, verkeerd hergebruik waar helaas beide redundante last van hadden (enkelvoudige redundantie)….
- Stuxnet is wellicht de beste aanval die de embedded industrie had kunnen overkomen (schade had veel groter kunnen zijn, en maakt industrie wel aware).