Gewünschte Ergebnisse verstehen: So haben wir den Funktionsumfang von Cloud Defense Free ausgewählt

Als wir uns entschieden, eine kostenlose Version von FireMon Cloud Defense auf den Markt zu bringen, war uns klar, dass wir zwei zentrale Herausforderungen ausbalancieren müssen:

• Wir wussten bereits, dass unsere Plattform skalieren kann. Aber ließe sie sich so anpassen, dass sie große Unternehmen langfristig auch wirtschaftlich skalierbar unterstützt? Es versteht sich von selbst, dass wir sie nicht einfach veröffentlichen und hoffen konnten, dass unsere AWS-Rechnungen uns nicht in die Insolvenz treiben.
• Konnten wir trotz dieser wirtschaftlichen Grenzen einen Funktionsumfang bereitstellen, der Anwendern echten Nutzen bringt? Worin bestünde dieser Nutzen? Welche Probleme würde er lösen?

Tatsache ist: „kostenlos“ ist nie völlig kostenlos, denn die Nutzung von etwas kostet immer Zeit und Aufwand. Wir betrachten die kostenlose Stufe von Cloud Defense nicht als Krümel, die wir über den Tischrand fallen lassen. Uns ist klar: Wenn wir Anwender bitten, sich zu registrieren, die Plattform bereitzustellen und mit ihr zu arbeiten, werden sie das nur tun, wenn wir ihnen helfen, ihre Aufgaben zu erledigen.

(Und was haben wir davon? Nun, wir wissen, dass ein gewisser Prozentsatz zu unseren kostenpflichtigen Tarifen wechseln wird. Vor allem aber liefert uns die kostenlose Plattform äußerst wertvolles Feedback dazu, was Anwender von ihrem CSPM erwarten und wie sie es einsetzen – und sie erlaubt uns, neue Ideen zu erproben.)

In künftigen Beiträgen gehen wir ausführlicher auf die Technologie ein. Heute möchten wir Ihnen darlegen, wie wir entschieden haben, welche Funktionen in die kostenlose Stufe aufgenommen werden. Da wir diese Version der Plattform als eigenständiges Produkt betrachten, haben wir denselben methodischen Ansatz gewählt, der einen Großteil unserer Strategie bestimmt.

Gewünschte Ergebnisse definieren

Wir bei FireMon sind große Anhänger des Jobs-to-be-Done-Frameworks für die Produktstrategie. Der Name verrät bereits einiges: Das Framework leitet Produktentscheidungen, indem es sich darauf konzentriert, welche Aufgabe der Kunde erledigen will und welche konkreten Ergebnisse er dabei erwartet. Das ist eine grobe Vereinfachung des JTBD-Frameworks, aber Sie verstehen das Prinzip. Statt sich auf Funktionen zu konzentrieren, richten Sie den Blick auf die von einem potenziellen Kunden gewünschten Ergebnisse bei der Nutzung eines Produkts und entwerfen auf dieser Grundlage die Funktionen.

Nach einem eingehenden Prozess aus Recherche, Erfahrung und Interviews haben wir einen Entwurf möglicher gewünschter Ergebnisse für Cloud-Security-Fachleute herausgearbeitet:

• Mein Wissen und Verständnis unserer Cloud-Posture über den gesamten Cloud-Footprint hinweg verbessern. (Transparenz)
• Die Wahrscheinlichkeit verringern, dass in unserem Cloud-Footprint eine Cloud-Fehlkonfiguration eingerichtet wird. (Prävention)
• Unsere Cloud-Security- und Compliance-Risiken (Umfang und Zeit) über den gesamten Cloud-Footprint hinweg in einer dezentralen Umgebung reduzieren. (Behebung)
• Unsere Fähigkeit verbessern, Cloud-Sicherheitsthemen gegenüber Management und Aufsichtsbehörden zu kommunizieren.
• Das Potenzial für Verlust und Missbrauch von IAM-Zugriffen auf unsere Cloud-Umgebungen verringern.
• Unsere Fähigkeit verbessern, Cloud-Angriffe zu verhindern, zu erkennen und darauf zu reagieren
• Unsere Sicherheit bei Änderungen an Cloud-Diensten und -Plattformen mehrerer Anbieter aktuell halten.
• Sicherheitsbedingte Reibungsverluste und Aufwände für Entwicklungs- und Cloud-Teams reduzieren, ohne unsere Sicherheitsrisiken zu erhöhen.
• Das Risiko einer Sicherheitsverletzung bei Deployments mit Containern verringern.
• Den Zeitaufwand für die Integration von Cloud Security in mein Programm durch standardisierte APIs und Datenstrukturen reduzieren.

