Coders Conquer Security Infrastructure as Code Series - Verwendung von Komponenten aus nicht vertrauenswürdigen Quellen
Wir nähern uns dem Ende unserer Infrastructure as Code-Serie, aber es war großartig, Entwicklern wie Ihnen auf ihrer IaC-Sicherheitsreise zu helfen.
Haben Sie die Herausforderungen gespielt? Wie ist Ihr Ergebnis bis jetzt? Bevor wir loslegen, wollen wir sehen, wie viel Sie bereits über die Fallstricke bei der Verwendung von Komponenten aus nicht vertrauenswürdigen Quellen wissen:
Haben Sie noch etwas zu tun? Lesen Sie weiter:
Das Verhalten, das eine Schwachstelle hervorruft, auf das wir uns heute konzentrieren werden, ist die Verwendung von Code aus nicht vertrauenswürdigen Quellen, eine scheinbar harmlose Praxis, die große Probleme verursacht. Die Verwendung von Open-Source-Code und -Ressourcen hat viele Vorteile. Im Allgemeinen ermöglicht es Experten, ihre Ideen, ihre Arbeit und sogar fertigen Code zu Repositories wie GitHub beizusteuern, damit sie von anderen genutzt werden können, die sich darum bemühen, dass sich ein Programm oder eine App richtig verhält. Die Verwendung von fertigem Code zur Regelung von Programmfunktionen erspart es Entwicklern, das Rad jedes Mal neu erfinden zu müssen, wenn sie eine neue Anwendung erstellen müssen.
Die Verwendung von Codeschnipseln aus unzuverlässigen, ungeprüften oder sogar potenziell gefährlichen Quellen birgt jedoch ein großes Risiko. Tatsächlich ist die Verwendung von Code aus nicht vertrauenswürdigen Quellen einer der häufigsten Wege, auf dem sich größere und kleinere Sicherheitslücken in ansonsten sichere Anwendungen einschleichen. Manchmal werden diese Schwachstellen versehentlich von ihren Erstellern herbeigeführt. Es gab auch schon Fälle, in denen bösartiger Code von potenziellen Angreifern geschrieben wurde. Der Code wird dann weitergegeben, in der Hoffnung, Opfer zu umgarnen, die ihn in ihre Anwendungen einbauen.
Warum ist die Verwendung von Code aus nicht vertrauenswürdigen Quellen gefährlich?
Nehmen wir an, ein Entwickler hat es eilig und muss eine Anwendung, die er entwickelt, konfigurieren. Das kann ein kniffliger Prozess sein. Anstatt also viel Zeit damit zu verbringen, jede mögliche Konfiguration auszuarbeiten, macht er eine Google-Suche und findet jemanden, der bereits eine scheinbar perfekte Konfigurationsdatei fertiggestellt hat. Auch wenn der Entwickler nichts über die Person weiß, die den Code geschrieben hat, ist es relativ einfach, ihn zu einer neuen Anwendung hinzuzufügen. Es kann in der Docker-Umgebung mit zwei Zeilen erfolgen:
RUN cd /etc/apache2/sites-available/ && \
wget -O default-ssl.conf https://gist.githubusercontent.com/vesche/\
9d372cfa8855a6be74bcca86efadfbbf/raw/\
fbdfbe230fa256a6fb78e5e000aebded60d6a5ef/default-ssl.conf
Jetzt zieht das Docker-Image die Konfigurationsdatei eines Drittanbieters dynamisch ein. Und selbst wenn die Datei zu diesem Zeitpunkt getestet und für in Ordnung befunden wird, bedeutet die Tatsache, dass der Zeiger nun in den Code der neuen Anwendung eingebettet ist, dass eine permanente Abhängigkeit vorhanden ist. Tage, Wochen oder Monate später könnte die Datei vom ursprünglichen Autor oder einem Angreifer, der das Code-Repository kompromittiert hat, geändert werden. Plötzlich kann die freigegebene Konfigurationsdatei der Anwendung sagen, dass sie sich ganz anders verhalten soll als beabsichtigt, was möglicherweise unbefugten Benutzern Zugriff gewährt oder sogar direkt Daten stiehlt und exfiltriert.
Bessere Nutzung gemeinsamer Ressourcen
Wenn Ihre Organisation die Verwendung von Code aus externen Quellen zulässt, müssen Prozesse eingerichtet werden, um sicherzustellen, dass dies sicher geschieht. Wenn Sie fremden Code für eine mögliche Verwendung evaluieren, achten Sie darauf, dass Sie Komponenten aus offiziellen Quellen nur über sichere Links beziehen. Und selbst dann sollten Sie niemals eine Verbindung zu einer externen Quelle herstellen, um diesen Code einzuholen, da dies den Prozess Ihrer Kontrolle entzieht. Stattdessen sollte genehmigter Code in eine sichere Bibliothek eingebracht werden und nur von diesem geschützten Ort aus verwendet werden. In einer Docker-Umgebung würde der Code also wie folgt aussehen:
COPY src/config/default-ssl.conf /etc/apache2/sites-available/
Anstatt sich auf entfernte Konfigurationsdateien von Drittanbietern zu verlassen, würde dies stattdessen auf eine lokale Kopie dieser Dateien setzen. Dies verhindert, dass unerwartete oder böswillige Änderungen vorgenommen werden.
Zusätzlich zur Verwendung einer sicheren Code-Bibliothek sollte ein Patch-Management-Prozess eingerichtet werden, um Komponenten während des gesamten Software-Lebenszyklus kontinuierlich zu überwachen. Alle client- und serverseitigen Komponenten sollten außerdem mit Tools wie NVD oder CVE auf Sicherheitswarnungen überprüft werden. Schließlich sollten alle nicht genutzten oder unnötigen Abhängigkeiten und Funktionen entfernt werden, die möglicherweise mit dem externen Code einhergehen.
Wenn Sie diese Schritte befolgen, können Entwickler externe Ressourcen sicherer nutzen, ohne versehentlich Schwachstellen in ihre Anwendungen und ihren Code einzubringen.
Schauen Sie sich die Secure Code Warrior Blog-Seiten, um weitere Einblicke in diese Schwachstelle zu erhalten und zu erfahren, wie Sie Ihr Unternehmen und Ihre Kunden vor den Auswirkungen anderer Sicherheitslücken schützen können. Sie können auch eine Demo der IaC-Herausforderungen auf der Schulungsplattform Secure Code Warrior ausprobieren, um alle Ihre Cybersecurity-Fähigkeiten zu schärfen und auf dem neuesten Stand zu halten.
Das Verhalten, das eine Schwachstelle hervorruft, auf das wir uns hier konzentrieren werden, ist die Verwendung von Code aus nicht vertrauenswürdigen Quellen, eine scheinbar harmlose Praxis, die große Probleme verursacht.
Matias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Demo buchen
Matias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Matias ist ein Forscher und Entwickler mit mehr als 15 Jahren praktischer Erfahrung im Bereich der Softwaresicherheit. Er hat Lösungen für Unternehmen wie Fortify Software und sein eigenes Unternehmen Sensei Security entwickelt. Im Laufe seiner Karriere hat Matias mehrere Forschungsprojekte zur Anwendungssicherheit geleitet, die zu kommerziellen Produkten geführt haben, und kann auf über 10 Patente verweisen. Wenn er nicht am Schreibtisch sitzt, ist Matias als Ausbilder für fortgeschrittene Anwendungssicherheitstrainings courses tätig und hält regelmäßig Vorträge auf globalen Konferenzen wie RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec und BruCon.
Matias hat einen Doktortitel in Computertechnik von der Universität Gent, wo er die Sicherheit von Anwendungen durch Programmverschleierung untersuchte, um die innere Funktionsweise einer Anwendung zu verbergen.
Wir nähern uns dem Ende unserer Infrastructure as Code-Serie, aber es war großartig, Entwicklern wie Ihnen auf ihrer IaC-Sicherheitsreise zu helfen.
Haben Sie die Herausforderungen gespielt? Wie ist Ihr Ergebnis bis jetzt? Bevor wir loslegen, wollen wir sehen, wie viel Sie bereits über die Fallstricke bei der Verwendung von Komponenten aus nicht vertrauenswürdigen Quellen wissen:
Haben Sie noch etwas zu tun? Lesen Sie weiter:
Das Verhalten, das eine Schwachstelle hervorruft, auf das wir uns heute konzentrieren werden, ist die Verwendung von Code aus nicht vertrauenswürdigen Quellen, eine scheinbar harmlose Praxis, die große Probleme verursacht. Die Verwendung von Open-Source-Code und -Ressourcen hat viele Vorteile. Im Allgemeinen ermöglicht es Experten, ihre Ideen, ihre Arbeit und sogar fertigen Code zu Repositories wie GitHub beizusteuern, damit sie von anderen genutzt werden können, die sich darum bemühen, dass sich ein Programm oder eine App richtig verhält. Die Verwendung von fertigem Code zur Regelung von Programmfunktionen erspart es Entwicklern, das Rad jedes Mal neu erfinden zu müssen, wenn sie eine neue Anwendung erstellen müssen.
Die Verwendung von Codeschnipseln aus unzuverlässigen, ungeprüften oder sogar potenziell gefährlichen Quellen birgt jedoch ein großes Risiko. Tatsächlich ist die Verwendung von Code aus nicht vertrauenswürdigen Quellen einer der häufigsten Wege, auf dem sich größere und kleinere Sicherheitslücken in ansonsten sichere Anwendungen einschleichen. Manchmal werden diese Schwachstellen versehentlich von ihren Erstellern herbeigeführt. Es gab auch schon Fälle, in denen bösartiger Code von potenziellen Angreifern geschrieben wurde. Der Code wird dann weitergegeben, in der Hoffnung, Opfer zu umgarnen, die ihn in ihre Anwendungen einbauen.
Warum ist die Verwendung von Code aus nicht vertrauenswürdigen Quellen gefährlich?
Nehmen wir an, ein Entwickler hat es eilig und muss eine Anwendung, die er entwickelt, konfigurieren. Das kann ein kniffliger Prozess sein. Anstatt also viel Zeit damit zu verbringen, jede mögliche Konfiguration auszuarbeiten, macht er eine Google-Suche und findet jemanden, der bereits eine scheinbar perfekte Konfigurationsdatei fertiggestellt hat. Auch wenn der Entwickler nichts über die Person weiß, die den Code geschrieben hat, ist es relativ einfach, ihn zu einer neuen Anwendung hinzuzufügen. Es kann in der Docker-Umgebung mit zwei Zeilen erfolgen:
RUN cd /etc/apache2/sites-available/ && \
wget -O default-ssl.conf https://gist.githubusercontent.com/vesche/\
9d372cfa8855a6be74bcca86efadfbbf/raw/\
fbdfbe230fa256a6fb78e5e000aebded60d6a5ef/default-ssl.conf
Jetzt zieht das Docker-Image die Konfigurationsdatei eines Drittanbieters dynamisch ein. Und selbst wenn die Datei zu diesem Zeitpunkt getestet und für in Ordnung befunden wird, bedeutet die Tatsache, dass der Zeiger nun in den Code der neuen Anwendung eingebettet ist, dass eine permanente Abhängigkeit vorhanden ist. Tage, Wochen oder Monate später könnte die Datei vom ursprünglichen Autor oder einem Angreifer, der das Code-Repository kompromittiert hat, geändert werden. Plötzlich kann die freigegebene Konfigurationsdatei der Anwendung sagen, dass sie sich ganz anders verhalten soll als beabsichtigt, was möglicherweise unbefugten Benutzern Zugriff gewährt oder sogar direkt Daten stiehlt und exfiltriert.
Bessere Nutzung gemeinsamer Ressourcen
Wenn Ihre Organisation die Verwendung von Code aus externen Quellen zulässt, müssen Prozesse eingerichtet werden, um sicherzustellen, dass dies sicher geschieht. Wenn Sie fremden Code für eine mögliche Verwendung evaluieren, achten Sie darauf, dass Sie Komponenten aus offiziellen Quellen nur über sichere Links beziehen. Und selbst dann sollten Sie niemals eine Verbindung zu einer externen Quelle herstellen, um diesen Code einzuholen, da dies den Prozess Ihrer Kontrolle entzieht. Stattdessen sollte genehmigter Code in eine sichere Bibliothek eingebracht werden und nur von diesem geschützten Ort aus verwendet werden. In einer Docker-Umgebung würde der Code also wie folgt aussehen:
COPY src/config/default-ssl.conf /etc/apache2/sites-available/
Anstatt sich auf entfernte Konfigurationsdateien von Drittanbietern zu verlassen, würde dies stattdessen auf eine lokale Kopie dieser Dateien setzen. Dies verhindert, dass unerwartete oder böswillige Änderungen vorgenommen werden.
Zusätzlich zur Verwendung einer sicheren Code-Bibliothek sollte ein Patch-Management-Prozess eingerichtet werden, um Komponenten während des gesamten Software-Lebenszyklus kontinuierlich zu überwachen. Alle client- und serverseitigen Komponenten sollten außerdem mit Tools wie NVD oder CVE auf Sicherheitswarnungen überprüft werden. Schließlich sollten alle nicht genutzten oder unnötigen Abhängigkeiten und Funktionen entfernt werden, die möglicherweise mit dem externen Code einhergehen.
Wenn Sie diese Schritte befolgen, können Entwickler externe Ressourcen sicherer nutzen, ohne versehentlich Schwachstellen in ihre Anwendungen und ihren Code einzubringen.
Schauen Sie sich die Secure Code Warrior Blog-Seiten, um weitere Einblicke in diese Schwachstelle zu erhalten und zu erfahren, wie Sie Ihr Unternehmen und Ihre Kunden vor den Auswirkungen anderer Sicherheitslücken schützen können. Sie können auch eine Demo der IaC-Herausforderungen auf der Schulungsplattform Secure Code Warrior ausprobieren, um alle Ihre Cybersecurity-Fähigkeiten zu schärfen und auf dem neuesten Stand zu halten.
Wir nähern uns dem Ende unserer Infrastructure as Code-Serie, aber es war großartig, Entwicklern wie Ihnen auf ihrer IaC-Sicherheitsreise zu helfen.
Haben Sie die Herausforderungen gespielt? Wie ist Ihr Ergebnis bis jetzt? Bevor wir loslegen, wollen wir sehen, wie viel Sie bereits über die Fallstricke bei der Verwendung von Komponenten aus nicht vertrauenswürdigen Quellen wissen:
Haben Sie noch etwas zu tun? Lesen Sie weiter:
Das Verhalten, das eine Schwachstelle hervorruft, auf das wir uns heute konzentrieren werden, ist die Verwendung von Code aus nicht vertrauenswürdigen Quellen, eine scheinbar harmlose Praxis, die große Probleme verursacht. Die Verwendung von Open-Source-Code und -Ressourcen hat viele Vorteile. Im Allgemeinen ermöglicht es Experten, ihre Ideen, ihre Arbeit und sogar fertigen Code zu Repositories wie GitHub beizusteuern, damit sie von anderen genutzt werden können, die sich darum bemühen, dass sich ein Programm oder eine App richtig verhält. Die Verwendung von fertigem Code zur Regelung von Programmfunktionen erspart es Entwicklern, das Rad jedes Mal neu erfinden zu müssen, wenn sie eine neue Anwendung erstellen müssen.
Die Verwendung von Codeschnipseln aus unzuverlässigen, ungeprüften oder sogar potenziell gefährlichen Quellen birgt jedoch ein großes Risiko. Tatsächlich ist die Verwendung von Code aus nicht vertrauenswürdigen Quellen einer der häufigsten Wege, auf dem sich größere und kleinere Sicherheitslücken in ansonsten sichere Anwendungen einschleichen. Manchmal werden diese Schwachstellen versehentlich von ihren Erstellern herbeigeführt. Es gab auch schon Fälle, in denen bösartiger Code von potenziellen Angreifern geschrieben wurde. Der Code wird dann weitergegeben, in der Hoffnung, Opfer zu umgarnen, die ihn in ihre Anwendungen einbauen.
Warum ist die Verwendung von Code aus nicht vertrauenswürdigen Quellen gefährlich?
Nehmen wir an, ein Entwickler hat es eilig und muss eine Anwendung, die er entwickelt, konfigurieren. Das kann ein kniffliger Prozess sein. Anstatt also viel Zeit damit zu verbringen, jede mögliche Konfiguration auszuarbeiten, macht er eine Google-Suche und findet jemanden, der bereits eine scheinbar perfekte Konfigurationsdatei fertiggestellt hat. Auch wenn der Entwickler nichts über die Person weiß, die den Code geschrieben hat, ist es relativ einfach, ihn zu einer neuen Anwendung hinzuzufügen. Es kann in der Docker-Umgebung mit zwei Zeilen erfolgen:
RUN cd /etc/apache2/sites-available/ && \
wget -O default-ssl.conf https://gist.githubusercontent.com/vesche/\
9d372cfa8855a6be74bcca86efadfbbf/raw/\
fbdfbe230fa256a6fb78e5e000aebded60d6a5ef/default-ssl.conf
Jetzt zieht das Docker-Image die Konfigurationsdatei eines Drittanbieters dynamisch ein. Und selbst wenn die Datei zu diesem Zeitpunkt getestet und für in Ordnung befunden wird, bedeutet die Tatsache, dass der Zeiger nun in den Code der neuen Anwendung eingebettet ist, dass eine permanente Abhängigkeit vorhanden ist. Tage, Wochen oder Monate später könnte die Datei vom ursprünglichen Autor oder einem Angreifer, der das Code-Repository kompromittiert hat, geändert werden. Plötzlich kann die freigegebene Konfigurationsdatei der Anwendung sagen, dass sie sich ganz anders verhalten soll als beabsichtigt, was möglicherweise unbefugten Benutzern Zugriff gewährt oder sogar direkt Daten stiehlt und exfiltriert.
Bessere Nutzung gemeinsamer Ressourcen
Wenn Ihre Organisation die Verwendung von Code aus externen Quellen zulässt, müssen Prozesse eingerichtet werden, um sicherzustellen, dass dies sicher geschieht. Wenn Sie fremden Code für eine mögliche Verwendung evaluieren, achten Sie darauf, dass Sie Komponenten aus offiziellen Quellen nur über sichere Links beziehen. Und selbst dann sollten Sie niemals eine Verbindung zu einer externen Quelle herstellen, um diesen Code einzuholen, da dies den Prozess Ihrer Kontrolle entzieht. Stattdessen sollte genehmigter Code in eine sichere Bibliothek eingebracht werden und nur von diesem geschützten Ort aus verwendet werden. In einer Docker-Umgebung würde der Code also wie folgt aussehen:
COPY src/config/default-ssl.conf /etc/apache2/sites-available/
Anstatt sich auf entfernte Konfigurationsdateien von Drittanbietern zu verlassen, würde dies stattdessen auf eine lokale Kopie dieser Dateien setzen. Dies verhindert, dass unerwartete oder böswillige Änderungen vorgenommen werden.
Zusätzlich zur Verwendung einer sicheren Code-Bibliothek sollte ein Patch-Management-Prozess eingerichtet werden, um Komponenten während des gesamten Software-Lebenszyklus kontinuierlich zu überwachen. Alle client- und serverseitigen Komponenten sollten außerdem mit Tools wie NVD oder CVE auf Sicherheitswarnungen überprüft werden. Schließlich sollten alle nicht genutzten oder unnötigen Abhängigkeiten und Funktionen entfernt werden, die möglicherweise mit dem externen Code einhergehen.
Wenn Sie diese Schritte befolgen, können Entwickler externe Ressourcen sicherer nutzen, ohne versehentlich Schwachstellen in ihre Anwendungen und ihren Code einzubringen.
Schauen Sie sich die Secure Code Warrior Blog-Seiten, um weitere Einblicke in diese Schwachstelle zu erhalten und zu erfahren, wie Sie Ihr Unternehmen und Ihre Kunden vor den Auswirkungen anderer Sicherheitslücken schützen können. Sie können auch eine Demo der IaC-Herausforderungen auf der Schulungsplattform Secure Code Warrior ausprobieren, um alle Ihre Cybersecurity-Fähigkeiten zu schärfen und auf dem neuesten Stand zu halten.
Klicken Sie auf den unten stehenden Link und laden Sie die PDF-Datei dieser Ressource herunter.
Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Bericht ansehenDemo buchen
Matias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Matias ist ein Forscher und Entwickler mit mehr als 15 Jahren praktischer Erfahrung im Bereich der Softwaresicherheit. Er hat Lösungen für Unternehmen wie Fortify Software und sein eigenes Unternehmen Sensei Security entwickelt. Im Laufe seiner Karriere hat Matias mehrere Forschungsprojekte zur Anwendungssicherheit geleitet, die zu kommerziellen Produkten geführt haben, und kann auf über 10 Patente verweisen. Wenn er nicht am Schreibtisch sitzt, ist Matias als Ausbilder für fortgeschrittene Anwendungssicherheitstrainings courses tätig und hält regelmäßig Vorträge auf globalen Konferenzen wie RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec und BruCon.
Matias hat einen Doktortitel in Computertechnik von der Universität Gent, wo er die Sicherheit von Anwendungen durch Programmverschleierung untersuchte, um die innere Funktionsweise einer Anwendung zu verbergen.
Wir nähern uns dem Ende unserer Infrastructure as Code-Serie, aber es war großartig, Entwicklern wie Ihnen auf ihrer IaC-Sicherheitsreise zu helfen.
Haben Sie die Herausforderungen gespielt? Wie ist Ihr Ergebnis bis jetzt? Bevor wir loslegen, wollen wir sehen, wie viel Sie bereits über die Fallstricke bei der Verwendung von Komponenten aus nicht vertrauenswürdigen Quellen wissen:
Haben Sie noch etwas zu tun? Lesen Sie weiter:
Das Verhalten, das eine Schwachstelle hervorruft, auf das wir uns heute konzentrieren werden, ist die Verwendung von Code aus nicht vertrauenswürdigen Quellen, eine scheinbar harmlose Praxis, die große Probleme verursacht. Die Verwendung von Open-Source-Code und -Ressourcen hat viele Vorteile. Im Allgemeinen ermöglicht es Experten, ihre Ideen, ihre Arbeit und sogar fertigen Code zu Repositories wie GitHub beizusteuern, damit sie von anderen genutzt werden können, die sich darum bemühen, dass sich ein Programm oder eine App richtig verhält. Die Verwendung von fertigem Code zur Regelung von Programmfunktionen erspart es Entwicklern, das Rad jedes Mal neu erfinden zu müssen, wenn sie eine neue Anwendung erstellen müssen.
Die Verwendung von Codeschnipseln aus unzuverlässigen, ungeprüften oder sogar potenziell gefährlichen Quellen birgt jedoch ein großes Risiko. Tatsächlich ist die Verwendung von Code aus nicht vertrauenswürdigen Quellen einer der häufigsten Wege, auf dem sich größere und kleinere Sicherheitslücken in ansonsten sichere Anwendungen einschleichen. Manchmal werden diese Schwachstellen versehentlich von ihren Erstellern herbeigeführt. Es gab auch schon Fälle, in denen bösartiger Code von potenziellen Angreifern geschrieben wurde. Der Code wird dann weitergegeben, in der Hoffnung, Opfer zu umgarnen, die ihn in ihre Anwendungen einbauen.
Warum ist die Verwendung von Code aus nicht vertrauenswürdigen Quellen gefährlich?
Nehmen wir an, ein Entwickler hat es eilig und muss eine Anwendung, die er entwickelt, konfigurieren. Das kann ein kniffliger Prozess sein. Anstatt also viel Zeit damit zu verbringen, jede mögliche Konfiguration auszuarbeiten, macht er eine Google-Suche und findet jemanden, der bereits eine scheinbar perfekte Konfigurationsdatei fertiggestellt hat. Auch wenn der Entwickler nichts über die Person weiß, die den Code geschrieben hat, ist es relativ einfach, ihn zu einer neuen Anwendung hinzuzufügen. Es kann in der Docker-Umgebung mit zwei Zeilen erfolgen:
RUN cd /etc/apache2/sites-available/ && \
wget -O default-ssl.conf https://gist.githubusercontent.com/vesche/\
9d372cfa8855a6be74bcca86efadfbbf/raw/\
fbdfbe230fa256a6fb78e5e000aebded60d6a5ef/default-ssl.conf
Jetzt zieht das Docker-Image die Konfigurationsdatei eines Drittanbieters dynamisch ein. Und selbst wenn die Datei zu diesem Zeitpunkt getestet und für in Ordnung befunden wird, bedeutet die Tatsache, dass der Zeiger nun in den Code der neuen Anwendung eingebettet ist, dass eine permanente Abhängigkeit vorhanden ist. Tage, Wochen oder Monate später könnte die Datei vom ursprünglichen Autor oder einem Angreifer, der das Code-Repository kompromittiert hat, geändert werden. Plötzlich kann die freigegebene Konfigurationsdatei der Anwendung sagen, dass sie sich ganz anders verhalten soll als beabsichtigt, was möglicherweise unbefugten Benutzern Zugriff gewährt oder sogar direkt Daten stiehlt und exfiltriert.
Bessere Nutzung gemeinsamer Ressourcen
Wenn Ihre Organisation die Verwendung von Code aus externen Quellen zulässt, müssen Prozesse eingerichtet werden, um sicherzustellen, dass dies sicher geschieht. Wenn Sie fremden Code für eine mögliche Verwendung evaluieren, achten Sie darauf, dass Sie Komponenten aus offiziellen Quellen nur über sichere Links beziehen. Und selbst dann sollten Sie niemals eine Verbindung zu einer externen Quelle herstellen, um diesen Code einzuholen, da dies den Prozess Ihrer Kontrolle entzieht. Stattdessen sollte genehmigter Code in eine sichere Bibliothek eingebracht werden und nur von diesem geschützten Ort aus verwendet werden. In einer Docker-Umgebung würde der Code also wie folgt aussehen:
COPY src/config/default-ssl.conf /etc/apache2/sites-available/
Anstatt sich auf entfernte Konfigurationsdateien von Drittanbietern zu verlassen, würde dies stattdessen auf eine lokale Kopie dieser Dateien setzen. Dies verhindert, dass unerwartete oder böswillige Änderungen vorgenommen werden.
Zusätzlich zur Verwendung einer sicheren Code-Bibliothek sollte ein Patch-Management-Prozess eingerichtet werden, um Komponenten während des gesamten Software-Lebenszyklus kontinuierlich zu überwachen. Alle client- und serverseitigen Komponenten sollten außerdem mit Tools wie NVD oder CVE auf Sicherheitswarnungen überprüft werden. Schließlich sollten alle nicht genutzten oder unnötigen Abhängigkeiten und Funktionen entfernt werden, die möglicherweise mit dem externen Code einhergehen.
Wenn Sie diese Schritte befolgen, können Entwickler externe Ressourcen sicherer nutzen, ohne versehentlich Schwachstellen in ihre Anwendungen und ihren Code einzubringen.
Schauen Sie sich die Secure Code Warrior Blog-Seiten, um weitere Einblicke in diese Schwachstelle zu erhalten und zu erfahren, wie Sie Ihr Unternehmen und Ihre Kunden vor den Auswirkungen anderer Sicherheitslücken schützen können. Sie können auch eine Demo der IaC-Herausforderungen auf der Schulungsplattform Secure Code Warrior ausprobieren, um alle Ihre Cybersecurity-Fähigkeiten zu schärfen und auf dem neuesten Stand zu halten.
Inhaltsübersicht
Matias Madou, Ph.D., ist Sicherheitsexperte, Forscher, CTO und Mitbegründer von Secure Code Warrior. Matias promovierte an der Universität Gent im Bereich Anwendungssicherheit und konzentrierte sich dabei auf statische Analyselösungen. Später wechselte er zu Fortify in den USA, wo er erkannte, dass es nicht ausreicht, nur Codeprobleme zu erkennen, ohne den Entwicklern beim Schreiben von sicherem Code zu helfen. Dies inspirierte ihn dazu, Produkte zu entwickeln, die Entwickler unterstützen, den Aufwand für die Sicherheit verringern und die Erwartungen der Kunden übertreffen. Wenn er nicht an seinem Schreibtisch im Team Awesome sitzt, steht er gerne auf der Bühne und hält Vorträge auf Konferenzen wie der RSA Conference, BlackHat und DefCon.
Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Demo buchenHerunterladenRessourcen für den Einstieg
Sicher durch Design: Definition von Best Practices, Befähigung von Entwicklern und Benchmarking von präventiven Sicherheitsergebnissen
In diesem Forschungspapier werden die Mitbegründer von Secure Code Warrior , Pieter Danhieux und Dr. Matias Madou, Ph.D., zusammen mit den Experten Chris Inglis, ehemaliger US National Cyber Director (jetzt strategischer Berater der Paladin Capital Group), und Devin Lynch, Senior Director, Paladin Global Institute, die wichtigsten Erkenntnisse aus mehr als zwanzig ausführlichen Interviews mit Sicherheitsverantwortlichen in Unternehmen, darunter CISOs, ein VP of Application Security und Software-Sicherheitsexperten, offenlegen.
Benchmarking von Sicherheitskompetenzen: Optimierung von Secure-by-Design im Unternehmen
Aussagekräftige Daten über den Erfolg von Secure-by-Design-Initiativen zu finden, ist bekanntermaßen schwierig. CISOs stehen oft vor der Herausforderung, den Return on Investment (ROI) und den Geschäftswert von Sicherheitsprogrammen sowohl auf Mitarbeiter- als auch auf Unternehmensebene nachzuweisen. Ganz zu schweigen davon, dass es für Unternehmen besonders schwierig ist, Erkenntnisse darüber zu gewinnen, wie ihre Organisation im Vergleich zu aktuellen Branchenstandards abschneidet. Die Nationale Cybersicherheitsstrategie des Präsidenten forderte die Beteiligten auf, "Sicherheit und Widerstandsfähigkeit durch Design" zu erreichen. Der Schlüssel zum Erfolg von Secure-by-Design-Initiativen liegt nicht nur darin, Entwicklern die nötigen Fähigkeiten zu vermitteln, um sicheren Code zu gewährleisten, sondern auch darin, den Aufsichtsbehörden zu versichern, dass diese Fähigkeiten vorhanden sind. In dieser Präsentation stellen wir eine Vielzahl von qualitativen und quantitativen Daten vor, die aus verschiedenen Primärquellen stammen, darunter interne Daten von über 250.000 Entwicklern, datengestützte Kundeneinblicke und öffentliche Studien. Auf der Grundlage dieser gesammelten Daten wollen wir eine Vision des aktuellen Stands von Secure-by-Design-Initiativen in verschiedenen Branchen vermitteln. Der Bericht zeigt auf, warum dieser Bereich derzeit nicht ausreichend genutzt wird, welche erheblichen Auswirkungen ein erfolgreiches Schulungsprogramm auf die Minderung von Cybersecurity-Risiken haben kann und welches Potenzial zur Beseitigung von Schwachstellen in einer Codebasis besteht.
Professionelle Dienstleistungen - Beschleunigen Sie mit Fachwissen
Das PSS-Team (Program Strategy Services) von Secure Code Warriorunterstützt Sie beim Aufbau, der Verbesserung und der Optimierung Ihres Programms für sichere Codierung. Ganz gleich, ob Sie neu anfangen oder Ihren Ansatz verfeinern möchten, unsere Experten bieten Ihnen maßgeschneiderte Beratung.
Themen und Inhalte der Schulung zu sicherem Code
Unsere branchenführenden Inhalte werden ständig weiterentwickelt, um sie an die sich ständig verändernde Softwareentwicklungslandschaft anzupassen und Ihre Rolle zu berücksichtigen. Die Themen reichen von KI bis XQuery Injection und werden für eine Vielzahl von Rollen angeboten, von Architekten und Ingenieuren bis hin zu Produktmanagern und QA. Verschaffen Sie sich einen kleinen Überblick über die Inhalte, die unser Katalog nach Thema und Rolle bietet.
Ressourcen für den Einstieg
Aufgedeckt: Wie die Cyber-Industrie "Secure by Design" definiert
In unserem neuesten Whitepaper haben sich unsere Mitbegründer Pieter Danhieux und Dr. Matias Madou, Ph.D., mit über zwanzig Sicherheitsverantwortlichen in Unternehmen, darunter CISOs, AppSec-Leiter und Sicherheitsexperten, zusammengesetzt, um die wichtigsten Teile dieses Puzzles herauszufinden und die Realität hinter der Secure by Design-Bewegung aufzudecken. Die Sicherheitsteams haben ein gemeinsames Ziel, aber kein gemeinsames Regelwerk.
Wird Vibe Coding Ihre Codebasis in eine Verbindungsparty verwandeln?
Vibe Coding ist wie eine College-Verbindungsparty, und AI ist das Herzstück aller Festivitäten, das Fass. Es macht eine Menge Spaß, sich auszutoben, kreativ zu werden und zu sehen, wohin die eigene Fantasie einen führen kann, aber nach ein paar Bierfässern ist das Trinken (oder die Verwendung von KI) in Maßen zweifellos die sicherere langfristige Lösung.
Entwicklergesteuerte Kodierung.
Sicher ist sicher.
Setzen Sie sich noch heute mit uns in Verbindung und machen Sie Softwaresicherheit zu einem festen Bestandteil Ihres Entwicklungsprozesses.
