dark

Cybersecurity – Was ist SAST, DAST, IAST und RASP? – ein kleines Intro

In diesem Beitrag werden wir uns die Unterschiede der verschiedenen Abwehrtechniken im Bereich der Cybersecurity ansehen. Hier kann man vier Hauptgruppen identifizieren, die wir eine nach der anderen kurz durchgehen werden um die Vor- und Nach-teile darzustellen.
Wer das Video zu diesem Blogpost
auf Youtube sehen möchte:

SAST – Static Application Security Testing

SAST bezeichnet den Vorgang bei dem die Komponenten von einer Anwendung einer statischen Analyse unterzogen werden. Hierbei werden nicht nur Sicherheitslücken gesucht, sondern auch die Lizenzen der einzelnen Elemente bestimmt. Im nachfolgenden werde ich mich in diesem Beitrag allerdings ausschließlich um die Betrachtung der Vulnerabilities kümmern.
Der Begriff statisch kommt daher, das für diese Auswertung ausschließlich der statische Kontext verwendet wird. Alle dynamischen oder kontext-bezogenen Auswertungen sind in diesem Verfahren nicht möglich. Mittels SAST kann man den gesamten Tech-Stack einer Anwendung analysieren, wenn der Zugriff auf diese Komponenten möglich ist, was auch einer der Vorteile von SAST im Vergleich zu den anderen Analyseverfahren ist. Einzige Ausnahme ist das IAST Verfahren, auf das wir später noch zurückkommen werden.
Was genau passiert nun bei dem SAST – Verfahren? Es gibt SAST in zwei Ausprägungen. Die erste die ich nennen möchte, bezieht sich auf die Überprüfung der eigenen Quelltexte. Hier wird versucht herauszufinden, ob nun Muster vorhanden sind die eine spätere Verwundbarkeit erleichtern oder gar erst möglich machen. Es wird nach Aufrufen von kritischen Bibliotheken gesucht oder unsichere Handhabung von Ressourcen identifiziert. Allerdings muss man ehrlicherweise an dieser Stelle zugeben, dass erstens der eigene Quelltext in den allermeisten Projekten der mit Abstand kleinste Anteil der Gesamtanwendung sein wird. Und zweitens die Analyseverfahren in diesem Bereich sich ein einem noch recht frühen Entwicklungsstadium befinden.
Bei dem Einsatz von SAST macht es wesentlich mehr Sinn, sich zuerst alle anderen Komponenten vorzunehmen. Gemeint sind hier alle Binärdateien des gesamten Anwendungsumfeldes. Dazu zählen auch alle Komponenten die bei der Entwicklung ein Rolle spielen, wie zum Beispiel der CI-Server aber auch die anderen eingesetzten Werkzeuge.

DAST – Dynamic Application Security Testing

Bei dem Analyseverfahren DAST, wird im Vergleich zu dem SAST Verfahren genau das Gegenteil gemacht. Hier wird die Anwendung wie eine BlackBox betrachtet. Sobald eine läuffähige Version der Anwendung zur Verfügung steht wird die mittels automatisch ausgeführter Cyberangriffe attackiert. Die zur Verfügung stehenden Angriffsmuster sind in den meisten Fällen an die Most Common Vulnerabilities, definiert durch die OSWAP, angelehnt. Die Definition eigener Angriffsvektoren ist in dem mir bekannten Werkzeugen entweder nicht vorgesehen oder erfordern ein sehr detailliertes Wissen in diesem Bereich. Für Entwickler die diese Werkzeuge nicht täglich und sehr intensive anwenden ist damit der Einsatz auf die vordefinierten Angriffsvektoren beschränkt. Gut bei diesem Verfahren ist es, das auch noch unbekannte Sicherheitslücken identifiziert werden können, solange diese auf den Most Common Vulnerabilities basieren. Einige Hersteller erweitern diesen Ansatz durch KI oder ML Techniken. Dieser Ansatz mittels der Techniken AI und ML ist noch in einem sehr frühen Entwicklungsstadium und das aktuell verfügbare Potential ist nicht abzusehen.
Leider kann man das Verfahren nur sinnvoll gegen die Produktionsumgebung einsetzen, da nur so alle Lücken basierend auf Konfigurationsmängel erkannt werden können. Der Einsatz innerhalb der CI Strecke macht im Gegenzug zum SAST Verfahren keinen Sinn.

