Security Incident Response in der DFN-AAI

Wir bitten darum, in der Metadatenverwaltung pro IdP/SP eine E-Mail-Adresse als Security-Kontakt zu hinterlegen und den Empfehlungen des Sirtfi Frameworks zu folgen.

Bei Sicherheitsvorfällen, die auch andere Föderationsteilnehmer betreffen, erreichen Sie uns so:

E-Mail: security@aai.dfn.de, Telefon: +49-30-884299-9127

Diese Seite fasst die folgenden englischsprachigen Dokumente zusammen: AARC Deliverable DNA3.2 Security Incident Response Procedure und A Security Incident Response Trust Framework for Federated Identity (Sirtfi) von REFEDS. Es geht um Best Practices für die Handhabung von IT-Sicherheitsvorfällen in der DFN-AAI und darum, was teilnehmende Organisationen darüber hinaus tun können, um sich am offiziellen Sirtfi Framework zu beteiligen.

Sirtfi (sprich: „certify“) steht für „Security Incident Response Trust Framework for Federated Identity“. Dieses Framework beschreibt einen geregelten Umgang mit Sicherheitsvorfällen in Föderationen. Was ist zu tun, wenn ein Benutzeraccount einer Hochschule gehackt wird und jemand mit den Zugangsdaten Verlagsinhalte abzusaugen beginnt? Was, wenn die Datenbank eines Service Providers abhanden kommt, egal ob sie Benutzer- oder Forschungsdaten enthält? Von Sicherheitsvorfällen ist in einer föderierten Infrastruktur wie der DFN-AAI schnell mehr als nur eine Organisation betroffen. Die Handhabung eines solchen Problems muss daher organisationsübergreifend innerhalb der Föderation geschehen, oder sogar international, auf föderationsübergreifender Ebene (eduGAIN). Obwohl die einzelnen Schritte sich nicht grundlegend von denen sonstiger Incident Response Prozeduren im IT-Umfeld unterscheiden, wird die Reaktion durch Verteiltheit und Diversität der Systeme und die Abwesenheit einer zentralen Stelle erschwert. Die Spezifikation dieses Frameworks wird von REFEDS publiziert, einer internationalen Kooperationsgruppe von Föderationen im Bereich Forschung und Lehre.

Die unten vorgestellten Best Practices für den Umgang mit IT-Sicherheitsvorfällen basieren darauf, dass es in der DFN-AAI wie in den meisten Föderationen eben keine zentrale Governance-Struktur gibt. Sie setzen stattdessen auf die Bereitschaft der beteiligten Organisationen, sich freiwillig auf Regeln für den Betrieb ihrer IT-Infrastruktur im Bereich AAI zu verpflichten. Organisationen, die sich bewusst in die Lage versetzen, Sicherheitsvorfälle auch im Föderationsumfeld kompetent zu handhaben, stärken ihre eigene Vertrauenswürdigkeit in der Community. Sie garantieren damit anderen Föderationsteilnehmern, dass die eigene Organisation sich auf gemeinsame, grundlegende Regeln verpflichtet. Sie zeigen nicht nur ihre Fähigkeit, sondern auch ihren expliziten Willen, bei sicherheitsrelevanten Vorfällen mit anderen Teilnehmern zusammenzuarbeiten.


Die unten formulierten Handlungsempfehlungen orientieren sich am AARC Deliverable DNA3.2 Security Incident Response Procedure, es beschreibt unter Bezugnahme auf Sirtfi entsprechende Rollen und Maßnahmen, die bei einem Security Incident zum Tragen kommen.

Definitionen

  • Sicherheitskontakt der DFN-AAI: Die auf der Website der DFN-AAI angebene Kontaktadresse für Security Incidents ist die erste Eskalationsstufe außerhalb der eigenen Organisation.
  • Koordinierungsstelle für die Reaktion auf sicherheitsrelevante Vorfälle: Die Bearbeitung eines Vorfalls innerhalb der Föderation oder in Zusammenarbeit mit eduGAIN wird zunächst vom CERT der DFN-AAI koordiniert. Bei föderationsübergreifenden Incidents ist das eduGAIN Support Team hinzuzuziehen.
  • Traffic Light Protocol (TLP): Das Traffic Light Protocol ist ein Schema, nach dem Absender von Informationen anzeigen können, an welche Empfängerkreise diese weitergegeben werden dürfen. Es unterscheidet anhand von vier Farben unbegrenzte öffentliche Weitergabe, organisationsübergreifende Weitergabe, organisationsinterne Verteilung und die persönliche Weitergabe an den Kreis der Anwesenden (siehe auch das deutschsprachige Merkblatt vom BSI).
  • „meldenswerter“ Security Incident / Wo ist die Schwelle zum sicherheitsrelevanten Vorfall?

Maßnahmen für Teilnehmende

  • Einhaltung bestehender organisationsinterner Prozesse: Bereits bestehende organisationsinterne Prozesse zum Umgang mit sicherheitsrelevanten Vorfällen in der IT-Infrastruktur werden durch diese Regelung nicht berührt. Sie werden als erstes befolgt. Die Organisation leitet alle nötigen Maßnahmen zur Schadensbegrenzung ein.
  • Meldepflicht: Der Sicherheitskontakt des CERTs der DFN-AAI ist innerhalb eines Werktags nach Bekanntwerden über den Vorfall zu informieren und auf dem Laufenden zu halten. Er ist per E-Mail unter security@aai.dfn.de oder telefonisch unter (+49) 030 / 88 42 99 - 9127 erreichbar.
  • Analyse und Bericht: Die (zuerst) betroffene Organisation analysiert den sicherheitsrelevanten Vorfall und berichtet dem Föderationsbetreiber und der Koordinierungsstelle innerhalb von 14 Tagen, welche Maßnahmen zur Behebung und künftigen Verhinderung des Problems oder Fehlers ergriffen wurden. Der Bericht erfolgt in einem Formular, das der Föderationsbetreiber zur Verfügung stellt.
  • Kommunikation mit anderen betroffenen Organisationen: Die betroffene Organisation steht für Rückfragen aus der Föderation zur Verfügung und beantwortet sie in einem Zeitraum von ein bis zwei Werktagen. Die Antworten gehen stets an alle weiteren betroffenen Organisationen, um den Umfang der Rückfragen möglichst gering zu halten und um zu gewährleisten, dass alle Betroffenen auf demselben Stand sind.
  • Wiederinbetriebnahme der betroffenen Systeme: Erst nachdem die betroffenen Systeme repariert bzw. abgesichert sind, werden sie wieder in Betrieb genommen.
  • Abschlussbericht: Ein abschließender Bericht zum sicherheitsrelevanten Vorfall wird in Zusammenarbeit mit dem Sicherheitskontakt der Föderation bzw. der Koordinierungsstelle für die Reaktion auf sicherheitsrelevante Vorfälle erstellt und allen Beteiligten zur Verfügung gestellt. Für das Verteilen dieser möglicherweise sensiblen Informationen empfiehlt der DFN-Verein das Traffic Light Protocol (TLP). In der Regel wird TLP Amber zur Anwendung kommen.
  • Lessons Learned: Die betroffene Organisation aktualisiert im Nachgang ihre Prozesse und Dokumentation.

