Mit statischer Analyse „Secure by Design“ für die DSGVO erreichen

Wenn Sie die statische Analyse mit dem richtigen Tool und den richtigen Regeln richtig einrichten, können Sie Ihre Software sichern, den Prüfern beweisen, dass Sie das Richtige tun, und zeigen, dass Sie die Grundsätze von „Security by Design“ und „Privacy by Design“ befolgen.

Die DSGVO ist groß und beängstigend. Kurz gesagt bedeutet die DSGVO, dass Sie den Benutzern Folgendes mitteilen müssen:

• Welche Daten Sie sammeln.
• Wie Sie es verwenden werden.
• Geben Sie Ihr Bestes, um es zu schützen.
• Seien Sie transparent, wenn es zu Verstößen kommt
• Entfernen Sie alle Benutzerdaten vollständig, wenn Sie dazu aufgefordert werden.

Und oh ja, wenn Sie sich nicht daran halten, drohen hohe Geldstrafen.

Theoretisch gilt die DSGVO nur für EU-Bürger, aber die globale Reichweite der meisten Geschäfte erfordert heutzutage Sorgfalt bei der Einhaltung der Vorschriften auf der ganzen Welt. Dies lässt die Wahl zwischen der sicheren und privaten Behandlung aller Benutzer und beispielsweise einem vollständig segmentierten Datenfluss für EU- und Nicht-EU-Kunden – wahrscheinlich ein teureres Unterfangen. In diesem Blog erkläre ich, wie Sie die statische Codeanalyse nutzen können, um den Datenschutz und die Privatsphäre zu verbessern.

Verständnis der DSGVO und ihrer Auswirkungen auf die Softwareentwicklung

Grundprinzipien der DSGVO

Die allgemeinen Ziele der DSGVO bestehen darin, Kundeninformationen angesichts der groß angelegten Datenerfassung durch Organisationen, vorwiegend im Internet, einzuschränken und zu schützen. Die Gesetze werden für EU-Bürger erlassen, aber die Auswirkungen werden weltweit sein, da die meisten Organisationen Geschäfte in EU-Ländern und/oder mit EU-Bürgern tätigen.

Hier sind die wichtigsten Prinzipien.

• Rechtmäßig und transparent. Die Datenerfassung muss rechtmäßig erfolgen, was die Einhaltung der DSGVO und aller anderen Datenerfassungsgesetze im Zuständigkeitsbereich des Benutzers voraussetzt. Die Nutzung der Daten sollte für den Nutzer transparent sein und auf rechtmäßige Weise und mit ausdrücklicher Genehmigung erfolgen.
• Lagerzeit minimieren. Benutzerdaten können nur so lange wie nötig und nicht länger aufbewahrt werden. Benutzerdaten müssen gelöscht oder anonymisiert werden, wenn sie nicht mehr benötigt werden.
• Minimieren Sie die Datenmenge. Die Menge der gesammelten Daten sollte nur so groß sein, wie nötig ist und den ursprünglichen Zweck der Datenerhebung unterstützt.
• Datengenauigkeit. Benutzerdaten müssen korrekt und aktuell sein. Unrichtige Daten müssen korrigiert oder entfernt werden.
• Spezifischer und begrenzter Zweck. Die Erhebung der Nutzerdaten erfolgt ausschließlich zur Erfüllung des ursprünglichen Zwecks. Daten können nicht gespeichert und für andere Zwecke wiederverwendet werden.
• Technische und organisatorische Sicherheitsmaßnahmen. Die Datenerfassung bedeutet, dass Unternehmen personenbezogene Daten vor unbefugtem Zugriff durch illegale oder versehentliche Mittel schützen müssen. Geeignete Technologielösungen zur Wahrung von Integrität und Vertraulichkeit sind erforderlich. Dieser Grundsatz beinhaltet implizit die organisatorische Verantwortung für angemessene Sicherheitsmaßnahmen zum Schutz der Benutzerdaten.

Auswirkungen auf die Softwareentwicklung

