Skip to main content

Best Practices für Enterprise-Sicherheit: Schwachstellen im großen Maßstab verwalten

Artikel von
Blog illustrations vulnerabilities at scale

9. November 2020

0 Min. Lesezeit

Was ist Enterprise-Sicherheit?

Bei Enterprise-Sicherheit im großen Maßstab geht es unter anderem darum, folgende Herausforderungen zu bewältigen:

  • Die Vielzahl an Sicherheitsproblemen nimmt zu und kostet Entwickler:innen und Security-Engineers wertvolle Zeit.

  • Entwickler:innen und Security-Engineers arbeiten aufgrund des schwindenden gegenseitigen Vertrauens nicht gut zusammen.

  • Schwerwiegende Schwachstellen bleiben lange offen, weil die wichtigsten behebbaren Sicherheitsprobleme nicht priorisiert werden.

Wie stellen Sie die Einhaltung von Sicherheitsvorgaben in mehreren Teams sicher, wenn diese mit einer überwältigenden Zahl an Schwachstellen konfrontiert sind, die behoben werden müssen?

Genau darum geht es in diesem Spickzettel zu Best Practices für Enterprise-Sicherheit!

Spickzettel herunterladen.

Ob Sie eine Enterprise-Sicherheitsarchitektur oder eine Enterprise-Cybersicherheitslösung implementieren: Sie werden vor Herausforderungen bei der Anwendungssicherheit stehen. Dazu gehört, sicherzustellen, dass Ihre Entwicklungsteams weder ausgebremst noch durch zusätzliche Hürden aufgehalten oder blockiert werden.

Snyk hat kürzlich seine Lösungen für Enterprise-Sicherheitsmanagement im großen Maßstab vorgestellt. Sie bieten Projektmanagement-Funktionen mit Fokus auf Entwickler:innen und fördern die Produktivität Ihrer Security- und Entwicklungsteams. Projektattribute, Projekt-Tags, Richtlinien auf Projektebene und Bedingungen für fehlgeschlagene Pull Requests sind Beispiele dafür, wie Entwickler:innen ins Handeln kommen und das Security-Team sich auf das Wesentliche konzentrieren kann.

Ergreifen Sie Maßnahmen, um Ihre Enterprise-Sicherheitsarchitektur zu verbessern:

  • Lassen Sie den Build nur fehlschlagen, wenn eine Behebung verfügbar ist

  • Weisen Sie automatisch den Security Champion zur Prüfung von Problemen zu

  • Erstellen Sie priorisierte Pull Requests, um Schwachstellen zu beheben

  • Lizenz-Compliance

  • Erreichbare Schwachstellen

    Snyk Reports-Dashboard mit der Anzahl der Sicherheits- und Lizenzprobleme sowie Diagrammen zum zeitlichen Verlauf der Probleme und zum Exposure-Zeitraum.

Erstellen Sie priorisierte Pull Requests, um Schwachstellen zu beheben

Herausforderung: Im Backlog gibt es zahlreiche Sicherheitslücken, und es fällt Entwickler:innen schwer, zwischen all den Problemen die Sicherheitsrisiken anzugehen.

Lösung: Senken Sie das Gesamtrisiko, indem Sie sich auf die schwerwiegendsten behebbaren Sicherheitslücken konzentrieren.

Snyk hat den Schwachstellen-Prioritätswert eingeführt, um ein seit Langem bestehendes Problem bei der Bewertung von Sicherheitslücken zu lösen. Standardisierte Systeme wie CVSS stellen Entwickler:innen und Application-Security-Engineers vor große Herausforderungen, wenn sie die tatsächlichen Auswirkungen einer Sicherheitslücke im richtigen Kontext bestimmen müssen. Mehr dazu erfahren Sie in unserem Beitrag über die Herausforderungen bei der Bewertung von Sicherheitslücken mit CVSS, der auch eine gute Einführung in die CVSS-Grundlagen bietet.

Der Prioritätswert von Snyk berücksichtigt unter anderem den Reifegrad von Exploits, die Verfügbarkeit einer Behebung und den CVSS-Wert. Daraus ergibt sich für eine Schwachstelle ein Prioritätswert zwischen 0 und 1000. Je höher der Wert, desto dringender sollte die Schwachstelle behoben werden.