Maßnahmen für den Föderationsbetreiber

  • Koordination der Bearbeitung des Vorfalls: Das CERT der DFN-AAI ist Sicherheitskontakt und Koordinierungsstelle für die Reaktion auf Sicherheitsvorfälle.
  • Information betroffener Organisationen: Die Koordinierungsstelle übernimmt die Information aller von dem Vorfall betroffenen Föderationsteilnehmer. Wurde ein Security-Kontakt hinterlegt, wird nur dieser Kontakt informiert. Fehlt diese Angabe, wird der technische Kontakt informiert, der in den Metadaten veröffentlicht ist. Die Information erfolgt per E-Mail und ist stets von der Koordinierungsstelle für die Reaktion auf Sicherheitsvorfälle signiert.
  • Unterstützung beim „Berichtswesen“: Als Föderationsbetreiber stellt der DFN-Verein eine Checkliste bereit, mit der betroffene Organisationen ihren Bericht über den sicherheitsrelevanten Vorfall einreichen.
  • Unterstützung bei datenschutzkonformer Zusammenarbeit: Der DFN-Verein bietet den Organisationen, die an der DFN-AAI teilnehmen, einen DSGVO-konformen Passus für ihre Datenschutzregelungen an. Er kann genutzt werden, um dem berechtigten Interesse (Art. 6 Abs. 1 Buchst. f gem. Erwägungsgrund 49) anderer Föderationsteilnehmer nachzukommen, die ggf. Logdateien anfragen, um ihre eigenen Systeme zu prüfen.
  • Dokumentation: Sicherheitsrelevante Vorfälle in der DFN-AAI werden dokumentiert.

Maßnahmen für die Koordinierungsstelle für die Reaktion auf sicherheitsrelevante Vorfälle

  • ggf. Information von eduGAIN: Wenn Teilnehmer aus anderen Föderationen von dem Vorfall betroffen sind, informiert die Koordinierungsstelle für die Reaktion auf sicherheitsrelevante Vorfälle den eduGAIN Security Contact.
  • Verantwortung: Die Koordinierungsstelle ist dafür verantwortlich, dafür zu sorgen, dass der Vorfall angemessen bearbeitet wird, sowohl an den betroffenen Organisationen als auch föderationsweit bzw. eduGAIN-weit.
  • Ansprechbarkeit: Die Reaktionszeit bei der Kommunikation über den Vorfall liegt bei einem Werktag.
  • Bericht: Die Koordinierungsstelle ist an der Erstellung eines Abschlussberichtes zu jedem Vorfall beteiligt (Checkliste).

Teilnehmende Organisationen, die sich offiziell auf die Regeln des Sirfti-Frameworks verpflichten möchten, müssen einige Schritte unternehmen, um in ihren Metadaten das zusätzliche Entity Attribut veröffentlichen zu dürfen. Die Teilnahme ist freiwillig.

Definitionen

  • Sirtfi (sprich: „certify“): Die Abkürzung steht für „Security Incident Response Trust Framework for Federated Identity“. Das Framework wird seit 2014 von der gleichnamigen REFEDS-Arbeitsgruppe entwickelt. Ziel ist es, den Umgang mit Security Incidents, von denen mehrere Föderationsteilnehmer betroffen sind, zu koordinieren. Die erste Version ist bewusst niedrigschwellig gehalten, damit der Einstieg möglichst vielen Föderationsteilnehmern offen steht.

Teilnahmevoraussetzungen

  • Jede Sirtfi-konforme Organisation verpflichtet sich freiwillig und auf der Basis einer Selbsteinschätzung auf unten angeführte Regeln.
  • Ein Security-Kontakt muss festgelegt und in den Metadaten publiziert sein.

Regeln

