Anzeige

In unserem Lab-Projekt zeigen wir auf, wie sich die Sicherheit von Sourcecode mit einfachsten Mitteln und Open Source Tools erhöhen lässt. Wir erläutern unser Vorgehen dabei Schritt für Schritt, sämtliche Ressourcen stehen als GitLab-Repository zur Verfügung.

Für unser Demo-Lab verwenden wir exemplarisch ein Sourcecode Management Tool sowie einen Sourcecode Scanner. Wir wählen in diesem Fall die Tools GitLab und SonarQube. GitLab ist in der Community Edition kostenfrei verfügbar und bringt von Haus aus nützliche Funktionalitäten wie z.B. Continuous Integration (CI) ein. Auf diese Weise kann eine YAML-Datei im eigenen Projektordner abgelegt werden.

SonarQube ist in der Community Edition ebenfalls ein frei verwendbares Tool und bietet eine große Diversität unterstützter Programmiersprachen.

Der Aufbau unserer Lab Umgebung ist dabei wie folgt:

 

DevSecOps

Architekturdiagramm. Bildquelle: carmasec

 

 

DevSecOps

Flussdiagramm. Bildquelle: carmasec


 

Der Scope

Dieses Lab legt den Fokus sehr stark auf die automatisierte Überprüfung der Sicherheit von Sourcecode. Zur Vereinfachung werden folgende Themen nicht berücksichtigt (siehe auch Architektur-Diagramm):
⦁  OS Hardening
⦁  Network Hardening
⦁  Container Security
⦁ Application Security

 

Das Deployment

Für das Deployment der Artefakte des Labs wird Ansible verwendet. Hierzu wird ein Ansible Playbook erstellt, welches folgende Funktionen erfüllt:
⦁ Updaten des Systems
⦁ Entfernen der vorinstallierten Docker Version
⦁ Installieren der Docker Community Edition
⦁ Anlegen eines Docker Users
⦁ Kopieren von Bash-Scripten auf das Zielsystem
⦁ Ändern der Berechtigung der Bash-Scripte

Die Bash-Scripte erfüllen verschiedene Aufgaben im Zusammenspiel mit den Docker-Containern. Ein Script kopiert die aktuellsten Images, welche für das Lab benötigt werden, von Docker Hub: Dies sind zum einen GitLab, des Weiteren GitLab Runner sowie SonarQube Server. Ein vorheriges manuelles Herunterladen des SonarQube Scanners ist nicht erforderlich, da dies durch die CI-Funktionalität von GitLab automatisch durchgeführt wird.

Die übrigen Scripte werden benötigt, um die Container auszuführen und einen persistenten Speicher innerhalb der Container zuzuweisen, sowie für die Dienste entsprechende Ports zu setzen und jeden Container eindeutig zu benennen.

Zusätzlich wird ein weiteres Script ausgeliefert, welches den GitLab-Runner konfiguriert. Dazu muss zunächst innerhalb von GitLab ein Runner-Token erstellt werden, welches anschließend dem Script weitergegeben und somit der Runner GitLab zugewiesen wird.

Die Besonderheit einer containerisierten GitLab Instanz ist die Portzuweisung. Am Anfang des Projektes traten häufiger Probleme mit git-Befehlen auf der Konsole auf, sofern GitLab nicht der Standard SSH Port 22 zugewiesen wurde. Daher entschließen wir uns, dem Host System einen alternativen SSH Port zuzuweisen und GitLab auf dem Standard SSH Port zu nutzen.

 

Projekte, Projekte, Projekte

Um ein Repository scannen zu können, muss zunächst ein SonarQube Projekt angelegt und ein Project Key vergeben werden. Anschließend wird ein Token generiert. Dies geschieht durch Vergabe eines Token Namens, zu dem SonarQube einen alphanumerischen String erzeugt.

Als nächstes muss im Projektordner die Konfigurationsdatei sonar-project.properties angelegt werden. Diese enthält insbesondere die Parameter Project.Key und Project.Name. Ohne diese generiert SonarQube eine Fehlermeldung. Weiterhin muss zwingend die Quelle (d.h. der Pfad zum Sourcecode) spezifiziert werden. Zusätzlich können noch weitere Eigenschaften wie Kodierung und Programmiersprache konfiguriert werden, was jedoch in unserem Fall nicht erforderlich ist.

Das Anlegen der Konfigurationsdatei sonar-project.properties ist ebenfalls nicht zwingend notwendig: Alternativ können die Werte Project.Key und Project.Name auch in GitLab selbst hinterlegt und anschließend in der .gitlab-ci.yml zugewiesen werden.

 

Die .gitlab-ci.yml

Das Herzstück der Automatisierung dieses kleinen Labs bildet die in YAML geschriebene Datei .gitlab-ci.yml. Für diesen Anwendungsfall ist die Komplexität minimal gehalten, alle Anweisungen werden vom GitLab-Runner ausgeführt.
In diesem simplen Fall sucht der GitLab-Runner das Sonar-Scanner-Image auf Dockerhub, sofern es nicht bereits lokal vorliegt. Hier kommt das alphanumerische Token zum Einsatz, welcher an den Scanner übergeben wird. Zusätzlich muss die Host-Adresse von SonarQube angegeben werden, um nach dem Scan die Ergebnisse auf den Server zu pushen. Nachdem dies ausgeführt wurde, beendet sich der Container mit dem Sonar-Scanner wieder automatisch und wird erst dann erneut gestartet, wenn ein neuer Merge-Request auf den Master aufgeführt wird.

 

