Parasoft C/C++test 2022.2 unterstützt das neue MISRA C:2012 Amendment 3 und eine Entwurfsversion von MISRA C++ 202x. Erfahren Sie mehr >>

Verwenden der statischen Analyse, um "Secure-by-Design" für GDPR zu erreichen

Von Arthur Hicken

10. Mai 2018

7  min lesen

Wenn Sie die statische Analyse mit dem richtigen Tool und den richtigen Regeln richtig einrichten, können Sie Ihre Software schützen, beweisen, dass Sie das Richtige für Auditoren tun, und zeigen, dass Sie die Prinzipien von Secure-by-Design und Privacy-by befolgen -Design.

GDPR ist groß und beängstigend und kommt von Tag zu Tag näher. Ein Teil von mir möchte glauben, dass wir alle bis zum 25. Mai fertig sein werdenth Frist, aber mehr von mir glauben, dass der eigentliche Drang zur Einhaltung nach diesem Datum stattfinden wird. Wenn Sie sich nicht sicher sind, was GDPR wirklich ist oder wenn es Ihnen wichtig ist, schauen Sie sich meine an letzten Blog für eine größere Übersicht. Kurz gesagt bedeutet dies, dass Sie den Benutzern mitteilen müssen, welche Daten Sie sammeln, wie Sie sie verwenden, Ihr Bestes tun, um sie zu schützen, bei Verstößen transparent zu sein und alle Benutzerdaten vollständig zu entfernen, wenn sie dazu aufgefordert werden. Und oh ja, wenn Sie sich nicht daran halten, gibt es hohe Geldstrafen.

Theoretisch gilt die DSGVO nur für EU-Bürger, aber die globale Reichweite der meisten Handelsunternehmen erfordert heutzutage Sorgfalt bei der Einhaltung der weltweiten Vorschriften. Dies lässt die Wahl zwischen einer sicheren und privaten Behandlung aller Benutzer und einem vollständig segmentierten Datenfluss für EU- und Nicht-EU-Kunden (wahrscheinlich ein teureres Angebot). In diesem Blog werde ich erklären, wie Sie die statische Code-Analyse nutzen können, um den Datenschutz und die Privatsphäre zu verbessern.

Sicherheit durch Design und Datenschutz durch Design

Wenn Sie an DSGVO, Datenschutz und andere damit verbundene Datenschutzbestimmungen wie PCI-DSS (Payment Card Industry-Datensicherheitsstandard) oder HIPAA (Gesetz über die Portabilität und Rechenschaftspflicht von Krankenversicherungen) denken, ist der unmittelbare Gedanke die Notwendigkeit verstärkter Tests und dynamischer Analysen und Penetrationstests. Diese Testtechnologien sind zwar notwendig und wichtig, verringern jedoch die Wahrscheinlichkeit, dass unsichere Software ausgeliefert wird, ohne die Sicherheit der Software zu erhöhen oder die Privatsphäre zu gewährleisten. Sicherheit und Datenschutz können jedoch nur in Qualität oder Leistung in Software „getestet“ werden. Daher erfordert die DSGVO Konzepte mit den Namen „Security by Design“ und „Privacy by Design“ (PbD), was bedeutet, dass Software in erster Linie besser erstellt werden muss.

 „Der Privacy by Design-Ansatz zeichnet sich eher durch proaktive als durch reaktive Maßnahmen aus. Es antizipiert und verhindert invasive Datenschutzereignisse, bevor sie eintreten. PbD wartet nicht auf das Eintreten von Datenschutzrisiken und bietet auch keine Abhilfemaßnahmen zur Behebung von Datenschutzverletzungen an, sobald diese aufgetreten sind. Ziel ist es, deren Auftreten zu verhindern. Kurz gesagt, Privacy by Design kommt vor und nicht danach. “

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

Ich spreche diese beiden Konzepte an, da sie der nächste Schritt nach den normalen Aktivitäten zur Anwendungssicherheit sind (Firewalls, Penetrationstests, rote Teams, DAST usw.). Der Teil "by design" kann auch als "build it in" gelesen werden. Dies ist die Idee, dass Sie, anstatt an Ihrer Anwendung herumzustochern und zu korrigieren, wo sich die Löcher befinden, eine Anwendung ohne die Löcher erstellen… sozusagen vom Design her. Beispielsweise ist SQL Injection (SQLi) weiterhin einer der häufigsten Exploits.

