CrowdStrike Falcon · Cloud Security

Zwölf Maßnahmen statt viertausend Befunde.

Falcon Cloud Security findet Fehlkonfigurationen, überprivilegierte Rollen und verwundbare Container in AWS, Azure und Google Cloud. Wir machen daraus eine Liste, die Ihr Team abarbeiten kann, und übernehmen auf Wunsch den Betrieb.

o
s
e
BSI-qualifiziert
APT-Response-Dienstleister
Vollzertifiziertes Team
CISSP · CySA+ · PMRP · CCFA · CCFR · CCFH · CCSE
Wir entwickeln auf Falcon
Foundry-Apps & Fusion-SOAR-Playbooks
24/7 aus Deutschland
SLA-Reaktion ab 60 Minuten
Warum die Cloud anders bricht

Was in der Cloud anders läuft als auf dem Endpoint.

Klassische Angriffserkennung sucht Schadsoftware auf Systemen. In AWS, Azure und Google Cloud entsteht der Schaden an anderer Stelle, und er sieht dabei aus wie normaler Betrieb.

Der Angriff läuft über die Steuerungsebene
Ein gültiger Zugangsschlüssel hinterlässt keine Datei und keinen Prozess, nur API-Aufrufe. Wer allein den Workload beobachtet, sieht davon nichts.
Einmal vergebene Rechte bleiben bestehen
Eine Rolle, die einmal „vorübergehend“ volle Administratorrechte bekam, hat sie drei Jahre später noch. Berechtigungen, die gerade nichts kaputt machen, entzieht niemand.
Der Container lebt neun Minuten
Ein Schwachstellenscan im Wochenrhythmus trifft ihn nie. Geprüft werden muss das Image, bevor es startet, und der Cluster, während er läuft.
Vier harmlose Befunde ergeben einen kritischen Pfad
Öffentlicher Bucket, Zugangsschlüssel im Log, überprivilegierte Rolle, erreichbarer Cluster. Einzeln jeweils als „mittel“ bewertet, zusammen ein durchgehender Weg nach draußen.
Was das Modul abdeckt

Sieben Disziplinen, eine Konsole.

ByteRay implementiert und betreibt CrowdStrike Falcon Cloud Security für Umgebungen in AWS, Microsoft Azure und Google Cloud. Falcon Cloud Security ist eine CNAPP: Sie vereint sieben Disziplinen, die sonst sieben Werkzeuge wären.

Disziplin
Welche Frage sie beantwortet
Was wir dort übernehmen
CSPMKonfiguration
Ist ein Dienst falsch konfiguriert oder öffentlich erreichbar?
Regelwerk, Schweregrade und dokumentierte Ausnahmen statt Werkseinstellung
CWPWorkload-Schutz
Läuft auf der Maschine gerade etwas, das dort nicht hingehört?
Sensor dort, wo Reaktion nötig ist, agentenlos dort, wo Sicht genügt
KSPMKubernetes
Ist der Cluster selbst sauber aufgesetzt?
Admission Controller, Cluster-Härtung, Trennung der Namespaces
Imagesvor dem Start
Welche Schwachstellen bringt das Image schon mit?
Prüfung in der Build-Pipeline und Regeln, was nicht starten darf
CIEMRechte
Wer darf was, und wer nutzt es seit Monaten nicht?
Abbau überprivilegierter Rollen, ohne den Betrieb zu brechen
IaCvor dem Deployment
Erzeugt der Terraform-Code die Lücke gleich mit?
Anbindung an GitLab, GitHub Actions oder Azure DevOps
DSPMDaten & Anwendungen
Welche Daten liegen wo, und welche Anwendung hängt daran?
Einordnung der Befunde nach Geschäftsrelevanz statt nach Schweregrad
Rahmendaten
Anbieter
ByteRay GmbH, Deutschland
Zertifizierung
CrowdStrike Certified Cloud Specialist (CCCS)
Plattformen
AWS, Microsoft Azure und Google Cloud, auch gemischt
Einstieg
Agentenlos über eine Read-Only-Rolle, ohne Change am Workload
Betrieb
Rund um die Uhr über das ByteRay Managed CSIRT
Im Ernstfall
Forensik durch dasselbe Team, BSI-gelistet für APT-Response
Sprachen
Deutsch und Englisch, Ansprechpartner in Deutschland
Ablauf
Anbindung, Aufräumen der Befunde, Automatisierung, Betrieb
Von der Liste zur Aufgabe