Damit Sie den Überblick über die Vielzahl an Sicherheitslücken und den langen Nachlauf behalten, möchten wir sicherstellen, dass Sie sich auf die schwerwiegendsten Schwachstellen konzentrieren und so das Gesamtrisiko und die Zeit, in der Sie Risiken ausgesetzt sind, reduzieren.

Wie machen wir das auf hilfreiche und umsetzbare Weise für Entwickler:innen?

Rufen Sie die Snyk-Integrationseinstellungen auf und aktivieren Sie die Option, Pull Requests für alle Schwachstellen mit höchster Priorität zu erstellen, die im Projekt vorhanden und behebbar sind. Keine Sorge: Entwickler:innen werden nicht mit einer Flut von Pull Requests überhäuft, die ihre gesamte Zeit beanspruchen! Stattdessen erstellen wir nur einen neuen Pull Request pro Tag. Diese Pull Requests enthalten konkrete Maßnahmen und verweisen auf Upstream-Paketversionen, für die ein Upgrade-Pfad verfügbar ist. Das Entwicklungsteam kann sie daher mit minimalem Aufwand prüfen und zusammenführen.

Snyk-GitHub-Integrationseinstellungen mit einem verbundenen Konto und Optionen für automatische Fix-Pull-Requests

Weisen Sie automatisch den Security Champion zur Prüfung von Problemen zu

Herausforderung: Sicherheitsbehebungen werden automatisiert und als Pull Request an das Projekt-Repository gesendet. Das ist eine gute Sache – aber wer sollte sie überprüfen?

Lösung: Vereinheitlichen Sie die Sicherheitsprüfung automatisierter Behebungen und Dependency-Upgrades, indem Sie dem erstellten Pull Request automatisch eine prüfende Person zuweisen. Sie können die Person anhand der letzten Person bestimmen, die die Manifestdatei geändert hat – egal, ob es sich um eine pom.xml oder eine package.json handelt. Alternativ können Sie gezielt den Security Champion oder eine andere Person in Ihrem Team mit der Prüfung der Änderungen im Pull Request beauftragen.

Snyk-Einstellungsseite mit einer verbundenen GitHub-Integration und aktivierten Optionen für Pull-Request-Zuständige.

Lassen Sie den Build nur fehlschlagen, wenn eine Behebung verfügbar ist

Herausforderung: Sie möchten Entwickler:innen dabei unterstützen, Open Source sicher zu nutzen, blockieren sie aber am Ende vollständig. Oft können sie nicht einmal auf Ihre Erkenntnisse reagieren.

  • Eine Entwickler:in stellt fest, dass die CI-Pipeline wegen eines Sicherheitsproblems mit geringer Schwere fehlgeschlagen ist und das Projekt nicht fortgesetzt werden kann.

  • Eine Entwickler:in hat Schwierigkeiten, eine von der CI-Pipeline gefundene Sicherheitslücke zu beheben. Der Build ist fehlgeschlagen, obwohl es keine tatsächliche Behebung für das Sicherheitsproblem gibt.

Lösung: Damit Entwickler:innen Sicherheit verinnerlichen und mit fehlgeschlagenen Builds umgehen können, ohne sie als Störsignale oder falsch positive Ergebnisse abzutun, benötigen sie Tools, die für ihre Workflows hilfreich und praktisch umsetzbar sind.

Snyk bietet detaillierte Konfigurationsmöglichkeiten, mit denen der CI-Build nur dann fehlschlägt, wenn die gefundenen Schwachstellen einen hohen Schweregrad überschreiten. So konzentrieren sich Entwickler:innen auf die wichtigsten Probleme, wenn sie aufgrund eines fehlgeschlagenen Builds Zeit in die Behebung einer Sicherheitslücke investieren müssen.

Was erwarten Sie von Entwickler:innen, wenn eine CI-Pipeline aufgrund einer Sicherheitslücke fehlschlägt? Wahrscheinlich erwarten Sie, dass sie die Lücke beheben. Das ist gut, aber die meisten Tools und Integrationen lassen den Build einfach fehlschlagen – unabhängig davon. Hier zeigt sich Snyks Entwickler:innen-zuerst-Ansatz. Die CI-Integration bietet ein Flag, mit dem Sie den Build nur dann fehlschlagen lassen, wenn für die gefundenen Probleme eine Behebung verfügbar ist. So können Entwickler:innen die Sicherheitsprobleme tatsächlich beheben, statt endlos Schwachstellen zu analysieren und erst dann festzustellen, dass es keine Lösung gibt.