Es gibt offensichtlich viele Wege, jedes dieser Probleme anzugehen. Für uns lautete die Frage daher: Welche davon können wir unter den wirtschaftlichen Rahmenbedingungen einer kostenlosen, gehosteten Plattform anbieten? Das unterscheidet sich deutlich davon, Open-Source-Software bereitzustellen, die jemand selbst installieren und betreiben muss. Wir wollten etwas bauen, das so schnell und einfach zu nutzen ist wie ein kommerzielles Produkt (nun ja, hoffentlich schneller und einfacher als viele Produkte, die Sie bisher eingesetzt haben).

Von Ergebnissen zu Funktionen

Mit dieser Liste galt es zu prüfen, was wir anpassen oder neu entwickeln konnten:

• Mein Wissen und Verständnis unserer Cloud-Posture über den gesamten Cloud-Footprint hinweg verbessern. (Transparenz)

Posture bezieht sich nicht zwangsläufig nur auf Sicherheit; Posture bedeutet, wie Dinge konfiguriert sind. Da eine bloße Liste von Fehlkonfigurationen die Posture nicht vermittelt, war uns klar, dass wir ein Cloud-Inventar in Unternehmensgröße aufbauen müssen – innerhalb unserer Kostengrenzen. Unsere Plattform unterstützte bereits ein Echtzeit-Inventar, doch dieses ließ sich für die kostenlose Stufe nicht wirtschaftlich skalieren.

Wir kamen zu dem Schluss, dass wir Kosten und Nutzen mit einem Scan pro Tag und einer Inventarhistorie von 30 Tagen inklusive Änderungsverfolgung ausbalancieren können. Wie Sie merken, sprechen wir noch nicht über sicherheitsrelevante Fehlkonfigurationen – dazu kommen wir gleich. Nach einigen Kostenmodellierungen stellten wir fest, dass wir dies in Unternehmensgröße (Tausende überwachte Konten) innerhalb unseres Budgets betreiben können. Damit waren beide Anforderungen erfüllt: Nutzen bieten und Kosten im Griff behalten.

Das erforderte tatsächlich erheblichen Entwicklungsaufwand, da das kommerzielle Produkt primär Echtzeit-Inventaraktualisierungen statt periodischer Scans unterstützte. Wir haben diese Änderungen jedoch mit weiteren geplanten Anpassungen gebündelt, die die Gesamteffizienz verbessern. Da beides gut zusammenpasste, fiel die Entscheidung leicht.

• Die Wahrscheinlichkeit verringern, dass in unserem Cloud-Footprint eine Cloud-Fehlkonfiguration eingerichtet wird. (Prävention)

Cloud-Fehlkonfigurationen zu verhindern ist deutlich schwieriger als sie zu erkennen. Blockiert man sie in der CI/CD-Pipeline, sofern Infrastructure as Code eingesetzt wird? Und was ist mit manuellen Änderungen? Wie gestaltet man die Workflows, ohne zu viel Reibung zu erzeugen oder etwas zu beschädigen?

Uns war klar, dass wir eine vollständige Prävention derzeit nicht in einem kostenlosen Produkt umsetzen können. Unsere aktuelle Plattform löst dies über Automatisierung, deren Betrieb im großen Maßstab kostenlos zu teuer wäre. Wir haben jedoch einige Ideen, die funktionieren könnten, und sie stehen inzwischen in unserem Entwicklungs-Backlog.

• Unsere Cloud-Security- und Compliance-Risiken (Umfang und Zeit) über den gesamten Cloud-Footprint hinweg in einer dezentralen Umgebung reduzieren. (Behebung)

Das ist seit den ersten Produktversionen das Kerngeschäft von Cloud Defense. Eine automatisierte Behebung wäre für unsere kostenlose Stufe zwar nicht praktikabel (auch hier gilt es, Kosten und Komplexität abzuwägen), doch es gab keinen Grund, nicht die vollständige Suite an Sicherheitsprüfungen laufen zu lassen.

Eine lange Liste potenzieller Sicherheitsprobleme hilft jedoch nicht zwangsläufig bei der Behebung. Eine weitere Kernfähigkeit unseres Produkts ist die tiefe ChatOps-Integration. Von Haus aus unterstützten wir Slack und Teams, wobei Teams mehr Support erfordern würde, weil … nun ja … es Teams ist. Deshalb haben wir entschieden, unsere granularen (kontobezogenen oder projektbezogenen) Slack-Benachrichtigungen vollständig freizuschalten, da uns dies keine nennenswerten Kosten verursacht und Anwendern viel Nutzen bringt.

• Unsere Fähigkeit verbessern, Cloud-Sicherheitsthemen gegenüber Management und Aufsichtsbehörden zu kommunizieren.