IAST – Interactive Application Security Testing

IAST verwendet Softwareinstrumente, um die Leistung einer Anwendung zu bewerten und Schwachstellen zu erkennen. IAST hat einen “agentenähnlichen” Ansatz, d. h. Agenten und Sensoren werden ausgeführt, um die Anwendungsfunktionen während automatisierter Tests, manueller Tests oder einer Mischung aus beidem kontinuierlich zu analysieren.
Der Prozess und das Feedback erfolgen in Echtzeit in der IDE, Continuous Integration (CI)-Umgebung oder Qualitätssicherung oder während des Produktionsbetriebs. Die Sensoren haben Zugriff auf:
  • Gesamten Quelltext
  • Daten- und Kontrollfluss
  • Systemkonfigurationsdaten
  • Webkomponenten
  • Backend-Verbindungsdaten
Der Hauptunterschied zwischen IAST, SAST und DAST besteht darin, dass es innerhalb der Anwendung ausgeführt wird.
Durch den Zugriff auf alle statischen Komponenten als auch auf die Laufzeitinformationen ermöglichen ein sehr umfassendes Bild.
Es handelt sich um eine Kombination aus statischer und dynamischer Analyse. Der Anteil der dynamischen Analyse ist aber dennoch kein reiner Blackboxtest, wie er bei DAST implementiert ist.
Einige Gründe die für die Anwendung von IAST sprechen:
Potenzielle Probleme werden früher erkannt, sodass IAST die Kosten zur Beseitigung potentieller Kosten und Verzögerungen minimiert.
Dies ist auf die Anwendung eines Shift-Left-Ansatzes zurückzuführen, dh er wird in den frühen Phasen des Projektlebenszyklus durchgeführt.
Ähnlich wie bei SAST liefert die IAST-Analyse gründliche datenhaltige Codezeilen, sodass Sicherheitsteams sofort auf einen bestimmten Fehler achten können.
Mit der Fülle an Informationen, auf die das Tool Zugriff hat, kann die Quelle von Schwachstellen genau identifizieren werden.
Im Gegensatz zu anderen dynamischen Softwaretests kann IAST problemlos in CI/CD-Pipelines (Continuous Integration and Deployment) integriert werden.
Die Auswertungen finden in Echtzeit auf der Produktionsumgebung statt.
Andererseits:
IAST-Tools können den Betrieb der Anwendung verlangsamen.
Das basiert auf der Tatsache, das die Agenten selbst den Bytecode verändern. Das führt zu einer geringeren performance des Gesamtsystems.
Ebenfalls kann natürlich die Veränderung selbst zu Problemen in der Produktionsumgebung führen.
Der Einsatz der Agenten stellt natürlich auch eine potentielle Gefahrenquelle dar, da diese Agenten ja ebenfalls kompromittiert sein können.
— Siehe Solarwinds Hack

RASP – Runtime Application Self Protection