Der Einfluss von (DSGVO) Datenschutzgrundverordnung konform zur Softwareentwicklung ist von Bedeutung, da sie eine Reihe von Auswirkungen auf die Softwareentwicklungspraktiken hat. Ein Hauptaugenmerk für Softwareentwickler liegt auf den technischen und organisatorischen Sicherheitsmaßnahmen, die erforderlich sind, um die wichtigsten Grundsätze einzuhalten und die Integrität und Vertraulichkeit der Benutzerdaten sicherzustellen.

• Sorgen Sie für eine rechtmäßige und transparente Sammlung. Wie wir bei der Vielzahl von Website-Popups gesehen haben, müssen Unternehmen sicherstellen, dass sie Benutzerdaten rechtmäßig sammeln, ihre Verwendung vollständig darlegen und vor der Erfassung die Zustimmung der Benutzer einholen. In vielen Fällen erhöhen sich dadurch die Anforderungen an Benutzeroberflächen und Anwendungs-Frontends.
• Organisatorische Maßnahmen zur Gewährleistung des Datenschutzes. Benutzerdaten müssen während ihrer gesamten Lebensdauer in den Systemen einer Organisation als vertraulich betrachtet und entsprechend behandelt werden. Dies steht im Einklang mit dem Dreiklang der CIA aus Vertraulichkeit, Integrität und Zugänglichkeit. Die Philosophie ist grundlegend für Infosec und der Ansatz wird jetzt für Kundendaten in kommerziellen IT-Systemen benötigt. Gemäß der DSGVO müssen Unternehmen auf allen Ebenen Maßnahmen ergreifen, um Kundendaten zu schützen, was Auswirkungen auf die Softwareentwicklung, IT-Systeme, das Organisationsverhalten und die Sicherheitslage hat.
• Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen. Um die Datenschutzgrundsätze der DSGVO zu erfüllen, ist der Einbau von Sicherheitsmaßnahmen erforderlich. Dies bedeutet, dass Sicherheit und Datenschutz beispielsweise bereits in den frühesten Phasen der Anwendungsentwicklung entwickelt und getestet werden. So wie die Sicherheit später im Lebenszyklus eines Produkts nicht getestet werden kann, gilt das Gleiche auch für den Datenschutz der DSGVO. Darüber hinaus sollte der Datenschutz die Standardkonfiguration für IT-Systeme und -Anwendungen sein und nicht davon ausgegangen werden, dass er später beispielsweise über Konfigurationsoptionen „eingeschaltet“ wird.
• Personenbezogene Daten werden angemessen und transparent verarbeitet. Persönliche Daten in Anwendungen und IT-Systemen müssen während der Übertragung und im Ruhezustand geschützt werden. Dies setzt in den meisten Fällen eine angemessene Verschlüsselung der Daten und die Verwendung im Klartext nur dann voraus, wenn dies unbedingt erforderlich ist. Wie die meisten Menschen bei aufsehenerregenden Datenverstößen erlebt haben, haben schlechte Datenspeicherungstechnologien und -praktiken zur Offenlegung hochsensibler Benutzerdaten geführt.
• Begrenzen Sie die Verwendung und die Lagerzeit. Softwareentwickler müssen sicherstellen, dass die Speicherung von Kundendaten zeitlich begrenzt ist, und die Weitergabe dieser Daten über den ursprünglichen Zweck hinaus beschränken. Wenn Kunden beispielsweise 30 Tage lang nicht mit Ihrer Anwendung interagieren, müssen Sie ihre gespeicherten Informationen vollständig löschen, was erhebliche neue Anforderungen an die Datenspeicherung mit sich bringt. Außerdem liegt es in der Verantwortung des Unternehmens, sicherzustellen, dass Kundendaten nicht intern für andere Zwecke verwendet werden. Sammeln Sie beispielsweise Kundensupportdetails und geben Sie diese dann an den Vertrieb oder das Marketing weiter. Ohne ausdrückliche Zustimmung zu dieser Weitergabe ist dies nicht möglich

Sicherheit durch Design und Datenschutz durch Design

Wenn man an DSGVO, Datenschutz und andere damit verbundene Datenvorschriften wie PCI DSS (Payment Card Industry Data Security Standard) oder HIPAA (Health Insurance Portability and Accountability Act) denkt, kommt einem sofort die Notwendigkeit verstärkter Tests, dynamischer Analysen usw. in den Sinn Penetrationstests.

