Interview mit Dr. Christopher Brennan, Checkmarx, zu IaC-Sicherheit „Open Source funktioniert auch im Enterprise-Umfeld“

Redakteur: Stephan Augsten

Infrastructure-as-Code, kurz IaC, steht für Agilität und Flexibilität. Doch auch Cloud-native Umgebungen bergen Sicherheitsrisiken, welche die Open-Source-Engine KICS mit statischer Code-Analyse aufspürt. Dr. Christopher Brennan, Regional Director DACH bei Checkmarx, spricht über das Projekt.

Firmen zum Thema

KICS soll Sicherheitslücken, Lizenzverstöße und Fehlkonfigurationen von IaC im Cloud-Native-Kontext früh im Entwicklungszyklus erkennen.
KICS soll Sicherheitslücken, Lizenzverstöße und Fehlkonfigurationen von IaC im Cloud-Native-Kontext früh im Entwicklungszyklus erkennen.
(Bild: kics.io / Checkmarx)

Dr. Christopher Brennan: „Security darf einfach nicht zulasten der Agilität oder Entwicklungsgeschwindigkeit gehen, vor allem nicht in DevOps-Umgebungen.“
Dr. Christopher Brennan: „Security darf einfach nicht zulasten der Agilität oder Entwicklungsgeschwindigkeit gehen, vor allem nicht in DevOps-Umgebungen.“
(Bild: Checkmarx)

Dev-Insider: Herr Dr. Brennan, Manch einer sieht bei IaC nur Vorteile wie Automatisierung, Konsistenz und Kostenreduzierung. Ähnlich wie bei der traditionellen Software-Entwicklung sind Fehlkonfigurationen oder Sicherheitslücken aber auch hier potenzielle Risiken und bieten Angriffsflächen für Cyberkriminelle …

Dr. Christopher Brennan: Grundsätzlich ja – der Vergleich hinkt allerdings, denn das Schadensausmaß bewegt sich in einer ganz anderen Dimension. Gefährdet ist ja nicht nur eine bestimmte Anwendung, sondern in einem viel größeren Maßstab das gesamte Unternehmen und die zugrundeliegende IT-Infrastruktur. Bei Cloud-Native-Anbietern können im Falle eines IaC-Breachs also ganz schnell die Lichter ausgehen.

Deshalb ist es dringend angeraten, die Security von Anfang an fest in der Infrastruktur zu verankern und mit Hilfe dedizierter IaC-Security-Tools abzuklopfen, ob die Ressourcen auch wirklich sicher sind. Solche Tools müssen dementsprechend zunächst einmal in der Lage sein, Konfigurationsdateien und Skripte in relevanten Formaten zu verarbeiten.

Anschließend geht es darum, die Compliance mit gängigen Hardening-Standards sicherzustellen – wie zum Beispiel die CIS-Benchmarks und andere. Die Tools müssen aber auch Sicherheitsprobleme im Zusammenhang mit bestimmten Betriebsumgebungen identifizieren, eingebettete Secrets erkennen und andere Tests im Hinblick auf unternehmensspezifische Standards und Compliance-Anforderungen durchführen.

Kern von KICS sind rund 1.300 heuristische Regeln.

Dev-Insider: Und hier kommt das Open-Source-Projekt „Keeping Infrastructure as Code Secure“ ins Spiel?

Dr. Brennan: Exakt. Mit unserer Open-Source-Engine geben wir Entwicklern das Rüstzeug, um Sicherheitslücken, Lizenzverstöße und Fehlkonfigurationen von IaC im Kontext von Cloud-nativen Anwendungen frühzeitig im Entwicklungszyklus zu erkennen. Kern des Ganzen sind rund 1.300 heuristische Regeln, sogenannte Queries, die ich – je nach Anforderungen meiner Entwicklungsumgebung – feintunen und erweitern kann.

Die Engine ist kompatibel mit gängigen Konfigurations- und Orchestrierungstools wie AWS Cloud Formation oder Kubernetes und Cloud-Computing-Plattformen wie AWS oder Azure und in puncto Architektur insofern flexibel, als dass sie mittel- und langfristig auch die Einbindung weiterer Tools erlaubt – Chef beispielsweise steht bereits auf der Roadmap.

Dev-Insider: Bis dahin war es aber ein weiter Weg, oder? Fast 1.500 Heuristik-Regeln sind ja nicht einfach über Nacht erstellt.

Dr. Brennan: Das kann man so sagen, ja. Gestartet ist das Projekt mit gerade einmal 50 Queries. Zu diesem Zeitpunkt noch in einem Private Repository und als Stand-Alone-Engine, die nur einige wenige IaC-Dateitypen lesen, sie in eine interne Repräsentation umwandeln und Ergebnisse im JSON-Format produzieren konnte. Damals haben wir es uns zum Ziel gesetzt, das Repertoire innerhalb von drei Monaten auf 1.000 REGO/OPA-Queries aufzustocken und das Projekt in weniger als zwei Monaten komplett in ein Open-Source-Modell zu überführen.

Dev-Insider: Klingt sehr ambitioniert …

Dr. Brennan: Es war definitiv eine große Herausforderung. Aber wir konnten unser Team mit einer Gruppe talentierter Studenten verstärken, die sich voll auf die Entwicklung weiterer Queries auf Basis von REGO/OPA fokussierte, einer deklarativen Sprache zur Abfrage strukturierter Dokumente. Unter Beachtung der von unserem Application Security Research Team bereitgestellten Liste bekannter Sicherheitslücken und anderer Schwachstellen entwickelten sie innerhalb kürzester Zeit Regeln und IaC-Samples – ein True-Positive und ein True-Negative pro Query.

