Doppelte Absicherung Iterative Software-Entwicklung weiter stärken

Neue Software-Versionen werden dank iterativer Entwicklung in kürzeren Abständen bereitgestellt und Bugs so schneller beseitigt. Doch wenn neue Releases und Patches seltener installiert werden können oder sollen, hilft das nur wenig. Das Problem muss an der Wurzel gepackt werden, nämlich im Entwicklungsprozess.

Anbieter zum Thema

SonicWall Germany

sysob IT-Distribution GmbH & Co. KG

Arvato Systems

Perforce Software UK Ltd.

Software schnell auf den Markt bringen und Änderungen in kurzfristigen Zyklen implementieren zu können, ist für viele Anwendungsentwickler heutzutage essentiell. In nahezu allen Branchen stellen Unternehmen ihre Lösungen in immer kürzeren Abständen bereit, Kundennutzen und Bedienkomfort stehen im Vordergrund.

Ob man dies nun „Continuous Delivery“ nennt, „Continuous Deployment“ oder „iterative Entwicklung“ – dieser Bereitstellungsansatz verändert das Wesen der Softwarebranche rasant und beeinflusst zunehmend unseren (Arbeits-)Alltag. Stellen wir uns nur einmal die Menge an Softwareupdates vor, die ein Online-Händler wie Amazon haben muss.

Vermutlich sind die meisten von uns auch im Privatleben mit einer steigenden Anzahl an Updates konfrontiert. Nicht selten werden diese mittlerweile sogar täglich für unsere Desktop-PCs, Laptops, Tablets oder Smartphones zur Verfügung gestellt.

Kleiner Bug, große Wirkung

Ein revolutionärer Ansatz zur Softwareentwicklung bringt allerdings auch seine Herausforderungen mit sich. Zunächst einmal beschränkt ein enger Veröffentlichungstakt mit kleinen Updates den Wirkungsradius der Änderungen potenziell – denn in der Theorie sind die Bugs „kleiner“ und leichter zu entdecken.

Falls aber ein Bug oder eine Sicherheitslücke in ein Release aufgenommen wird, kann der Fehler potenziell an hunderte oder tausende Server verteilt werden. Bevor der Fehler auffällt, sind wie im Falle von „Heartbleed“ mitunter schon zahlreiche Server und Millionen von Anwendern betroffen.

Natürlich ermöglicht Continuous Deployment aufgrund seiner agilen Natur wiederum rasche Korrekturen: Wie sich bei „Heartbleed“ gezeigt hat, waren die Hersteller recht schnell in der Lage, OpenSSH-Fixes zur Verfügung stellen. Das ändert aber nichts an der Tatsache, dass die Anfälligkeit faktisch in Umlauf gewesen ist – und so das Vertrauen der Anwender stark erschüttert sowie Software-Herstellern viel zusätzliche Arbeit beschert hat.

Neue Entwicklungsprozesse erfordern ein Umdenken

Die vielen prominenten Sicherheitsvorfälle im vergangenen Jahr machen deutlich, dass dieses Problem noch weit von seiner Lösung entfernt ist. Wenn iterative Entwicklung die Methode der Zukunft ist, wie können wir dann verhindern, dass solche Probleme auftreten?

Natürlich wird jedes vorausschauende Unternehmen ein ganzes Arsenal an speziellen Tools für Informationssicherheit im Einsatz haben. Doch gerade traditionelle Ansätze passen nicht unbedingt am besten zu den modernen Entwicklungsmethoden von heute: Zu dem Zeitpunkt, an dem ein vollständiger System-Scan abgeschlossen ist, richtet der Bug unter Umständen bereits im Produktivbetrieb Schaden an.

Konventionelle Sicherheitsstrategien, die darauf abzielen, Mauern zu errichten, werden den Continuous-Delivery-Prozess behindern und die Entwickler frustrieren. Aus diesem Grund bedarf es eines eher holistischen Ansatzes, der das große Ganze im Blick hat und einen sorgfältigeren, strengeren Umgang mit internen Prozessen erforderlich macht.

Denn selbstverständlich gilt: Je früher eine potentielle Schwachstelle entdeckt wird, desto besser stehen die Chancen, dass ihre Auswirkungen minimiert und die daraus entstehenden Kosten so gering wie möglich gehalten werden können. Mit folgenden fünf „Best Practices“ lässt sich dieser Prozess optimieren:

1. Für eine lückenlose Beweiskette sorgen

Sollte ein Problem auftreten, muss nachvollziehbar sein, was genau im Release beinhaltet war – nicht nur in Bezug auf den Quellcode, sondern auch auf ausführbare Dateien und Images der virtualisierten Maschinen („Infrastructure as Code“). Denn nur so können die möglichen Auswirkungen eingeschätzt werden.