Wie aus der Rohliste eine Maßnahmenliste wird.

Die Anbindung eines Cloud-Kontos ist eine Rolle und ein Stack. Am selben Abend stehen vierstellig viele Befunde in der Konsole, und sechs Wochen später öffnet sie niemand mehr. Der Weg von dort zu einer Liste, die ein Team abarbeiten kann, sieht so aus.

4.312
Rohbefunde
Was die Konsole am ersten Abend zeigt
Ungefiltert, ungewichtet, ohne Eigentümer. So aufbereitet lässt sich mit der Liste nicht arbeiten, und genau deshalb bleibt sie liegen.
890
nach Entdopplung
Eine Ursache, hundertfach gemeldet
Eine falsch gesetzte Richtlinie erzeugt einen Befund pro betroffener Ressource. Wir melden die Ursache, nicht jede Auswirkung einzeln.
240
tatsächlich erreichbar
Was einen Weg dorthin hat
Ein Fund in einem abgeschotteten Testkonto ohne Netzpfad ist real, aber keine Aufgabe für diese Woche. Erreichbarkeit entscheidet über die Reihenfolge.
61
nach Angreiferlogik
Was zu beobachtetem Vorgehen passt
Gewichtet nach dem, was Angreifer in vergleichbaren Umgebungen tatsächlich nutzen, nicht allein nach CVSS-Punktzahl.
12
Maßnahmen
Mit Eigentümer, Frist und Prüfschritt
Jede Zeile hat ein Team, einen Termin und eine Definition davon, wann sie erledigt ist. Erst damit wird eine Befundliste tatsächlich abgearbeitet.

Die ersten vier Stufen erledigt das Werkzeug, vorausgesetzt, das Regelwerk stimmt. Die fünfte ist Handarbeit. Sie ist der Grund, warum Befundlisten sonst liegen bleiben.

Größenordnungen einer mittelgroßen Multi-Cloud-Umgebung, gerundet. Die absoluten Zahlen unterscheiden sich je nach Umgebung deutlich, das Verhältnis kaum.

Was wir liefern

Fünf Stufen, von der Bestandsaufnahme bis zum Betrieb.

Jede Stufe ist einzeln beauftragbar. Wer nur wissen will, wo er steht, bleibt bei Stufe eins. Wer die Cloud dauerhaft übergeben will, geht bis fünf.

01
Einstieg
Cloud Exposure Check

14 Tage Falcon Cloud Security in Ihrem eigenen Tenant. Ein bis drei Cloud-Konten agentenlos angebunden, danach ein priorisierter Befund statt einer Rohliste.

  • Anbindung über eine Read-Only-Rolle: kein Agent, kein Change am Workload
  • Befund entlang der fünf Filterstufen, nicht als Konsolen-Export
  • Einschätzung, welche Ausbaustufe für Ihre Umgebung sinnvoll ist
  • Übernahme in den Produktivbetrieb ohne Neuaufbau
02
Implementierung
Anbindung und Einrichtung

Einrichtung über die gesamte Cloud-Landschaft: organisationsweit statt Konto für Konto, damit neue Konten automatisch mitlaufen.

  • AWS, Microsoft Azure und Google Cloud, auch parallel betrieben
  • CSPM-Regelwerk, Schweregrade und Ausnahmenlogik statt Werkseinstellung
  • Container und Kubernetes: Image-Prüfung, Admission Controller, Runtime-Schutz
  • Build-Pipelines für Image- und Terraform-Prüfung angebunden
03
Aufräumen
Posture Baseline

Der Schritt, der in Implementierungsprojekten meist offen bleibt und ohne den das Modul nach sechs Wochen niemand mehr öffnet.

  • Rauschunterdrückung und ein Ausnahmenkatalog, der begründet ist
  • Jeder offene Punkt bekommt ein verantwortliches Team und eine Frist
  • Abbau überprivilegierter Rollen, ohne den Betrieb zu unterbrechen
  • Zuordnung der Befunde zu CIS, BSI C5, ISO 27001, NIS2 und DORA
04
Automatisieren
Fusion SOAR und Foundry