Es gibt viele Tools, mit denen versucht werden kann, entweder eine Injektion über die Benutzeroberfläche zu erzwingen (Penetrationstest) oder den Datenfluss in einem Programm zu simulieren, ohne ihn auszuführen, um festzustellen, ob fehlerhafte Daten zu einer Datenbankabfrage gelangen können (Flussanalyse). Ein "by Design" -Ansatz bedeutet, dass alle Eingaben (von der Datenbank, vom Benutzer oder von irgendwoher) zum Zeitpunkt der Eingabe in eine Validierungsfunktion eingeschlossen werden. Dies reduziert die möglichen Pfade, auf denen die Daten umgangen werden können, auf Null. Sie müssen die Penetrationstests noch ausführen, um sicherzustellen, dass Sie Ihre Software richtig erstellt haben. Der Unterschied besteht jedoch darin, dass Sie bei einem erfolgreichen Pentest nicht einfach die gefundene Schwachstelle beheben. Stattdessen schauen Sie zurück und finden heraus, WARUM Pentest erfolgreich war, und erstellen Ihre Software, damit sie nicht erfolgreich ist.

Wenn Pentest viele Sicherheitslücken in Ihrer Software findet, erstellen Sie keine sichere Software "von Natur aus". Ähnlich wie bei Privacy by Design beobachten wir, wer / was / wo wir teilen, und wir gehen davon aus, dass alle Daten wichtig sind, sofern nicht anders angegeben. Wiederum gehen Programmierer häufig davon aus, dass Daten nicht wichtig sind, es sei denn, sie sind speziell gekennzeichnet. Sie sehen dies beispielsweise in Entscheidungen darüber, ob die Daten in einfacher Form gespeichert oder ob Daten verschlüsselt sind. Das Verschlüsseln von allem ist eine Möglichkeit, die Privatsphäre von Natur aus zu schützen. Eine von vielen selbstverständlich, aber das ist die Grundidee. Wenn Sie alles verschlüsseln, müssen Sie sich keine Sorgen machen, dass Sie etwas nicht verschlüsselt haben, das Sie haben sollten.

Welche Rolle spielt hier die statische Analyse?

Die Rolle der statischen Analyse besteht nicht darin, uns mitzuteilen, dass unsere Software anfällig ist (dies ist die Aufgabe des Testens). Die Rolle der statischen Analyse besteht darin, sicherzustellen, dass die Software in erster Linie stark ist… von Natur aus. Während die Flussanalyse in den letzten 10 Jahren als Sicherheitstesttechnik populär geworden ist, ist sie immer noch eine Möglichkeit, die Software zu testen, anstatt die Software zu härten, Sicherheit einzubauen oder sie „beabsichtigt“ durchzuführen.

Die statische Analyse kann eindeutig positioniert werden, um bei richtiger Anwendung als echte Präventionstechnik zu fungieren. Zusätzlich zu den Sicherheitsregeln für die Flussanalyse, dh der Suche nach fehlerhaften Daten, aktivieren wir auch Regeln, die sicherstellen, dass die Software auf sichere Weise erstellt wird. In Anbetracht der beiden oben genannten Fälle kann ich bei der Ausführung des Datenschutzes statische Analyseregeln festlegen, die kennzeichnen, wenn Daten gespeichert werden, ohne zuvor verschlüsselt zu werden, oder wenn anstelle einer starken Verschlüsselung eine alte, nicht hackbare Verschlüsselungsmethode verwendet wird oder wenn Benutzer dies tun versuchen, auf unangemessene Daten für ihre erwarteten Berechtigungen zuzugreifen.

Hier ist eine kurze Beschreibung einer Beispielregel, die die Protokollierung erzwingt, wenn sensible Methoden aufgerufen werden. Diese statische Analyseregel findet keine Fehler, hilft Ihnen jedoch dabei, Software zu erstellen, die die Vorgänge protokolliert, damit sie in der Produktion sicherer ist. Diese Regel passt sowohl zu PCI-DSS als auch zu GDPR.

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 gilt für OWASP Top 10, CWE, PCI-DSS und GDPR. Dies bedeutet, dass dies eine wirklich gute Idee ist, unabhängig davon, warum Sie versuchen, Sicherheit zu gewährleisten.

Erste Schritte

Da GDPR kein Codierungsstandard ist, gibt es keine einfache statische Analysekonfiguration, die dies abdeckt. Häufig besteht der beste Ausgangspunkt darin, statische Analyseregeln zu finden, die sich direkt auf die Probleme beziehen, die Sie derzeit beim Testen feststellen, z. B. XSS- oder SQLi-Probleme. Solche Probleme haben im Allgemeinen einige statische Analyseregeln, die als Fehlersucher fungieren und eine frühzeitige Erkennung dieser Probleme ermöglichen, bevor sie zum Testen gelangen. Noch wichtiger ist, dass es auch Regeln gibt, in diesem Fall zur Eingabevalidierung, mit denen Sie sicherstellen können, dass SQLi einfach nicht wie oben erwähnt ausgeführt werden kann.

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 gefunden und aktiviert haben, die Sie beim Testen gefunden haben, möchten Sie 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 aktiviert haben, die sich auf diese Standards beziehen, leisten Sie gute Arbeit für GDPR. Wenn Sie bereits PCI-DSS-kompatibel sind, werden Sie feststellen, dass zumindest dieser Teil der DSGVO relativ einfach vorzubereiten sein sollte.

