Programmierer erobern die Sicherheitsinfrastruktur mit Code: Deaktivierte Sicherheitsfunktionen

Heute sind Cybersicherheitsbedrohungen allgegenwärtig und nehmen ständig zu. Je mehr Bereiche unseres Lebens digitalisiert werden, desto größer wird das Risiko für Cyberkriminelle – es gibt zu viel Code, dessen Sicherheit nicht gewährleistet werden kann, und private Daten sind zu wertvoll. Außerdem ist es fast unmöglich, nach der Bereitstellung von Programmen mit allen Aspekten der Angriffsfläche Schritt zu halten und sich dagegen zu schützen.

Es gibt einige Methoden, um einige dieser Symptome zu lindern, und eine davon ist offensichtlich, wenn kluge Organisationen das Konzept „Infrastructure as Code“ (IaC) annehmen. Natürlich gibt es wie bei jeder Entwicklung einige Sicherheitsfallen, die es zu lösen gilt. Und da Entwickler Code generieren, der für die wichtige Infrastruktur zur Bereitstellung von Anwendungen verwendet wird, ist Sicherheitsbewusstsein in jeder Phase des Prozesses von entscheidender Bedeutung.

Wie können Entwickler, die gerade erst mit der Cloud-Server-Umgebung in Berührung gekommen sind, ihre Fähigkeiten verbessern, neue Fähigkeiten erlernen und unter Berücksichtigung der Sicherheit entwickeln? Wir haben die nächste Folge der Reihe „Coders Conquer Security” erstellt, um häufige IaC-Schwachstellen zu beheben. In den nächsten Blogbeiträgen werdenwir uns auf die Schritte konzentrieren, die Sie (als Entwickler) unternehmen können, um in Ihrem Unternehmen mit der Bereitstellung einer Sicherheitsinfrastruktur in Form von Code zu beginnen.

Lasst uns beginnen.

Im alten Westen der USA gibt es eine Fabel über einen paranoiden Mann, der glaubte, Banditen würden sein Haus überfallen und ausrauben. Als Ausgleichinvestierte er in verschiedene Sicherheitsmaßnahmen, wie zum Beispiel eine extrem robuste Eingangstür, vergitterte Fenster und eine große Anzahl von Schusswaffen in Reichweite. Eines Nachts wurde er im Schlaf ausgeraubt, weil er vergessen hatte, die Seitentür abzuschließen. Die Banditen fanden lediglich die unwirksamen Sicherheitsvorkehrungen und nutzten die Situation schnell aus.

Die Deaktivierung von Sicherheitsfunktionen in der Infrastruktur funktioniert so. Selbst wenn Ihr Netzwerk über eine starke Sicherheitsinfrastruktur verfügt, nützt dies nichts, wenn Elemente deaktiviert sind.

Bevor wir uns darauf einlassen, möchte ich eine Herausforderung stellen:

Wenn Sie den obigen Link aufrufen, gelangen Sie zu unserer Gamification-Trainingsplattform, auf der Sie sofort versuchen können, Sicherheitslücken zu überwinden. (Bitte beachten Sie: Die Plattform wird in Kubernetes geöffnet, aber über das Dropdown-Menü können Sie zwischen Docker, CloudFormation, Terraform und Ansible wählen. )

Wie läuft es bei Ihnen? Wenn Sie noch etwas zu tun haben, lesen Sie bitte weiter:

Sicherheitsfunktionen können aus verschiedenen Gründen deaktiviert sein. Bei einigen Anwendungen und Frameworks sind sie möglicherweise standardmäßig deaktiviert und müssen erst aktiviert werden, bevor sie ausgeführt werden können. Administratoren können auch bestimmte Sicherheitsfunktionen deaktivieren, um bestimmte Aufgaben einfacher ausführen zu können, ohne ständig herausgefordert oder blockiert zu werden (z. B. öffentliche AWS S3-Speicher). Nach Abschluss der Arbeitvergessen sie möglicherweise, die deaktivierten Funktionen wieder zu aktivieren. Möglicherweise ziehen sie es auch vor, sie deaktiviert zu lassen, um die Arbeit in Zukunft einfacher zu gestalten.

Warum sind deaktivierte Sicherheitsfunktionen so gefährlich?

Das Deaktivieren einer oder mehrerer Sicherheitsfunktionen ist aus zwei Gründen nicht empfehlenswert. Erstens werden Sicherheitsfunktionen in die Infrastrukturressourcen integriert, um bekannte Schwachstellen, Bedrohungen oder Sicherheitslücken abzuwehren. Wenn sie deaktiviert werden, können sie Ihre Ressourcen nicht mehr schützen.

Angreifer versuchen immer zuerst, leicht auszunutzende Schwachstellen zu finden, und verwenden möglicherweise sogar Skripte, um gängige Schwachstellen zu beheben. Das ist nicht anders, als wenn ein Dieb alle Autos auf der Straße überprüft, um zu sehen, ob eine Tür unverschlossen ist, was viel einfacher ist, als eine Scheibe einzuschlagen. Hacker sind möglicherweise überrascht, wenn sie feststellen, dass gängige Sicherheitsmaßnahmen nicht aktiv sind. Wenn dies jedoch der Fall ist, nutzen sie dies schnell aus.

