Statische Codeanalyse
DSGVO-Konformität für Software
Die Digitalisierung treibt nicht nur die Komplexität voran, sondern auch Anforderungen an Sicherheit, Datenschutz, Zuverlässigkeit, medizinische Zulassung und Kosten. Das gilt insbesondere, seit im Mai dieses Jahres die DSGVO in Kraft getreten ist.
Bei der DSGVO, dem Datenschutz und anderen Daten-Regelwerken wie HIPAA und PCI-DSS (Payment Card Industry-Data Security Standard) oder anderen assoziiert der Software-Entwickler sofort die Notwendigkeit verstärkter Tests, dynamischer Analyse und von Penetrationstests. Tatsächlich sind diese Prüftechniken notwendig und wichtig, denn sie verringern die Wahrscheinlichkeit dafür, dass unsichere Software ausgeliefert wird. Allerdings können Sicherheit und Datenschutz ebenso wenig durch Testen in die Software eingebracht werden wie Qualität oder Leistungsfähigkeit. Die DSGVO erfordert stattdessen Konzepte, die man als »Security by Design« (SbD) und »Privacy by Design« (PbD) bezeichnet, also als designbedingte Sicherheit beziehungsweise designbedingter Datenschutz. Diese beiden Konzepte sind der nächste Schritt im Anschluss an die normalen Applikationssicherheits-Aktivitäten (Firewalls, Penetrationstests, Red Teams, DAST usw.). Das »by Design« lässt sich auch als eingebaut interpretieren.
Der Grundgedanke hierbei ist, dass man nicht in der Applikation herumstochert und etwaige Löcher stopft, sondern eine Applikation baut, die von vornherein keine Löcher aufweist. Die Aufgabe der statischen Analyse besteht nicht nur darin, darüber zu informieren, dass die Software anfällig ist – das ist Aufgabe der Tests. Vielmehr soll sie dabei helfen sicherzustellen, dass die Software von vornherein stabil istläuft. In den letzten Jahren ist die Flussanalyse als Technik für Sicherheitstests populär geworden, aber sie ist nach wie vor nur ein Verfahren zum Testen der Software – und nicht dafür, die Software abzuhärten oder Sicherheit by Design einzubauen.
Um ein DSGVO-Audit zu bestehen, müssen Softwareteams sicherstellen, dass sie nicht nur testen. Richtig angewendet, kann die statische Analyse auf einzigartige Weise als wirklich präventive Technik dienen. Über die Security-Regeln der Flussanalyse hinaus (Suche nach manipulierten Daten) bietet sie Regeln, die für das gesamte Projekt über verschiedene Sprachen und Zielsysteme hinweg sicherstellen, dass die Software auf sichere Weise entwickelt wurde. In Bezug auf PbD lassen sich für die statische Analyse Regeln anwenden, die darauf hinweisen, wenn Daten ohne vorherige Verschlüsselung gespeichert werden, anstelle eines sicheren Verschlüsselungsverfahrens eine gegen Hacking anfällige, ältere Verschlüsselungsmethode zum Einsatz kommt, oder Anwender auf Daten zuzugreifen versuchen, für die sie keine Berechtigung besitzen.
Statistische Analyseregeln
Die folgende Regel erzwingt beim Aufruf von sensiblen Daten ein Logging. Diese statische Analyseregel findet keine Fehler, sondern warnt bei potenzieller Gefahr für Sicherheit und Privatsphäre. So bietet sie beste Voraussetzungen für die DSGVO.
» Ensure all sensitive method invocations are logged [SECURITY.BV.ENFL] «
Diese Regel identifiziert Code, der Aufrufe sensibler Methoden nicht aufzeichnet. Ein Fehler wird gemeldet, sobald Aufrufe sensibler Methoden (zum Beispiel »login« und »logout« aus »javax.security.auth.login. LoginContext«) bei ihrer Verwendung nicht protokolliert sind. Befolgt man diese Regel, werden alle wichtigen Aktionen (Log-In/Out-Versuche, Zugang zu vertraulicher Information etc.) für Sicherheitszwecke protokolliert.
Ein weiteres Beispiel für PbD ist die folgende Regel, die die unabsichtliche Herausgabe persönlicher oder wichtiger Informationen verhindert, wenn in der Software ein Fehler auftritt:
» Do not pass exception messages into output in order to prevent the application from leaking sensitive information [SECURITY.ESD.PEO] «
Sie identifiziert Code, der Exception-Meldungen an den Ausgang weiterleitet. Ein Fehler wird gemeldet, sobald eine Catch-Klausel eine Ausgabemethode aufruft, und die in der Catch-Klausel gefangene Ausnahme in der Parameterliste erscheint oder als aufrufendes Objekt genutzt wird. Diese Regel deckt neben der DSGVO auch OWASP Top 10, CWE und PCI-DSS ab und ist somit auf jeden Fall empfehlenswert für jedes Projekt, in dem Sicherheit eine Rolle spielt.
Da es sich bei der DSGVO um keinen Codierstandard handelt, wird sie von keiner einfachen statischen Analysekonfiguration abgedeckt. Oft ist es am besten, zunächst statische Analyseregeln ausfindig zu machen, die in direktem Zusammenhang mit jenen Aspekten stehen, auf die sich die derzeitigen Testaktivitäten beziehen (zum Beispiel XSS- oder SQLi-Aspekte). Für solche Dinge gibt es meist statische Analyseregeln, die als Bug-Finder agieren können, sodass die Früherkennung derartiger Dinge möglich ist, bevor sie es bis in die Testphase schaffen. Wichtiger noch ist, dass es außerdem Regeln gibt, die in diesem Fall mit der Eingabe-Validierung zusammenhängen und sicherstellen, dass eine SQL-Einschleusung – als eine der gängigsten Exploits – einfach nicht vorkommen kann. Das Verfolgen von Daten von der Eingabe durch den Anwender bis zur Speicherung ist schwierig. Programme so zu schreiben, dass eine Verschlüsselung in jedem Fall erfolgt, ist einfach und lässt sich problemlos durch Testen nachweisen.
Keine Angst vor der DSVGO
Nachdem für die Punkte, die sich beim Testen herausgestellt haben, Regeln ausfindig gemacht und aktiviert wurden, ist der nächste Schritt das Erstellen einer umfangreichen Konfiguration an statischen Analyseregeln. Für DSGVO muss die Konformität mit der Regulierung dokumentiert und gezeigt werden. Weil es in der DSGVO Dokumentation keinen speziellen Codierstandard gibt, ist es lohnenswert, Ideen von anderen Codierstandards zu übernehmen, die sich bereits mit dem Thema Datenschutz befassen. In Frage kommen beispielsweise HIPAA, OWASP und PCI-DSS. Sind in der bestehenden statischen Analyse bereits Regeln aktiviert, die sich auf diese Standards beziehen, ist das ganz im Sinne der DSGVO.
Gelten für ein Projekt bereits weitere Sicherheitsanforderungen wie CWE oder CERT, lässt sich auch deren Befolgung sicherstellen. Darüber hinaus lässt sich die Konfiguration so erweitern, dass nach Bedarf bestimmte Datenschutz-Vorgaben der DSGVO ebenso abgedeckt werden, indem man in diesen anderen Standards all jene Punkte ausfindig macht, die mit Datenschutz und Verschlüsselung zu tun haben.
So furchteinflößend die DSGVO auch erscheinen mag, die korrekte Einrichtung der statischen Analyse mit dem passenden Tool und den richtigen Regeln kann helfen, die Software abzusichern, Prüfern das korrekte Handeln nachzuweisen und den Beleg zu erbringen, dass die Secure-by-Design- und Privacy-by-Design-Prinzipien befolgt wurden. Mit Penetrationstests alleine ist dies nicht möglich. Dazu kommt: Die Herangehensweise nach dem by Design-Prinzip ist wesentlich effektiver als der Versuch, die Sicherheit der Software zwischen Qualitätssicherung und Freigabe durch Testen zu gewährleisten.
| So unterstützt Parasoft bei der DSGVO-Konformität |
|---|
Die automatisierten Softwaretest-Werkzeuge von Parasoft unterstützen auf mehrere Arten, dass der Code von Anfang an auf Sicherheit und Datenschutz ausgerichtet ist: Alle statischen Analyse-Engines beinhalten Konfigurationen für viele Sicherheits-Standards (u.a. HIPAA, OWASP, CWE, CERT, PCI-DSS). Anwender müssen nur die fürs Unternehmen jeweils passenden Security-Regeln aktivieren, damit diese automatisch durchgesetzt werden. Durch die Integration von Parasoft DTP in die statische Analyse entsteht eine vollwertige Audit-Fähigkeit, die die Dokumentation, welche Regeln wann auf welchen Code angewandt wurden, automatisiert. Anhand der ausgewählten Regeln lässt sich nachweisen, dass man testet oder nach dem Secure-by-Design-Konzept arbeitet. Zudem bietet Parasoft DTP einige besondere Reports, u.a. Konformitätsreports für die unterschiedlichen Standards. Entscheidet man sich, die Security-Maßnahmen etwa auf CWE aufzusetzen, stellt das Parasoft CWE Dashboard sicherheits- und datenschutzbezogene Reports zur Verfügung, wobei die Vorfälle nach Schwere, Ort, Typ, Historie usw. geordnet werden. Einen Schritt weiter geht Parasoft, indem das CWE Dashboard mit dem TI (Technical Impact) eine berechnete Kennzahl mit einschließt. Jedes CWE-Resultat informiert darüber, welche Art von Problemen auftreten können, und spezielle Grafiken erleichtern die Navigation durch die statischen Analyseaspekte, die nicht nur auf Sicherheitslevel basieren, sondern auf dem für das eigene Unternehmen wichtigsten Problem. |
Lesen Sie mehr zum Thema
Das könnte Sie auch interessieren
