Sie befin­den sich hier:Start­sei­te/Blog/Durch Modell­ba­sier­te Risi­ko­ana­ly­se zum Secu­re Deve­lo­p­ment Life Cycle

Durch Modellbasierte Risikoanalyse zum Secure Development Life Cycle

Lese­zeit: 3 Minu­ten
computer 1591018 960 7201 socialshare

Im Zeit­al­ter der Digi­ta­li­sie­rung und Ver­net­zung ist es uner­läss­lich, Soft­ware im Rah­men des Ent­wick­lungs­pro­zes­ses auf Gefähr­dungs­po­ten­zi­al zu ana­ly­sie­ren. In die­sem Arti­kel erfah­ren Sie, wie Sie mit einer modell­ba­sier­ten Ana­ly­se die Risi­ken wie z. B. nach Frei­ga­be Feh­ler­be­he­bun­gen aus­brin­gen zu müs­sen, Repu­ta­ti­on zu ver­lie­ren, ver­trau­li­che Daten zu offen­ba­ren und Sys­tem­über­nah­men hin­neh­men zu müs­sen, min­dern können.

Doch wie opti­miert man nun einen Sys­tem Deve­lo­p­ment Life Cycle zu einem Secu­re Deve­lo­p­ment Life Cycle? Um die Sicher­heit einer Appli­ka­ti­on zu gewähr­leis­ten, wird die Fra­ge, wie eine Thre­at and Risk Ana­ly­sis (TRA) durch­ge­führt wer­den soll, immer wich­ti­ger. Denn die Zeit zwi­schen dem Bekannt­wer­den einer Ver­wund­bar­keit und einer mög­li­chen Aus­nut­zung wird immer kür­zer und ver­hin­dert eine erfolg­rei­che Patch­in­stal­la­ti­on auf vie­len Maschinen.

Eine wei­te­re Alter­na­ti­ve ist das Ein­bin­den von Sicher­heits­über­le­gun­gen in alle Pha­sen des SDLC – vom Design über Ent­wick­lung, Test und Frei­ga­be bis zur War­tung. Hier­bei soll­ten Model­le zur Risi­ko­be­wer­tung mög­lichst bald im SDLC gene­riert und ent­wick­lungs­be­glei­tend ver­fei­nert werden.
Die­se wer­den in Zusam­men­ar­beit von Sys­tem­ar­chi­tek­ten, Ent­wick­lern und Sicher­heits­ex­per­ten erstellt und berück­sich­ti­gen die fol­gen­den Aspekte:

  • Hacker ver­ste­hen ihre Arbeit
  • der Ent­wick­ler hält sich an vor­ge­ge­be­ne Regeln, der Hacker nicht
  • der Ent­wick­ler hat das gan­ze Sys­tem im Blick, der Hacker ein Detail
  • der Ent­wick­ler kennt geschlos­se­ne Exploits, der Hacker sucht / kennt Neue

Model­le zur Risi­ko­be­wer­tung beant­wor­ten min­des­tens die­se Fragen:

  • Was kann schiefgehen?
  • Ist dies wahrscheinlich?
  • Wie dras­tisch sind die Folgen?
  • Kann das Risi­ko beho­ben werden?

Die Risi­ko-/ Bedro­hungs­ana­ly­sen kön­nen aus Lis­ten und Dia­gram­men bestehen, aber auch aus Model­len, wie sie aus dem Modell­zen­trier­ten Tes­ten bekannt sind. Für bei­de Vor­ge­hens­wei­sen gibt es Vor­ga­ben und Werkzeuge.

Der Modell­zen­trier­te Ansatz bie­tet zum einen den Vor­teil, Zusam­men­hän­ge zu visua­li­sie­ren sowie zum ande­ren Test­fäl­le auto­misch abzuleiten.

Ein Bei­spiel:

dicomsend

Erklä­rung zum Schaubild:

Die bei­den “Geld­sä­cke” ste­hen für das schüt­zens­wer­te Objekt des Sys­tems (EU Ver­ord­nung 2016/679), in die­sem Fall Patientendaten.

Zwei Wege, um Pati­en­ten­da­ten von der bild­ge­ben­den Moda­li­tät in ein Archiv zu sen­den, wer­den bewertet:

Rechts der klas­si­sche Ver­sand der Daten über DICOM Port 104, links der ver­schlüs­sel­te Ver­sand über DICOM Port 2762.

Über den Ver­sand mit DICOM Port 104 hackt der “Angrei­fer” die Netz­werk­über­tra­gung und kann wegen des unver­schlüs­sel­ten Ver­sands (Ver­wund­bar­keit) den Daten­strom mit­le­sen und die Pati­en­ten­da­ten entwenden.

Ist der Ver­sand über Port 2762 ver­schlüs­selt, kann der Daten­strom immer noch mit­ge­le­sen wer­den, aber um ihn zu ent­schlüs­seln ist eine schlech­te Kon­fi­gu­ra­ti­on und oder sehr gutes Ver­ständ­nis der Kom­mu­ni­ka­ti­on not­wen­dig; der Dieb­stahl der Pati­en­ten­da­ten ist daher sehr unwahrscheinlich.

Kommentare und Feedback gerne via Social Media:

Blei­ben Sie auf dem Lau­fen­den – mit dem monat­li­chen sepp.med Newsletter: