Die Rolle von SAST für das Scannen von Anwendungen bei der Einhaltung von DISA ASD STIG

Defense Information Systems Agency (DISA), Application Security and Development (ASD) und Security Technical Implementation Guides (STIG), bekannt als DISA ASD STIG, ist ein technischer Implementierungsleitfaden zur Anwendungssicherheit und -entwicklung für die Agentur für Verteidigungsinformationssysteme. Es gibt viele STIGs zur Sicherung verschiedener Teile der DoD-Infrastruktur und -Dienste. Die ASD-Richtlinien decken jedoch die interne Anwendungsentwicklung und die Bewertung von Anwendungen Dritter ab.

Einhaltung der DISA ASD STIG-Richtlinien erreichen erfordert einen Nachweis, meist in Form einer Dokumentation, der die Prüfer zufriedenstellt. Dieser Beitrag behandelt:

• Herausforderungen im Zusammenhang mit der Einhaltung von DISA ASD STIG
• Der von Parasoft empfohlene Ansatz zur effizienten, weniger riskanten und kostengünstigen Einhaltung von Vorschriften.
• Anforderungen, die die Verwendung von Anwendungsscannern oder Anwendungscodescannern spezifizieren, mit denen Teams validieren können Statische Analysatoren.

Verständnis der DISA ASD STIG Compliance-Herausforderungen

Das DISA ASD STIG bietet eine detaillierte Reihe von Richtlinien zur Verbesserung der Sicherheit von Softwaresystemen, vor allem innerhalb der Verteidigungsministerium (DoD). Die Compliance-Behörde beurteilt, ob Systeme und Software so konfiguriert sind, dass sie die Anforderungen der Defense Information Security Agency (DISA) erfüllen. Die Nichteinhaltung der DISA STIGs kann die Bereitstellung Ihrer Software blockieren oder verzögern.

Angesichts des umfangreichen Charakters dieser Compliance-Richtlinie stehen Regierungsbehörden und Verteidigungsunternehmen häufig vor mehreren Herausforderungen, wenn sie versuchen, die DISA ASD STIG-Compliance-Anforderungen zu erfüllen. Zu diesen Herausforderungen gehören die folgenden.

• Anforderungen sind komplex. DISA ASD STIGs bestehen aus einer großen Anzahl spezifischer Sicherheitskontrollen, Konfigurationen und Empfehlungen. Diese Richtlinien decken ein breites Spektrum an Bereichen ab, beispielsweise Authentifizierung, Zugriffskontrolle, Verschlüsselung, Netzwerkeinstellungen und mehr. Die schiere Menge an Richtlinien und ihre technische Tiefe können es für Unternehmen schwierig machen, sie richtig zu verstehen, zu interpretieren und umzusetzen. Um sicherzustellen, dass jede Richtlinie in verschiedenen Systemen und Komponenten ordnungsgemäß berücksichtigt wird, ist viel Liebe zum Detail und Fachwissen in Sicherheitskonfigurationen erforderlich.
• Probleme mit Legacy-Systemen. Viele Regierungsbehörden und Verteidigungsministerien betreiben Legacy-Systeme, die seit Jahren, wenn nicht Jahrzehnten, im Einsatz sind. Diese Systeme wurden möglicherweise nicht unter Berücksichtigung moderner Sicherheitsprinzipien entwickelt und ihre Architektur ist möglicherweise nicht mit einigen STIG-Anforderungen kompatibel. Die Neukonfiguration dieser Altsysteme zur Erfüllung aktueller Sicherheitsstandards kann eine große Herausforderung darstellen. Sehr oft geht es darum, Code neu zu schreiben, Hardware zu aktualisieren oder sogar die Systeme komplett auszutauschen, was kostspielig und störend sein kann.
• Dokumentation und Berichterstattung. Die DISA ASD STIG-Konformität erfordert eine gründliche Dokumentation der Sicherheitskonfigurationen, der vorgenommenen Änderungen und der Gründe für diese Änderungen. Organisationen müssen detaillierte Aufzeichnungen führen, um ihre Einhaltung der Richtlinien nachzuweisen. Die Erstellung präziser und umfassender Berichte zu Prüfungszwecken ist unerlässlich, kann jedoch zeitaufwändig sein und zu Verwaltungsaufwand führen. Das Versäumnis, eine ordnungsgemäße Dokumentation zu führen, kann zu Schwierigkeiten bei Audits oder bei der Behebung von Sicherheitsvorfällen führen.
• Vielfältige IT-Infrastruktur. Regierungsorganisationen und DoD-Komponenten betreiben oft komplexe und vielfältige IT-Umgebungen. Sie können eine Vielzahl von Betriebssystemen, Hardware, Softwareanwendungen und Netzwerkgeräten verwenden. Für jede dieser Komponenten können unterschiedliche Sicherheitsanforderungen und -einstellungen gelten. Daher kann die Anpassung der Implementierung der STIG-Richtlinien an die spezifischen Merkmale jeder Technologie zeitaufwändig sein und möglicherweise Fachwissen und vor allem manuellen Aufwand erfordern.
• Balance zwischen Sicherheit und Interoperabilität. Zusammenarbeit und Informationsaustausch sind innerhalb von Regierungs- und Verteidigungsinstitutionen von wesentlicher Bedeutung. Oftmals müssen verschiedene Behörden oder Komponenten über vernetzte Systeme zusammenarbeiten. Die Einführung strenger Sicherheitskontrollen zur Einhaltung der Vorschriften könnte jedoch die Interoperabilität oder den Datenaustausch innerhalb dieser Behörden behindern. Die Herausforderung besteht hier also darin, das richtige Gleichgewicht zwischen der Durchsetzung von Sicherheitsmaßnahmen und der Aufrechterhaltung einer reibungslosen Kommunikation zu finden. Um das richtige Gleichgewicht zu gewährleisten, müssen möglicherweise Anpassungen an Konfigurationen oder Arbeitsabläufen vorgenommen werden, um sowohl den Sicherheits- als auch den Zusammenarbeitsanforderungen gerecht zu werden.
• Kontinuierliche Überwachung und Wartung. Compliance ist keine einmalige Aufgabe. Bei jeder Systemaktualisierung ist eine Überwachung und Wartung erforderlich, um sicherzustellen, dass die Systeme langfristig sicher bleiben. Das Erreichen der anfänglichen Einhaltung der DISA ASD STIG-Richtlinien ist nur der Ausgangspunkt. Der Großteil der Arbeit liegt in der Sicherstellung einer kontinuierlichen Compliance, was von Organisationen verlangt, Prozesse für eine kontinuierliche Überwachung und Wartung einzurichten. Hierzu kann es erforderlich sein, Systeme, Konfigurationen und Sicherheitsmaßnahmen regelmäßig zu überprüfen, um etwaige Abweichungen von den festgelegten STIG-Anforderungen festzustellen. Diese Aufgabe kann jedoch aufgrund von Faktoren wie der Weiterentwicklung der DISA ASD STIG-Richtlinien, Systemänderungen, der sich entwickelnden Bedrohungslandschaft und den Kosten für den manuellen Aufwand, der normalerweise zur Gewährleistung der Compliance erforderlich ist, entmutigend sein.

Dreistufiger Ansatz zur Einhaltung der Softwareentwicklungsrichtlinien

Um die Einhaltung zu erreichen, ist ein dreistufiger Validierungsansatz erforderlich:

• Scannen des Anwendungscodes Erkennt Schwachstellen mit statischen Analysetools, um die Behebung in der Anwendung sicherzustellen. Der ASD STIG verfügt über spezifische Richtlinien, welche Schwachstellenklassen erkannt und behoben werden müssen.
• Systemtests für Sicherheit mit Funktions- und Penetrationstest-Tools verifiziert und validiert die DISA ASD STIG-Anforderungen.
• Einhaltung vorbeugender Prozesse nach links verschieben beseitigt schlechte Codierungspraktiken, die zu Schwachstellen führen. Dieser breitere Erkennungsbereich umfasst das Scannen von Anwendungen und die Anwendung von Industrie-Codierungsstandards wie OWASP, CWE oder CERT Secure Coding. Es enthält auch Richtlinien wie die Entfernung von „Code riechtDies sind schlechte Praktiken, von denen bekannt ist, dass sie die Hauptursache für Sicherheitslücken in der Software sind.

Dieser 1-2-3-Schlag ist der Schlüssel zum Erreichen der Konformität durch Validierung und Dokumentation. Ziel ist es, den Prozess bis zur Erkennung zu reifen, um Sicherheitslücken zu vermeiden.

Was bedeutet die Einhaltung von DISA ASD STIG?

Die ASD STIG verwendet einen Schweregradkategoriecode (CAT I, CAT II, ​​CAT III), um die Richtlinien basierend auf den möglichen Auswirkungen einer Ausnutzung der Richtlinie zu organisieren und zu priorisieren.

Die Bewertung der Produkt- und Prozessdokumentation sowie die Beobachtung und Überprüfung der Funktionalität anhand der Richtlinien bestimmen die Einhaltung. Mit anderen Worten, die STIG erfordert den Nachweis eines sicheren Entwurfs und einer sicheren Implementierung durch Dokumentation, Überprüfung und Validierung aller Aspekte des Softwareentwicklungslebenszyklus. Dies umfasst die Bereitstellung und den Betrieb. Diese Richtlinien gelten während der gesamten Lebensdauer des Produkts ab Konfiguration, Bereitstellung, Wartung und Lebensdauer.

Statische Anwendungssicherheitstests

Wichtig für die Diskussion in diesem Beitrag ist die Anforderung an Anwendungscodescanner:

„… Ein automatisiertes Tool, das den Quellcode von Anwendungen auf Sicherheitslücken, bösartigen Code und Hintertüren analysiert.“ —DISA ASD STIG Übersicht, Abschnitt 4.1

In der gängigeren Terminologie handelt es sich um statische Anwendungssicherheitstests (SAST), die durch statische Code-Analyse implementiert werden. Es sollte nach Möglichkeit verwendet werden. Insbesondere in der Entwicklungsumgebung, in der Code, bei dem festgestellt wurde, dass er behoben werden muss, vor der Veröffentlichung behoben werden kann. “ Der ASD STIG enthält außerdem die folgenden Anleitungen:

„Mit einem Anwendungsscanner können Entwicklungs- oder Produktionsanwendungssysteme auf Sicherheitslücken getestet werden, die entweder auf Anwendungscodefehler oder auf Fehlkonfigurationen des Anwendungssystems zurückzuführen sind. Zu diesen Sicherheitsanfälligkeiten gehören SQL Injection, Code Injection, Cross Site Scripting (XSS), Offenlegungen von Dateien, Berechtigungen und andere Sicherheitslücken, die in Anwendungen mit Netzwerkzugriff zu finden sind. “- Übersicht über DISA ASD STIG, Abschnitt 4.2 - Anwendungsscanner

Das ASD STIG erfordert den Einsatz aktiver Schwachstellentests, zum Beispiel Pen-Testing-Tools oder DAST, um ausführbare Software zu testen. Diese Tools sind während der Entwicklung und Bereitstellung erforderlich, um Schwachstellenbewertungen zu unterstützen.

DISA ASD STIG-Validierungsmethoden

Der ASD STIG beschreibt Möglichkeiten zur Überprüfung der Einhaltung der Anforderungen, darunter:

• Anwendungscode und Anwendungsscan
• Manuelle Überprüfung
• Funktionale Sicherheitstests

Teams verwenden SAST-Toolberichte und Audits, um Anwendungen und Code-Scans zu validieren. Beim Funktionstest wird mit automatisierten Tools oder manuellen Tests überprüft, ob die Schwachstelle in der Software nicht vorhanden ist. Mit anderen Worten: Stellen Sie sich den Ansatz als „etwas tun, etwas überprüfen“ vor. Überprüfen Sie beispielsweise, ob die Aktion ordnungsgemäß funktioniert hat und ggf. protokolliert wurde. Diese Ansätze eignen sich aufgrund der Effizienz und der Audit-Trail-Tools für automatisierte Tests.

Ein pragmatischer Ansatz zur DISA ASD STIG-Konformität mit statischen Analysewerkzeugen

Die Realität der Softwareentwicklung für DoD, für die DISA ASD STIG erforderlich ist, besteht darin, dass Sie alle Anforderungen und Schwachstellen testen müssen. Es kann eine entmutigende Aufgabe sein, aber die Automatisierung ist möglich, um einige der Lasten zu heben.

Die Empfehlung von Parasoft zur Einhaltung von DISA ASD STIG besteht darin, die Automatisierung dort zu nutzen, wo sie am sinnvollsten ist, beispielsweise in CI/CD-Pipelines oder DevSecOps-Prozessen. Das Ziel besteht darin, die Compliance-Belastung zu verringern, präventive Techniken zur Vermeidung von Schwachstellen einzusetzen und letztendlich eine kontinuierliche Compliance zu erreichen.

Es ist teurer und zeitaufwändiger, Schwachstellen zu erkennen und zu beheben, wenn die Software fast fertig ist, als während der Entwicklung. Aus diesem Grund besteht der Ansatz von Parasoft darin, die Bewertung, Erkennung und Behebung von Schwachstellen früher im Lebenszyklus nach links zu verlagern.

Erfüllen der Anforderungen für das Scannen von DISA ASD STIG-Anwendungen mit statischer Analyse

Der DISA ASD STIG verwendet den Begriff „Anwendungsscannen“, der sich auf die statische Code-Analyse und verwandte Technologien wie die Analyse der Software-Zusammensetzung bezieht. Zusätzlich zu den allgemeinen Anforderungen für die Schwachstellenbewertung über die statische Code-Analyse gibt es spezielle Anforderungen, um nach bestimmten Schwachstellen zu suchen, z.

• OWASP Top 10 (V-69513)
• Überläufe (V-70277)
• Rennbedingungen (V-70185)
• Fehlerbehandlung (V-70391)

Obwohl dies wie eine kleine Reihe von Sicherheitslücken aussieht, führt dies in der Realität zu vielen verwandten Softwareschwächen. Beispielsweise werden die Top 10 von OWASP (Open Web Application Security Project) in über 50 CWEs übersetzt. Jeder kann mehrere verwandte Schwächen haben.

Obwohl dies eine Reihe von Sicherheitslücken ist, die für die Einhaltung von Vorschriften spezifisch sind, ist es ratsam, eine größere Anzahl von zu erkennenden Sicherheitslücken in Betracht zu ziehen. Darüber hinaus ist es wichtig, dass die Teams ihren Fokus über die Richtlinien im DISA ASD STIG hinaus erweitern, um vorbeugende Richtlinien aufzunehmen, wie sie in den branchenüblichen Standards für sichere Codierung enthalten sind.

Wie der Name schon sagt, handelt es sich bei den OWASP Top 10 um eine Organisation, die sich für die Verbesserung der Sicherheit von Webanwendungen einsetzt. Das OWASP Top 10-Projekt bietet eine Liste der häufigsten und schwerwiegendsten Sicherheitslücken in Webanwendungen.

Integration in SCA-Tools

Während es möglich ist, statische Analysewerkzeuge zu verwenden, um die meisten Probleme zu erkennen, sind einige nicht statisch analysierbar. Die Richtlinie zur Vermeidung von Software mit bekannten Schwachstellen bezieht sich auf die Software Composition Analysis (SCA). Parasoft unterstützt dies durch die Integration von SCA-Tools mit unserer statischen Analyse in einen einzigen Bericht, was zu einer vollständigen Top-10-Abdeckung führt.

Die statische Analyse von Parasoft bietet sofort einsatzbereite Unterstützung für OWASP Top 10 durch vorkonfigurierte Einstellungen und spezifische Web-Dashboards für C / C ++, Javac und C # /. NET. Die OWASP-Berichterstellung in Parasoft DTP bietet ein vollständig überprüfbares Compliance-Framework für Projekte. Das standardspezifische Dashboard, wie das unten für DISA ASD STIG, bietet eine einfache Möglichkeit, den Status kontinuierlich zu überwachen.

Parasoft implementierte alle wichtigen Anwendungssicherheitsstandards, wie sichere SEI CERT-Kodierung, CWE-Kodierungsrichtlinien (Common Weakness Enumeration), UL 2900, OWASP und sicherheitsspezifische Dashboards für jeden. Dies hilft Benutzern, das Risiko zu verstehen und offene Verstöße/Schwachstellen/Sicherheitsmängel zu priorisieren.

Sicherheitsorientierte Berichte

Compliance-Berichte sind auf Anfrage verfügbar. Die Compliance-Kriterien sind flexibel und spezifisch für das Projekt und die Codebasis des Teams. Entwickler können Richtlinien basierend auf Schweregrad, Risiko, Auswirkung, Alter des Codes, Wichtigkeit von Komponenten usw. erstellen. Sie können sie nutzen, um die Entwicklung einfach zu leiten und einem Prüfer die Bemühungen zu zeigen. Entwickler können Richtlinien auch an das Sicherheitsteam weitergeben, um sie mit den Ergebnissen anderer Teile der Sicherheitstests zu integrieren, z. B. des Betriebssystems, des Netzwerks usw.

Einer der entscheidenden Aspekte statischer Analysetools sind Berichts- und Analysefunktionen. Projekte erstellen eine große Datenmenge in Bezug auf Warnungen und werden Build für Build multipliziert. Das Datenmanagement ist der Schlüssel für die erfolgreiche Einführung und den Return on Investment von statischen Analysetools.

Dashboards, Berichte und Konformität, die für jeden Codierungsstandard und jede Sicherheitsrichtlinie optimiert wurden, sind von entscheidender Bedeutung. Parasoft Analytics nutzt branchenübliche Risikomodelle und mehrere Techniken der künstlichen Intelligenz (KI) und des maschinellen Lernens (ML), um die Sicherheitswarnungen zu priorisieren und Entwicklern dabei zu helfen, sich auf die kritischsten Probleme mit den größten Auswirkungen zu konzentrieren.

Sicherstellung der DISA ASD STIG-Konformität mit SAST

Der DISA ASD STIG bietet eine Reihe von Anforderungen an die Sicherung von Software für DoD-Anwendungen. Es gibt verschiedene Methoden, um die Einhaltung der im STIG festgelegten Regeln nachzuweisen. Die üblichen Methoden umfassen:

• Audits der Dokumentation
• Berichte von Tools wie statischen Analysatoren und anderen
• Manueller Aufwand zur Untersuchung von Anwendungsprotokollen, falls erforderlich

Das STIG beschreibt wichtige Bereiche für die Automatisierung wie Anwendungscode und Anwendungsscannen. Die statische Analyse hilft dabei, einige davon zu erreichen.

Ein pragmatischer Ansatz verringert die Compliance-Belastung und fördert präventive Techniken, die Schwachstellen frühzeitig im Projektlebenszyklus beseitigen. Die statische Analyse von Parasoft ermöglicht die frühzeitige Erkennung von Schwachstellen. Diese Lösung erzwingt Codestil und -qualität, um schlechte Sicherheitspraktiken so früh wie möglich zu verhindern.