Bei RASP handelt es sich um den Ansatz die Anwendung von innen heraus zu sichern.
Die Sicherung erfolgt zur Laufzeit und besteht im Allgemeinen darin, das nach verdächtigen Kommandos bei der Ausführung gesucht wird.
Was bedeutet das nun?
Bei dem Ansatz mittels RASP kann man den gesamten Kontext der Applikation untersuchen, und das auf der Produktionsmaschine und in Echtzeit.
Hier werden alle Befehle die verarbeitet werden auf mögliche Angriffsmuster hin untersucht.
Dieses Verfahren zielt also nicht nur darauf ab bestehende Sicherheitslücken und Angriffsmuster zu erkennen, sondern eben auch die noch nicht bekannten.
Hier geht es ganz klar in die Verwendung von AI und ML Techniken.
RASP Werkzeuge kann man meist in zwei Betriebsarten einsetzen.
Die erste Betriebsart (monitoring) ist beschränkt auf das Beobachten und Melden von möglichen Angriffen.
Die zweite Betriebsart (protection) beinhaltet dann noch die Durchführung von Abwehrmaßnahmen in Echtzeit und direkt auf der Produktionsumgebung.
RASP zielt darauf ab, die Lücke zu schließen, die durch Anwendungssicherheitstests und Netzwerk-Perimeter-Kontrollen hinterlassen wird.
Die beiden Ansätze (SAST und DAST) haben keinen ausreichenden Einblick in Echtzeitdaten- und Ereignisflüsse, um entweder das Durchrutschen von Schwachstellen durch den Überprüfungsprozess zu verhindern oder neue Bedrohungen zu blockieren, die während der Entwicklung übersehen wurden.
RASP ist dem Interactive Application Security Testing (IAST) ähnlich, der Hauptunterschied besteht darin, dass sich IAST auf die Identifizierung von Schwachstellen in den Anwendungen konzentriert und RASPs sich auf den Schutz vor Cybersecurity-Angriffen konzentrieren, die diese Schwachstellen oder andere Angriffsvektoren ausnutzen können.
Die RASP-Technologie besitzt folgende Vorteile:
  • RASP ergänzt SAST und DAST durch eine zusätzliche Schutzschicht, nachdem die Anwendung in Gang gesetzt wurde (normalerweise in der Produktion).
  • Es kann mit schnelleren Entwicklungszyklen einfach angewendet werden.
  • Unerwartete Eingaben werden geprüft und kontrolliert.
  • Es ermöglicht Ihnen, schnell auf einen Angriff zu reagieren, indem es umfassende Analysen und Informationen über die möglichen Schwachstellen bereitstellt.
RASP-Tools haben jedoch bestimmte Nachteile:
  • Durch das Sitzen auf dem Anwendungsserver können sich RASP-Tools negativ auf die Anwendungsleistung auswirken.
  • Die Technologie (RASP) ist möglicherweise nicht mit Vorschriften oder internen Richtlinien kompatibel,
    • die die Installation anderer Software erlaubt oder
    • das automatische Sperren von Diensten gestattet.
  • Der Einsatz dieser Technologie kann auch dazu führen das sich die beteiligten Personen in falscher Sicherheit glauben.
  • Die Anwendung muss ebenfalls bis zur Behebung der Schwachstelle offline geschaltet werden.
RASP ist kein Ersatz für Anwendungssicherheitstests, da es keinen umfassenden Schutz bieten kann.
Während RASP und IAST ähnliche Methoden und Verwendungen haben, führt RASP keine umfassenden Scans durch, sondern wird stattdessen als Teil der Anwendung ausgeführt, um den Datenverkehr und die Aktivität zu untersuchen. Beide berichten über Angriffe, sobald sie auftreten, bei IAST geschieht dies zum Zeitpunkt des Tests, während es bei RASP zur Laufzeit in Produktion erfolgt.

Conclusion

