Ein Sicherheitsprogramm von Grund auf aufbauen

Als erste Sicherheitsperson in einem Unternehmen eingestellt zu werden ist eine ganz spezielle Art von Chaos. Es gibt keine Ticket-Queue, keine etablierten Tools und normalerweise auch keine Budgetzeile, die auf dich wartet. Das Folgende ist eine grobe Orientierungshilfe für die ersten 90–180 Tage, die typischerweise ablaufen, und was tatsächlich etwas bewirkt im Gegensatz zu dem, was sich nur produktiv anfühlt.

Was "nichts" normalerweise bedeutet

Wenn Leute sagen, ein Unternehmen habe keine Sicherheitsfunktion, meinen sie selten null Kontrollen. Sie meinen keinen dedizierten Eigentümer. Engineering hat wahrscheinlich bereits einige grundlegende AWS IAM Richtlinien aktiviert, IT hat Antivirus über ein MDM-Tool ausgerollt, und jemand aus der Finanzabteilung hat eine Meinung zu SOC 2, weil ein Kunde danach gefragt hat. Deine erste Aufgabe ist Bestandsaufnahme, nicht Implementierung. Bevor du eine einzelne Richtlinie schreibst, finde heraus, was bereits läuft: Cloud-Konten (und wie viele es gibt, die niemand mehr im Gedächtnis hat), SaaS-Tools mit Admin-Zugriff auf Quellcode und ob es eine Single Source of Truth für das Offboarding von Mitarbeitern gibt. Eine Tabelle ist dafür ausreichend. Eine GRC-Plattform ist derzeit keine Priorität.

Die ersten 30 Tage: Sichtbarkeit vor Kontrolle

Widerstand gegen den Drang, in Woche eins eine Richtlinie für akzeptable Nutzung zu schreiben. Niemand wird sie lesen und sie werden die eigentlichen Risiken nicht verhindern. Hole dir stattdessen Sichtbarkeit in drei Bereiche:

• Identity: ziehe eine vollständige Benutzerliste von deinem Identity Provider (Okta, Google Workspace, Azure AD) und gleiche sie mit HRs aktiver Mitarbeiterliste ab. Du wirst Ghost-Konten finden.
• Cloud-Footprint: führe etwa aws organizations list-accounts aus, wenn du auf AWS bist, oder überprüfe GCPs Asset Inventory, um zu sehen, wie viele Umgebungen existieren im Vergleich zu denen, an die sich jemand aus dem Gedächtnis erinnern kann.
• Code- und Secrets-Exposure: führe gitleaks detect oder trufflehog filesystem . gegen deine Haupt-Repos aus. Ein hardcodierter API-Schlüssel in der Commit-Historie von vor zwei Jahren zu finden ist nahezu garantiert und eine schnelle Möglichkeit, Mehrwert nachzuweisen.

Dokumentiere Ergebnisse, aber drehe das nicht in einen 40-seitigen Bericht, den niemand öffnet. Eine einseitige Risikozusammenfassung mit fünf Stichpunkten wird von einem CTO gelesen. Ein langes PDF nicht.

Deine ersten drei Kontrollen wählen

Ohne Headcount und ohne Tooling-Budget kannst du nicht alles auf einmal tun. Eine Abfolge von Operationen, die typischerweise funktioniert:

1. MFA überall dort, wo es nicht bereits vorhanden ist, beginnend mit dem Identity Provider, dann GitHub/GitLab, dann Cloud-Konsolen. Dies allein schließt den am häufigsten vorkommenden Account-Übernahme-Weg ab.
2. Zentralisiertes Logging für Cloud- und Auth-Events. Selbst ein kostenloser Tarif eines SIEM-ähnlichen Tools oder einfach nur das Verschieben von CloudTrail/GCP Audit Logs in einen Bucket mit Aufbewahrung ist besser als nichts, wenn ein Incident passiert.
3. Ein schriftlicher, kurzer Incident Response Plan, selbst wenn er zwei Seiten umfasst: wer bekommt einen Anruf, wer spricht mit Kunden, wer hat die Vollmacht, etwas abzuschalten. Niemand erinnert sich daran, das zu bauen, bis zum Tag, an dem es nötig ist, und dann ist es zu spät.

Beachte, dass keines dieser Dinge einen großen Vendor-Vertrag erfordert. Sie erfordern Entscheidungen und Durchhaltevermögen.

Buy-in ohne Sicherheits-Budgetzeile bekommen

Der schnellste Weg, die Glaubwürdigkeit als erste Sicherheitseinstellung zu verlieren, besteht darin, mit einer Wunschliste von Tools zu erscheinen, bevor du irgendwelche Ergebnisse zeigst. Verknüpfe stattdessen jede Anfrage mit etwas Konkretem: "wir haben drei IAM-Benutzer mit nicht rotierten Zugangsschlüsseln von 2021 gefunden" kommt besser an als "wir brauchen ein CSPM-Tool." Formuliere Anfragen in Begriffen, die Engineering und Finanz bereits kümmern: reduzierter Blast Radius, schnellere Audits, weniger 2-Uhr-Nachts-Seiten. Wenn das Unternehmen SOC 2 oder ISO 27001 anstrebt, ist dieser Compliance-Termin oft dein bestes Druckmittel, um Ressourcen zu bekommen, auch wenn Compliance selbst nicht das Ziel ist.

Häufige Fehler im ersten Jahr

Eine teure Plattform zu kaufen (SIEM, EDR, CSPM), bevor du die Prozesse oder das Headcount hast, um sie tatsächlich zu betreiben, ist die häufigste Verschwendung von Early-Stage-Budget. Ein $50k-Tool, das niemand optimiert, erzeugt Lärm, nicht Detection. Gleichermaßen, Richtlinien zu schreiben, die aus einer Vorlage kopiert sind, ohne sie an die tatsächliche Arbeitsweise des Unternehmens anzupassen, garantiert, dass sie ignoriert werden, sobald jemand eine Ausnahme benötigt. Und zu versuchen, alles alleine über die ersten sechs Monate hinweg zu besitzen, ist ein Burnout-Weg; im Moment, in dem es Traktion gibt, sollte die nächste Einstellung normalerweise jemand sein, der Detection und Response übernehmen kann, damit du dich weiterhin auf den Aufbau der Programmstruktur konzentrieren kannst.

Security von Grund auf ist hauptsächlich eine Frage der Sequenzierung: sehe, was existiert, schließe die lautesten Lücken, baue genug Prozess auf, damit Entscheidungen nicht von deinem Gedächtnis abhängen, und expandiere von dort.

Wenn dich diese Art von bodengestütztem Programmaufbau interessiert, hat Korra Studio verwandte Segmente zu Grundlagen der Incident Response und Cloud Security Posture, die sich gut mit diesem hier kombinieren lassen.