Tätigkeitsbeschreibung

Enterprise Security Architect / TISO was ist das und was sind die Aufgaben?


Von Recruitern/Vermittlern erhalte ich regelmäßig Anfragen zu Projekten, in denen irgendwo das Stichwort „Security“, „Security Consultant“, „Architekt/Architect“, oder „Architektur/Architecture“ auftaucht.
Die Anfragen umfassen dann sämtliche Varianten von „Architect“, „Security Architect“ über den „Solutions Architect in Security“ bis hin zum „Enterprise Security Architect“. Häufig auch eher unspezifische Anfragen als „Security Analyst“, „Security Administrator“ oder eben einfach nur „Security Spezialist“.
Bei so vielen Titeln und verschiedenen Kulturen, die eine passende Ressource anfragen, werden die Titel in vielen Fällen leider synonym verwendet, auch wenn sie dies keinesfalls sind.
Meine Positionen heißen (zumindest in großen Organisationen) typischerweise "Security Architect" oder explizit "Enterprise Security Architect" bzw. im Bereich Security Management „Technical Information Security Officer (TISO)“ oder „Senior Information Security Consultant/Manager/Advisor“.
TISO (Technical Information Security Officer)

Als TISO (Technical Information Security Officer) agiere ich hauptsächlich als Manager und technisch orientierter Ansprechpartner z.B. eines CISO (Chief Information Security Officer) oder des Programm- bzw. Projektleiters.

Dabei kümmere mich um:
• Information Security Management
• Sicherheitsbeurteilung von Konzepten und Beratung zu Infrastruktur,
• Design/Implementierung (keine Administration oder Betrieb!)
• InfoSec Management (ISMS) & GRC (Governance, Risk, Compliance) Beratung
• Anforderungsbestimmung und Analyse
• Bewertung von Sicherheitsrichtlinien, Strategien zur Sicherheitsüberwachung
• (Monitoring) und Auditierung (keine Mandate als reiner Auditor!)
• Mentoring von Nachwuchstalenten im Bereich Information Security (Advisory)

Ähnlich einem CISO (Chief Information Security Officer), allerdings mehr auf der technischen Seite. Als Externer bin ich auch weitaus weniger im internen politischen Umfeld unterwegs.

Enterprise Security Architect (E.S.A)


Als Enterprise Security Architect (E.S.A) bin ich für die Weiterentwicklung von Risiko-, Sicherheits- und Compliance-Maßnahmen, -Fähigkeiten und -Lösungen verantwortlich. Es wird von mir erwartet, dass mein Wissen sehr breit angelegt ist.
In die Tiefe gehe ich dann bei der konzeptionellen oder logischen Ebene – dies jedoch nicht mehr notwendigerweise auf einer physischen Ebene.
Typische Blöcke eines E.S.A Mandats in der Organisation
1.) Direction = Richtung der Enterprise Security Architektur erarbeiten und vorgeben
2.) Enablement = Die Organisation zur Veränderung befähigen
3.) Execution = Die geplante Architektur umsetzen

WICHTIG
Ein Enterprise Security Architect ist für Direction und das Enablement verantwortlich. Er ist hingegen NICHT für die Execution zuständig !

Gerade dieser ganz wesentliche Punkt führt immer wieder zu Missverständnissen oder trifft nicht die Erwartung der Kunden. Sehr oft suchen diese eigentlich einen Administrator oder Engineer. Architekturentscheidungen sind oft schon längst gefallen - ob sie wirklich zum Business passen und es unterstützen, oder eher nicht und eigentlich nur ein scheinbar unausweichliches Übel darstellen, das man eben irgendwie managen muss. In dieser Situation wäre das Hauptpotential meines Engagements bereits mehr oder weniger verschenkt worden.

Wie beim Hausbau, sollte der Architekt recht weit vorne im Prozess eingebunden sein. Er muss wissen welche Bausteine und Materialien wie zusammen gehören. Er behält den Überblick, spricht fundierte Empfehlungen für den Bauherrn/die Baufrau in ihrem Interesse aus, überwacht und kontrolliert den Baufortschritt und ist schließlich der kreative Kopf hinter einem Bauvorhaben.

Bildlich gesprochen rührt er also nicht den Mörtel für die Mauern selbst an, sondern vertraut auf das Können entsprechender Handwerker. Er hält die Fäden zusammen.
Idealerweise hat er aber selbst eine solide handwerkliche Ausbildung genossen und praktische Erfahrung in einem oder mehreren der überwachten Gewerke gesammelt.

Genauso verhält es sich bei meiner Arbeit als TISO oder Security Architect.
Ich hantiere also inzwischen weder mit Kabeln, Routern oder Switches, noch sitze ich an der Konsole und administriere irgendwelche Komponenten.
Bitte gehen Sie also nicht davon aus, dass ich noch selbst Skripte schreibe, die PKI administriere und Zertifikate ausstelle oder Dropping Regeln auf Edge Firewalls erstelle.
Gehen Sie hingegen fest davon aus, dass ich die Ausführung durch entsprechende KollegInnen sehr wohl in die Tiefe hinein zu beurteilen vermag, da ich solche Tätigkeiten selbst viele Jahre durchgeführt und entsprechende Teams fachlich geleitet habe.

Direction