Obwohl diese Testtechnologien notwendig und wichtig sind, verringern sie die Wahrscheinlichkeit, unsichere Software auszuliefern, ohne die Software tatsächlich sicherer zu machen oder den Datenschutz überhaupt zu gewährleisten. Aber Sicherheit und Datenschutz können ebenso wenig in die Software „eingetestet“ werden wie Qualität oder Leistung. Daher erfordert die DSGVO Konzepte namens „Security by Design“ und „Privacy by Design“ (PbD), was in erster Linie bedeutet, Software besser zu entwickeln.

„Der Privacy by Design-Ansatz zeichnet sich durch proaktive statt reaktive Maßnahmen aus. Es antizipiert und verhindert Ereignisse, die in die Privatsphäre eingreifen, bevor sie eintreten. PbD wartet nicht darauf, dass Datenschutzrisiken eintreten, und bietet auch keine Abhilfemaßnahmen für die Behebung von Datenschutzverletzungen an, sobald diese eingetreten sind – es zielt darauf ab, deren Auftreten zu verhindern. Kurz gesagt: „Privacy by Design“ steht im Vordergrund und nicht im Nachhinein.“

-A. Cavoukian. Privacy by Design – Die 7 Grundprinzipien, Januar 2011.

Ich erwähne diese beiden Konzepte, weil sie der nächste Schritt nach den normalen Anwendungssicherheitsaktivitäten sind (Firewalls, Penetrationstests, Red Teams, DAST usw.). Der Teil „by design“ kann auch als „einbauen“ gelesen werden. Das ist die Idee, dass Sie, anstatt in Ihrer Anwendung herumzustochern und zu reparieren, wo die Lücken sind, eine Anwendung ohne die Lücken erstellen – sozusagen per Design. Beispielsweise ist SQL-Injection (SQLi) nach wie vor einer der häufigsten Exploits.

Es gibt viele Tools, mit denen versucht wird, entweder eine Injektion über die Benutzeroberfläche zu erzwingen (Penetrationstests) oder den Datenfluss in einem Programm zu simulieren, ohne es auszuführen, um zu sehen, ob fehlerhafte Daten zu einer Datenbankabfrage gelangen können (Flussanalyse).

Ein „by design“-Ansatz bedeutet, jede Eingabe – von einer Datenbank, einem Benutzer oder irgendwo anders – in dem Moment, in dem die Eingabe erfasst wird, in eine Validierungsfunktion einzubinden. Dadurch werden die möglichen Pfade, die die Daten umgehen können, auf Null reduziert. Sie müssen immer noch die Penetrationstests durchführen, um sicherzustellen, dass Sie Ihre Software richtig erstellt haben. Der Unterschied besteht jedoch darin, dass Sie bei einem erfolgreichen Penetrationstest nicht einfach die eine Schwachstelle beheben, die Sie gefunden haben. Stattdessen blicken Sie zurück und finden heraus, WARUM der Pen-Test erfolgreich war, und bauen Ihre Software so auf, dass sie nicht erfolgreich ist.

Wenn ein Pentest viele Sicherheitslücken in Ihrer Software aufdeckt, dann entwickeln Sie keine sichere Software „by design“. Ähnlich wie bei Privacy by Design beobachten wir, wen/was/wo wir teilen, und wir gehen davon aus, dass alle Daten wichtig sind, sofern nicht anders angegeben. Auch hier gehen Programmierer häufig davon aus, dass Daten NICHT wichtig sind, sofern sie nicht speziell gekennzeichnet sind.

Dies zeigt sich beispielsweise bei Entscheidungen darüber, ob die Daten im Klartext gespeichert oder verschlüsselt werden. Alles zu verschlüsseln ist eine Möglichkeit, Privatsphäre durch Design zu gewährleisten. Eines von vielen, aber das ist die Grundidee. Wenn Sie alles verschlüsseln, müssen Sie sich nie Sorgen machen, dass Sie etwas nicht verschlüsselt haben, das Sie haben sollten.

Welche Rolle spielt hier die statische Analyse?

