Arten von Cybersicherheitsprüfungen erklärt

In diesem Beitrag behandeln wir drei Arten von Code-Sicherheitsprüfungen, die Unterschiede zwischen internen und externen Prüfungen und wie Sie die Sicherheit während des gesamten Software Development Lifecycle (SDLC) prüfen.

Welche Arten von Cybersicherheitsprüfungen gibt es?

Es gibt drei Arten von Cybersicherheitsprüfungen:

1. Threat Modeling

2. Schwachstellenanalysen/Penetrationstests

3. Prüfungen der Security-Compliance

Sehen wir uns die einzelnen Arten von Sicherheitsprüfungen genauer an.

1. Threat Modeling

Moderne Softwareentwicklung ist darauf ausgerichtet, drei entscheidende Ziele zu erreichen: schnellere Releases, kürzere Zyklen und eine höhere Codequalität. Hochwertiger Code muss sicher sein. Deshalb muss Cybersicherheit so in den Entwicklungszyklus integriert werden, dass Entwickler weiterhin schnell Code bereitstellen können.

Der Schlüssel zur Implementierung von Anwendungssicherheit, ohne DevOps-Workflows zu beeinträchtigen, liegt darin, Sicherheitsrisiken von Anfang an mit Threat Modeling zu bewerten. Bei diesem Verfahren werden Geschäftsanforderungen und -logik untersucht, um potenzielle Sicherheitsrisiken aufzudecken.

Threat Modeling untersucht insbesondere vier Bereiche:

• Das Design von Systemabläufen und Datenflüssen

• Die Risiken und potenziell ausnutzbaren Bereiche

• Wie Sie sich vor den einzelnen Angriffen schützen können

• Wie effektiv Threat Modeling und die Schutzmaßnahmen sind

Threat Modeling ist ein fortlaufender Prozess, der nie vollständig abgeschlossen ist. Es ist jedoch der erste Schritt, um Sicherheit fest in Ihren Entwicklungsprozess zu integrieren und Best Practices für Cybersecurity-Hygiene zu befolgen.

2. Schwachstellenanalysen/Penetrationstests

Schwachstellenanalysen beruhen auf dem Grundsatz, dass sich Schwachstellen leichter beheben lassen, wenn sie entdeckt werden, bevor sie eine Laufzeitumgebung erreichen. Mit statischer Analyse und Quellcode-Analysetools können Unternehmen bei Code-Sicherheitsprüfungen die häufigsten und riskantesten Schwachstellen aufdecken und beheben, darunter Injection-Angriffe und Schwachstellen in Komponenten von Drittanbietern. Außerdem können sie sicherstellen, dass der Code vor der Veröffentlichung Compliance- und Lizenzanforderungen erfüllt.

Penetrationstests sind eine Form des ethischen Hackings, bei der interne oder externe Tester versuchen, Schwachstellen aufzudecken, indem sie einen Cyberangriff auf eine Umgebung simulieren.

Penetrationstests gibt es in drei Varianten, je nachdem, wie viel Einblick die Tester in den Code haben: White-Box-, Black-Box- und Gray-Box-Tests.

White-Box-Tests

Bei White-Box-Tests kennt der Tester oder das Tool die interne Funktionsweise der Software und weiß, was sie leisten soll. Mit diesem Wissen können Tester den Code in kleinste funktionale Komponenten zerlegen und jede davon testen („Unit-Tests“). Tester können auch bestimmte Codeteile untersuchen, um Fehler wie Schlupflöcher in der Geschäftslogik auszuschließen. White-Box-Tests lassen sich mit Tools wie Snyk Code automatisieren und in der CI-Pipeline ausführen.

Black-Box-Tests

Bei Black-Box-Tests kennt der Tester oder das Tool die interne Funktionsweise der Software nicht. So wird simuliert, wie ein Angreifer versuchen würde, Schwachstellen in einem System auszunutzen, um es zu kompromittieren. Zu den Methoden für Black-Box-Tests gehören:

• Fuzzing: API-Services oder Web-Interfaces werden mit zufälligen oder eigens erstellten Eingaben getestet;

• Syntax-Tests: Es wird nach ungültigen Ein- oder Ausgaben gesucht, etwa falscher Syntax oder der Offenlegung sensibler Daten;

• Explorative Tests: Analysten decken verborgene Sicherheitsprobleme auf, dokumentieren sie und schlagen Korrekturen vor;

• Datenanalyse: Systemprotokolle oder Antworten werden analysiert, um verdächtiges Verhalten oder potenzielle Sicherheitsprobleme aufzudecken.

Eine der beliebtesten Methoden für Black-Box-Tests ist Dynamic Application Security Testing (DAST), das manuell oder automatisiert durchgeführt werden kann. Anders als Tools für Static Application Security Testing (SAST), die den Quellcode selbst analysieren, benötigt DAST keinen Einblick in die interne Funktionsweise der Software und kann daher extern durchgeführt werden. DAST weist weniger False Positives auf als SAST-Tools, da nur ausnutzbare Schwachstellen aufgedeckt werden. Es ist jedoch schwierig, die Bewertung der gesamten Codebasis sicherzustellen, und für DAST-Tests müssen Anwendungen bereitgestellt werden, was mit entsprechenden Kosten verbunden ist.

