DevSecOps – der nächste Hype nach DevOps und Containern?

Inhaltsverzeichnis

Bei grundlegenden Betrachtungen, die helfen sollen, im Team Security-Know-how aufzubauen, geht es zumeist darum, in einem ersten Schritt ein Problembewusstsein zu schaffen. Gerade bei agil arbeitenden Teams ist es deshalb wichtig, Kontrollpunkte zu etablieren. Das Prinzip der Automatisierung aus DevOps trägt auch hier: Es gibt viele Tools, die dabei helfen, manuelle Aufgaben zu eliminieren, zum Beispiel Schwachstellen zu scannen oder Codeanalysen durchzuführen.

Bei DevOps geht es nicht nur um Entwicklungs- und Betriebsteams. Wer die Agilität und Reaktionsfähigkeit eines DevOps-Ansatzes voll ausschöpfen will, für den muss die IT-Sicherheit eine integrierte Rolle im gesamten Lebenszyklus der Anwendungen spielen. In der Vergangenheit wurde die Rolle der Sicherheit in der Endphase der Entwicklung auf ein bestimmtes Team beschränkt. Das war nicht so problematisch, als die Entwicklungszyklen noch Monate oder gar Jahre dauerten, aber diese Tage sind vorbei. Effizientes DevOps gewährleistet schnelle und häufige Entwicklungszyklen (manchmal in Wochen oder Tagen), aber veraltete Sicherheitspraktiken können selbst die besten DevOps-Initiativen zurückwerfen.

Mehr Infos

DevSecOps – die Serie

• Grundlegendes zur Sicherheit in der Softwareentwicklung und wie Angreifer arbeiten
• Selbst hacken und dabei lernen
• Mit DevOps-Prinzipien kontinuierlich sicherer werden

Kontinuierlich sicherer

Im kollaborativen Rahmen von DevOps ist Sicherheit eine gemeinsame Verantwortung, die von Anfang bis Ende integriert ist. Es ist eine Denkweise, die so wichtig ist, dass einige den Begriff "DevSecOps" geprägt haben, um die Notwendigkeit zu unterstreichen, eine Sicherheitsgrundlage in DevOps-Initiativen zu schaffen.

DevSecOps bedeutet, von Anfang an über die Sicherheit von Anwendungen und Infrastrukturen nachzudenken. Es bedeutet auch, einige Sicherheitsgatter zu automatisieren, um zu verhindern, dass sich der DevOps-Workflow verlangsamt. Die Auswahl der richtigen Tools zur kontinuierlichen Integration von Sicherheit kann helfen, Sicherheitsziele zu erreichen, aber eine effektive DevOps-Sicherheit erfordert mehr als neue Tools – sie baut auf den kulturellen Veränderungen von DevOps auf, um die Arbeit von Sicherheitsteams lieber früher als später zu integrieren.

Ob man es nun "DevOps" oder "DevSecOps" nennt, es war schon immer ideal, Sicherheit als integralen Bestandteil des gesamten Softwarelebenszyklus zu sehen. Bei DevSecOps geht es um eingebaute Sicherheit, nicht um Sicherheit, die als Polizei für Software und Daten fungiert. Wenn die Sicherheit erst am Ende der Entwicklungs-Pipeline greift, können Unternehmen, die DevOps einsetzen, zu den langen Entwicklungszyklen zurückkehren, die sie ursprünglich vermeiden wollten.

Mehr Infos

Sicherheit sollte begleiten und nicht blockieren. Lieber Leitflanken aufzeigen, als Strafzettel verteilen.

DevSecOps betont die Notwendigkeit, Sicherheitsteams zu Beginn der DevOps-Initiativen einzuladen, um Informationssicherheit einzubauen und einen Plan für die Sicherheitsautomatisierung festzulegen. Es unterstreicht auch die Notwendigkeit, Entwicklern bei ihrer Arbeit bei der Sicherheit zu helfen. Dieser Prozess, bei dem Sicherheitsteams transparent Feedback und Erkenntnisse über bekannte Bedrohungen
austauschen, hilft dem gegenseitigen Verständnis. Es ist möglich, dass das auch neue Sicherheitsschulungen für Entwickler umfassen kann, da sie nicht immer ein Schwerpunkt in der traditionellen Anwendungsentwicklung sind.