Wenn Sie bereits andere Sicherheitsanforderungen wie CWE oder CERT haben, können Sie sicherstellen, dass Sie diese auch befolgen, und Ihre Konfiguration nach Bedarf erweitern, um den spezifischen Datenschutz der DSGVO abzudecken, indem Sie Elemente in diesen Standards finden, die sich auf Datenschutz und Daten beziehen Schutz und Verschlüsselung.

Was kann Parasoft noch für Sie tun?

Parasoft kann Ihnen dabei helfen, Ihren Code auf verschiedene Weise sicher und privat zu machen. 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 geeignet sind, und diese dann automatisch erzwingen.

Wenn Sie Parasoft DTP in die statische Analyse integrieren, verfügen Sie außerdem über die vollständige Überwachungsfunktion und automatisieren den Prozess der Dokumentation, welche Regeln für welchen Code wann ausgeführt wurden. Sie können anhand der von Ihnen ausgewählten Regeln nachweisen, dass Sie Tests durchführen oder sogar sicher sind.

Parasoft DTP verfügt auch über einige ganz besondere Berichte. Wenn Sie sich dafür entscheiden, Ihre Sicherheitsanstrengungen auf CWE zu stützen, bietet Ihnen das Parasoft CWE-Dashboard hervorragende SAST-Berichte, z. B. Probleme nach Schweregrad, Standort, Typ, Verlauf usw. Wir haben einen erstellt Schritt weiter und implementierte die technischen Auswirkungsdaten in CWE. Technical Impact (TI) ist eine Forschung, die bei Mitre im Rahmen des Common Weakness Risk Analysis Framework (CWRAF) durchgeführt wurde und Ihnen hilft, SAST-Ergebnisse anhand des Problems zu klassifizieren, das sie verursachen können. Anstelle einer Meldung, die besagt, dass Sie einen Pufferüberlauf haben, den einige möglicherweise nicht als Sicherheitsproblem erkennen, weist TI Sie darauf hin, dass ein Pufferüberlauf zu einem Denial-of-Service führen kann.

Jeder CWE-Befund zeigt Ihnen, welche Arten von Problemen auftreten können, und es gibt spezielle Diagramme, mit denen Sie Ihre statischen Analyseprobleme anhand der für Sie wichtigsten Problembereiche und nicht nur anhand des Schweregrads steuern können. Diese bahnbrechende Technik hilft Ihnen dabei, die häufig überwältigende Anzahl von Sicherheitslücken in den Griff zu bekommen, insbesondere wenn Sie an einer Legacy-Codebasis arbeiten. Konzentrieren Sie sich zunächst auf die Themen, die Sie am meisten erschrecken.

Und während ich mich heute auf statische Analysen konzentrierte, um Security-by-Design durchzuführen, vergessen Sie natürlich nicht, dass Parasoft auch Penetrationstest-Tools, API-Tests und Service-Virtualisierung bietet, die alle ein wichtiger Bestandteil sind eine umfassende Strategie für sichere Softwareentwicklung.

Zusammenfassung

GDPR sieht beängstigend aus und kann es auch sein, aber wenn Sie die statische Analyse mit dem richtigen Tool und den richtigen Regeln richtig einrichten, können Sie Ihre Software schützen, beweisen, dass Sie das Richtige für Auditoren tun, und zeigen, dass Sie folgen die Prinzipien von Secure-by-Design und Privacy-by-Design. Dies ist etwas, was Penetrationstests allein nicht können. Der zusätzliche Vorteil besteht darin, dass Sie feststellen, dass die Annäherung an die Sicherheit aus der Sicht des „By-Design“ weitaus effektiver ist, als zu versuchen, Ihren Weg zur Sicherung von Software zwischen Qualitätssicherung und Veröffentlichung zu testen. Um tiefer zu tauchen, lesen Sie die Anleitung: Verwenden der statischen Analyse für Secure-By-Design GDPR-Datensicherheit und Datenschutz.

Neuer Call-to-Action

Von Arthur Hicken

Arthur ist seit über 25 Jahren bei Parasoft im Bereich Software-Sicherheit und Testautomatisierung tätig. Er hilft bei der Erforschung neuer Methoden und Techniken (einschließlich 5 Patente) und hilft Kunden dabei, ihre Software-Praktiken zu verbessern.

Erhalten Sie die neuesten Nachrichten und Ressourcen zum Testen von Software sofort.