Coders Conquer Security Infrastruktur als Code Serie: Deaktivierte Sicherheitsfunktionen

Die Bedrohungen für die Cybersicherheit sind heutzutage allgegenwärtig und unerbittlich. Je mehr Facetten unseres Lebens digitalisiert werden, desto mehr steht für Cyberkriminelle auf dem Spiel - es gibt zu viel Code, den es zu schützen gilt, und private Daten sind zu wertvoll. Und, nun ja, der Versuch, mit jedem Aspekt der Angriffsfläche Schritt zu halten und sie zu verteidigen, nachdem die Programme bereitgestellt wurden, ist fast unmöglich geworden.

Es gibt Ansätze, die einige dieser Symptome lindern können, und einer davon ist offensichtlich, wenn kluge Organisationen das Konzept von Infrastructure as Code (IaC) annehmen. Natürlich gibt es, wie bei jeder Entwicklung, einige Sicherheitsfallen, die es zu umschiffen gilt. Und da die Entwickler an dem Code arbeiten, der die lebenswichtige Infrastruktur für den Betrieb der Anwendungen generiert, ist das Sicherheitsbewusstsein in jeder Phase des Prozesses entscheidend.

Wie genau würde ein Entwickler, der neu in einer Cloud-Server-Umgebung ist, vorgehen, um sich fortzubilden, die Grundlagen zu erlernen und mit erhöhtem Sicherheitsbewusstsein an den Build heranzugehen? Wir haben die nächste "Coders Conquer Security"-Reihe ins Leben gerufen, um häufige IaC-Schwachstellen zu beheben. In den nächsten Blogs werden wir uns auf Schritte konzentrieren, die Sie als Entwickler unternehmen können, um mit der Bereitstellung einer sicheren Infrastruktur als Code in Ihrem eigenen Unternehmen zu beginnen.

Fangen wir an.

Es gibt eine Fabel aus dem alten amerikanischen Westen über einen Mann, der paranoid war, dass Banditen sein Gehöft angreifen und ausrauben würden. Um dies zu kompensieren, investierte er in alle möglichen Sicherheitsmaßnahmen, wie z. B. den Einbau einer extrastarken Eingangstür, das Vernageln aller Fenster und die Aufbewahrung vieler Gewehre in unmittelbarer Nähe. Trotzdem wurde er eines Nachts im Schlaf ausgeraubt, weil er vergessen hatte, die Seitentür zu verschließen. Die Banditen fanden einfach die deaktivierte Sicherung und nutzten die Situation schnell aus.

Mit deaktivierten Sicherheitsfunktionen in Ihrer Infrastruktur verhält es sich ähnlich. Selbst wenn Ihr Netzwerk über eine starke Sicherheitsinfrastruktur verfügt, nützt es sehr wenig, wenn Elemente deaktiviert wurden.

Lassen Sie mich eine Herausforderung stellen, bevor wir eintauchen:

Besuchen Sie den obigen Link, und Sie werden zu unserer gamifizierten Trainingsplattform transportiert, wo Sie jetzt versuchen können, eine deaktivierte Sicherheitsfunktion zu überwinden. (Achtung! Es öffnet sich in Kubernetes, aber verwenden Sie das Dropdown-Menü und Sie können zwischen Docker, CloudFormation, Terraform und Ansible wählen).

Wie haben Sie abgeschnitten? Wenn Sie noch etwas Arbeit vor sich haben, lesen Sie weiter:

Sicherheitsfunktionen können aus verschiedenen Gründen deaktiviert werden. Bei einigen Anwendungen und Frameworks sind sie möglicherweise standardmäßig deaktiviert und müssen erst eingeschaltet werden, um zu funktionieren. Es ist auch möglich, dass Administratoren bestimmte Sicherheitsfunktionen deaktiviert haben, um bestimmte Aufgaben leichter ausführen zu können, ohne ständig herausgefordert oder blockiert zu werden (z. B. ein AWS S3-Bucket öffentlich machen). Nach Abschluss ihrer Arbeit vergessen sie vielleicht, diese deaktivierten Funktionen wieder zu aktivieren. Sie könnten es auch vorziehen, sie ausgeschaltet zu lassen, um ihre Arbeit in Zukunft einfacher zu machen.

Warum deaktivierte Sicherheitsfunktionen so gefährlich sind

Eine oder mehrere deaktivierte Sicherheitsfunktionen zu haben, ist aus mehreren Gründen schlecht. Zum einen wurde die Sicherheitsfunktion in die Infrastrukturressourcen integriert, um sie vor einem bekannten Exploit, einer Bedrohung oder einer Schwachstelle zu schützen. Wenn sie deaktiviert ist, kann sie Ihre Ressourcen nicht mehr schützen.