Siehe hierzu auch die Sirtfi FAQ.

  • Operational Security [OS]
    (Betriebssicherheit)
    Managing access to information resources, maintaining their availability and integrity, and maintaining confidentiality of sensitive information is the goal of operational security.
    • [OS1]: Security patches in operating system and application software are applied in a timely manner.
      (Zeitnahes Einspielen von Sicherheitsupdates in Betriebssystemen und Applikationen)
    • [OS2]: A process is used to manage vulnerabilities in software operated by the organisation.
      (Es gibt einen Prozess, mit dem Sicherheitslücken in der eingesetzten Software behandelt werden.)
    • [OS3]: Mechanisms are deployed to detect possible intrusions and protect information systems from significant and immediate threats
      (Die Organisation verfügt über Mechanismen zur Intrusion Detection und für den Schutz vor unmittelbaren, relevanten Bedrohungen.)
    • [OS4]: A user’s access rights can be suspended, modified or terminated in a timely manner.
      (Zugriffsrechte eines Nutzers können kurzfristig entzogen, gelöscht oder modifiziert werden.)
    • [OS5]: Users and Service Owners (as defined by ITIL) within the organisation can be contacted.
      (Innerhalb der Organisation können BenutzerInnen und Dienstverantwortliche (wie in ITIL definiert) kontaktiert werden.
    • [OS6]: A security incident response capability exists within the organisation with sufficient authority to mitigate, contain the spread of, and remediate the effects of a security incident.
      (Innerhalb der Organisation existieren die erforderlichen Mechanismen und Berechtigungen, um sicherheitsrelevante Vorfälle zu entschärfen, einzudämmen und ihre Folgen zu beseitigen.
  • Indicent Response [IR]
    (Reaktion auf sicherheitsrelevante Vorfälle)
    Assertion [OS6] above posits that a security incident response capability exists within the organisation. This section’s assertions describe its interactions with other organisations participating in the Sirtfi trust framework.
    • [IR1]: Provide security incident response contact information as may be requested by an R&E federation to which your organization belongs.
      (Benennung eines Kontakts für Sicherheitsvorfälle)
    • [IR2]: Respond to requests for assistance with a security incident from other organisations participating in the Sirtfi trust framework in a timely manner
      (Kurzfristige Reaktion auf Rückfragen anderer Föderationsteilnehmer, die einen Sicherheitsvorfall betreffen.)
    • [IR3]: Be able and willing to collaborate in the management of a security incident with affected organisations that participate in the Sirtfi trust
      (Fähigkeit und Bereitschaft, im Falle eines Vorfalls mit anderen an Sirfti teilnehmenden Organisationen zusammenzuarbeiten)
    • [IR4]: Follow security incident response procedures established for the organisation.
      (Befolgung organisationsinterner Prozesse für Incident Response)
    • [IR5]: Respect user privacy as determined by the organisations policies or legal counsel.
      (Der Schutz der Privatsphäre von NutzerInnen wird entsprechend der Rechtslage und der organisationsinternen Richtlinien berücksichtigt)
    • [IR6]: Respect and use the Traffic Light Protocol TLP information disclosure policy.
      (Das Traffic-Light-Protokoll (TLP) wird bei der Informationsweitergabe befolgt und berücksichtigt.)
  • Traceability [TR]
    (Nachvollziehbarkeit)
    To be able to answer the basic questions „who, what, where, and when“ concerning a security incident requires retaining relevant system generated information, including accurate timestamps and identifiers of system components and actors, for a period of time.
    • [TR1]: Relevant system generated information, including accurate timestamps and identifiers of system components and actors, are retained and available for use in security incident response procedures.
      (Alle relevanten, computergenerierten Informationen werden für eine bestimmte Zeit gespeichert und stehen für die Bearbeitung von Sicherheitsvorfällen zur Verfügung, einschließlich exakten Zeitstempeln und Kennungen von Systemkomponenten und AkteurInnen.)
    • [TR2]: Information attested to in [TR1] is retained in conformance with the organisation’s security incident response policy or practices.
      (Das Vorhalten dieser Informationen erfolgt konform mit den organisationsinternen Richtlinien.))
  • Participant Responsibilities [PR]
    (Verantwortung der teilnehmenden Organisationen)
    All participants (IdPs and SPs) in the federations need to rely on appropriate behavior.
    • [PR1]: The participant has an Acceptable Use Policy (AUP).
      (Die Organisation hat für die AAI-relevanten Dienste Nutzungsbedingungen.)
    • [PR2]: There is a process to ensure that all users are aware of and accept the requirement to abide by the AUP, for example during a registration or renewal process. (Die Organisation stellt sicher, dass alle BenutzerInnen die Nutzungsbedingungen kennen und annehmen.)

1. Erstbewertung und Feststellung eines Security Incidents

  • Wenn Ihnen Anomalien an Ihren Systemen auffallen, untersuchen Sie sie, um zu bewerten, ob es einen unbefugten Zugriff auf Ressourcen gab oder noch gibt.
  • Wenn Zugangsdaten zu einem oder mehreren Benutzeraccounts gestohlen wurden, sperren Sie diese(n) Account(s) umgehend.
  • Falls nötig, kündigen Sie die vorübergehende Abschaltung eines betroffenen Dienstes an und nehmen Sie ihn vom Netz.
  • Sichern Sie Spuren! Kopieren Sie Logdateien auf die Seite, damit sie nicht bei der Rotation gelöscht werden. Verhindern Sie eine nachträgliche Manipulation der Logs. Sichern Sie alles, was relevant sein könnte, lieber zu viel als zu wenig!

2. Befolgung organisationsinterner Prozesse

Ihre Organisation hat eigene Prozesse, wie sie mit Security Incidents umgeht. Diesen folgen Sie zuerst. Sie unternehmen in dem Rahmen sowieso Schritte zum Containment und dokumentieren sie.

3. Meldung an den Sicherheitskontakt der DFN-AAI

  • Nehmen Sie sich unsere Berichtsvorlage und tragen Sie alle bereits bekannten Informationen zusammen.
  • Melden Sie den Vorfall mit diesen Informationen bei unserer Security-Mailadresse oder Telefonnummer (s.o.). Wir unterstützen Sie beim weiteren Vorgehen.
  • Die ggf. nötige Information weiterer Föderationsteilnehmer übernimmt der Sicherheitskontakt der DFN-AAI. Nach dem Need-to-know-Prinzip werden nur betroffene Föderationsteilnehmer informiert.

4. Analyse des Vorfalls

  • Analysieren Sie den Vorfall: Was ist geschehen? Wer ist betroffen? Worauf wurde unbefugt zugegriffen? Wie konnte es dazu kommen?
  • Halten Sie sich für Rückfragen aus der Föderation verfügbar.

5. Teilen Sie neue Erkenntnisse so oft wie möglich

  • Halten Sie die Beteiligten auf dem neuesten Stand Ihres Wissens über den Vorfall.

6. Beantwortung und Dokumentation von Rückfragen

  • Halten Sie sich für Rückfragen anderer betroffener Föderationsteilnehmer bereit. Sirtfi-compliant zu sein, bedeutet, Rückfragen innerhalb eines lokalen Werktages zu beantworten.
  • Alle Beteiligten erhalten die Rückfragen und Antworten, um den Umfang der Rückfragen aus das nötige Minimum zu reduzieren und zu gewährleisten, dass alle auf demselben Stand sind
  • Dokumentieren Sie alle Rückfragen und Ihre Antworten für den Abschlussbericht.
  • Bitte beachten Sie bei der Herausgabe von Logdateien, dass sie personenbezogene Daten enthalten können. Sie sollten sie nur in anonymisierter Form an Dritte weitergeben.

7. Fehlerbehebung und Wiederinbetriebnahme der betroffenen Dienste/Server

  • Beheben Sie das Problem und nehmen Sie erst danach den betroffenen Dienst wieder in Betrieb.
  • Dokumentieren Sie alle unternommenen Schritte für den Abschlussbericht.

8. Abschlussbericht

  • Reichen Sie einen Abschlussbericht bei der Koordinierungsstelle ein. Er soll alle Punkte umfassen, die unsere Vorlage beinhaltet.
  • Die Verteilung des Berichts an alle Betroffenen übernimmt die Koordinierungsstelle.
  • Die Weitergabe des Abschlussberichtes unterliegt - soweit nicht anders besprochen - dem Traffic Light Protocol Amber.

9. Aktualisierung von Dokumentation und Prozessen

  • Aktualisieren Sie Ihre organisationsinterne Dokumentation und Prozesse mit dem neu Gelernten.
  • Zuletzt geändert: vor 6 Wochen