Gerade vor dem Hintergrund von immer kürzeren Releases (Continuous Delivery und Continuous Integration) wird häufig die Sicherheit vernachlässigt. Durch die Schnelligkeit und Häufigkeit von Deployments steht besonders die IT-Sicherheit vor neuen Herausforderungen und es sind ähnlich wie bei der DevOps-Intitiative weitere Maßnahmen nötig, um die IT-Sicherheit und die Entwicklung enger zu verzahnen. Neben der klassischen Java-Architektur gilt es bei einer solchen Betrachtung auch die gerade aktuell sehr populären JavaScript-Umgebungen miteinzubeziehen. Deren Schnelllebigkeit bringt dabei eine weitere Dimension in die Betrachtung, die aber damit auch eine Chance bietet, wie im Folgenden dargestellt wird.
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. Gerade bei agil arbeitenden Teams ist es deshalb auch wichtig, verschiedene Kontrollpunkte mit automatischen Sicherheitstests zu etabilieren. Ein sinnvoller erster Schritt können statische Codeanalysen sein, die im Rahmen der Build-Pipeline ausgeführt werden. Oder aber, sinnvolle Techniken zur Verwaltung von technischen Logins wie z.B. Spring Vault zu berücksichtigen. Im Rahmen der Definition of Done (DoD) können aber auch zum Beispiel bestimmte Sicherheitsüberprüfungen berücksichtigt werden. Für Continuous Delivery gibt es verschiedene Tools, die helfen, bekannte Schwachstellen zu erkennen. Setzt man diese im Rahmen von Continuous Integration ein, erhält man einen ersten Kontrollpunkt, der sicherstellt, dass bekannte Sicherheitslücken nicht ausgenutzt werden können.
Ein interessantes Framework, das sich vor allem im Bereich DAST und IAST nutzen lässt, ist BDD-Security. Damit lassen sich Testszenerien im Behaviour-Driven-Design-Stil umsetzen. Man kann auch einzelne Module aus dem Framework nutzen. Neben statischen Analyse-Werkzeugen wie Sonar und FindBugs ist es durchaus sinnvoll, die Abhängigkeiten in umfangreichen Java-Anwendungen kontinuierlich auf bekannte Schwachstellen zu prüfen. Dabei kann OWASP-Dependency-Check Maven-Plugin helfen. Neben der klassischen Java-Architektur gilt es bei einer solchen Betrachtung aber auch, die gerade aktuell sehr populären JavaScript-Umgebungen miteinzubeziehen. Deren Schnelllebigkeit bringt dabei eine weitere Dimension in die Betrachtung. Deswegen ist es gut zu wissen, dass es mit dem Node-Security-Projekt auch im JavaScript-Bereich ein geeignetes Tool gibt. Beide Tools gleichen die jeweiligen Abhängigkeiten nach bekannten Schwachstellen ab. GitHub bietet für NSP eine direkte Integration, so dass Prüfungen auch in Pull Requests stattfinden. Außerdem bietet sich für OpenSource-Projekte CodeClimate an, das die generelle Codequalität berücksichtigt.
Im Rahmen der Internet Security Days stelle ich in meinem Talk das Ganze detailliert vor.