Um all diese Sicherheitsvorteile zu nutzen, rufen Sie die relevanten Integrationseinstellungen für Ihre Umgebung auf, zum Beispiel für GitHub, und passen Sie die Bedingungen für fehlgeschlagene Builds an, wenn snyk Pull Requests testet. Zum Beispiel:

Snyk-Einstellungsseite mit einer verbundenen GitHub-Integration und aktivierten standardmäßigen Sicherheitstests für Pull Requests.

Priorisieren Sie Schwachstellen, die über Ihren eigenen Code erreichbar sind

Herausforderung: Es fällt Ihnen schwer, zu entscheiden, welche Open-Source-Komponenten zuerst behoben werden sollten. Zum Beispiel:

  • In meinen Open-Source-Bibliotheken gibt es viele Sicherheitslücken. Aber woran erkenne ich, welche Bibliothek im Produktivcode verwendet wird?

  • Entwickler:innen sagen: „Ja, wir verwenden diese Open-Source-Bibliothek. Aber wie können wir feststellen, ob wir die Klasse oder Methode verwenden, in der die Sicherheitslücke besteht?“

Lösung: Snyk weiß, dass Entwickler:innen und Security-Engineers eine bessere Möglichkeit brauchen, die Arbeit zur Analyse Hunderter Schwachstellen zu priorisieren. Snyk löst dieses Problem durch statische Codeanalyse. Damit wird ermittelt, ob eine Sicherheitslücke in einer von Ihnen verwendeten Open-Source-Bibliothek eines Drittanbieters von Ihrem eigenen Code (First-Party-Code) aus erreichbar ist.

Snyk versteht den Kontext, in dem eine Schwachstelle gefunden wurde, und priorisiert ihre Behebung, um Geschäftsrisiken und Zeiträume mit erhöhtem Risiko zu reduzieren.

Technisch basiert die Funktion für erreichbare Schwachstellen auf einem Snyk-Algorithmus, der anhand des Aufrufgraphen Ihres Anwendungscodes Verbindungen zu den Open-Source-Abhängigkeiten des Projekts herstellt.

Derzeit gilt die Unterstützung der Analyse erreichbarer Schwachstellen durch Snyk nur für Java-, Maven- und Gradle-Projekte. Sie ist nur bei CLI-Tests oder in der Snyk-Benutzeroberfläche verfügbar, wenn Sie ein Projekt testen. Git-Unterstützung folgt in Kürze!

Ermitteln Sie Sicherheitslücken danach, ob sie von Ihrem Code aus erreichbar sind:

  1. Stellen Sie sicher, dass Sie die neueste Snyk-CLI-Version verwenden

  2. Navigieren Sie zum Ordner Ihrer Anwendung und zu den relevanten Manifestdateien.

  3. Führen Sie snyk test --reachable aus

Wenn erreichbare Schwachstellen gefunden werden, sieht die Testausgabe ähnlich wie im folgenden Screenshot aus:

Terminalausgabe mit vier Problemen bei Abhängigkeiten und einem erreichbaren Schwachstellenpfad, der durch ein Upgrade von Apache HttpComponents behoben wurde.

All diese Informationen können Sie auch in der Snyk-Benutzeroberfläche überwachen.

Übertragen Sie einen Snapshot dieses Manifests an Snyk. So können wir es kontinuierlich überwachen und Sie über Änderungen benachrichtigen. Führen Sie zum Überwachen des Projekts folgenden Befehl aus:

snyk monitor --reachable

Nun können wir alle Sicherheitsprobleme nach erreichbaren Schwachstellen filtern und diese zuerst zur Behebung priorisieren:

Dashboard für Sicherheitslücken mit einer erreichbaren Directory-Traversal-Sicherheitslücke mittlerer Schwere in Apache HttpClient sowie Angaben zur Behebung und zu Erreichbarkeitspfaden.

Weitere Informationen zur Funktion für erreichbare Schwachstellen finden Sie in den folgenden Blogbeiträgen:

Richtlinien zur Lizenz-Compliance

Herausforderung: Wenn Sie mit den folgenden Anliegen der Rechtsabteilung zu kämpfen haben, benötigen Sie Enterprise-Sicherheitssoftware:

  • Wir benötigen eine Liste aller Ihrer Open-Source-Bibliotheken aus sämtlichen Anwendungsprojekten.

  • Wir dürfen keinesfalls gegen Lizenz- und Urheberrechtsgesetze verstoßen, indem wir unwissentlich Copyleft-Software vertreiben, die gegen ihre Lizenzbedingungen verstößt.

