Die Infor­ma­ti­ons­si­cher­heit hat Ein­zug in den All­tag genom­men. Vie­le ken­nen jetzt Dank der Gerä­te und Social Media Platt­for­men, die sie ver­wen­den, Tech­ni­ken wie Zwei-Fak­tor-Authen­ti­sie­rung, Ver­schlüs­se­lung und Soft­ware-Updates. Wenn es um die Inne­rei­en — also das Secu­re Design — geht, so blei­ben vie­le Fra­gen offen. Was in moder­nen Pro­zes­so­ren heut­zu­ta­ge vor­geht, lässt sich schwer in weni­gen Wor­ten aus­drü­cken. Die Feh­ler Melt­down und Spect­re sind zwar in aller Mun­de, jedoch braucht man viel Vor­wis­sen, um zu ver­ste­hen, was da genau pas­siert. Dazu kommt zusätz­lich der Code, der in der Firm­ware, qua­si unter dem Betriebs­sys­tem, Arbeit für Gerä­te wie Gra­fik­kar­ten oder Netz­werk­kar­ten ver­rich­tet. Möch­te man jetzt eine Appli­ka­ti­on ent­wi­ckeln, stellt sich die fol­gen­de Fra­ge: Wie kann man bei der Viel­zahl von Kom­po­nen­ten den Über­blick behal­ten und sicher pro­gram­mie­ren? Secu­re Coding, also siche­re Pro­gram­mier­tech­ni­ken, allei­ne hilft ja nur beim eige­nen Code. Die Ant­wort liegt in der Archi­tek­tur des Ganzen.

Der Auf­bau ent­schei­det beim Secu­re Design

Eine Anwen­dung beginnt nie­mals mit Code. Am Anfang steht immer ein Design und eine Beschrei­bung der Auf­ga­ben, die eine Appli­ka­ti­on erfül­len soll. Die­se Pha­se ist der kri­tischs­te Teil bei der Soft­ware­ent­wick­lung, denn Ent­schei­dun­gen, die hier getrof­fen wer­den, bestim­men meist die Zukunft des Pro­jekts. Das bedeu­tet im Beson­de­ren, dass die Grund­la­ge für die spä­te­re Infor­ma­ti­ons­si­cher­heit des Codes an die­ser Stel­le getrof­fen wird. Bei­spiels­wei­se die Aus­wahl der Kom­po­nen­ten, die ver­wen­de­ten Pro­to­kol­le, not­wen­di­ge Bedin­gun­gen (wie bei­spiels­wei­se kryp­to­gra­fi­sche Schlüs­sel, Anfor­de­run­gen an Netz­werk und Spei­cher, etc.) und Kom­mu­ni­ka­ti­on mit Dritt­an­bie­tern wer­den in der Design­pha­se fest­ge­schrie­ben. Was bedeu­tet also Secu­re Design in die­sem Zusammenhang?

Secu­re Design besteht aus einer Rei­he von Grund­la­gen, die an jeder Stel­le im Soft­ware­pro­jekt beach­tet wer­den. Man ver­sucht die Angriffs­flä­che des Codes zu mini­mie­ren, über­all siche­re Defaults zu ver­wen­den, so weni­ge Berech­ti­gun­gen wie mög­lich an Konten/Komponenten zu ver­tei­len, Sicher­heits­prü­fun­gen in allen Schich­ten ein­zu­bau­en, Feh­ler sicher abzu­fan­gen, kei­nen frem­den Diens­ten zu ver­trau­en und Auf­ga­ben im Code zu tren­nen. Die Appli­ka­ti­on muss in jeder Umge­bung zuver­läs­sig arbei­ten kön­nen, ohne Schwach­stel­len preis­zu­ge­ben. Ver­ar­bei­te­te Daten müs­sen stän­dig auf ihre Inte­gri­tät über­prüft wer­den. Das gilt auch für inter­ne Pro­zes­se wie Kom­mu­ni­ka­ti­on mit einer Daten­bank oder ande­ren Tei­len. Ent­wick­ler und der Code dür­fen zu kei­ner Zeit von Annah­men aus­ge­hen, die ein Angriff negie­ren könn­te. Dies schließt Soft­ware­bi­blio­the­ken und Fähig­kei­ten von Hard­ware bzw. Betriebs­sys­te­men ein. Dar­un­ter fal­len auch die Eigen­schaf­ten von Pro­zes­so­ren, die die Klas­se der Melt­down und Spect­re Feh­ler her­vor­ge­ru­fen haben.

Natür­lich darf man sich jetzt nicht von der Para­noia packen las­sen und auf alle Fea­tures der Platt­form ver­zich­ten. Man soll ja Code wie­der­ver­wen­den und nicht immer das Boot neu erfin­den (das Boot ist älter als das Rad). Es geht immer um Annah­men, die man trifft, wenn man pro­gram­miert. Die XML Ein­ga­be ist viel­leicht kein XML. Die Ant­wort des Cloud Ser­vices stammt viel­leicht nicht von der ange­nom­me­nen Quel­le oder ist ein­fach falsch. Die Daten, die man vor­her in die Daten­bank geschrie­ben hat, sind mög­li­cher­wei­se nun falsch (weil es einen Angriff gab). Moder­ner Code steckt vol­ler Annah­men. Span­nend wird es, wenn die­se nicht stimmen.

