Im Laufe seiner Karriere als Cybersicherheitsingenieur musste Matthew Rosenquist so manche Enttäuschung hinnehmen. Da war der Vorstandsvorsitzende, der sein eigenes Team entließ, nachdem es ihm Schwachstellen im Hauptprodukt des Unternehmens aufgezeigt hatte. Es gab Softwareentwickler, denen es an Erfahrung im Bereich Sicherheit mangelte, die aber kein Interesse daran hatten, sich diese anzueignen.
„In ihren Augen waren sie brillante Programmierer, und das reichte ihnen“, sagt Rosenquist. „Sie sagten: ‚Das ist nicht mein Problem.‘“ „Ich programmiere es einfach so, dass es funktioniert, und der Rest ist das Problem eines Sicherheitsbeauftragten.“
Diese ablehnende Haltung ist nachvollziehbar. Softwareentwickler bewegen sich in einer Welt des iterativen Designs, schneller Veröffentlichungen und des „Minimum Viable Product“. Aus Zeitgründen und um sich auf den Code zu konzentrieren, kümmern sie sich um kaum etwas anderes, auch nicht um die Sicherheit. Sie empfinden dies oft als Belastung für den Zeitplan oder sogar für das Produkt selbst.
„Wenn Sie Entwickler oder Ingenieur sind, ist dies Ihr Herzensprojekt“, sagt Rosenquist, ein Cybersicherheitsstratege und Vorstandsberater, der 23 Jahre bei Intel tätig war und derzeit als CISO bei Eclipz.io, einem Unternehmen für Softwareverschlüsselung, tätig ist. „Sie haben Termine einzuhalten. Sie werden danach beurteilt, wie gut es Ihnen gelingt, Ihren Code termingerecht zum Laufen zu bringen. Nun stellen Sie sich einen Cybersicherheitsexperten vor, der Ihr Produkt nicht kennt. „Sie möchten, dass ich X, Y und Z erledige?“ „Das wird meinen Zeitplan durcheinanderbringen.“ Diese Reibung nimmt zu. „Das Einzige, was noch schlimmer ist, ist, überhaupt keine Sicherheitsmaßnahmen zu ergreifen.“
Die Kluft überbrücken
Die von Rosenquist beschriebene Reibung ist nichts Neues. Dies ist aus einer seit Langem bestehenden Kluft zwischen DevOps- und Sicherheitsteams innerhalb des Unternehmens entstanden und wurde durch die Herausforderungen einer globalen Gesundheitskrise noch verschärft. Da Millionen von Remote-Mitarbeitern über mehrere zehn Millionen Endgeräte – darunter Laptops, PCs und Tablets – auf sensible Datensysteme zugreifen, haben Sicherheitslücken und Sicherheitsvorfälle sprunghaft zugenommen. Laut einer von Tanium im Jahr 2020 veröffentlichten Umfrage entstehen nordamerikanischen Unternehmen durch IT-Ausfälle jährlich Verluste in Höhe von 700 Milliarden US-Dollar. Die Uneinigkeit zwischen den Teams ist nicht gerade hilfreich.
Doch zusammenarbeiten müssen sie. Ein sich entwickelnder Ansatz namens DevSecOps zielt beispielsweise darauf ab, Brücken zwischen den rivalisierenden Bereichen zu schlagen, indem Mitglieder und Prozesse des Sicherheitsteams in den Lebenszyklus der Softwareentwicklung integriert werden, um Schwachstellen frühzeitig zu erkennen. Dennoch beeinträchtigen tiefgreifende kulturelle Probleme, ein weltweiter Fachkräftemangel im Bereich Sicherheit sowie organisatorische Strukturen nach wie vor die Harmonie zwischen den Teams. Während IT-Führungskräfte nach Wegen suchen, diese Hürden zu überwinden, haben sich mehrere bewährte Vorgehensweisen herauskristallisiert, angefangen bei einer deutlicheren Unterstützung auf Führungsebene bis hin zur Entwicklung einer Kultur der Zusammenarbeit. So fangen Sie an:
Den Ton von oben vorgeben
Nachdem Microsoft im Jahr 2001 von zwei schwerwiegenden Würmern heimgesucht worden war, versandte Bill Gates im folgenden Jahr ein Memo mit dem Titel „ “ an das gesamte Unternehmen und kündigte an, dass Sicherheit zu einem festen Bestandteil der Programmierung aller Produkte werden solle: „Wenn wir vor der Wahl stehen, entweder neue Funktionen hinzuzufügen oder Sicherheitsprobleme zu beheben“, schrieb Gates, „müssen wir uns für die Sicherheit entscheiden.“ … Wir sind gerade dabei, alle unsere Entwickler in den neuesten Techniken der sicheren Programmierung zu schulen. ... „Unsere Software sollte so grundlegend sicher sein, dass sich die Kunden darüber überhaupt keine Gedanken machen müssen.“
Das Ergebnis war der bahnbrechende und vielfach kopierte „-Sicherheitsentwicklungszyklus“ des Unternehmens – eine Reihe von Vorgehensweisen, mit denen Sicherheit bereits während der Entwicklung und Reifung des Produkts integriert wird. Unternehmen aus der gesamten Technologiebranche haben diese Sicherheitsmaßnahmen inzwischen übernommen – und angepasst.
Die Erkenntnis: Die Einbindung zusätzlicher Sicherheitsmaßnahmen in den Produktentwicklungszyklus kann sich durchaus auf die Zeitpläne auswirken. Und wenn die Führungskräfte dem keine Priorität einräumen, wird es auf den unteren Ebenen der Hierarchie wesentlich schwieriger sein, dies durchzusetzen. „Von ganz oben muss man ein Geschäftsverständnis entwickeln, das mit den Unternehmenszielen im Einklang steht“, sagt Rosenquist.
“„Von der obersten Führungsebene aus müssen Sie ein Geschäftsverständnis entwickeln, das mit den Unternehmenszielen im Einklang steht.“Matthew Rosenquist, CISO bei Eclipz.io Inc.
David Hahn hat dies aus erster Hand miterlebt. Als CISO, der im Bereich Cybersicherheit unter anderem bei der Silicon Valley Bank, dem Medienkonzern Hearst und Intuit tätig war, ist es ihm gelungen, eine erfolgreiche Zusammenarbeit mit IT-Führungskräften aufzubauen, indem er ihnen klargemacht hat, dass Cybersicherheit einen festen Platz am Tisch haben muss, und ihren Teams die Bedeutung verschiedener Kompetenzbereiche vermittelt hat, die letztendlich zusammenwirken müssen. „Man kann nicht erst später dazukommen und dann die Rolle des Bösewichts übernehmen“, sagt er.
Verlagerung der Verantwortlichkeit
Eine Möglichkeit, diese Kluft zu überbrücken, besteht darin, die Sicherheit stärker in den Entwicklungsprozess zu integrieren. Laut einer Studie von EY beziehen heute fast zwei Drittel der Unternehmen ihre Sicherheitsteams nicht bereits in frühen Phasen von IT-Projekten mit ein.
Experten zufolge besteht eine Möglichkeit, diese Lücke zu schließen, darin, den Ansatz „Shift-Left-“ bei der Softwaretestung anzuwenden – das heißt, den Tests bereits in einer viel früheren Phase des Entwicklungszyklus Vorrang einzuräumen, anstatt sie erst nachträglich anzuhängen. Zudem fördert dies – wenn nicht sogar erfordert – eine stärkere Zusammenarbeit zwischen Sicherheitsteams und Entwicklern.
Solche Vorgehensweisen tragen dazu bei, alte Silos aufzubrechen. „Es geht darum, eine neue Mannschaft aufzubauen“, sagt Hahn. „Jeder sollte sich Kenntnisse in den Bereichen Entwicklung, Sicherheit und Betrieb aneignen, doch manche verfügen in einem dieser Bereiche über mehr Erfahrung als andere.“
Eine Möglichkeit, sie dorthin zu bringen, ist die Schulung. Softwareentwicklern Sicherheitskompetenzen zu vermitteln, sei „eine Wachstumschance“, so Hahn. Ebenso würden viele Sicherheitsanalysten davon profitieren, wenn sie sich grundlegende Programmierkenntnisse aneignen würden. „Sie können mit einer Programmiersprache wie Go oder Python beginnen, um die prozedurale Programmierung und die Feinheiten der Softwareentwicklung zu verstehen“, sagt Ax Sharma, Sicherheitsforscher und Ingenieur beim britischen Softwareentwickler Sonatype. „Dies wird dazu beitragen, die Skepsis hinsichtlich der Fähigkeit der Sicherheitsabteilung, an den Teamergebnissen mitzuwirken, abzubauen.“
DevSecOps: Neue Denkansätze für Sicherheit und Entwicklung
Sollten Sicherheits- und Softwareentwicklungsteams in den kommenden Jahren zu einer neuen Art der Zusammenarbeit finden, so wird dies zum Teil darauf zurückzuführen sein, dass sie eine Arbeitsweise übernommen haben, die sich bei der Überwindung einer anderen langjährigen Kluft im Unternehmenskontext – nämlich zwischen Softwareentwicklern und IT-Betriebsteams – als äußerst erfolgreich erwiesen hat. In den letzten rund zehn Jahren haben Entwickler wesentlich enger mit dem IT-Betrieb zusammengearbeitet, um beide Bereiche zu integrieren und neue Software schneller und effizienter als je zuvor auf den Markt zu bringen.
Es handelt sich um eine Methodik namens DevOps, die laut GitLab mittlerweile in irgendeiner Form von schätzungsweise 62 % der Unternehmensorganisationen angewendet wird. DevSecOps baut auf demselben Konzept auf und integriert Sicherheitstests bereits während der Entwicklung in den Prozess, nicht erst im Nachhinein.
DevSecOps bindet Sicherheitsteams nicht nur früher in den Prozess ein, sondern ermöglicht es der gesamten Gruppe, die Risikotoleranz zu erörtern. Für Softwareentwickler, die befürchten, dass ihre Kollegen aus dem Bereich Cybersicherheit die Entwicklung verlangsamen könnten, gibt es laut Hahn eine Möglichkeit, alle auf einen gemeinsamen Nenner zu bringen und die Code-Entwicklung voranzutreiben: Erläutern Sie ihnen, was passiert, wenn Schwachstellen nicht frühzeitig erkannt werden. „Führen Sie ein Bedrohungsmodell ein“, sagt er. „Wenn man anfängt, es zu skizzieren, wird es zu etwas Greifbarem. „Es wird zu einer fachlichen Diskussion, anstatt zu einer Äußerung wie: ‚Davids Meinung war nicht besonders gut, das gefällt mir nicht.‘“
Ein Bedrohungsmodell bietet beiden Seiten die Möglichkeit, nach Kompromissen zu suchen. So sind Softwareentwickler beispielsweise bestrebt, ein MVP oder eine Beta-Version eines neuen Produkts zu erstellen, die eine vollständige Datenbank mit firmeneigenen Datensätzen enthält. Die Sicherheitsabteilung möchte nicht, dass diese Datenbank in irgendeiner Weise mit dem Produkt in Berührung kommt, bis eine vollständige Prüfung auf Sicherheitslücken abgeschlossen ist. Ein Bedrohungsmodell könnte auf die Risiken hinweisen, die mit der Bereitstellung sensibler Daten in einem unfertigen Produkt verbunden sind.
Und dann ist es an dem Sicherheitsteam, sich zu Wort zu melden. „Sie müssen sagen: ‚Wir müssen dieses Risiko nicht eingehen.‘ „Wir könnten Scheindaten einfügen“, sagt Hahn. Der EY-Bericht kommt ebenfalls zu dem Ergebnis, dass Sicherheitsteams solche Risiken besser kommunizieren könnten.
Um beide Seiten zusammenzubringen, schlägt Sharma vor, mit kleineren Maßnahmen zu beginnen, wie beispielsweise der Überprüfung des Zustands der Sicherheitsprozesse und der Bedrohungsstufen bei allen Produkten. Dadurch wird ein Bewusstsein dafür geschaffen, wo Schwachstellen entstehen. Anschließend können die beiden Teams Sicherheitsautomatisierungstools von – wie beispielsweise Software zur Malware-Erkennung – einsetzen, um verbleibende Schwachstellen aufzuspüren. „Betrachten Sie den ersten Monat Ihrer Bemühungen als Beobachtungsphase, damit die Teams die Auswirkungen erkennen, zusammenarbeiten und durch iterative Anpassungen Verschwendung beseitigen können“, sagt Sharma.
Wenn die Dinge aus dem Ruder laufen
Manchmal klappt es einfach. In anderen Fällen tun sie dies jedoch nicht. Wenn die beiden Seiten nicht zusammenarbeiten, sollten Sie nach zwei Ursachen suchen, so Hahn: eine schleichende Ausweitung des Projektumfangs, die den Zeitplan und den Ablauf eines Projekts aus der Bahn wirft, sowie Ego. „So wie Menschen, die sich nicht an die Grundsätze halten, auf die sie sich geeinigt hatten“, sagt er.
An diesem Punkt ist es an der Zeit, die Entwicklung zu unterbrechen, auch wenn dies bedeutet, dass Sie Ihren Veröffentlichungstermin verschieben müssen. „Es ist besser, eine Sicherheitslücke aufzudecken, die ein Projekt um zwei Monate zurückwirft“, so Hahn, „als nach der öffentlichen Einführung mit einer potenziellen Katastrophe konfrontiert zu werden.“
„Es wird immer Kosten geben“, sagt Rosenquist, der CISO bei Eclipz.io. „Aber Sie beugen Verlusten vor oder stellen sicher, dass Sie die gesetzlichen Vorschriften einhalten.“ Die Zusammenführung Ihrer Sicherheits- und IT-Teams, fügt er hinzu, sei nicht nur für die Mitarbeiter von Vorteil. „Dies kann einen Wettbewerbsvorteil darstellen.“