Das Rolle der statischen Analyse soll uns nicht sagen, dass unsere Software angreifbar ist. Das ist die Aufgabe des Testens. Die Rolle der statischen Analyse besteht darin, sicherzustellen, dass die Software von vornherein stark ist – vom Design her. Obwohl die Flussanalyse in den letzten 10 Jahren als Sicherheitstesttechnik populär geworden ist, handelt es sich immer noch um eine Methode zum Testen der Software und nicht um eine Möglichkeit, die Software zu härten – oder Sicherheit einzubauen – oder dies „by design“ durchzuführen.

Bei richtiger Anwendung kann die statische Analyse hervorragend als echte Präventionstechnik eingesetzt werden. Zusätzlich zu den Sicherheitsregeln für die Flussanalyse, beispielsweise zur Suche nach fehlerhaften Daten, aktivieren wir auch Regeln, die sicherstellen, dass die Software sicher erstellt wird. In Anbetracht der beiden oben genannten Fälle kann ich beim Durchführen von „Privacy by Design“ statische Analyseregeln haben, die Folgendes markieren:

Die Daten werden ohne vorherige Verschlüsselung gespeichert.

Anstelle einer starken Verschlüsselung wird eine alte, unsachgemäße und hackbare Verschlüsselungsmethode verwendet.

Benutzer versuchen, für ihre erwarteten Berechtigungen auf ungeeignete Daten zuzugreifen.

Hier finden Sie eine kurze Beschreibung einer Beispielregel, die die Protokollierung erzwingt, wenn vertrauliche Methoden aufgerufen werden. Diese statische Analyseregel findet keine Fehler, hilft Ihnen aber dabei, Software zu erstellen, die protokolliert, was vor sich geht, sodass sie in der Produktion sicherer ist. Diese Regel passt perfekt zu PCI DSS und DSGVO.

Stellen Sie sicher, dass alle vertraulichen Methodenaufrufe protokolliert werden [SECURITY.BV.ENFL] 

BESCHREIBUNG: Diese Regel identifiziert Code, der keine vertraulichen Methodenaufrufe protokolliert. Ein Fehler wird gemeldet, wenn einige vertrauliche Methodenaufrufe, z. B. "Anmelden" und "Abmelden" von "javax.security.auth.login.LoginContext", bei Verwendung nicht protokolliert werden.

Ein weiteres Beispiel für Datenschutz ist diese Regel, die verhindert, dass Sie ungewollt persönliche oder wichtige Informationen verlieren, wenn ein Fehler in Ihrer Software auftritt:

Übergeben Sie keine Ausnahmemeldungen an die Ausgabe, um zu verhindern, dass die Anwendung vertrauliche Informationen verliert [SECURITY.ESD.PEO] 

BESCHREIBUNG: Diese Regel identifiziert Code, der Ausnahmemeldungen an die Ausgabe übergibt. Ein Fehler wird gemeldet, wenn eine catch-Klausel eine Ausgabemethode aufruft und die in der catch-Klausel abgefangene Ausnahme in der Liste der Parameter angezeigt wird oder als aufrufendes Objekt verwendet wird.

Diese Regel deckt OWASP Top 10, CWE, PCI DSS und DSGVO ab – das heißt, es ist eine wirklich gute Idee, egal warum Sie versuchen, Sicherheit zu gewährleisten.

Vorteile der Verwendung der statischen Analyse für DSGVO

Statische Analysewerkzeuge sind nützlich, um die Anforderungen zum Schutz von Benutzerdaten auf allen Ebenen zu unterstützen, indem sie die Qualität, den Datenschutz und die Sicherheit von Anwendungen verbessern. Im Einzelnen umfasst dies:

• Frühzeitige Erkennung von Sicherheitslücken. Die statische Analyse hilft durch sichere Codierungsstandards, die Entwicklung minderwertiger Software zu verhindern, die zu Schwachstellen führt, die später ausgenutzt werden können. Diese Tools erkennen und identifizieren potenzielle Sicherheitslücken auch früh im Softwareentwicklungslebenszyklus, bevor die Software in der Produktion bereitgestellt wird. Dadurch können Entwickler diese Schwachstellen beheben, bevor sie zu einem Sicherheits- oder Datenschutzproblem werden.
• Verhinderung schlechter Datenschutz- und Sicherheitspraktiken. Statische Analysetools können so konfiguriert werden, dass sie nach bestimmten schlechten Sicherheits- und Datenschutzpraktiken suchen, die bei Datenschutzverletzungen häufig vorkommen. Beispielsweise kann die Verwendung bekanntermaßen schlechter Kryptografietechniken gemeldet werden.
• Verbesserte Softwarequalität. Eine allgemeine Verbesserung der Softwarequalität ist unerlässlich, um die Möglichkeit zukünftiger Datenlecks und Sicherheitslücken auszuschließen.