Mathe­ma­ti­sche Bewei­se für Secu­re Coding

Eine Mög­lich­keit Mehr­deu­tig­kei­ten in Spe­zi­fi­ka­tio­nen zu ver­mei­den ist die Mathe­ma­tik. Da Code aus der Infor­ma­tik kommt und die Infor­ma­tik ein Teil­ge­biet der Mathe­ma­tik ist, las­sen sich Pro­zes­se mathe­ma­tisch dar­stel­len. Über­setzt man nun Auf­ga­ben aus den Design­do­ku­men­ten in eine mathe­ma­ti­sche Spra­che, so las­sen sich mit Hil­fe von Werk­zeu­gen Abläu­fe im Code mathe­ma­ti­siert dar­stel­len und bewei­sen. Schafft man dies, so ist man sprich­wört­lich auf der siche­ren Sei­te. Zusätz­lich eli­mi­niert man so unkla­re For­mu­lie­run­gen, was wie­der­um den Ent­wick­le­rin­nen hilft.

Die For­ma­lis­men sind auch ein Teil von Secu­re Design.

Daten­ba­sier­te Ent­wick­lung ≠ Datenbank-Entwicklung

Wie imple­men­tiert man nun Secu­re Design? Da man es immer mit Daten zu tun hat, kann man bei die­sen begin­nen. Die Appli­ka­ti­on soll ja mit Feh­lern sichern umge­hen kön­nen. Das bedeu­tet bei Ein­ga­be von unsin­ni­gen oder mani­pu­lier­ten Daten darf nichts Kri­ti­sches pas­sie­ren. Eine Tak­tik ist daher, die Soft­ware mit zufäl­lig erzeug­ten oder mani­pu­lier­ten Daten zu füt­tern und zu schau­en was pas­siert. Letzt­lich ist das die Stra­te­gie der Test­fäl­le, die man bei der Ent­wick­lung oft hat, um besei­tig­te Feh­ler nicht wie­der im Code zu fin­den. Die Tech­nik, Sys­te­me mit Zufalls­da­ten zum Stol­pern zu brin­gen, heißt Fuz­zing. Es gibt vie­le Werk­zeu­ge dafür, teil­wei­se auch schon für die Ent­wick­lungs­werk­zeu­ge. Am bes­ten funk­tio­niert die Kom­bi­na­ti­on aus Zufalls­da­ten und ech­ten Daten, damit man über die ers­te Über­prü­fung hin­weg­kommt. Schließ­lich möch­te man ja den gan­zen Code testen.

Her­stel­ler von Betriebs­sys­te­men oder Teams, die kri­ti­sche Soft­ware ent­wi­ckeln, ver­wen­den die­sen Ansatz schon.

Die Gewohn­hei­ten ändern!

Infor­ma­ti­ons­si­cher­heit steht und fällt mit den Gewohn­hei­ten des All­tags. Alles, was aktiv bedacht wer­den muss, geht frü­her oder spä­ter schief. Das­sel­be gilt natür­lich auch für die Soft­ware­ent­wick­lung. Aus die­sem Grun­de muss man Secu­re Design und Secu­re Coding in geeig­ne­ten Schrit­ten in die eige­nen Pro­zes­se ein­bau­en. Das lässt sich lei­der nicht mit der Lek­tü­re einer Doku­men­ta­ti­on oder Anlei­tung allei­ne durch­füh­ren. Emp­feh­lens­wert ist die Umset­zung in Teil­schrit­ten, beglei­tet durch einen Work­shop für alle Ent­wick­ler. Es gibt reich­hal­tig Mate­ri­al zur Anschau­ung, denn das Stu­di­um von bekann­ten Feh­lern schafft Pra­xis­nä­he und hilft den eige­nen Code zu hinterfragen.

Über René Pfeiffer

René Pfeif­fer ist seit 2009 als Seni­or Secu­ri­ty Con­sul­tant für SEC4YOU tätig. Neben sei­ner selbst­t­än­di­gen Tätig­keit ist der Geschäft­füh­rer der Deep­Sec GmbH und ver­an­stal­tet seit über 10 Jah­ren die DEEPSEC. Durch die Nut­zung von aner­kann­ten Metho­den und sei­ne Affi­ni­tät zu IT-Secu­ri­ty und Linux durf­te er unzäh­li­ge Kun­den den den Bran­chen Indus­trie, Luft­fahrt, Tele­kom­mu­ni­ka­ti­on, Ener­gie­ver­sor­ger, Phar­ma­zie, Gesund­heits­we­sen, Wer­bung, Anwalts­kanz­lei­en, NGOs, Medi­en, Logis­tik und Soft­ware-Ent­wick­lung in Sicher­heits­fra­gen beraten.

Fra­gen an René Pfeif­fer zu Secu­re Design — Secu­re Coding  stel­len Sie bit­te über unser Kon­takt­for­mu­lar.