Wie sieht die eingebaute Sicherheit aus?

Eine gute DevSecOps-Strategie besteht zunächst darin, die Risikotoleranz zu bestimmen und eine Risiko-Nutzen-Analyse durchzuführen. Wie viele Sicherheitskontrollen sind innerhalb einer bestimmten App erforderlich? Wie wichtig ist die schnelle Markteinführung verschiedener Apps? Die Automatisierung wiederholter Aufgaben ist der Schlüssel zu DevSecOps, da das Durchführen manueller Sicherheitschecks in der Pipeline zeitaufwendig sein kann.

Darüber hinaus ist es nötig, die engere Zusammenarbeit zwischen isolierten Teams zu fördern. Alle diese Initiativen beginnen auf der menschlichen Ebene – mit den Besonderheiten der Zusammenarbeit in Unternehmen. Diese sollten zurücktreten und die gesamte Entwicklungs- und Betriebsumgebung berücksichtigen. Dazu gehören Versionskontroll-Repositorys, Container-Registrys, Continuous-Integration- und Continuous-Deployment-Pipeline (CI/CD), API-Management (Application Programming Interface), Orchestrierung und Release-Automatisierung sowie die operative Verwaltung und Überwachung. Neue
Automatisierungstechniken haben Unternehmen geholfen, agilere Entwicklungspraktiken einzuführen, und sie haben dazu beigetragen, neue Sicherheitsmaßnahmen voranzutreiben.

Aber die Automatisierung ist nicht das Einzige in der IT-Landschaft, das sich in den letzten Jahren verändert hat: Cloud-Techniken wie Container und Microservices sind heute ein wichtiger Bestandteil der meisten DevOps-Initiativen, und die Sicherheit von DevOps muss sich anpassen, um ihren Anforderungen nachzukommen. Cloud-native Techniken eignen sich nicht für statische Sicherheitsrichtlinien und Checklisten. Vielmehr muss die Sicherheit in jeder Phase des Lebenszyklus von Apps und Infrastrukturen kontinuierlich und integriert sein:

• Standardisierung und Automatisierung (Provisioning, Rollout, Patching)
• zentrales Identity- und Access Management
• integrierte Security-Scanner für Container
• automatisches Security-Testing innerhalb der CI-Pipeline
• Isolierung von Microservices
• Verschlüsselung auf der Transportebene
• Prüfung auf bekannte Schwachstellen

Der Einsatz von Tools ersetzt – wie in anderen Bereichen – nicht das Auseinandersetzen mit den Hintergründen. Wichtig ist eher, dass man sich mit den Hintergründen beschäftigt und Schritt für Schritt vorgeht. Dieses Vorgehensmodell passt auch gut zum agilen Mindset, zunehmend besser zu werden. Warum also nicht auch bei der Sicherheit? Es ist mit vertretbarem Aufwand möglich, im Rahmen von Continuous Delivery Continuous Security umzusetzen. An nahezu allen Stellen lassen sich Sicherheitsaspekte berücksichtigen. So können User-Stories für die Härtung geschrieben oder auch in fachlichen Anforderungen sicherheitsrelevante Punkte berücksichtigt werden. Es ist generell gerade in größeren Projekten ratsam, die Rolle des Security-Champions zu besetzen und gegebenenfalls einen oder mehrere Security-Sprints einzuplanen. Für das methodische Grundgerüst gibt es also verschiedene Punkte, die es zu beachten gilt:

• Erstellen von Security Guidelines
• Berücksichtigen von Sicherheit beim Erstellen von User Stories
• Codescans durchführen
• Peer-Reviews durch einen Security-Champion durchführen
• Penetrationstests einplanen

Ganz essenziell wird dabei der Aufbau von Security-Know-how im Team. Zunächst gilt es jedoch, ein Problembewusstsein zu schaffen.

Checklisten und Datenbanken

Damit Sicherheitsexperten, Entwickler und Anwender weltweit bei der Beseitigung von Sicherheitsschwachstellen zusammenarbeiten können, ist ein einheitliches Schema zur Identifizierung von Schwachstellen erforderlich.

Die Common Vulnerabilities and Exposures (CVE) sind hierfür seit 1999 ein unverzichtbarer Industriestandard. Im Wesentlichen ist das eine Datenbank, die verschiedene Abfragen ermöglicht. Zunächst ist ein CVE-Eintrag nur eine erkannte Schwachstelle. Er sagt nichts über das Risiko, dass diese Schwachstelle auch ausgenutzt werden kann, und über die Auswirkungen eines Ausfalls auf ein Unternehmen oder seine IT-Infrastruktur. Es ist daher das Risiko, das die Schwachstelle oder das Risiko der CVEs definiert, und nicht deren Anzahl.

Aber auch hier gibt es einen Ansatz, der den Sicherheitsverantwortlichen das Leben etwas einfacher macht – das CVSS (Common Vulnerability Scoring System). Je einfacher eine Schwachstelle auszunutzen ist, desto geringer ist die zu überwindende Hürde und desto höher ist der Risikofaktor der Schwachstelle. Er erreicht Werte von 0 bis 10, wobei 10 den höchsten Wert darstellt.

Mit diversen Tools lässt sich prüfen, ob es für eine Software bekannte Schwachstellen gibt. Der CVE-Record beschreibt dabei oft auch einen konkreten Angriffsvektor. Das ist vor allem deswegen wichtig, weil es gerade damit einfach ist, Angriffe schnell und im großen Stil zu realisieren, denn ein Großteil der Lücken bleibt lange ungepatcht. Außerdem lohnt ein Blick in die OWASP Top 10, die die häufigsten und kritischsten Schwachstellen in Webanwendungen auflistet.

Generell sollte man die diversen Hacking-Tools nicht auf seinem regulärem Computer installieren. Am besten nutzt man Whonix oder Kali-Linux in einer VM. Im Folgenden wird Kali-Linux genutzt. Das Schöne dabei ist: Es sind bereits die meisten Tools installiert und direkt nutzbar. Alternativ kann man ein Docker-Image verwenden, was auch in diesem Artikel der Fall ist.

Mehr Infos

Noch ein Hinweis zur Nutzung von Tor: Es ist brauchbar für den Aufruf von Webseiten, wenn es aber um die Verwendung von Hacking-Tools wie nmap, sqlmap und nikto geht, die Tausende von Anfragen verarbeiten, verlangsamt Tor die Übertragung zu sehr.

Auch wenn Hollywood es anders darstellt: Hacker verbringen oft mit der Vorbereitung der Attacke mehr Zeit als mit dem eigentlichen Hack. Dabei geht es primär um das Sammeln von Informationen: Domain-Einträge mit fierce auslesen, Whois-Abfragen von IP-Adressen und Domain-Namen und Reverse-Whois-Abfragen, um alle IP-Adressbereiche und Domain-Namen zu finden, die mit einer Organisation verbunden sind. Hier ein Beispiel für eine Fierce-Abfrage für holisticon.de:

root@kali:~# fierce -DNS holisticon.de
DNS Servers for holisticon.de:
        ns6.kasserver.com
        ns5.kasserver.com

Trying zone transfer first... (1)
        Testing ns6.kasserver.com
                Request timed out or transfer not allowed.
        Testing ns5.kasserver.com
                Request timed out or transfer not allowed.

Unsuccessful in zone transfer (it was worth a shot)
Okay, trying the good old fashioned way... brute force

Checking for wildcard DNS... (2)
        ** Found 99752187575.holisticon.de at 85.214.158.97.
        ** High probability of wildcard DNS.
Now performing 2280 test(s)... (3)
85.214.38.253   blog.holisticon.de
81.169.187.209  cms.holisticon.de
195.201.92.152  honeypot-wp.holisticon.de
81.169.173.205  wiki.holisticon.de

Subnets found (may want to probe here using nmap or unicornscan):
        195.201.92.0-255 : 1 hostnames found.
        81.169.173.0-255 : 1 hostnames found.
        81.169.187.0-255 : 1 hostnames found.
        85.214.38.0-255 : 1 hostnames found.