Zweitens: Eine gute Sicherheitseinstellung und anschließende Deaktivierung kann ein falsches Gefühl der Sicherheit vermitteln. Wenn Administratoren nicht wissen, dass jemand diese Schutzmaßnahmen deaktiviert hat, könnten sie glauben, dass sie vor gängigen Bedrohungen sicher sind.

Als Beispiel dafür, wie Angreifer deaktivierte Sicherheitsfunktionen ausnutzen können, kann man sich die AWS S3-Sicherheitsfunktion zum Blockieren des öffentlichen Zugriffs vorstellen. Mit Amazon S3 Public Access Block können Kontoadministratoren und Bucket-Besitzer auf einfache Weise eine zentrale Kontrolle einrichten, um den öffentlichen Zugriff auf ihre Amazon S3-Ressourcen zu beschränken.Einige Administratoren haben jedoch Probleme beim Zugriff auf S3-Buckets und entscheiden sich, diese öffentlich zugänglich zu machen, um ihre Aufgaben so schnell wie möglich zu erledigen. Wenn sie vergessen, die Sicherheitsfunktion zu aktivieren, erhalten Angreifer uneingeschränkten Zugriff auf die in diesem S3-Bucket gespeicherten Informationen, was nicht nur zu Informationslecks führt, sondern auch zusätzliche Kosten für die Datenübertragung verursacht.

Lassen Sie uns einige Codes aus der realen Welt vergleichen. Sehen Sie sich den folgenden CloudFormation-Ausschnitt an:

Anfällig:

Unternehmensspeicher:
Typ: AWS:: S3:: Bucket
Eigenschaften:
Konfiguration für öffentlichen Zugriff:
blockPublicACLS: Fehler
BlockPublicy: Fehler
ignorepublicacls: Fehler
restrictPublicBuckets:
Versionskontrollkonfiguration:
Status: Aktiviert
Speicherverschlüsselung:
Konfiguration für serverseitige Verschlüsselung:
- Standardmäßige serverseitige Verschlüsselung:
SSE-Algorithmus: „AES256”

Sicherheit:

Unternehmensspeicher:
Typ: AWS:: S3:: Bucket
Eigenschaften:
Konfiguration des öffentlichen Zugriffsbereichs:
blockPublicACLS: Ja
BlockPublicy: Ja
ignoreRepublicacls:
restrictPublicBuckets:
Versionskontrollkonfiguration:
Status: Aktiviert
Speicherverschlüsselung:
Konfiguration der serverseitigen Verschlüsselung:
- Standardmäßige serverseitige Verschlüsselung:
SSE-Algorithmus: „AES256”

Verhindern der Deaktivierung von Sicherheitsfunktionen

Die Verhinderung negativer Auswirkungen durch deaktivierte Sicherheitsfunktionen auf Ihre Organisation ist sowohl eine Frage der Richtlinien als auch der Praxis. Es sollte eine strenge Richtlinie festgelegt werden, die vorsieht, dass Sicherheitsfunktionen nur in ganz besonderen Fällen deaktiviert werden dürfen. Vorfälle, in denen Funktionen vorübergehend deaktiviert werden müssen, um Probleme zu beheben oder Anwendungen zu aktualisieren, sollten dokumentiert werden. Nach Abschluss der erforderlichen Arbeiten sollten die Funktionen überprüft werden, um sicherzustellen, dass sie vollständig wieder aktiviert wurden.

Wenn Sicherheitsfunktionen dauerhaft deaktiviert werden müssen, um den Betrieb zu vereinfachen, sollten für die betroffenen Daten andere Schutzmaßnahmen getroffen werden, um sicherzustellen, dass Hacker ohne den standardmäßigen Schutz keinen Zugriff auf diese Funktionen erhalten. Wenn die erforderlichen Schutzfunktionen deaktiviert wurden, ist es nur eine Frage der Zeit, bis Angreifer eine ungeschützte Tür finden und diese Situation ausnutzen.

Mehr erfahren, sich selbst herausfordern:

Besuchen Sie die Blog-Seite von Security Code Warrior, um mehr über diese Sicherheitslücke zu erfahren und zu erfahren, wie Sie Ihr Unternehmen und Ihre Kunden vor anderen Sicherheitslücken und Schwachstellen schützen können.

Nachdem Sie diesen Artikel gelesen haben, sind Sie bereit, diese Sicherheitslücke zu entdecken und zu beheben? Dann ist es an der Zeit,die iMac-Gamification-Sicherheitsherausforderung auf Secure Code Warrior auszuprobieren, Secure Code Warrior kontinuierlich zu verbessern und auf dem neuesten Stand zu halten.

Dies ist eine wöchentliche Artikelserie, die unsere acht wichtigsten „Infrastructure as Code“-Schwachstellen behandelt. Schauen Sie nächste Woche wieder vorbei, um mehr zu erfahren!