12AvfKdSOZndDUhrNNK72VSnA
(An English-language version of this post can be read here.)
Disclaimer: Bei dem folgendem Blogpost handelt es sich um eine aktualisierte deutsche Version des bereits im Englischen veröffentlichten Blogposts “How Palantir Manages Continuous Vulnerability Scanning At Scale.” Er bezieht sich konkret auf Cloud-Implementierungen von Palantir-Produkten. Bei Kunden, die eine on-prem Installation verwalten, gelten u.U.. andere Prozesse und Maßnahmen.
Effektives Schwachstellenmanagement ist ein Eckpfeiler jedes etablierten Sicherheitsprogramms. Für Hersteller komplexer Cloud-Softwareprodukte wie Palantir ist es entscheidend, Schwachstellen zu identifizieren und schnell zu beheben, um potenziellen Angreifern immer einen Schritt voraus zu sein. Bleiben Schwachstellen in Container-Images und Software-Abhängigkeiten unentdeckt oder werden sie nicht behoben, bieten sie Angriffsfläche, die ausgenutzt werden kann. Unternehmen, die komplexe Softwareprodukte und Infrastrukturen anbieten, sind zunehmend auf eine Vielzahl von Open-Source-Bibliotheken von Drittanbietern angewiesen. Hier reicht es nicht mehr aus, Schwachstellen in Abhängigkeiten manuell zu identifizieren und einzeln zu beheben. Unternehmen sind viel mehr damit konfrontiert, Sicherheitslücken programmatisch zu identifizieren und einzuschätzen. Dabei müssen Prioritäten gesetzt werden, in welcher Reihenfolge es Lücken zu beheben gilt und wie dabei ein festgelegter Zeitrahmen eingehalten werden kann. Nur so können Unternehmen sicherstellen, mit der technologischen Entwicklung Schritt zu halten.
Palantirs Produkte unterstützen die Arbeit führender öffentlicher und kommerzieller Organisationen auf der ganzen Welt. Unsere Kunden verlassen sich darauf, dass ihre Daten mit unserer Software vor potenziellen Bedrohungen sicher sind. Wir haben vor diesem Hintergrund einen Service entwickelt, den wir Container Vulnerability Scanner (CVS) nennen. Dieses Tool wurde ursprünglich als eigenständiger Schwachstellen-Scanner entwickelt, ist inzwischen aber auch an unsere Continuous-Deployment-Plattform Apollo gekoppelt. So ermöglichen wir es, die Schwachstellenbehebung zu optimieren — und diesen Prozess sogar zu automatisieren.
Unser Ziel ist es, nicht nur unsere eigenen strengen Sicherheitsanforderungen zu übertreffen, sondern auch einige der am strengsten regulierten Informationssicherheits-Standards zu erfüllen, die der Markt aktuell kennt. So ist unsere Cloud-Umgebung beispielsweise vom US Amerikanischen Verteidigungsministerium als FedRAMP Moderate/DoD Impact Level 6 (IL6) zertifiziert; dementsprechend ist CVS darauf ausgelegt, die FedRAMP-Anforderungen an das Schwachstellenmanagement in allen unseren Produktionsumgebungen zu erfüllen — oder eben sogar zu übertreffen. Diese Anforderungen schreiben Aspekte wie das authentifizierte Scannen, die CVE-Nummerierung und CVSS-Risikobewertung, Signatur-Updates oder die Asset-Identifizierung vor.
Grundsätzlich stellt CVS sicher, dass alle Softwarekomponenten und Produkte, die wir entwickeln und einsetzen, strenge Sicherheitsanforderungen erfüllen:
Auf der Grundlage der FedRAMP-Anforderungen und unserer eigenen hohen Sicherheitsstandards setzt Palantir strenge SLAs an, um Schwachstellen zu beheben. Diese SLAs stellen zwar die maximal verfügbare Zeitspanne dar, um eine Schwachstelle zu beheben. In der Praxis versuchen wir jedoch, Schwachstellen wesentlich schneller zu beheben. Wir priorisieren kritische Schwachstellen nach ihrem Schweregrad, um sie schnellstmöglich zu beheben, sobald sie entdeckt wurden.
Für Schwachstellen in der zugrundeliegenden Infrastruktur, in Containern oder auf Hosts halten wir uns an die folgenden maximalen SLAs:
KRITISCH: 72 Stunden
HOCH: 30 Tage
MEDIUM: 90 Tage
GERING: 120 Tage
Für Schwachstellen in von Palantir entwickelten Softwareprodukten, deren Aufhebung wesentlich komplizierter sein kann, gelten die folgenden maximalen SLAs:
KRITISCH: 30 Tage
HOCH: 30 Tage
MEDIUM: 90 Tage
GERING: 120 Tage
Verwaltung und Integration mehrerer Schwachstellen-Scanner in CVS
Im Grunde ist CVS ein Rahmenwerk, das die Implementierung mehrerer einzelner Schwachstellen-Scanner ermöglicht. Ändern sich unsere Sicherheitsanforderungen im Laufe der Zeit, können wir mit einfachen Mitteln einen neuen Scanner hinzufügen, mit Hilfe dessen weitere bestimmte Funktionen für die Überprüfung von Schwachstellen ausgeführt werden können. Die Ergebnisse dieses Scanners können dann sofort in die nachgeschaltete bedingte Logik integriert werden.
Es gibt drei wichtige Scanner, auf die wir uns heute verlassen:
In Rubix, der Kubernetes-basierten Cloud-Deployment-Architektur von Palantir, verwenden wir minimierte und gehärtete Container-Images auf Basis von Ubuntu Linux für die zugrunde liegende Infrastruktur und die Hosts. Alle Hosts in einer Rubix-Umgebung sind kurzlebig — sie werden in regelmäßigen Abständen erstellt, zerstört und neu aufgebaut. Ein aktuelles Maschinen-Image mit den neuesten Patches garantiert, dass die Hosts mindestens jedes Mal gepatcht werden, wenn sie neu erstellt werden. Mit dieser Methode der Container-Image-Verwaltung können wir sicherstellen, dass jeder Host vor der Bereitstellung entsprechend aktualisiert und von CVS gescannt wird.
Bei unseren Anwendungs-Containern gehen wir mit einem Scratch-basierten Image noch einen Schritt weiter. Es hat einen extrem minimalen Fußabdruck, um die Angriffsfläche von Paketen zu reduzieren, die nicht unbedingt notwendig sind. Während ein Standard-Container ungefähr 90 Pakete enthalten kann, wird unser Container-Image mit 6 Paketen ausgeliefert. Insbesondere enthält es keine Shells, Paketmanager, Coreutils (z.B. ls, cp usw.) oder andere Pakete außer glibc.
Indem wir minimierte Container-Images als Ausgangspunkt verwenden, reduzieren wir für unsere Produkte die Angriffsfläche innerhalb unserer Anwendungen erheblich und beseitigen eine Großzahl von Schwachstellen. Dieser Ansatz stellt sicher, dass wir unsere begrenzten Ressourcen und unseren Arbeitsaufwand auf entscheidende Sicherheitsmängel konzentrieren können anstatt auf die Behebung von Schwachstellen in Zusatzpaketen oder Abhängigkeiten, die keine Auswirkungen auf die Sicherheit unserer Produkte haben.
Software in unserer Cloud-Umgebung wird über Apollo verwaltet. Jede einzelne Softwarekomponente, die wir in unserer Cloud-Umgebung einsetzen möchten, wird zunächst im Apollo-Katalog registriert. Sobald sie registriert ist, wird sie in CVS eingetragen und muss bestimmte Sicherheitskriterien erfüllen, bevor sie in einer Umgebung eingesetzt werden kann.
In der Praxis bedeutet das, dass jede Version jeder Softwarekomponente, die wir freigeben, bei der allerersten Aufnahme in den Katalog einen CVS-Scan durchläuft und kontinuierlich die in den oben genannten SLAs festgelegten Sicherheitskriterien erfüllen muss. Diese hoch skalierbare Automatisierung garantiert grundlegende Sicherheitsstandards in allen von Apollo verwalteten Produktionsumgebungen.
In Anbetracht der höchsten Sicherheitsanforderungen unserer Kunden und ihrer Arbeit ist die richtlinienbasierte Durchsetzung von SLAs für Behebungen völlig unzureichend. Die hohen Anforderungen an die Verfügbarkeit, die erforderlichen Tests um Patches sicher zu installieren, und die Koordination von Wartungsfenstern machen umfangreiches menschliches Eingreifen unmöglich. Stattdessen arbeiten CVS und Apollo zusammen, um auf der Grundlage von Scan-Ergebnissen und logischen Regeln automatisch Maßnahmen zu ergreifen.
In Apollo verwenden wir ein Software-Rückruf Verfahren. Das genaue Verfahren ist je nach Bedarf konfigurierbar, aber standardmäßig können Artefakte, die als zurückgerufen markiert sind, nicht eingesetzt werden, weder durch eine Neuinstallation noch durch ein Upgrade. Stattdessen verbleiben sie in ihrer bestehenden Version, bis eine neue, nicht zurückgerufene Version veröffentlicht wird.
Wenn ein Container- oder Artefakt-Scan eine CVS-Prüfung nicht besteht, wird das entsprechende Produkt in Apollo automatisch als zurückgerufen markiert. Dieser Zwischenschritt stellt sicher dass für den Fall, dass in einer neuen Produktversion eine Schwachstelle eingeführt wird, diese dann nicht im Rest unserer Flotte als potentieller Angriffspunkt verbreitet wird. Wenn die zurückgerufene Version auch die neueste Version im Apollo-Katalog ist, wird ein Produkt-Support-Ticket eingereicht, das sofort an den für den zurückgerufenen Dienst Produktverantwortlichen weitergeleitet wird. Auf diese Weise wird das Problem — entsprechend priorisiert — direkt an das Produktteam weitergeleitet, um einzugreifen und die besten kurz- und langfristigen Lösungen zu finden. Indem die Verantwortung für das Schwachstellenmanagement früh in der Build-Pipeline angesiedelt wird, bietet dieser “Shift-Links”-Ansatz den Entwicklern einen Anreiz, die Abhängigkeiten auf dem neuesten Stand zu halten, und sorgt für Flexibilität bei der Problembehebung.
Während des Erkennens von Sicherheitslücken gibt es immer wieder Grenzfälle. Es kann zu falsch-positiven Ergebnissen kommen, Pakete können fälschlicherweise als verwundbar markiert werden, vom Hersteller zur Verfügung gestellte Patches sind möglicherweise noch nicht vorhanden, und weitere externe Effekte können auftreten. CVS und Apollo verfügen über eine flexible Unterdrückungsfunktion, die eine zeitlich begrenzte und dem Risiko entsprechende Behandlung dieser Randfälle ermöglicht.
In unserer Cloud-Umgebung müssen alle Unterdrückungen manuell von unserem Informationssicherheits-Team überprüft und genehmigt werden. Als sekundäre Kontrolle werden diese Unterdrückungen regelmäßig vom Tech-Compliance-Team überprüft, um sicherzustellen, dass wir alle gesetzlichen und Compliance-Anforderungen erfüllen.
Produkteigentümer müssen eine Unterdrückung in einem strukturierten Format angeben. Ein Beispiel für eine Unterdrückung könnte wie folgt aussehen:
validUntil: "2022-10-15" # One month from now
CVE-2022-XXXX:
category: VENDOR_DEPENDENCY
rationale: package-name | No stable vendored fix available yet
In diesem Fall wurde für das spezifische CVE eine vorübergehende 30-tägige Unterdrückung beantragt, da noch keine Herstellerbehebung verfügbar ist. Nach Ablauf des validUntil-Datums wird die Unterdrückung automatisch aufgehoben, und Apollo beginnt ohne Vorwarnung mit seinem Rückrufprozess.
Zu den Kategorien, die für eine Unterdrückung in Frage kommen, gehören:
Mit einem robusten, prüffähigen und getesteten System zur Unterdrückung und zum Rückruf von Sicherheitslücken können die Entwickler alltägliche Patches in ihren Produkten schnell aufspüren und beheben, während sich das Informationssicherheits-Team intensiver auf die kritischsten Sicherheitslücken konzentrieren kann, die unsere Flotte betreffen.
CVS hat entscheidend dazu beigetragen, die Sicherheitsanforderungen und -erwartungen unserer Kunden sowohl in unseren Cloud- als auch in unseren On-Premise-Umgebungen zu übertreffen. Seit wir CVS implementiert haben, konnten wir die Patching-Geschwindigkeit drastisch erhöhen, das Vertrauen in die einheitliche und effektive Anwendung von Sicherheitskontrollen stärken und unsere Fähigkeit, auf Sicherheitsmängel in unseren Produkten und unserer Infrastruktur zu reagieren, deutlich verbessern.
Als CVE-2021–44832, die Sicherheitslücke in log4j, die Tech-Branche im Dezember 2021 erschütterte, bildeten CVS, Apollo und Foundry den Kern unserer globalen Reaktion. Dank der Zusammenarbeit dieser Produkte waren wir in der Lage, die Schwachstelle eindeutig zu identifizieren, bekannte fehlerhafte Versionen zurückzurufen und zu blockieren. So konnten wir innerhalb weniger Stunden Tausende von Upgrades von Produktivinstallationen in den Umgebungen von mehreren hundert Kunden, die Palantir damals verwaltete, durchführen — einschließlich Cloud, On-Premise, sicherheitseingestuften und Edge-Netzwerken.
Mit Blick auf die Zukunft arbeiten wir an einer engeren Integration zwischen CVS und Apollo, fügen mehr konfigurierbare Kontrollen und Regellogik hinzu und führen Überprüfungen/Genehmigungen durch mehrere Parteien in Apollo ein. Außerdem arbeiten wir an der Erstellung und Validierung eines nativen Software Bill of Materials (SBOM) in Apollo. Zum Schutz unserer Software-Lieferkette modifizieren wir CVS und Apollo, um Sicherheitskontrollen durchzusetzen, die die Herkunft und Integrität unserer veröffentlichten Software-Artefakte garantieren, um Angriffen auf die Lieferkette, die häufig auf Software-Unternehmen abzielen, besser entgegentreten zu können.
Wir sind gespannt, zusätzliche Scanner hinzuzufügen, die unserer Meinung nach den Sicherheitswert dieser Plattform noch weiter verbessern werden. Unsere Teams zur Erkennung von Sicherheitsvorfällen verwenden YARA-Regeln, um weltweit nach schadhaften und anomalen Einschleusungen und Schadsoftware in unserer Flotte zu suchen. Zur besseren Verteidigung unserer Netzwerke könnte zum Beispiel ein nativer YARA-Scanner als Teil von CVS einen besseren Einblick und Schutz vor Akteuren bieten, die versuchen, sicherheitskritischen Code in unsere Container und Software einzuschleusen.
Wir sind bestrebt, unsere Kunden mit Wissen und Werkzeugen auszurüsten, damit sie ihre lückenlose Sicherheit selbst gestalten können. Zu diesem Zweck haben wir ein Projekt zur Offenlegung von CVS in Foundry und Apollo gestartet, um Kunden die Möglichkeit zu geben, ihre selbst erstellten Container und Software direkt in unseren Plattformen zu sichern.
Sind Sie daran interessiert, bei der Entwicklung von CVS, der Apollo-Plattform oder anderer unternehmenskritischer Software bei Palantir mitzuwirken? Besuchen Sie unsere Karriereseite, um mehr zu erfahren.
Sind Sie an Apollo für Ihr Unternehmen interessiert? Erfahren Sie mehr und buchen Sie eine Apollo-Demo auf unserer Website.
Dieser Beitrag enthält zukunftsgerichtete Aussagen im Sinne von Abschnitt 27A des Securities Act von 1933 in seiner aktuellen Fassung und Abschnitt 21E des Securities Exchange Act von 1934 in seiner aktuellen Fassung. Diese Aussagen können sich unter anderem auf die Erwartungen hinsichtlich der Entwicklung und des erwarteten Nutzens unserer Softwareplattform und -lösungen beziehen. Zukunftsgerichtete Aussagen sind naturgemäß mit Risiken und Ungewissheiten behaftet, von denen einige nicht vorhergesagt oder quantifiziert werden können. Zukunftsgerichtete Aussagen beruhen auf Informationen, die zu dem Zeitpunkt verfügbar waren, als diese Aussagen gemacht wurden, und basieren auf den aktuellen Erwartungen sowie den Überzeugungen und Annahmen der Geschäftsleitung zu diesem Zeitpunkt in Bezug auf zukünftige Ereignisse. Diese Aussagen unterliegen Risiken und Ungewissheiten, von denen viele Faktoren oder Umstände betreffen, die außerhalb der Kontrolle von Palantir liegen. Zu diesen Risiken und Unwägbarkeiten gehören die Fähigkeit von Palantir, die besonderen Anforderungen seiner Kunden zu erfüllen, das Versagen seiner Plattformen und Lösungen, seine Kunden zufrieden zu stellen oder die gewünschte Leistung zu erbringen, die Häufigkeit oder Schwere von Software- und Implementierungsfehlern, die Zuverlässigkeit seiner Plattformen und die Fähigkeit seiner Kunden, ihre Verträge zu ändern oder zu kündigen. Weitere Informationen zu diesen und anderen Risiken und Ungewissheiten sind in den Unterlagen enthalten, die Palantir von Zeit zu Zeit bei der Securities and Exchange Commission einreicht. Sofern nicht gesetzlich vorgeschrieben, übernimmt Palantir keine Verpflichtung, zukunftsgerichtete Aussagen öffentlich zu aktualisieren oder zu revidieren, sei es aufgrund neuer Informationen, zukünftiger Entwicklungen oder aus anderen Gründen.
Kontinuierliches und skalierbares Schwachstellenmanagement bei Palantir was originally published in Palantir Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.
Jasper Research Lab’s new shadow generation research and model enable brands to create more photorealistic…
We’re announcing new updates to Gemini 2.0 Flash, plus introducing Gemini 2.0 Flash-Lite and Gemini…
Interactive digital agents (IDAs) leverage APIs of stateful digital environments to perform tasks in response…
This post is co-written with Martin Holste from Trellix. Security teams are dealing with an…
As AI continues to unlock new opportunities for business growth and societal benefits, we’re working…
An internal email obtained by WIRED shows that NOAA workers received orders to pause “ALL…