Lesen Sie, worauf es bei der Zusammenarbeit zwischen Ihrem IT-Security- und Engineering-Team ankommt.
Foto: Lipik Stock Media â shutterstock.com
Security-Teams bestehen in erster Linie aus Mitarbeitern, die fĂŒr den Betrieb und die Einhaltung von Vorschriften und Richtlinien zustĂ€ndig sind. IT-Sicherheitstechnik-Teams, neudeutsch Security-Engineering-Teams, hingegen sind Konstrukteure. Sie entwickeln Dienste, automatisieren Prozesse und optimieren Bereitstellungen, um das zentrale IT-Sicherheitsteam und seine Stakeholder zu unterstĂŒtzen. Das Security-Engineering-Team bestehen in der Regel aus Software- und Infrastrukturingenieuren, Architekten und Produktmanagern.
Technische FĂ€higkeiten im Bereich IT-Sicherheitstechnik
Security Engineering ist im Wesentlichen eine technische Disziplin, so dass eines der grundlegenden Elemente dieser Rolle natĂŒrlich in der Technologie verwurzelt ist. Dies sind die wesentlichen FĂ€higkeiten, die CISOs in ihren Security-Engineering-Teams vermitteln und entwickeln sollten:
Verstehen des technischen Umfelds
Dass es von entscheidender Bedeutung ist, die technische Umgebung zu verstehen und in ihr zu arbeiten, scheint eine SelbstverstÀndlichkeit zu sein. Doch wenn ein Unternehmen beispielsweise Dienste in Kubernetes bereitstellt und das Technikteam noch nie mit Containern gearbeitet hat, ist das ein Problem. Ein hohes Maà an technischem VerstÀndnis der gesamten IT-Umgebung wirkt sich positiv auf das Security-Team aus.
Ein Kontrapunkt dazu ist die Förderung eines vielfĂ€ltigen Teams in Bezug auf die FĂ€higkeiten, Problemlösungsperspektiven und Erfahrungsstufen in den verschiedenen Bereichen eines Unternehmens. Es gibt natĂŒrlich viele Möglichkeiten, diese Vielfalt in einem Team anzustreben und zu fördern, vom Geschlecht und der ethnischen Zugehörigkeit ĂŒber den Bildungshintergrund bis hin zu frĂŒheren Berufserfahrungen und dem Alter. DiversitĂ€t kann die kreative Energie eines Teams stark erhöhen, wenn Ideen in Frage gestellt, debattiert und wiederholt werden.
Allerdings sollten FĂŒhrungskrĂ€fte mit der Vielfalt an Perspektiven und Erfahrungen sorgfĂ€ltig umgehen. Ein ĂŒbermĂ€Ăiges MaĂ an Variation und Reibung im Denk- und Kooperationsprozess kann zum Gegenteil der gewĂŒnschten Wirkung fĂŒhren. HĂ€ufig kommt es zu einer Analyse-Paralyse, bei der die Teams in einem Zustand des Nachdenkens ĂŒber das Tun statt des Tuns stecken bleiben. Ein Ă€hnlicher Zustand, der sich aus ĂŒbermĂ€Ăig unterschiedlichen Teams ergeben kann, ist eine komplexe Reihe von voneinander abhĂ€ngigen Ergebnissen, die miteinander verbundene Fehlerbedingungen aufweisen.
Den gesamten Stack beherrschen
IT-Sicherheitstechnikteams sollten in der Lage sein, die von ihnen entwickelten Dienste zu erstellen und zu betreiben. Dieses MaĂ an Eigenverantwortung innerhalb einer Gruppe ist aus Sicht der technischen Kompetenz und aus kultureller Sicht von entscheidender Bedeutung, da es den Ton in Bezug auf die Verantwortlichkeit angibt. Technisch gesehen wird ein Team, das in der Lage ist, seine Dienste selbst zu verwalten, die Infrastruktur, die CI/CD-Tools, die Security-Tools, den Anwendungscode, die Deployments und die von einem Dienst ausgehenden operativen Telemetriedaten kompetent verwalten. DarĂŒber hinaus sind die FĂ€higkeiten, die hinter der UnterstĂŒtzung durch ein Team stehen, in hohem MaĂe ĂŒbertragbar, um andere Gruppen im Unternehmen zu unterstĂŒtzen.
Das Entwicklererlebnis miteinbeziehen (DevX)
Security-Teams, die das Entwickler-Tool DevX verstehen, annehmen und optimieren, werden wahrscheinlich besser zusammenarbeiten. DarĂŒber hinaus wird ein besonderer Schwerpunkt auf der Beseitigung von Reibungsverlusten liegen. Reibung fĂŒhrt dazu, dass Dinge lĂ€nger dauern und mehr kosten, dass sich Lernzyklen verlĂ€ngern und dass Frustration auftritt. Weniger Reibung wird dazu fĂŒhren, dass die Dinge im Allgemeinen viel besser ablaufen.
Manchmal sind Reibungen aber auch notwendig und sollten gewollt sein. Ein Beispiel ist eine erzwungene CodeĂŒberprĂŒfung von kritischem Code, bevor er zusammengefĂŒhrt wird. Wenn diese Unterbrechung, ĂberprĂŒfung und ZusammenfĂŒhrung auf einer bewussten Entscheidung beruht, ist das eine gerechtfertigte, bewusste Reibung. Wenn das IT-Sicherheitsteam Reibungsverluste im Freigabeprozess von Entwicklern anstrebt, sollten diese auf spezifischen Anforderungen beruhen, zum Beispiel auf einer Compliance-Kontrolle, die eine manuelle ĂberprĂŒfung als Teil des Change Managements vorschreibt. Diese Kontrollen sollten nicht unĂŒberlegt eingesetzt werden. Die Reibungsverluste, die den Entwicklern entstehen, stellen Nachteile dar, die jedes vom IT-Sicherheitsteam in Betracht gezogene, nicht definierte Risiko aufwiegen könnten.
IT-Sicherheitsteams, die die Erfahrung der Entwickler als oberste PrioritĂ€t betrachten, mĂŒssen die Werkzeuge und AblĂ€ufe verstehen, die fĂŒr das Schreiben von QualitĂ€tssoftware auf verschiedenen Ebenen des Stacks erforderlich sind. Die Ăbernahme dieser Denkweise, bei der der Entwickler im Vordergrund steht, erfordert möglicherweise Kenntnisse im Bereich Infrastruktur oder Plattform-Engineering. Andererseits kann sich der Output eines IT-Sicherheitstechnik-Teams auf andere auswirken, die ebenfalls mit der Automatisierung von ArbeitsablĂ€ufen, der Verbindung von Diensten untereinander und im Wesentlichen mit der gemeinsamen Instrumentierung einer immer gröĂer werdenden Umgebung beschĂ€ftigt sind. All diese Arbeiten helfen den Entwicklern, schneller und mit weniger Reibungsverlusten zu arbeiten. Resultat sind mehr FlexibilitĂ€t und ein schnelleres Deployment. UnabhĂ€ngig davon ist dies eine Eigenschaft und ein Leitfaden, von dem ein Security-Engineering-Tem in seiner ProduktivitĂ€t profitiert und das EinfĂŒhlungsvermögen derer, denen es dient, fördert und kultiviert.
FĂ€higkeiten zur FĂŒhrung und Zusammenarbeit in der Sicherheitstechnik
Security-Entwickler-Teams arbeiten nicht im luftleeren Raum, unabhÀngig von ihrem Umfang und ihrer Projektauslastung. Die Arbeit an der Seite und im Dienste anderer ist ein wesentlicher Bestandteil des Auftrags. Sie ist ein notwendiger Teil des Ganzen und hilft anderen, erfolgreiche Ergebnisse zu erzielen.
Kommunizieren und zusammenarbeiten
Die Mitglieder des Security-Engineering-Teams sollten in der Lage sein, miteinander und mit den Beteiligten auĂerhalb der Gruppe zu kommunizieren. DarĂŒber hinaus sollten sie die FĂ€higkeit besitzen, gut zusammenzuarbeiten, um die gemeinsamen Ziele zu erreichen. Verstehen der Probleme, der Reibungspunkte, der BeschrĂ€nkungen und der Möglichkeiten der IT-sicherheitsorientierten Entwicklung. Letztendlich ist es wichtiger, die richtigen Dinge zu tun, als einfach nur effizient zu arbeiten.
All diese Fragen mĂŒssen durch gezielte Kommunikation und Zusammenarbeit erforscht werden. Dies kann sich in menschenzentrierten Gestaltungsprinzipien, matrixbasierten Ressourcen oder einer auf Teamtopologien basierenden Ausrichtung manifestieren. NatĂŒrlich gibt es kein Patentrezept fĂŒr die Kommunikation und Zusammenarbeit in und zwischen Teams. UnabhĂ€ngig von der Herangehensweise sind Vertrauensbildung, EinfĂŒhlungsvermögen, Interesse an gemeinsamen Zielen und die Bereitschaft, den eigenen Stolz zugunsten der Mission zurĂŒckzustellen, die Grundlage.
FĂŒhren und andere beeinflussen
Seth Godin, Bestsellerautor und Marketingexperte, vertritt die Ansicht, dass jeder eine FĂŒhrungspersönlichkeit sein kann â es ist eine Entscheidung, kein Titel. Es geht um das Zusammentreffen von Ideen, eine LĂŒcke in der Richtung und jemanden, der motiviert genug ist, sich zu engagieren.
Der Erfolg von Security-Engineering-Teams ist, wie bei anderen Cybersecurity-Bereichen auch, von anderen abhĂ€ngig. Er ist jedoch unabhĂ€ngig von der Leistung des Teams, so optimal diese auch sein mag. Anders ausgedrĂŒckt: Man kann nicht einfach etwas bauen und dann gehen. Sie mĂŒssen anderen zuhören, sie einbeziehen, sie zur Ăbernahme bewegen und vieles mehr.
All das erfordert FĂŒhrung. Genauer gesagt, FĂŒhrung ohne AutoritĂ€t. Die Mitglieder eines leistungsstarken Teams sollten in der Lage sein, das IT-Sicherheitstechnikteam selbst zu leiten und auĂerhalb der Gruppe Einfluss aufzubauen und zu nutzen. Das kann mit anderen Beteiligten oder mit internen Kunden eines Dienstes geschehen. FĂŒhren ohne AutoritĂ€t bringt das Team dem Erfolg nĂ€her. Starke Beziehungen, organisatorisches Wissen und Kontext sowie technisches Fachwissen sollte zusammengebracht werden, um andere zu beeinflussen.
Soft Skills fĂŒr Sicherheitsingenieure
Die FĂ€higkeiten eines Security Engineers und des gesamten Teams sollten ĂŒber Kommunikation und Zusammenarbeit hinausgehen. In diesem Zusammenhang bezieht sich der Begriff âSoft Skillsâ auf die zahlreichen nichttechnischen FĂ€higkeiten, die eher nach innen gerichtet sind und die technischen FĂ€higkeiten ergĂ€nzen.
Zeit- und PrioritÀtenmanagement
Security-Entwickler werden immer viel zu tun haben. Die technischen FĂ€higkeiten fĂŒhren dazu, dass hĂ€ufig Anfragen zum Erstellen, HĂ€rten, Patchen oder allgemein zum Einmischen in die Software einer Umgebung eingehen werden. Zeit ist eine universelle EinschrĂ€nkung fĂŒr alle Teams. Aus diesem Grund mĂŒssen sowohl Einzelpersonen als auch Teams effektiver darin werden, PrioritĂ€ten zu setzen. Effizient zu sein, aber die falschen Dinge zu tun, bringt keinen Fortschritt. Es gibt viele Techniken, um Arbeit zu priorisieren, Wert gegen KomplexitĂ€t abzuwĂ€gen und sich auf die Kundenzufriedenheit zu konzentrieren oder verschiedene Faktoren zu gewichten. Kunden- und Compliance-Anforderungen sind oft die treibende Kraft hinter den PrioritĂ€ten des Teams. Die Art der PrioritĂ€tensetzung ist weniger wichtig als die rĂŒcksichtslose Einhaltung der PrioritĂ€ten und der Schutz vor dem endlosen Ansturm von Anfragen, die mehr wertvolle Zeit in Anspruch nehmen.
AnpassungsfÀhigkeit
Security-Engineering-Teams sollten in der Lage sein, sich an verĂ€nderte Anforderungen, Technologien und UmstĂ€nde anzupassen. AnpassungsfĂ€higkeit bedeutet mehr als die Priorisierung einer Aufgabe gegenĂŒber einer anderen: Entscheiden ist die Anpassung der Herangehensweise an ein Problem auf der Grundlage der BedĂŒrfnisse der Beteiligten. IT-Sicherheitstechnikteams mĂŒssen sich an die Eigenverantwortung auf der Grundlage des Teamwachstums und der sich Ă€ndernden BedĂŒrfnisse der Interessengruppen sowie an die bewusste Einbeziehung einer vielfĂ€ltigen Gruppe von Stimmen in den Problemlösungsprozess anpassen. Der Nutzen fĂŒr die Beteiligten und die gesamte IT-Sicherheitsorganisation liegt dabei in der AgilitĂ€t und FlexibilitĂ€t. Ein agiles Team ist ein widerstandsfĂ€higeres Team.
Kontinuierliches Lernen
Ein Team, das in der Lage ist, stÀndig neue FÀhigkeiten, organisatorische ZusammenhÀnge, Richtlinien und Arbeitsweisen zu erlernen, ist in der heutigen schnelllebigen Welt unbedingt notwendig. So sollten sich Mitglieder des Security Engineering-Teams stÀndig weiterentwickeln, sich selbst erneuern und auf bestehenden mentalen Modellen und Erfahrungen aufbauen. Dieses Konstrukt mentaler Modelle ermöglicht es Menschen, in Situationen einzutreten, die Àhnliche Eigenschaften aufweisen wie etwas, an dem sie zuvor gearbeitet haben, und damit zu beginnen, etwas beizutragen, zu erforschen und zu tun.
Kontinuierliches Lernen kann sich auch auf die Kultur in einer Organisation auswirken. Wissen fĂŒhrt zum Austausch, Austausch fĂŒhrt zu Diskussionen und die Diskussion ĂŒber neue Dinge weckt Interesse und GesprĂ€che. Diese kollektive Entwicklung der mentalen Modelle, die das Unternehmen durchdringen, und der Art und Weise, wie Teams mit IT-Sicherheit umgehen und sich darauf beziehen, bringt die Kultur der Zusammenarbeit voran.
Die Arbeit in diesem hoch spezialisierten Bereich bedeutet nicht, dass sich ein leistungsstarkes Team nur auf die Technologie konzentrieren kann. Menschen, die Erforschung von Problemen, der Aufbau von Beziehungen und die Festlegung von PrioritÀten sind allesamt wesentliche Bestandteile eines leistungsstarken Sicherheitstechnikteams. Achten Sie beim Aufbau Ihres Teams darauf, diese Elemente zu investieren und zu pflegen. (jm)
Lesetipp: Fehlendes Knowhow â eine Gefahr fĂŒr die Anwendungssicherheit
Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation CSO Online.