Häufige Datenschutzprobleme, die durch statische Analyse behoben werden

Die Stärken statischer Analysetools liegen in zwei Schlüsselbereichen.

1. Verhinderung schlechter Codierungspraktiken durch Durchsetzung von Codierungsstandards.
2. Erkennung von Fehlern und Schwachstellen aufgrund von Logikfehlern im Code.

Die DSGVO stellt weder einen Codierungsstandard bereit, noch beschreibt sie explizit Sicherheits- und Datenschutzfehler, die erkannt und behoben werden müssen. Wenn Sie sich jedoch die Unterstützung anderer verwandter Standards wie PCI DSS ansehen, können wir dieselben Konzepte wiederverwenden. Es können beispielsweise folgende Arten von Datenschutzproblemen festgestellt werden:

• Injektionsfehler, einschließlich SQL-, Befehls-, LDAP- und XPath-Injektionen
• Puffer läuft über
• Unsichere kryptografische Funktionen
• Unsichere Datenkommunikation
• Unsachgemäße Fehlerbehandlung
• Unsachgemäße Zugangskontrolle
• Cross-Site-Skripting
• Standortübergreifende Fälschung von Anfragen
• Unterbrochene Authentifizierung und Sitzungsverwaltung

Darüber hinaus unterstützt Parasoft die folgenden sicheren Codierungsstandards, von denen Entwickler einen einzigartigen Satz für ihre Organisation anpassen können:

• SEI CERT C und CERT C++
• CWE Top 25 der gefährlichsten Softwarefehler, CWE an der Schwelle
• OWASP Top 10, OWASP API-Sicherheit Top 10

Erste Schritte

Da es sich bei der DSGVO nicht um einen Codierungsstandard handelt, gibt es keine einfache statische Analysekonfiguration, die diese abdeckt. Der beste Ausgangspunkt besteht häufig darin, statische Analyseregeln zu finden, die sich direkt auf die Probleme beziehen, die Sie derzeit beim Testen finden, z. B. XSS- oder SQLi-Probleme. Für solche Probleme gibt es im Allgemeinen einige statische Analyseregeln, die als Fehlersucher dienen und eine frühzeitige Erkennung dieser Probleme ermöglichen, bevor sie zum Testen gelangen. Noch wichtiger ist, dass es auch damit verbundene Regeln gibt, in diesem Fall rund um die Eingabevalidierung, die Ihnen helfen, sicherzustellen, dass SQLi einfach nicht passieren kann, wie ich oben erwähnt habe.

Das Verfolgen von Daten von Benutzereingaben über den Speicher ist schwierig. Die Programmierung so, dass die Validierung immer erfolgt, ist einfach. Die Programmierung so, dass die Verschlüsselung immer erfolgt, ist einfach durchzuführen und leicht zu testen. Warum auf die harte Tour?

Was sind einige andere statische Analyseregeln?

Sobald Sie Regeln für Probleme, die Sie beim Testen finden, gefunden und aktiviert haben, möchten Sie vielleicht noch weiter gehen. Ich würde vorschlagen, Ideen von anderen Codierungsstandards zu übernehmen, die bereits Datenschutz und Datenschutz abdecken. Einige gute Optionen sind OWASP, HIPAA und PCI DSS.

Wenn Sie in Ihrem statischen Analysetool Regeln aktivieren, die sich auf diese Standards beziehen, leisten Sie gute Arbeit für die DSGVO. Wenn Sie bereits PCI DSS-konform sind, werden Sie feststellen, dass zumindest die Vorbereitung auf diesen Teil der DSGVO relativ einfach sein sollte.