Es gilt deshalb, einen einzigen, zentralen Referenzbestand („Single Source of Truth“) durch die Verwendung eines Versionsmanagement-Tools sicherzustellen. Dies erlaubt es Entwicklern, jederzeit auf einen Blick zu sehen, was aktuell im Entwicklungsprozess geschieht und in der Vergangenheit geschehen ist (Wer hat was, wann und wo geändert?). Zudem ist es damit möglich, im Notfall ein Rollback auf eine frühere Version durchzuführen.

2. So viel wie möglich automatisieren

Durch Automatisierung von Prozessen, die für kontinuierliche Integration, Tests und Bereitstellung notwendig sind, kann die Dauer bis zur Marktreife des Produkts verkürzt werden, die Fertigstellung wird planbarer. Zudem reduzieren automatisierte Prozesse die Wahrscheinlichkeit menschlicher Fehler, und damit die Entstehung von Sicherheitslücken.

Die Automatisierung komplexer Build- und Testsysteme – etwa Applikationen mit vielen unterschiedlichen Content-Arten oder Projekte, an denen mehrere weltweit verteilte Teams mitarbeiten – macht ein gemeinsames Repository unerlässlich, um Duplizierungen oder Lücken im Validierungsprozess zu vermeiden. Natürlich lässt sich nicht jeder Prozess automatisieren – erstaunlich viele allerdings sehr wohl.

3. Kontinuierliches Monitoring sicherstellen

Das klassische Modell, jährliche Assessments sowie regelmäßige, aber nicht unbedingt gleichbleibende Sicherheitsscans durchzuführen, kann die modernen Umgebungen von heute schlichtweg nicht mehr schützen. Die hohe Änderungsfrequenz macht Berichte, die erst von wenigen Tagen erstellt wurden, bereits hinfällig. Aus diesem Grund muss kontinuierlich an der Überwachung der Sicherheit gearbeitet werden – und das mithilfe von Prozessen und Tools, die auftretende Probleme unmittelbar ans Licht bringen.

4. Die echten Gefahren erkennen

Wie bereits zahlreiche Studien herausgefunden haben, werden viele Sicherheitslücken von Mitarbeitern verursacht – sowohl aus Versehen als auch absichtlich. Selbstverständlich ist es unerlässlich, solche Risikoquellen zu identifizieren.

Doch Unternehmen laufen leicht Gefahr, Tools zu implementieren, die eine überwältigende Vielzahl an potenziellen Schwachstellen melden, ohne eine Einschätzung liefern zu können, welche davon eine wirkliche Bedrohung darstellen. Die neueste Generation von Tools zur Verhaltensanalyse („Behavioral Analytics“) sucht hingegen „intelligent“ nach Verhaltensänderungen.

Ein Beispiel: Ein Softwareentwickler checkt eine große Codemenge aus, aber nicht dieselbe Menge wieder ein. Dazu ist er außerhalb seiner gewohnten Arbeitszeiten aktiv. Beides für sich genommen mag verdächtig sein, unter Umständen aber eine harmlose Erklärung besitzen. Das gemeinsame Auftreten der beiden Ereignisse jedoch ist der entscheidende Aspekt, der das Risiko dieser Aktion überdurchschnittlich erhöht.

5. Geeignete Tools für moderne Umgebungen wählen

Unternehmen sollten nach Tools Ausschau halten, die wirklich auf die zunehmend komplexen, verteilten und mehrdimensionalen Umgebungen der heutigen Zeit ausgelegt sind und mit ihnen umgehen können. Zudem müssen die Lösungen in der Lage sein, je nach Bedarf zu skalieren, und eine Vielzahl an unterschiedlichen Betriebsumgebungen und Bereitstellungsarten unterstützen – inklusive On-Premise und in der Cloud.

Doppelt auf Nummer sicher gehen

Den Grundstein für gute Software legt bereits das Entwicklerteam. Aus diesem Grund ist es unerlässlich, Best-Practice-Ansätze wie diese umzusetzen, um eine „saubere“ Sicherheitskultur über Prozesse und Tools hinweg zu etablieren.

Auch wenn die Sicherheitssoftware selbst natürlich eine entscheidende Rolle spielt, müssen Unternehmen vor dem Hintergrund moderner Entwicklungsmethoden wie Continuous Delivery doppelt auf Nummer sicher gehen: Nur so können sie sicherstellen, dass ihre einzigartigen Innovationen nicht durch Sicherheitslücken untergraben werden, die letztendlich vermeidbar gewesen wären.

* Mark Warren ist European Marketing Director bei Perforce Software.

(ID:43377549)