Ein Befund, der jede Woche wiederkehrt, gehört in ein Playbook statt in den nächsten Bericht. Wir entwickeln beides selbst.

  • Öffentlich gewordener Speicher wird geschlossen und der Verursacher informiert
  • Eine neue Freigabe auf 0.0.0.0/0 wird zurückgerollt und protokolliert
  • Kritischer Befund erzeugt ein Ticket mit Eigentümer statt einer Rundmail
  • Eigene Foundry-App, wenn die mitgelieferten Berichte nicht reichen
05
Betrieb
Managed Cloud Security

Laufende Pflege und Reaktion, auf Wunsch vollständig bei uns, ergänzend zu Falcon Complete oder zu Ihrem eigenen Team.

  • Regelwerk pflegen, neue Konten anbinden, Sensoren aktuell halten
  • Rund um die Uhr Reaktion auf Cloud-Erkennungen über das Managed CSIRT
  • Cloud-Forensik im Ernstfall durch dasselbe Team, ohne Übergabeverlust
  • Deutschsprachige Ansprechpartner und regelmäßige Service-Termine
Eigenentwicklung
Playbooks und Foundry-Apps kommen aus demselben Haus wie der Betrieb.
Fusion SOAR ist in der Falcon-Plattform enthalten, ohne Zusatzlizenz. Wir schreiben die Playbooks dafür und entwickeln Foundry-Apps in Python und Go; eine davon ist von CrowdStrike zertifiziert und steht im offiziellen App Catalog. Was ein wiederkehrender Cloud-Befund bei Ihnen auslösen soll, ist damit keine Frage des Lieferumfangs mehr, sondern eine Frage der Abstimmung.
AWS, Azure, Google Cloud

Was in AWS, Azure und Google Cloud jeweils schiefgeht.

Das Modul ist für alle drei dasselbe, der Weg hinein und die typischen Fehler sind es nicht. Gemischte Landschaften sind bei uns der Normalfall.

Amazon Web Services
Anbindung organisationsweit über AWS Organizations: ein StackSet statt Konto für Konto. Neue Mitgliedskonten laufen automatisch mit. Agentenlose Prüfung über Snapshots, Sensor nur dort, wo Reaktion gefragt ist.
Häufigste Funde
  • S3-Buckets, die nach außen lesbar sind, ohne dass es jemand wollte
  • IAM-Rollen mit Platzhalter-Berechtigungen aus der Aufbauphase
  • Security Groups mit offenem SSH oder RDP zum Internet
  • Zugangsschlüssel, die seit Monaten niemand mehr benutzt hat
Microsoft Azure
Anbindung auf Ebene der Management Group statt je Subscription. Sonst fällt bei jeder neuen Subscription eine Lücke auf. Entra ID berührt hier beide Seiten: Cloud-Konfiguration und Identität.
Häufigste Funde
  • Speicherkonten mit öffentlichem Blob-Zugriff
  • Netzwerksicherheitsgruppen mit Verwaltungsports zum Internet
  • Rollenzuweisungen in Entra ID ohne Ablaufdatum
  • Key Vaults ohne Löschschutz oder ohne Netzwerkbeschränkung
Google Cloud
Anbindung über die Organisation mit einem Dienstkonto; Organization Policies bestimmen, was überhaupt erlaubt sein soll. Die Projektstruktur entscheidet darüber, wie weit ein Fund trägt.
Häufigste Funde
  • Buckets, die für alle Nutzer im Internet freigegeben sind
  • Dienstkonten mit Projekt-Editor-Rechten aus Bequemlichkeit
  • Firewallregeln, die 0.0.0.0/0 zulassen
  • Alte Dienstkonto-Schlüssel, die nie ersetzt wurden

Wer in mehreren Clouds arbeitet, hat sonst mehrere Werkzeuge, mehrere Bewertungslogiken und keine gemeinsame Rangfolge. Das fällt hier weg.

Abgrenzung

Womit Cloud Security oft verwechselt wird.

Drei Leistungen aus unserem Portfolio klingen ähnlich und lösen etwas anderes. Die Unterscheidung spart im Erstgespräch eine halbe Stunde.