Unsere internen Kosten für die Erstellung eines Compliance-Berichts sind selbst bei großen Umgebungen vernachlässigbar. Für Compliance-Zwecke erfüllen tägliche Bewertungen dieses gewünschte Ergebnis in der Regel mehr als ausreichend. Wir mussten allerdings zusätzlichen Entwicklungsaufwand investieren, um bessere PDF-Berichte für größere Umgebungen (z. B. Hunderte von Konten) zu unterstützen – das brauchten wir jedoch ohnehin für unsere kommerziellen Kunden.

• Unsere Sicherheit bei Änderungen an Cloud-Diensten und -Plattformen mehrerer Anbieter aktuell halten.

Da unser kostenloses und unser kommerzielles Produkt dieselbe, laufend aktualisierte Bibliothek an Prüfungen verwenden, war dies von Haus aus verfügbar. Unser anfänglicher Entwicklungsaufwand konzentrierte sich auf Kostenoptimierungen für AWS, weshalb wir zunächst ohne Unterstützung für Azure oder GCP starten. Azure ist nahezu fertig, sodass Anwender künftig vollständige Multi-Cloud-Unterstützung kostenlos erhalten.

• Das Potenzial für Verlust und Missbrauch von IAM-Zugriffen auf unsere Cloud-Umgebungen verringern.

Wir haben eine ziemlich beeindruckende Funktion namens Authorization Control, die die IAM-Sicherheit spürbar verbessert, doch wirtschaftlich ließ sie sich im kostenlosen Produkt nicht abbilden.

• Unsere Fähigkeit verbessern, Cloud-Angriffe zu verhindern, zu erkennen und darauf zu reagieren

Unser kommerzielles Produkt unterstützt Bedrohungserkennung in Echtzeit. Auch hier ließ sich die Unterstützung für eine kostenlose Plattform wirtschaftlich jedoch nicht darstellen, da wir dafür ein sehr hohes Aktivitätsvolumen in Echtzeit überwachen müssten.

• Sicherheitsbedingte Reibungsverluste und Aufwände für Entwicklungs- und Cloud-Teams reduzieren, ohne unsere Sicherheitsrisiken zu erhöhen.
• Das Risiko einer Sicherheitsverletzung bei Deployments mit Containern verringern.
• Den Zeitaufwand für die Integration von Cloud Security in mein Programm durch standardisierte APIs und Datenstrukturen reduzieren.

Alle diese Ergebnisse verursachten zusätzliche Kosten und/oder Komplexität, die wir im kostenlosen Produkt aufgrund von Infrastruktur-, Support- oder Entwicklungskosten nicht angemessen abdecken konnten.

Den Funktionsumfang schnüren

Die gewünschten Ergebnisse haben uns gemeinsam mit unserer Kostenanalyse geholfen zu entscheiden, welche Funktionen wir bündeln:

• Ein Scan pro Tag
• Ressourceninventar mit einer Historie von 30 Tagen
• Die vollständige Suite an Sicherheitsprüfungen
• Grundlegende Compliance-Berichte
• Slack-Integration
• AWS zunächst, Azure und GCP mit den kommenden Plattform-Updates

Diese Entscheidungen fielen nicht immer leicht. Selbst ein Inventar über 30 Tage verursacht beispielsweise Kosten, doch wir waren der Ansicht, dass reine Fehlkonfigurationsberichte dem Transparenzbedarf der Anwender nicht gerecht werden. Ebenso kamen wir zu dem Schluss, dass eine Beschränkung unserer Sicherheitsprüfungen oder der Zwang, für Compliance-Berichte auf das kommerzielle Produkt zu wechseln, zu einem Produkt geführt hätte, das kein ausreichendes Ergebnis liefert.

Dieses Paket adressiert die zentralen gewünschten Ergebnisse im Bereich Sicherheitstransparenz sowie die Ergebnisse im Bereich Kommunikation, um sowohl das Reporting zu verbessern als auch die Behebungszeiten zu verkürzen. Und wir wissen um den Nutzen, denn genau für diese gewünschten Ergebnisse wurden zuerst Open-Source-Werkzeuge für Cloud Security entwickelt – sie bilden den Ursprung des gesamten Marktes für Cloud Security Posture Management.

Das JTBD-Framework hat uns wirklich dabei geholfen, den Fokus auf die Verbesserung der Kundenergebnisse zu richten, statt lediglich einige Funktionen herauszulösen, die zusammengenommen niemandem wirklich weiterhelfen. Das Ergebnis ist aus unserer Sicht eine kostenlose Plattform, die echten Mehrwert liefert und zugleich so kosteneffizient ist, dass wir sie langfristig unterstützen können.

Probieren Sie es aus und teilen Sie uns Ihre Meinung mit. FireMon Cloud Defense befindet sich in der Weiterentwicklung und ist für uns eine gute Möglichkeit, Cloud-Sicherheitsfachleute noch besser bei ihrer Arbeit zu unterstützen.