Angreifer werden immer zuerst versuchen, leicht ausnutzbare Schwachstellen zu finden und können sogar ein Skript verwenden, um gängige Schwachstellen durchzuspielen. Es ist nicht unähnlich einem Dieb, der alle Autos in einer Straße überprüft, um zu sehen, ob irgendwelche Türen unverschlossen sind, was viel einfacher ist, als ein Fenster einzuschlagen. Hacker könnten überrascht sein, wenn sie feststellen, dass eine gängige Sicherheitsabwehr inaktiv ist. Aber wenn das passiert, wird es nicht lange dauern, bis sie es ausnutzen.

Zweitens: Gute Sicherheitsmaßnahmen zu haben und sie dann zu deaktivieren, schafft ein falsches Gefühl von Sicherheit. Administratoren denken vielleicht, dass sie vor allgemeinen Bedrohungen geschützt sind, wenn sie nicht wissen, dass jemand diese Verteidigungsmaßnahmen deaktiviert hat.

Als Beispiel dafür, wie ein Angreifer eine deaktivierte Sicherheitsfunktion ausnutzen könnte, betrachten Sie die AWS S3-Sicherheitsfunktion "block public access". Mit Amazon S3 block public access können Kontoadministratoren und Bucket-Besitzer ganz einfach zentralisierte Kontrollen einrichten, um den öffentlichen Zugriff auf ihre Amazon S3-Ressourcen zu beschränken. Einige Administratoren, die auf Probleme beim Zugriff auf den S3-Bucket stoßen, entscheiden sich jedoch dafür, diesen öffentlich zu machen, um die Aufgabe so schnell wie möglich zu erledigen. Wenn sie vergessen, diese Sicherheitsfunktion zu aktivieren, hat ein Angreifer vollständigen Zugriff auf die in diesem S3-Bucket gespeicherten Informationen, was nicht nur zur Offenlegung von Informationen führt, sondern auch zusätzliche Kosten aufgrund von Datenübertragungsgebühren verursacht.

Lassen Sie uns einige reale Codes vergleichen; sehen Sie sich diese CloudFormation-Schnipsel an:

Verwundbar:

CorporateBucket:
Type: AWS::S3::Bucket
Properties:
PublicAccessBlockConfiguration:
BlockPublicAcls: false
BlockPublicPolicy: false
IgnorePublicAcls: false
RestrictPublicBuckets: false
VersioningConfiguration:
Status: Enabled
BucketEncryption:
ServerSideEncryptionConfiguration:
- ServerSideEncryptionByDefault:
SSEAlgorithm: "AES256"

Sicher:

CorporateBucket:
Type: AWS::S3::Bucket
Eigenschaften:
PublicAccessBlockConfiguration:
BlockPublicAcls: true
BlockPublicPolicy: true
IgnorePublicAcls: true
RestrictPublicBuckets: true
VersioningConfiguration:
Status: Enabled
BucketEncryption:
ServerSideEncryptionConfiguration:
- ServerSideEncryptionByDefault:
SSEAlgorithm: "AES256"

Verhindern von deaktivierten Sicherheitsfunktionen

Zu verhindern, dass deaktivierte Sicherheitsfunktionen Ihrem Unternehmen Schaden zufügen, ist ebenso eine Frage der Richtlinie wie der Praxis. Es sollte eine feste Richtlinie geben, die besagt, dass Sicherheitsfunktionen nur unter ganz bestimmten Umständen deaktiviert werden sollten. Vorfälle, in denen Funktionen vorübergehend deaktiviert werden müssen, um an einem Problem zu arbeiten oder Anwendungen zu aktualisieren, sollten protokolliert werden. Nach Abschluss der erforderlichen Arbeiten sollten die Funktionen überprüft werden, um sicherzustellen, dass sie vollständig reaktiviert wurden.

Wenn eine Sicherheitsfunktion dauerhaft deaktiviert werden muss, um den Betrieb zu rationalisieren, sollten für die betroffenen Daten andere Schutzmechanismen vorgesehen werden, um sicherzustellen, dass Hacker nicht in der Lage sind, auf die Daten zuzugreifen, wenn der Standardschutz nicht vorhanden ist. Wenn eine benötigte Schutzfunktion deaktiviert wurde, ist es nur eine Frage der Zeit, bis ein Angreifer diese unverschlossene Tür findet und die Situation ausnutzt.

Lernen Sie mehr, fordern Sie sich selbst heraus:

Schauen Sie sich die Secure Code Warrior Blog-Seiten, um weitere Informationen über diese Sicherheitslücke zu erhalten und zu erfahren, wie Sie Ihr Unternehmen und Ihre Kunden vor den Auswirkungen anderer Sicherheitslücken und Schwachstellen schützen können.

Sind Sie bereit, diese Schwachstelle zu finden und zu beheben, nachdem Sie diesen Beitrag gelesen haben? Es ist an der Zeit,eine gamifizierte IaC-Sicherheitsherausforderung auf der Plattform Secure Code Warrior auszuprobieren, um alle Ihre Cybersecurity-Fähigkeiten zu verfeinern und auf dem neuesten Stand zu halten.

Dies ist eine wöchentliche Serie, die sich mit den acht wichtigsten Infrastructure as Code-Schwachstellen befasst; schauen Sie nächste Woche wieder vorbei, um mehr zu erfahren!