Ironischerweise wurde so sehr schnell eher die Genehmigung von Pull Requests als die Entwicklung selbst zum Bottleneck. Bis zu unserer Deadline hatten wir den Meilenstein von 1.000 Queries nicht nur erreicht, sondern ihn mit rund 1.200 Queries sogar übertroffen.

Open Source war von Anfang an unser Credo.

Dev-Insider:Wie sieht es mit der Zielsetzung aus, das Projekt komplett quelloffen zu machen?

Dr. Brennan: Open Source war von Anfang an unser Credo. Bei der Geschwindigkeit, mit der sich IaC entwickelt, war klar, dass es ein großes Projekt werden würde, und wir deshalb gut beraten wären, die Last auf viele Schultern zu verteilen und die Schwarmintelligenz zu nutzen. Nicht zuletzt dank des wertvollen Inputs unseres OSS-Beraters Lior Kaplan, der das Projekt begleitete, konnten wir aber auch an diesen Punkt einen Haken setzen.

Das Team löste die Abhängigkeiten mit dem Private Repository auf, schrieb die Commit History um und verschob sie unter Apache-2.0-Lizenz in das öffentliche GitHub-Repository. Parallel erstellten wir CI-Pipelines mit GitHub Actions, um die gesamte Infrastruktur innerhalb der GitHub-Umgebung zu halten. Bald lief eine Reihe von Validierungen pro Pull Request in der Pipeline.

Adressiert werden damit mehrere Qualitätsaspekte, darunter Testabdeckung, Code-Qualität und Sicherheit – vorausgesetzt, die Qualitätsstufe wird in jedem CI-Schritt erreicht, liegt zwischen erfolgreichem Pull Request und Release trotzdem nur etwa eine Minute. Heute stellen wir gemäß der Open-Source-Best-Practices kontinuierlich ein nächtliches Release bereit, benannt mit dem Hash des entsprechenden Commits.

Zusätzlich dazu liefern wir alle zwei Wochen ein offizielles Release unter Verwendung des SemVer-Standards. Jedes Release enthält den reinen Quellcode, Binärdateien für Windows, Linux und MacOS sowie ein Docker-Image, das auf DockerHub zur Verfügung gestellt wird.

Dev-Insider: Wie fällt rückblickend ihr Fazit aus?

Dr. Brennan: Open Source funktioniert auch im Enterprise-Umfeld! Unsere Engine hat einen starken Kern, der viele Arten von IaC-Dateien analysieren kann, und mittlerweile Tausende von Queries – alles komplett auf Open-Source-Basis.

Als Entwickler ist Zeit meine wertvollste Ressource – Security darf einfach nicht zulasten der Agilität oder Entwicklungsgeschwindigkeit gehen, vor allem nicht in DevOps-Umgebungen. Eine Engine, die einfach zu installieren und auszuführen ist, mir nachvollziehbare Ergebnisse liefert und sich nahtlos in meine CI/CD-Pipelines und Workflows integrieren lässt, bietet mir an dieser Stelle also einen echten Mehrwert. 15.000 Downloads in weniger als drei Monaten seit Release sprechen da eine eindeutige Sprache, denke ich.

Jetzt geht es darum, Awareness für das Projekt zu schaffen: Mit unserer KICS-Website haben wir bereits den ersten Schritt gemacht – aber das ist noch lange nicht alles. Die Dokumentation stellen wir über MKDocs aus Markdown-Dateien zusammen und machen sie über GitHub Pages verfügbar. Sie enthält alles über das Projekt, einschließlich Roadmaps, Anleitungen zur Nutzung oder zum Mitwirken. Außerdem haben wir mit Gitter eine eigene Community aufgebaut.

Um die Beiträge der User besser managen und letztendlich deren Qualität vereinheitlichen zu können, haben wir Templates für Bugs, Features, neue Queries und Pull-Requests definiert. Es gibt bereits zahlreiche Posts von Followern und wir freuen uns auf viele weitere, denn das hier ist ein echtes Gemeinschaftsprojekt! Sowohl die Scan-Engine als auch die Queries sind offen für die Softwareentwickler-Community. Egal, ob einfach nur als Follower, durch Feedback, das Öffnen von Issues und Feature Requests oder das Einreichen von Codeänderungen – jeder kann seinen eigenen Weg finden, zum Projekt beizutragen.

Ergänzendes zum Thema
Hintergrund: Infrastructure as Code (IaC)

Infrastructure as Code (IaC) ist die Erstellung, Bereitstellung und Konfiguration von Software-Defined Compute (SDC), Netzwerk- und Speicherinfrastrukturen durch maschinenlesbare Definitionsdateien anstelle von physischer Hardwarekonfiguration oder interaktiven Konfigurationstools.

IaC automatisiert die manuellen Aufgaben, die normalerweise mit der Konfiguration und Implementierung der Computing-Infrastruktur verbunden sind, und …

  • beschleunigt die Konfiguration und Implementierung einer neuen Computing-Infrastruktur,
  • reduziert die Kosten und Ressourcen für die Skalierung und Verwaltung großer Infrastrukturen,
  • beseitigt Inkonsistenzen, die unweigerlich auftreten, wenn mehrere Personen neue Geräte oder Anwendungen manuell konfigurieren.

Artikelfiles und Artikellinks

(ID:47532292)