Alle Ansätze ergeben ein breites Spektrum von Möglichkeiten sich gegen bekannte und unbekannte Sicherheitslücken zu wappnen. Hier ist es wichtig die eigenen Bedürfnisse und die des Unternehmens für die Ausrichtung in der Zukunft in Einklang zu bringen.
Conclusion RASP:
Wir haben gesehen das mit RASP ein Ansatz existiert bei dem die Anwendung zur Laufzeit in der Lage ist, sich gegen Angriffe selbständig zu schützen. Die permanente Überwachung der eigenen Aktivitäten und der Daten die der Anwendung übergeben werden, ermöglichen eine Analyse auf Basis der Laufzeitumgebung. Hier kann man zwischen dem reinen Monitoring bzw. Alerting und dem aktiven Selbstschutz entscheiden. Allerdings werden bei RASP Ansätzen der Laufzeitumgebung Softwarekomponenten hinzugefügt die in der Lage sind das System selbständig zu manipulieren. Das hat Auswirkungen auf die Performance. RASP konzentriert sich mit diesem Ansatz auf die Erkennung und Abwehr von aktuelle stattfindenden Cyberangriffen. Es analysiert also die Daten und das Benutzerverhalten um auffällige Aktivitäten zu identifizieren.
Conclusion IAST:
Der IAST Ansatz kombiniert den SAST und DAST Ansatz und wird schon innerhalb des SDLC also innerhalb der Entwicklung selbst angewendet. Damit sind die IAST Werkzeuge schon weiter “links” im Vergleich zu den RASP Werkzeugen. Ebenfalls ist der Unterschied zu den RASP Werkzeugen derart, das IAST aus statischen, dynamischen und manuellen Tests besteht. Hier wird auch deutlich, dass IAST eher in der Entwicklungsphase anzusiedeln ist. Die Kombination der dynamischen, statischen und manuellen Tests verspricht eine umfassende Sicherheitslösung. Allerdings darf man an der Stelle nicht die Komplexität der manuellen und dynamischen Sicherheitstests unterschätzen.
Conclusion DAST:
Mittels dem DAST-Ansatz konzentriert man sich auf die Sichtweise wie ein Hacker an das System herangehen würde. Das Gesamtsystem wird wie eine Black-box verstanden und die Angriffe erfolgen ohne Kenntnisse der eingesetzten Technologien. Hier geht es darum, das Produktionssystem gegen die Most Common Vulnerabilities zu härten. Jedoch darf man an dieser Stelle nicht vergesse, das diese Technik erst am Ende der Produktionszyklen eingesetzt werden kann.
Conclusion SAST:
Wenn man Zugriff auf alle Systemkomponenten hat, kann man mit dem SAST – Ansatz sehr effektiv gegen bekannte Sicherheitslücken und Lizenz-Probleme vorgehen. Dieses Verfahren garantiert einem als einziges, dass der vollständige Techstack einer direkten Kontrolle unterzogen werden kann. Hier liegt der Schwerpunkt auf der statischen Semantik und ist im Gegenzug vollständig blind für Sicherheitslücken die sich in dem dynamischen Kontext befinden. Ein sehr großer Vorteil ist es, das dieser Ansatz schon bei der ersten Zeile Quelltext eingesetzt werden kann.

Meine persönliche Meinung:

Meine persönliche Meinung zu diesen verschiedenen Ansätzen ist die nachfolgende:
Wenn man mit dem Bereich DevSecOps oder auch Security in der IT allgemein beginnt, so macht der SAST Ansatz den meisten Sinn. Hier kann mit recht wenig Aufwand das größte Bedrohungspotential eliminiert werden. Ebenfalls ist es ein Verfahren das in allen Schritten der Produktionslinie eingesetzt werden kann. Erst wenn alle im System enthaltenen Komponenten gegen bekannte Sicherheitslücken abgesichert sind ergeben die nachfolgenden Methoden ihr höchstes Potential. Ich persönlich würde nach der Einführung von SAST den IAST Ansatz einbringen und als letztes den RASP-Ansatz. Hiermit ist auch gewährleistet, dass die jeweiligen Teams mit der Aufgabe mitwachsen können und es in der Produktion zu keinen Hindernissen oder Verzögerungen kommen muss.
Cheers Sven
Total
0
Shares
Previous Post

Bewährte Praktiken für APIs

Related Posts

PCI DSS-Sicherheitsauditverfahren – alles, was Sie wissen müssen

Die Einhaltung des Datensicherheitsstandards (DSS) der Zahlungskartenbranche (PCI, engl.: Payment Card Industry) erfordert eine jährliche Berichterstattung. Diese jährliche Berichterstattung umfasst umfangreiche PCI-DSS-Auditverfahren für Organisationen, die die höchsten Transaktionsvolumina abwickeln. Die Auditverfahren werden im Rahmen einer Vor-Ort-Bewertung durchgeführt, die als Konformitätsbericht (ROC, engl.: Report on Compliance) bezeichnet wird.
weiterlesen