Application Security & Secure Development
Threat Modeling
Jede eigene Entwicklung sowie Outsourcing von Projekten beginnt mit Sicherheitsanforderungen.Wir unterstützen Sie bei der Definition von angemessenen und individuellen Sicherheitsanforderungen für Ihre Applikationen. Dies kann sowohl bei der inhouse-Entwicklung als auch bei einer extern ausgelagerten Entwicklung relevant sein und gehört in jede Lasten- und Pflichtenheft sowie in die vertragliche Ausgestaltung.
Threat Modeling nach STRIDE ist eine Methode zur Bedrohungsanalyse zur Identifizierung von Risiken und Angriffsvektoren. Hier wird zunächst die Applikationslandschaft inklusive der darunterliegenden ITInfrastruktur modelliert mit den Elementtypen Prozess, Datenspeicher, Datenfluss, externe Entität, Trust Boundary. Dieses kann sowohl technisch und auf mehreren hierarchischen Ebenen geschehen oder Use-case-/Mis-use-case-orientiert Anschließend werden auf das gesamte Datenflussdiagramm die Threats nach STRIDE gemappt und im technologischem Kontext spezifiziert sowie Subbedrohungen erzeugt (z.B. Threat Spoofing (das erste S von STRIDE) mittels des Angriffs Passwort-Bruteforcing beim Login).
Ziel von Threat Modeling ist es Mitigationsmaßnahmen zu definieren und damit die Architektur mit Sicherheitsmaßnahmen anzureichern. In diesem Beispiel Einsatz von CAPTCHAs und Throttling beim Login. Threat Modeling ist in der Gesamtheit also eine hervorragende Methode, um systematisch und vollständig alle Risiken eine Applikationsarchitektur und IT-Landschaft zu identifizieren und abzusichern. Ohne Threat Modeling ist es für einen Security-Architekten fast unmöglich ALLE Risiken zu erkennen und Maßnahmen zu ergreifen, hier wird dann nur auf die vergangene Erfahrung zurückgegriffen und Maßnahmen nur unvollständig platziert.
STRIDE-Kategorisierung von Threats
- Spoofing: Der Angreifer spooft einen User / ein System / einen Prozess etc., gibt sich also als eine andere Entität aus. Mitigierungsmaßnahmen der Kategorie Authentifizierung.
- Tampering: Der Angreifer manipuliert einen Datenfluss, Daten, Prozess etc. Mitigierungsmaßnahmen der Kategorie Verschlüsselung / Integritätsprüfung / Eingabevalidierung
- Repudiation: Der Angreifer führt seine Aktionen unbemerkt durch. Maßnahmen der Kategorie Logging, Monitoring, Intrusion Detection
- Information Disclosure: Der Angreifer gelangt unerlaubt an sensitive Informationen. Umfangreiche Maßnahmen notwendig, wie z.B. sicheres Error-Handling, Verschlüsselung, Härtung
- Denial-of-Service: Der Angreifer legt das System lahm. Umfangreiche Maßnahmen notwendig, wie z.B. Härtung, DDoS-Protection-Mechanismen, sichere Programmierung
- Elevation-of-Privilege: Der Angreifer erlangt mehr Rechte als ihm eigentlich zusteht. Maßnahmen der Kategorie Autorisierung gemäß Least-Privilege-Principle
Einsatzmöglichkeiten
- Risikoanalyse nach ISO 27001 / ISO 27034
- Analyse einer (Cloud-basierten) Anwendungsarchitektur
- Erfassung von Angriffsvektoren und Unterstützung bei Festlegung des Scopes bei einem Penetrationstest
- Cloud Migrationsprojekte
Secure Source Code Review
Im Rahmen Security Code-Review werden ein automatisierter und ein manueller Security Source Code Review auf sicherheitsrelevante Bereiche zum Identifizieren von Sicherheitslücken durchgeführt.
Der automatische Test wird nicht eingeschränkt und über den gesamten Code ausgeführt. Eine manuelle Überprüfung wird sowohl auf die Findings aus den automatischen Tests durchgeführt, um False-Positives zu identifizieren und auszuschließen als auch auf sicherheitskritische Code-Stellen der Applikation.Ergebnisse hin wird durchgeführt.
- Automatisierte Code-Reviews
- Qualitätssicherung der Findings, Ausschluss von False Positives
- Manuelle Code-Reviews auf sicherheitskritischen Codestellen
Automatischer Security-Code-Review
Zunächst erfolgt das Onboarding der Software in geeignete Security-Code-Scanner. Anschließend werden die Scans gestartet, gefolgt von der Auswertung und Bereinigung der Ergebnisse. Wichtig ist eine Einlieferung des Codes in Build-fähigen Projekten, da andernfalls erhebliche Mehraufwände beim Onboarding entstehen können. Hier ist ggf. die Unterstützung eines versierten Buildmasters des Kunden erforderlich.
Die eingesetzten Scanner gelten aktuell als Standard hinsichtlich automatischer Sicherheitsprüfungen von Sourcecode. Sie liefern gute bis sehr gute Leistungen beim Auffinden von einfachen technischen Sicherheitsschwachstellen. Leider ist die dabei durchgeführte Bewertung des Schweregrades eines Findings oft nicht korrekt. Hoch bewertete Findings stellen sich bei näherer Betrachtung häufig als niedrig schweres Findings dar und umgekehrt. Die Erkennungsrate im Bereich komplexer bzw. fachlicher Sicherheitsschwachstellen (z.B. Berechtigungsvergabe beim Login) ist jedoch deutlich schlechter als bei technischen Sicherheitsschwachstellen (z.B. Verwendung anfälliger Methoden). Im Anschluss werden die automatisch ermittelten Sicherheitsschwachstellen deshalb qualitätsgesichert und um False-Positives bereinigt. Währenddessen erfolgt bereits ein manueller Review, da auch die Code-Bereiche rund um die automatischen Findings manuell betrachtet werden.
Manueller Security-Code-Review
Im Rahmen des manuellen Security-Code-Reviews werden ausgewählte sicherheitsrelevante Codebereiche manuell nach dem internationalen CWE-Standard geprüft, um typische Implementierungsfehler wie die folgenden zu identifizieren:
- Eingabevalidierung (Blacklisting/Whitelisting)
- SQL-Injection
- OS-Command Injection
- Buffer Overflow
- Cross-Site-Scripting
- Starke Authentifizierung
- Einsatz von Kryptographie
- Zugriffskontrolle
- Unrestricted Upload
- Cross-Site Request Forgery
- ErrorHandling
- Denial-of-Service
- Information Disclosure
- Open Redirect
- Path Traversal
Manueller und automatischer Dependency-Check
Im Rahmen des Dependency-Checks werden alle eingesetzten Drittanbieterkomponenten (Third-Party Libraries) auf einen Versionsstand und insbesondere auf enthaltene bzw. veröffentlichte Sicherheitslücken (CVEs) geprüft. Damit dieser Test vollständig durchgeführt werden kann, müssen alle Libraries entweder im Repository vorliegen oder entsprechende Build-Files vorhanden sein, die beim Build die eingesetzten ThirdParty-Libraries und deren Versionen heranziehen.
Da nicht alle Sicherheitslücken und Security-Fixes in öffentlichen Datenbanken für Sicherheitslücken enthalten sind, wird auch ein manueller Dependency-Check durchgeführt und im Rahmen dessen Changelogs und Commits auf Security-Fixes geprüft.
Etablierung sicherer CI/CD-Pipelines gemäß dem DevSecOps-Paradigma
Bereits vor Beginn der eigentlichen Softwareentwicklung ist es wichtig, eine sichere Architektur zu entwickeln, welche Bedrohungen und deren Schutz miteinbezieht. Während der Entwicklung sollte dann Sicherheit in den kompletten Entwicklungsprozess integriert werden, wobei Insentis auch bei der Nutzung moderner Verfahren wie DevSecOps und sicheren CI/CD-Pipelines unterstützt. Zusätzlich unterstützen wir Sie durch die Durchführung von Dependency-Checks von Drittanbietercode, damit sichergestellt ist, dass Fremdbibliotheken, die Sie einsetzen, keine Sicherheitslücken in Ihre Software bringen und führen ein Review Ihres Codes durch, um Sicherheitslücken schnell zu erkennen, bevor Sie zur Gefahr werden. Auch wenn Sie sich im Zuge einer agilen Softwareentwicklung mit Rapid Deployment für Containerlösungen interessieren, z. B. mittels Docker oder Kubernetes, bieten wir Ihnen an, Ihre Container zu scannen und helfen Ihnen bei einem späteren sicheren Deployment nach Best Practices.
- Scannen & Absichern von Containerlösungen (Kubernetes, Docker, Openshift)
- Härtung von Entwicklungs- & Deployment-Umgebungen mittels CIS Benchmarks
- Scanning & Monitoring (CVE Monitoring, Dependency & Vulnerability Scanning, Vulnerability Management)
- Security in IaC & Compliance as Code (Terraform, AWS CloudFormation)
- Applikations-Penetrationstests zur Verifizierung von Secure Coding Standards, wie OWASP ASVS, MSVS uvm.
- Etablierung eines Secure Software Development Life Cycle (SSDLC)
Secure Coding Guidelines
Wir bieten gern die Erstellung von Entwicklungsrichtlinien zur sicheren Softwareentwicklung nach Stand der Technik an. Diese erstellen wir auf Basis eines Workshops mit Ihnen (z. B. Leiter IT, ISB, Architekten, Entwickler), um Ihre eingesetzten Frameworks, Technologien und Programmiersprachen zu erfassen. Das Ergebnis sind maßgeschneiderte und umfassende Entwicklungsrichtlinien.
Grundsätzlich orientieren wir uns an internationalen Standards wie OWASP Top10, OWASP ASVS, CWE sowie Best Practices in den eingesetzten Technologien. Zusätzlich setzen wir unsere Expertise ein, um die Empfehlungen kritisch zu hinterfragen, zu ergänzen und zu orchestrieren, wobei unter anderem Redundanzen vermieden werden.
Zunächst erstellen wir generische Entwicklungsrichtlinien unter Zuhilfenahme des CWE-Standards. Auf Basis dieser generischen Entwicklungsrichtlinien leiten wir im Anschluss spezifische, die von den Frameworks, Technologien und Programmiersprachen abhängige Entwicklungsrichtlinien und Best Practices ab, wobei hier auch konfigurative Aspekte hinzukommen, die im Rahmen von DevSecOps einen sicheren Betrieb bzw. sichere Deployment als Ziel haben.
