Security ist wichtig — es ist aber auch wichtig zu beachten, dass das Thema nicht einfach am Ende „draufgepackt werden“ kann. Gerade bei agil arbeitenden Teams ist es deshalb auch wichtig, das entsprechende Bewusstsein zu etablieren — und zwar am Anfang. Das Prinzip der Automatisierung aus DevOps trägt auch hier: Es gibt viele Tools, die dabei helfen, manuelle Aufgaben zu eliminieren, die z.B. Schwachstellen scannen oder Codeanalysen durchführen. So können veraltete Komponenten auch Bußgelder mit sich bringen.
Bei DevOps geht es nicht nur um Entwicklungs- und Betriebsteams. Wer die Agilität und Reaktionsfähigkeit eines DevOps-Ansatzes voll ausschöpfen will, muss auch der IT-Sicherheit eine integrierte Rolle im gesamten Lebenszyklus Ihrer Anwendungen zugestehen.
In der Vergangenheit wurde die Rolle der Sicherheit in der Endphase der Entwicklung auf ein bestimmtes Team beschränkt. Das war nicht so problematisch, wenn die Entwicklungszyklen Monate oder gar Jahre dauerten, aber diese Tage sind vorbei. DevOps setzt auf schnelle und häufige Entwicklungszyklen (manchmal Wochen oder Tage), aber veraltete Sicherheitspraktiken können selbst die effizientesten DevOps-Initiativen zunichte machen.

Kontinuierlich sicherer

Im Rahmen der Kollaboration von DevOps und wo Remote eher die Regel als die Ausnahme darstellt, 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 Ihnen helfen, Ihre 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 eher früher als später zu integrieren.

Ob Sie es nun „DevOps“ oder „DevSecOps“ nennen, es war schon immer ideal, Sicherheit als integralen Bestandteil des gesamten Software-Lebenszyklus‘ zu integrieren. 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 Entwicklungspipeline wirkt, können Unternehmen, die DevOps einsetzen, zu den langen Entwicklungszyklen zurückkehren, die sie ursprünglich vermeiden wollten.

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

DevOps 2.0

Zum Teil betont DevSecOps 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 Tätigkeit im Hinblick auf die 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 dies auch neue Sicherheitsschulungen für Entwickler beinhalten kann, was nicht immer ein Schwerpunkt in der traditionellen Anwendungsentwicklung war.

Wie sieht die eingebaute Sicherheit wirklich aus? Eine gute DevSecOps-Strategie besteht zunächst darin, die Risikotoleranz zu bestimmen und eine Risiko-/Nutzenanalyse 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 die Durchführung manueller Sicherheitschecks in der Pipeline zeitaufwändig 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. Unternehmen sollten einen Schritt zurücktreten und die gesamte Entwicklungs- und Betriebsumgebung berücksichtigen. Dazu gehören Source-Control-Repositories, Container-Register, Continuous Integration and Continuous Deployment (CI/CD)-Pipeline, Application Programming Interface (API)-Management, Orchestrierung und Release-Automatisierung sowie die operative Verwaltung und Überwachung. Neue Automatisierungstechnologien haben Unternehmen geholfen, agilere Entwicklungspraktiken einzuführen, und sie haben auch dazu beigetragen, neue Sicherheitsmaßnahmen voranzutreiben.

Container können z.B. gut isoliert ohne die Infrastruktur nach Schwachstellen untersucht werden und ermöglichen es somit, Angriffsvektoren direkt zuordnen zu können.

Aber die Automatisierung ist nicht das einzige in der IT-Landschaft, das sich in den letzten Jahren verändert hat: cloudbasierte Technologien wie Container und Mikroservices sind heute ein wichtiger Bestandteil der meisten DevOps-Initiativen, und die Sicherheit von DevOps muss sich anpassen, um sie zu erfüllen. Cloud-native Technologien 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
• Static Application Security Testing (SAST) = White Box Testing
  • Prüfung auf bekannte Schwachstellen
  • Integrierte Security-Scanner für Container
  • Automatisches Security-Testing innerhalb der CI-Pipeline
• Dynamic Application Security Testing (SAST) = Black Box Testing
  • Isolierung von Microservices
  • Verschlüsselung auf der Transport-Ebene
  • Monitoring
  • Prüfung auf neue Schwachstellen

Tools are not the solution

Der Tool-Einsatz 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 sehr gut zum agilen Mindset, immer besser zu werden. Warum also nicht auch bei der Sicherheit?
Es ist mit vertretbarem Aufwand möglich, im Rahmen von Continuous Delivery auch Continuous Security umzusetzen. An nahezu allen Stellen lassen sich Sicherheitsaspekte berücksichtigen. So können User-Stories für die Härtung geschrieben werden 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 ggf. auch einen oder mehrere Security-Sprints einzuplanen. Für das methodische Grundgerüst gibt es also verschiedene Punkte, die es zu beachten gilt:

• Erstellung von Security-Guidelines
• Berücksichtigung von Sicherheit im Rahmen der Erstellung von User Stories
• Codescans durchführen
• Peer-Reviews durch einen Security Champion durchführen
• Penetrationstests einplanen

Ganz essenziell wird dabei, dass im Team Security-Know-how aufgebaut wird. Zunächst gilt es, ein Problembewusstsein zu schaffen. Das Team von Holisticon hilft dabei!

Wissen ist Macht

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

• Wenig Informationen preisgeben, z.B. Versionen von Diensten wie Apache, Nginx, SSH und Anwendungen wie WordPress verschleiern
• Standard-Ports vermeiden. Wenn man beispielsweise SSH auf einem anderen Port konfiguriert, wird es für den Angreifer schon erheblicher zeitaufwändiger
• Anwendungen absichern

Diese Mittel sind aber nur der erste Schritt. Man muss auch verstehen, wie ein Hacker mit diesen Informationen umgeht, um zu verstehen, wie sinnvolle Sicherheitsmaßnahmen aussehen können. Gerade mit dem „Selbsthacken“ wird das Ganze auch noch mit sportlichem Ehrgeiz und Spaß verbunden.

Mehr dazu gibt es auf der Security Webseite.