Security Incident Response in der DFN-AAI

Mit der Anzahl der verfügbaren Diensten (Service Provider) und teilnehmenden Einrichtungen (Identity Provider) vergrößert sich in einer Föderation auch die Angriffsfläche für Attacken aller Art. Auf Seiten der Identity Provider ist dies typischerweise Identitätsdiebstahl und der damit verbundene illegale Zugriff auf geschützte Daten sowie andere Ressourcen bei Service Providern. Bei Service Providern besteht die Gefahr, dass im Falle eines Angriffs unberechtigte Dritte Zugriff auf personenbezogene oder sonstige Nutzerdaten erlangen. In beiden Fällen ist es wichtig, die jeweilige(n) Gegenstelle(n) rechtzeitig zu informieren und die bestehenden Sicherheitslücken schnellstmöglich zu schließen.

Das Incident Response Team des DFN-CERT hat gemeinsam mit dem Team der DFN-AAI Prozesse und Kommunikationskanäle definiert, die bei Sicherheitsvorfällen mit AAI-Bezug eine schnelle Eindämmung des Problems unter Einbeziehung aller Betroffenen ermöglichen.

Diese Seite fasst die folgenden englischsprachigen Dokumente zusammen: AARC Deliverable I051: Guide to Federated Security Incident Response for Research Collaboration, sowie Version 1 und Version 2 der REFEDS-Spezifikation des Security Incident Response Trust Framework for Federated Identity (Sirtfi). 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.
Metadatentechnisch wird die Sirtfi-Compliance über ein Entity Attribut ausgedrückt.

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 an der diesbezüglichen Dokumentation im GÉANT Wiki. Hier werden unter Bezugnahme auf Sirtfi entsprechende Rollen und Maßnahmen beschrieben, die bei einem Security Incident zum Tragen kommen.

• 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 Incident Resonse Team des DFN-CERT koordiniert, die Kontaktdaten finden sich oben im Kasten "Was tun im Fall eines Incidents?". Bei föderationsübergreifenden Incidents ist das eduGAIN Security Team hinzuzuziehen. Siehe hierzu auch unter https://wiki.geant.org/display/eduGAIN/eduGAIN+Security
• 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?

https://wiki.geant.org/display/AARC/Procedure+for+Federation+Participants

• 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) 040 808077-590 erreichbar.
• Analyse und Bericht: Die (zuerst) betroffene Organisation analysiert den sicherheitsrelevanten Vorfall und berichtet dem Föderationsbetreiber und der Koordinierungsstelle innerhalb eines Monats, 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 innerhalb eines Werktags. 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.
  Liste der Security- und sonstigen Kontakte in der DFN-AAI: unter https://tools.aai.dfn.de/entities/ auf „All Contacts“ klicken
• 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.

https://wiki.geant.org/display/AARC/Procedure+for+Federations

• 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.
  Liste der Security- und sonstigen Kontakte in der DFN-AAI: unter https://tools.aai.dfn.de/entities/ auf „All Contacts“ klicken
• 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.

• 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.

• 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. Die Version 2 beinhaltet alle Punkte der Version 1, ergänzt und präzisiert diese jedoch.

Die Konformität mit Sirtfi(2) wird in den Föderationsmetadaten über ein entsprechendes Entity Attribut modelliert.

• 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.

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]: Means are implemented to detect and act on possible intrusions using threat intelligence information in a timely manner.
    (Die Organisation verfügt über Mechanismen zur zeitnahen 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 Sirtfi. They are intended to augment but not supersede local procedures when an incident may extend beyond the organisation.
  • [IR1]: Provide security incident response contact information as may be requested by any 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 Sirtfi in a timely manner
    (Kurzfristige Reaktion auf Rückfragen anderer Föderationsteilnehmer, die einen Sicherheitsvorfall betreffen.)
  • [IR3]: Notify security contacts of entities participating in Sirtfi when a security incident investigation suggests that those entities are involved in the incident. Notification should also follow the security procedures of any federations to which your organisation belongs.
    (Benachrichtigung der Sicherheitskontakte anderer Sirtfi-Teilnehmer, wenn die Untersuchung eines Incidents nahelegt, dass diese ebenfalls betroffen sind. Die Benachrichtigung sollte darüber hinaus den Sicherheitsprozeduren aller Föderationen folgen, an denen die betreffende Organisation teilnimmt)
  • [IR4]: Be able and willing to collaborate in the management of a security incident with affected organisations that participate in Sirtfi
    (Fähigkeit und Bereitschaft, im Falle eines Vorfalls mit anderen an Sirfti teilnehmenden Organisationen zusammenzuarbeiten)
  • [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.)
• User Rules and Conditions [UR]
  (Verantwortung der teilnehmenden Organisationen gegenüber den Endnutzer:innen)
  Identity Providers and Service Providers (participants) have a responsibility to notify users that their access may be controlled following unauthorised use, such as during a security incident. The definition of authorised use may be communicated to the user via an Acceptable Usage policy, terms and conditions, contract or other agreement. This may be done directly between the participant and the user, or between a third party and the user in the case that operation of a system has been delegated.
  • [UR1]: The participant has defined rules and conditions of use.
    (Die Organisation hat für die AAI-relevanten Dienste Nutzungsbedingungen.)
  • [UR2]: There is a process to notify all users of these rules and conditions of use.
    (Die Organisation stellt sicher, dass alle BenutzerInnen die Nutzungsbedingungen kennen und annehmen.)

• 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!

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.

• 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 (siehe oben). 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.

• 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.

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

• Halten Sie sich für Rückfragen anderer betroffener Föderationsteilnehmer bereit. Sirtfi-compliant zu sein, bedeutet, Rückfragen möglichst zeitnah, idealerweise 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.

• Beheben Sie das Problem und nehmen Sie erst danach den betroffenen Dienst wieder in Betrieb.
• Dokumentieren Sie alle unternommenen Schritte für den 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.

• Aktualisieren Sie Ihre organisationsinterne Dokumentation und Prozesse anhand des neu Gelernten.