Lösung: Mit Snyk können Sie Herausforderungen rund um Enterprise-Sicherheit und Lizenz-Compliance auf zwei Arten bewältigen:

  • Sie erhalten einen Bericht über die Lizenznutzung in all Ihren Projekten, den Sie als CSV-Datei exportieren können.

  • Sie können Lizenzrichtlinien für Open-Source-Software auf Projekt- und Organisationsebene festlegen und durchsetzen, um die Vorgaben der Rechtsabteilung Ihres Unternehmens einzuhalten.

Softwarelizenzverwaltung

Im Tab Berichte von Snyk können Sie bei Bedarf die Lizenzen aller importierten Projekte und Organisationen einsehen.

Sie können die Liste nach Bedarf filtern oder nach der Anzahl der Abhängigkeiten oder Projekte sortieren, die von bestimmten Lizenzen betroffen sind. So lassen sich rechtliche Anforderungen, die aufgrund bestimmter Lizenzverstöße erfüllt werden müssen, schnell priorisieren.

Wenn Sie die Liste zur Zusammenarbeit mit einem anderen Team in einer Tabellenkalkulation exportieren möchten, klicken Sie einfach auf Als CSV exportieren, um eine Software-Stückliste mit Ihren Lizenzen zu erstellen.

Snyk Reports-Lizenzseite mit Projekttypen für Lizenzen, Abhängigkeitsanzahl, Projektanzahl und einer Schaltfläche „Als CSV exportieren“.

Lizenzrichtlinien

Unternehmensweite Lizenzrichtlinien sind wichtig, damit Ihr Unternehmen keine rechtlichen Schritte wegen unsachgemäßer Verwendung von Softwarebibliotheken riskiert oder – noch schlimmer – gegen die Lizenzbedingungen verstößt.

Um dieser Herausforderung zu begegnen, können Sie mit Snyk Lizenzrichtlinien für Projekte festlegen. So schlagen Lizenzprüfungen im Build oder in einer CI-Pipeline fehl, wenn die Vorgaben nicht erfüllt werden.

Sie können solche Sicherheitsrichtlinien sehr granular konfigurieren und auf Projekte anwenden, die bestimmte Attribute erfüllen. So haben Teams genügend Freiraum, eigenständig zu arbeiten, während die nötigen Leitplanken bestehen bleiben.

Wie richten Sie eine Richtlinie in der Snyk-Benutzeroberfläche ein?

Richtlinien werden auf Gruppenebene eingerichtet. Sie müssen daher Gruppenadministrator:in sein. Die Richtlinien gelten für alle Organisationen und Projekte, die zu bestimmten Gruppen gehören.

Snyk Policy Manager mit der Standard-Lizenzrichtlinie, die auf eine Organisation angewendet wird.

Wie Sie sehen, wendet Snyk bereits eine standardmäßige Lizenz-Compliance-Richtlinie an, die auf die Anforderungen von Unternehmen zugeschnitten ist. Sie können sie weiter an Ihre eigenen rechtlichen Vorgaben anpassen.

Snyk-Lizenzrichtlinien-Oberfläche mit Lizenznamen, Einstellungen für hohe und mittlere Schweregrade sowie einem Beschreibungsfeld

Projekte effektiv kategorisieren

Herausforderung: Daran erkennen Sie, dass Sie Enterprise-Sicherheitslösungen dringend benötigen:

  • Entwickler:innen und Security-Engineers verbringen viel Zeit damit, die Projekte zu finden, um die sie sich kümmern müssen.

  • Sie versinken in einer Flut von Sicherheitslücken und wissen nicht, wo Sie anfangen sollen.

Lösung: Richten Sie Projekte mit Attributen zur geschäftlichen Bedeutung und Metadaten zum Tech-Stack ein. So werden die angemessene Kritikalität des Dienstes, Details zur Bereitstellungsumgebung und die Merkmale der Anwendung berücksichtigt und die Zuordnung zum Frontend oder Backend korrekt abgebildet.