Falcon Shield
SaaS Security
Falcon Shield sichert fremde Anwendungen, die Sie nutzen: Microsoft 365, Salesforce und Google Workspace, samt Schatten-IT und riskanten OAuth-Freigaben. Cloud Security sichert die Infrastruktur, die Ihnen selbst gehört.
↳ Zu Falcon Shield
Managed CSIRT
Reaktion rund um die Uhr
Cloud Security ist die Sensorik: Sie erkennt und meldet. Das Managed CSIRT ist die Mannschaft, die um drei Uhr nachts eingreift. Erst zusammen ergibt das einen vollständigen Dienst.
↳ Zum Managed CSIRT
Risk Assessments
Einmalige Bestandsaufnahme
Ein Cloud-Risk-Assessment ist eine Momentaufnahme mit Bericht und Maßnahmenkatalog, breiter angelegt, aber ohne Dauerbetrieb. Diese Seite beschreibt den laufenden Zustand.
↳ Zu den Assessments
Ihr Team soll Falcon Cloud Security selbst betreiben?
Wir schulen Administratoren und Analysten als Private Class in Ihrer eigenen Umgebung, mit höchstens zehn Teilnehmern und CrowdStrike-zertifizierten Trainern.
Zu den Falcon Trainings
Häufige Fragen

Was vor dem Erstgespräch meistens gefragt wird.

Wer implementiert CrowdStrike Falcon Cloud Security in Deutschland?

ByteRay ist ein deutscher CrowdStrike-Partner mit CCCS-zertifizierten Consultants und implementiert Falcon Cloud Security für AWS, Microsoft Azure und Google Cloud. Ansprechpartner, Betrieb und Support sind deutschsprachig; im Ernstfall übernimmt dasselbe Haus die Forensik.

Braucht Falcon Cloud Security einen Agenten auf jeder Maschine?

Nein. Konfiguration, Berechtigungen und Schwachstellen lassen sich agentenlos erheben, dafür genügt eine Read-Only-Rolle im Cloud-Konto. Ein Sensor wird nur dort ausgerollt, wo Sie in Echtzeit reagieren wollen, etwa auf produktiven Workloads und in Clustern.

Was ist der Unterschied zwischen Falcon Cloud Security und Falcon Shield?

Falcon Cloud Security sichert Infrastruktur, die Ihnen gehört: Konten, Netze, Workloads und Container in AWS, Azure und Google Cloud. Falcon Shield sichert fremde SaaS-Anwendungen, die Sie nutzen: Microsoft 365, Salesforce und vergleichbare Dienste. Beide ergänzen sich, ersetzen einander aber nicht.

Funktioniert das mit AWS, Azure und Google Cloud gleichzeitig?

Ja, und das ist der übliche Fall. Alle drei Plattformen laufen in derselben Konsole mit derselben Bewertungslogik zusammen. Der Vorteil zeigt sich vor allem bei der Rangfolge: Sie bekommen eine gemeinsame Liste statt drei Werkzeuge mit drei Meinungen.

Wie lange dauert die Anbindung eines Cloud-Kontos?

Die reine Anbindung dauert in der Regel weniger als einen Arbeitstag, organisationsweit statt Konto für Konto. Der aufwändige Teil kommt danach: Regelwerk, Ausnahmen und die Zuordnung der Befunde zu Verantwortlichen. Dafür rechnen wir je nach Größe mit zwei bis sechs Wochen.

Was passiert mit den Befunden nach der Implementierung?

Genau das ist der Kern unseres Angebots. Wir verdichten die Rohliste zu einer Maßnahmenliste mit Eigentümer und Frist, automatisieren wiederkehrende Fälle über Fusion SOAR und übernehmen auf Wunsch den laufenden Betrieb samt Reaktion rund um die Uhr.

Kann ich von Wiz, Prisma Cloud oder Defender for Cloud wechseln?

Ja. Wir gleichen vorher ab, welche Ihrer heutigen Regeln und Ausnahmen sich abbilden lassen und wo es Unterschiede gibt. Danach entscheiden Sie. Der Parallelbetrieb während der Umstellung ist üblich; abgeschaltet wird erst, wenn die neue Abdeckung nachweislich steht.

z
z
z
z
i
i
z
z
Wir durchleuchten Ihre
Cloud.
Der Cloud Exposure Check bindet ein bis drei Konten agentenlos an und liefert eine priorisierte Maßnahmenliste. Kein Agent, kein Change-Ticket, kein Wartungsfenster.