Ausblick

Wie oben erwähnt sind einige Security-Best-Practices, wie die Härtung von Betriebssystem und Netzwerk, hier nicht berücksichtigt.

Auch dieser Ausblick fokussiert daher eher den horizontalen Ausbau rechts und links der im Architekturdiagramm skizzierten Lösung. Beginnen wir mit der Betrachtung des „Links“:
Dem Sourcecode Management Tool vorgelagert sitzt im Normalfall der Editor oder die IDE des Entwicklers. Hier können verschiedene Plugins genutzt werden, um z.B. implementierte Kryptographie zu identifizieren und festzustellen, ob die Schlüssellänge richtig gewählt ist. Somit können Sicherheitsmängel sofort behoben werden. Danach erfolgt ein Commit und ggf. der Merge-Request und ein automatischer SonarQube-Scan.

Dem Lab nachgelagert (gedanklich rechts von unserer Lösung) sind andere Sicherheitsfeatures eingereiht, z.B. ein eigenes Image Repository und ein Image Vulnerability Scanner. Somit kann sichergestellt werden, dass die Security-Abteilung diese Images vorab überprüfen kann, bevor Entwickler diese nutzen. Auch hier ist Kommunikation zwischen den Abteilungen sehr wichtig.
Zu guter Letzt sollen weitere nicht-funktionalen Tests noch Erwähnung finden: Ebenso wie funktionale- und End-to-End Tests können auch einige Security Tests automatisiert durch Scanner und andere Tools durchgeführt werden. Diese sind nicht nur hilfreich für die Entwickler, sondern auch für die Operatoren, da auch Konfigurationen mit in diese Tests einbezogen werden.

 

Fazit

Die Qualität von Sourcecode in Hinblick auf Security-Aspekte zu erhöhen, muss weder aufwändig noch kostenintensiv sein. So lässt sich die Integration eines Basissets von (Open Source) Security-Tools in die Entwicklungspipeline bereits mit einfachen Mitteln realisieren und liefert dabei einen klaren Mehrwert.
Wie so oft führen viele Wege zum Ziel und jede Reise beginnt mit dem ersten Schritt.

 

Lesen Sie hier Teil 1: Schritt für Schritt zur DevSecOps Pipeline

 

Jan Sudmeyer ist Managing Partner und Senior Trusted Advisor der carmasec GmbH & Co. KG. Seine Expertise liegt im Bereich Cybersecurity, sowie dem Aufbau von Managementsystemen zur Informationssicherheit (ISMS).

 

 

 

 

 

 Kevin Kloft ist Security Solution Architect der carmasec GmbH & Co KG. Er beschäftigt sich schwerpunktmäßig mit der Evaluation neuer Technologien und der Implementierung von DevSecOps Tools und Praktiken.

 

Weitere Artikel

Cyber Security

Cybersecurity muss Prävention und Detektion ausbalancieren

In ihrer bisherigen Historie konzentrierten sich Cybersicherheitsprodukte hauptsächlich darauf, bösartigen Code daran zu hindern, auf Computer zu gelangen und diesen auszuführen. Joe Levy, CTO bei Sophos erjklärt, warum wir Unvollkommenheit nicht mit…
Cyber-Versicherung

Cyber-Versicherungen erleben einen Aufschwung - die Prämien auch

Unternehmen stehen heute mehr denn je unter Druck, ausreichend gegen Angriffe von außen geschützt zu sein. Regelmäßig werden Hacker-Angriffe auf Unternehmen publik – und diese sind nur die Spitze des Eisbergs.
Cyber Security

Microsoft native Security Lösungen optimal nutzen

Mit der Zunahme an Security Tools steigt die Komplexität für Administratoren und Sicherheitsverantwortliche. Sicherheitsrichtlinien, Profile und Berechtigungen müssen verwaltet werden. Anders gesagt: Je mehr Tools, Endgeräte und User desto komplexer wird…
2022 Security

Cybersicherheit 2022: Worauf sich Unternehmen einstellen müssen

Das Jahr 2021 war gespickt mit vielen öffentlich wirksamen Cyberangriffen auf Unternehmen und Behörden. Es hat sich gezeigt, dass die Zielgerichtetheit und Rafinesse der Attacken deutlich zugenommen hat. Besonders prominent waren dabei vor allem zahlreiche…
Social Engineering

Social Engineering-Attacken stoppen mit Verhaltensbiometrie

Kein Sicherheitsfaktor ist so kritisch, wie der Mensch selbst. Das BSI stellt in seinem aktuellen Lagebericht zur IT-Sicherheit in Deutschland 2021 zu Recht fest, dass der Mensch ein oft unterschätztes Sicherheitsrisiko als Einfallstor für Cyberangriffe…

Anzeige

Jetzt die smarten News aus der IT-Welt abonnieren! 💌

Mit Klick auf den Button "Zum Newsletter anmelden" stimme ich der Datenschutzerklärung zu.