Zusatzpunkte: Mit Snyk berücksichtigen Enterprise-Sicherheitslösungen das Feedback unserer Kunden. Wir hören wirklich zu – deshalb wissen wir, was wir entwickeln sollten. Hier ist noch eine Möglichkeit, die Zuständigkeit für eine Anwendung innerhalb Ihrer Organisation zu ermitteln: Es gibt ein eigenes Feld _Project owner_field, das Sie einer beliebigen Person oder einem beliebigen Entwickler zuweisen können, der Zugriff auf das Snyk-Projekt hat.

Wenn Sie sich lieber ein Video dazu ansehen möchten, finden Sie hier eine kurze Zusammenfassung dazu, wie Sie Ihre Projekte anhand von Attributen und Projekt-Tags verwalten:

Managing Projects at Scale with Snyk
Snyk-Projektübersicht für package.json mit Schwachstellen, Projektdetails und geöffnetem Dropdown-Menü zur Auswahl des Projektverantwortlichen.

Die folgende Projektliste kann auf den ersten Blick einschüchternd wirken, oder?

Mit welchem Projekt sollte ich anfangen? Wie kann ich diese Projektliste für meine gesamte Organisation oder Geschäftseinheit filtern?

Snyk Projects-Dashboard mit einer Liste von Projekten und hohen, mittleren und niedrigen Schwachstellenzahlen sowie Links zu Berichten.

Wenn Sie im Bereich SecOps, also Security Operations, tätig sind, kennen Sie diese Herausforderungen wahrscheinlich. Als Sicherheitsverantwortliche oder Sicherheitsverantwortlicher in der Organisation – etwa als Security Champion oder Teamleitung – wünschen Sie sich vermutlich Unterstützung, um Enterprise-Sicherheitsfragen angemessen anzugehen.

So lösen wir dieses Problem mit Snyk – ein Bild sagt mehr als tausend Worte. Hier sehen Sie die Filter auf der linken Seite, mit denen Sie Ihre Projekte anhand der folgenden Kriterien filtern können:

  • Probleme und behebbare Schwachstellen – ein besonders leistungsstarker Filter. So können Sie sicherstellen, dass sich Ihre Entwickler zuerst auf tatsächlich behebbare Sicherheitslücken konzentrieren und keine Zeit mit der Triage und Validierung nicht behebbarer Probleme verschwenden. Enterprise-Sicherheit leicht gemacht!

  • Integrationen – durchsuchen Sie Projekte nach ihrer Quelle. Suchen Sie ein Projekt, das über die Snyk CLI überwacht wird? Möchten Sie alle Projekte aus der GitLab- oder Bitbucket-Cloud-Integration finden?

  • Umgebung – um welche Art von Projekt handelt es sich? Frontend? Backend? Vielleicht ist es eine mobile Anwendung, die Sie mit der brandneuen Gradle-Plugin-Unterstützung von Snyk überwachen? Filtern Sie hier schnell.

  • Lebenszyklus – in der Enterprise-Sicherheitsarchitektur müssen Sicherheitsrichtlinien häufig berücksichtigen, ob eine Anwendung öffentlich zugänglich ist. Wird eine Anwendung beispielsweise ausschließlich intern von Mitarbeitern eines Unternehmens genutzt, kann ihre Kritikalität geringer sein. Mit diesem Lebenszyklusattribut können Sie Projekte danach festlegen und filtern, ob sie in der Produktion, im Staging oder in einer anderen Umgebung bereitgestellt werden.

    Snyk Projects-Dashboard mit Projekten und der Anzahl kritischer, mittelschwerer und geringfügiger Probleme sowie Filtern für Integrationen und Umgebungen

So habe ich eines meiner Projekte konfiguriert, damit ich es mithilfe der sicherheitsbezogenen Filter ganz einfach in der Projektliste finden kann:

Snyk-Projektübersicht für package.json mit angezeigten Sicherheitslücken und geöffnetem Dropdown-Menü „Umgebung“ mit Frontend, Backend, Intern, Extern, Mobil und Saa

Laden Sie den Leitfaden zu Best Practices für Enterprise-Sicherheit herunter.

Möchten Sie mehr dazu lesen?

Lesen Sie mehr darüber, wie Sie mit Snyk erfolgreich skalieren – direkt vom Produktteam von Snyk.

In der Snyk-Wissensdatenbank finden Sie Dokumentation zu Projektattributen und ihrer Einrichtung.

Starten Sie mit Capture the Flag

Erfahren Sie in unserem virtuellen On-Demand-Workshop für Einsteiger, wie Sie Capture-the-Flag-Herausforderungen lösen.