Wenn Sie bereits andere Sicherheitsanforderungen wie CWE oder CERT haben, können Sie sicherstellen, dass Sie diese ebenfalls befolgen, und Ihre Konfiguration bei Bedarf erweitern, um den spezifischen DSGVO-Datenschutz abzudecken, indem Sie in diesen Standards nach Elementen suchen, die sich auf Datenschutz beziehen und Verschlüsselung.

Was kann Parasoft noch für Sie tun?

Parasoft kann Ihnen auf verschiedene Weise dabei helfen, Ihren Code sicher und privat zu gestalten. Erstens verfügen alle unsere statischen Analyse-Engines über Konfigurationen für OWASP, CWE, CERT, PCI DSS, HIPAA usw. Sie können genau die Sicherheitsregeln aktivieren, die für Ihr Unternehmen am besten geeignet sind, und diese dann automatisch durchsetzen.

Darüber hinaus verfügen Sie durch die Integration von Parasoft DTP mit der statischen Analyse über vollständige Audit-Funktionen und automatisieren den Prozess der Dokumentation, welche Regeln wann für welchen Code ausgeführt wurden. Sie können anhand der von Ihnen ausgewählten Regeln nachweisen, dass Sie Tests durchführen oder sich sogar als sicher erweisen.

Parasoft DTP hat auch einige ganz besondere Berichte. Wenn Sie sich dafür entscheiden, Ihre Sicherheitsbemühungen auf CWE zu stützen, bietet Ihnen das Parasoft CWE-Dashboard großartige SAST-Berichte, z. B. Probleme nach Schweregrad, Standort, Typ, Verlauf und mehr.

Wir sind noch einen Schritt weiter gegangen und haben die technischen Auswirkungsdaten in CWE implementiert. Technical Impact (TI) ist eine bei Mitre im Rahmen des Common Weakness Risk Analysis Framework (CWRAF) durchgeführte Forschung und hilft Ihnen, SAST-Ergebnisse basierend auf dem Problem, das sie verursachen können, zu klassifizieren. Anstelle einer Meldung, dass ein Pufferüberlauf vorliegt, den manche möglicherweise nicht als Sicherheitsproblem erkennen, teilt Ihnen TI mit, dass ein Pufferüberlauf zu einem Denial-of-Service führen könnte.

Jeder CWE-Befund sagt Ihnen, welche Arten von Problemen auftreten können. Es gibt spezielle Diagramme, die Ihnen bei der Navigation durch Ihre statischen Analyseprobleme anhand der für Sie wichtigsten Problembereiche und nicht nur anhand der Schweregrade helfen. Diese bahnbrechende Technik hilft Ihnen dabei, die oft überwältigende Anzahl an Schwachstellen in den Griff zu bekommen, insbesondere wenn Sie mit einer älteren Codebasis arbeiten. Konzentrieren Sie sich zunächst auf die Themen, die Ihnen am meisten Angst machen.

Und obwohl ich mich heute auf die statische Analyse als Möglichkeit für Security by Design konzentriert habe, dürfen wir nicht vergessen, dass Parasoft auch über Penetrationstest-Tools, API-Tests und Service-Virtualisierung verfügt, die alle ein wichtiger Bestandteil eines umfassenden Ansatzes sind sichere Software-Entwicklungsstrategie.

Zusammenfassung und wichtige Erkenntnisse

Die DSGVO sieht beängstigend aus und kann es sicherlich auch sein, aber die ordnungsgemäße Einrichtung der statischen Analyse mit dem richtigen Tool und den richtigen Regeln wird Ihnen helfen:

• Sichern Sie Ihre Software.
• Beweisen Sie für Wirtschaftsprüfer, dass Sie das Richtige tun.
• Zeigen Sie, dass Sie die Grundsätze „Secure by Design“ und „Privacy by Design“ befolgen.

Dies ist etwas, was Penetrationstests allein nicht leisten können. Der zusätzliche Vorteil besteht darin, dass Sie feststellen werden, dass es weitaus effektiver ist, Sicherheit aus der „by-design“-Perspektive anzugehen, als zu versuchen, Ihren Weg zur Sicherung von Software zwischen QA und Release zu testen.