Gray-Box-Tests

Da sowohl White-Box- als auch Black-Box-Tests Vor- und Nachteile haben, kombinieren Tester bei Gray-Box-Tests häufig die besten Aspekte beider Methoden. Gray-Box-Tests simulieren beispielsweise, wie ein Angreifer eine Anwendung sehen würde, nutzen dabei aber auch Kenntnisse über die Anwendung, um Schwachstellen aufzudecken. Wenn ein Tester weiß, in welcher Programmiersprache eine Anwendung geschrieben ist, kann er dieses Wissen nutzen, um typische Schwachstellen dieser Sprache zu finden.

3. Prüfungen der Security-Compliance

Für Anwendungen, die sensible Daten verarbeiten, die unter HIPAA, PCI oder anderen Standards geschützt sind, können besondere Maßnahmen erforderlich sein, um die Compliance sicherzustellen. Insbesondere sollten sie regelmäßig auf neue oder bisher unentdeckte Schwachstellen getestet werden. Snyk bietet einen PCI-Compliance-Service, der Compliance-as-Code und weitere Methoden einsetzt, um die Compliance sicherzustellen und Prüfern einen Prüfpfad bereitzustellen.

Interne und externe Cybersicherheitsprüfungen

Zu den Arten von Cybersicherheitsprüfungen gehören interne und externe Prüfungen. Interne Prüfungen, etwa durch Entwickler- und Security-Teams, eignen sich besser für White-Box-Tests, da der Quellcode nur internen Teams zugänglich gemacht wird. Externe Prüfer können anschließend Black-Box-Tests aus der Perspektive eines Angreifers durchführen.

Für interne und externe Prüfer stehen zahlreiche neue Tools zur Verfügung. Interne Prüfer können fortschrittliche SAST-Tools wie Snyk Code nutzen, um Schwachstellen im Code automatisch aufzudecken. Externe Prüfer können moderne Penetrationstest-Tools sowie leistungsstarke, KI-gestützte Tools wie Sicherheitsanalysen einsetzen. Diese überwachen Protokolle und Anfragen, um ungewöhnliche Muster zu erkennen, die auf eine Schwachstelle hindeuten könnten.

Sicherheit während des gesamten SDLC prüfen

Traditionell wurde Sicherheit erst am Ende des SDLC berücksichtigt. DevSecOps-Ansätze beziehen sie dagegen von Anfang an ein. Wenn Sie die Sicherheit während des gesamten SDLC kontinuierlich prüfen, können Sie Schwachstellen aufdecken und beheben, bevor sie sich auf Produktionsumgebungen auswirken. Sehen wir uns an, wie Prüfungen die einzelnen Aspekte moderner Softwareanwendungen abdecken:

Open-Source-Prüfungen

Der Großteil des Codes in einer modernen Anwendung kann aus Open-Source-Bibliotheken bestehen, die von der Hauptanwendung verwendet werden. Auch diese Bibliotheken müssen geprüft werden, da sie Schwachstellen enthalten können, die Entwicklern unbekannt sind. Snyk bietet Open-Source-Prüfungen, mit denen Sie Schwachstellen aufdecken und Ihre Open-Source-Software verwalten können. Außerdem hilft Snyk Open Source dabei, sicherzustellen, dass die Nutzung von Open Source den geltenden Lizenzanforderungen entspricht.

Code-Sicherheitsprüfungen

Code-Reviews sind ein wichtiger Bestandteil des SDLC, da sie helfen, die Hauptursachen für mangelhafte Codequalität aufzudecken, darunter Sicherheitsprobleme. Sie unterscheiden sich etwas von Audits: Code-Reviews werden in der Regel von Entwicklern selbst durchgeführt und decken alle Aspekte der Codequalität ab. Audits hingegen konzentrieren sich gezielt auf Sicherheitsrisiken und können von Security-Teams oder externen Prüfern durchgeführt werden.

Prüfungen von Container-Images

Da moderne Entwickler Container-Konfigurationen üblicherweise zusammen mit ihrer Anwendung festlegen, müssen sie auch ihre Container-Management-Prozesse prüfen. Snyk Container unterstützt Sie bei den Sicherheitsaspekten von Containern. Dazu gehören die Auswahl eines sicheren Basis-Images, automatisierte Upgrades von Basis-Images und die kontinuierliche Überwachung auf neue Schwachstellen. So können Entwickler Container sicher nutzen, ohne umfassende Kenntnisse über Betriebssysteme zu benötigen.

Prüfungen von IaC-Templates

Im DevOps-Ansatz sind Entwickler zunehmend für die Konfiguration der Infrastruktur verantwortlich, in der ihre Container bereitgestellt werden. Aus Sicherheitssicht bedeutet das, IaC-Best-Practices umzusetzen, etwa das Prinzip der geringsten Berechtigungen zu befolgen, Netzwerkverkehr zu segmentieren und Daten bei der Übertragung und Speicherung zu verschlüsseln.

Häufig gestellte Fragen