Kontext herstellen
Mein erster Part ist, erst einmal völlig unabhängig von Herstellern oder eventuell schon in Betracht gezogener Losungen, die "Pain Points" mit dem Kunden zu beleuchten, also zu fragen "wo tut es Ihrer Meinung nach weh, wo sehen Sie Handlungsbedarf?"
Grobkonzept Architektur
Wenn die eigentlichen Ursachen/Wünsche erkannt und kodifiziert wurden, entwerfe ich die ganz grobe High Level Architektur. Verschiedene Gesprächspartner, verschiedene (Teil)Informationen. Immer aber möglichst grafisch und hoffentlich für die jeweilige Zielgruppe verständlich.
Definition logische Architektur
Hier beginnt der wirklich spannende Part nämlich sich mit den Solution Architects, Engineers, Administratoren oder Security Analysts regelmäßig auszutauschen.
In diesem intensiven Austausch wird das von mir definierte Gerüst mit den entsprechenden Steinen ausgefüllt - Wir brauchen z.B. weitere Firewalls, eine stringente Netzsegmentierung, mehr Automatisierung, ein verbessertes SIEM...

Definition Physische Architektur
Wir wissen also was wir machen wollen. Jetzt definieren wir gemeinsam das Wie, das Wo und auf welcher technischen Basis.

Enablement


Auswahl der Komponenten/Dienstleister
Jetzt gibt es Vendor Hearings, Testinstallationen, Bewertungen, Shortlists,... Viel Kommunikation/Reviews mit dem PMO für die Aufbereitung von Entscheidungsvorlagen für das Management.

Service Architektur
Hier beginnt dann der regelmäßige Austausch mit den Kollegen aus dem Tagesgeschäft. Ihre operationelle Kenntnis ist unverzichtbar und hilft die Sicht aus dem Lehrbuch an das reale Geschehen anzupassen und sie für Änderungen oder Umbrüche zu gewinnen, damit sie diese vollumfänglich mittragen können.
Ich agiere dann oft als zentraler fachlicher Ansprechpartner.
Die Engineers oder Solution Architects kommen dann i.d.R. von einem Hersteller oder Dienstleister, seltener sind es ebenfalls Freelancer Kollegen, die dann auch wieder bei mir fachlich und beim Projektleiter organisatorisch zusammenlaufen.
Der Projektleiter liefert die wöchentlichen Projektfortschritte an das Senior Management des Kunden, ich liefere dem Projektmanager, in fachlicher Abstimmung mit den Solution Architects und Engineers, die realistischen Einschätzungen zu den Meilensteinen in seinem Projekt- oder Sprint Plan.

Übergang Execution

Übergabe Tagesgeschäft
Das Konstrukt steht und funktioniert. Hier habe ich dann meinen Auftrag erfüllt. Es wird nun in den „BAU (business as usual) Modus“ übergeben. 

Die richtige Positionierung

Ich weise verschiedenen Architektenteams spezifische Fähigkeiten und Domänen zu und nehme den aktuellen Zustand, den Übergangszustand und den Zielzustand der Sicherheitsarchitektur auf. Es kommt auch durchaus vor, dass ich mit einem CIO Strategiegespräche führe.
Von mir kann erwartet werden, dass ich Branchentrends und die Bedrohungslandschaft proaktiv erkenne und ebenso proaktiv die Richtung vorgebe und anwende.
Von mir wird erwartet, dass ich, gemeinsam mit den internen KollegInnen, architektonische Artefakte erstelle.
Die eigentliche Verantwortung eines Enterprise Security Architects bzw. TISO liegt jedoch in der Zusammenarbeit und der Entwicklung von Strategien zur Risikominderung mit Anwendungs-, Technik- und Datenarchitekten, Geschäftspartnern und den klassischen Enterprise Architekten.
Der Blick fürs Ganze gehört zu den Grundfesten der Arbeit. Nur so kann sichergestellt werden, dass die IT Sicherheit nicht mehr nur als reiner Kostenblock wahrgenommen wird, sondern das Geschäftsziel aktiv unterstützt.

Erfahrung zählt


Im Bereich Architecture und Engineering kann ich sehr vieles selbst in die Tiefe hinein aus meiner langjährigen Historie (UNIX & Netzwerkspezialist) heraus beurteilen und auch fundiert vorschlagen. Ich muss aber selbst nicht mehr jedes Bit mit dem Vornamen ansprechen können. Was zählt, ist mit den Plattformspezialisten (Solution Architects/Engineers) und den Kollegen aus operationellen Tagesgeschäft (Administratoren/Analysts) auf Augenhöhe kommunizieren zu können und notfalls gemeinsam mit dem Programm- oder Projektleiter moderierend einzugreifen, wenn aus objektiver Sicht Unsinn erzählt wird, oder durch Silodenken Insellösungen gebaut werden sollen.
Der Status als Externer erlaubt mir in vielen Fällen über die Abteilungsgrenzen hinweg und weitgehend politisch unbelastet Kontakte herzustellen und zu vermitteln. Zum richtigen Zeitpunkt die richtigen Personen einzubinden und ihnen dabei als Ansprechpartner zur Seite zu stehen ist dabei wesentlich.

Ich freue mich auf Ihre Herausforderung. Lassen Sie uns darüber sprechen !

Mit besten Grüßen aus Königstein,
Steffen Müller - CISSP,CCSP,CISA,Prince2 Practitioner