Done with Fierce scan: http://ha.ckers.org/fierce/
Found 4 entries. (4)

Have a nice day

Zunächst wird versucht, per Zone Transfer mehr Informationen (AXFR Request) über das Netzwerk zu erhalten. Das wird im Großteil der Fälle nicht funktionieren.

1. Nun sucht Fierce, ob ein Wildcard-Eintrag existiert, und ist fündig geworden.
2. Anschließend werden per Brute Force weitere Subdomains gefunden.
3. Insgesamt wurden 10 Einträge gefunden.

Mit Whois-Abfragen kann man nun beginnen, mehr über den Anbieter herauszufinden, der die Domain registriert hat und vermutlich auch betreibt:

root@60808f78e55d:/# whois 85.214.65.25
...
inetnum:        85.214.16.0 - 85.214.139.255
netname:        STRATO-RZG-DED2
org:            ORG-SRA1-RIPE
descr:          Strato Rechenzentrum, Berlin
country:        DE
admin-c:        SRDS-RIPE
...

Nun können die Leser per Reverse-Whois-Suche nach weiteren Adressen fahnden. Da diese aber Geld kosten, können sie ihr Glück auch mit Google versuchen. Dazu einfach folgende Suchbegriffe eingeben:

"Strato Rechenzentrum, Berlin" inurl:ip-address-lookup
"Strato Rechenzentrum, Berlin" inurl:domaintools

Da in dem Fall kein direkter Whois-Eintrag vorliegt, sondern nur der des Hosters, werden hier zu viele IP-Bereiche gelistet. Das kann aber je nach Konfiguration und Set-up der Firma stark variieren. Letztlich dient die Reverse-Suche dazu, die Liste an interessanten IPs/Domains zu erweitern.

An dieser Stelle noch ein Hinweis zur Sicherheit von Cloud-Anbietern: Versucht man bei AWS mehr Informationen per DNS zu erhalten, gestaltet sich das nicht so einfach:

root@kali:~# fierce -DNS cloudci.net
DNS Servers for cloudci.net:
        ns-999.awsdns-60.net
        ns-1802.awsdns-33.co.uk

Trying zone transfer first...
        Testing ns-999.awsdns-60.net
                Request timed out or transfer not allowed.
        Testing ns-1802.awsdns-33.co.uk
                Request timed out or transfer not allowed.

Unsuccessful in zone transfer (it was worth a shot)
Okay, trying the good old fashioned way... brute force

Checking for wildcard DNS...
Nope. Good.
Now performing 2280 test(s)...

Subnets found (may want to probe here using nmap or unicornscan):

Done with Fierce scan: http://ha.ckers.org/fierce/
Found 0 entries.

Die Fierce-Abfrage findet hier keine Einträge, obwohl diese registriert und erreichbar sind.

Hier zeigt sich ein Vorteil großer Anbieter wie Amazon. Deren Angebote bieten weniger Angriffsfläche, um Informationen abzugreifen, und das kann schon viele Angreifer abhalten.

Wissen ist Macht

Je weniger Informationen man einem potenziellen Angreifer preisgibt, desto besser. Dafür reichen schon einfache Mittel:

• wenig Informationen zur Verfügung stellen, zum Beispiel Versionen von Diensten wie Apache, nginx und SSH sowie Anwendungen wie WordPress verschleiern
• Standard-Ports vermeiden. Wenn man beispielsweise SSH auf einem anderen Port konfiguriert, wird es für den Angreifer erheblicher zeitaufwendiger
• Anwendungen absichern

Diese Mittel sind aber nur der erste Schritt. Man muss auch nachvollziehen, wie ein Hacker mit den Informationen umgeht, um zu verstehen, wie sinnvolle Sicherheitsmaßnahmen aussehen können. Gerade mit dem "Selbsthacken" wird das Ganze mit sportlichem Ehrgeiz und Spaß verbunden. Darauf geht Teil 2 der Artikelserie ein.

Martin Reinhardt
arbeitet als Architekt bei der Management- und IT-Unternehmensberatung Holisticon AG. Er beschäftigt sich dort mit der Architektur komplexer verteilter Systemen, modernen Webarchitekturen und Build Management. (ane)