Richtlinien zur verantwortungsvollen Offenlegung

image

Richtlinien zur verantwortungsvollen Offenlegung

Informationen, Daten mit zugrunde liegenden Prozessen, Informationssysteme und Netzwerke sind für die Geschäftstätigkeiten von Bühler, die unserer Kunden und unserer Geschäftspartner von entscheidender Bedeutung. Die Wahrung der Vertraulichkeit, Integrität und Verfügbarkeit von wertvollen Informationen stellt einen wesentlichen Bestandteil unserer Verpflichtung dar, das Vertrauen unserer Kunden und Geschäftspartner zu würdigen. Wenn Sie Sicherheitsprobleme oder Sicherheitslücken gefunden haben, dann würden wir uns sehr freuen, wenn Sie uns diese melden. Das folgende Dokument beschreibt den Rahmen dafür, wie eine solche Meldung und eine verantwortungsvolle Offenlegung für Bühler definiert sind.

+

Meldungen

Zuständig für die Bearbeitung solcher Meldungen ist das Informationssicherheits-Team von Bühler, welches Sie unter folgender Adresse erreichen: security[at]buhlergroup.com.

Wenn Sie Sicherheitslücken melden, dann geben Sie bitte die folgenden Punkte an:

  • Art der Sicherheitslücke.
  • Genaue Beschreibung der Sicherheitslücke und der betroffenen Elemente/Ressourcen.
  • Eine genaue Beschreibung, warum es sich Ihrer Ansicht nach um ein Sicherheitsproblem oder eine Sicherheitslücke handelt.
  • Zusätzliche hilfreiche Informationen wie etwa Schritte zum Nachvollziehen des Problems, Screenshots, Proof-of-Concept-Nachweise und Ähnliches.

Richtlinien

Im Sinne einer verantwortungsvollen Offenlegung bitten wir alle Forschenden, sich an die folgenden allgemeinen Richtlinien zu halten:
 

  • Bühler hat genügend Zeit (mindestens 60 Tage), um eine Meldung zu verifizieren und die Behebung umzusetzen. Geben Sie während dieser Zeit ohne unsere Zustimmung keinerlei Informationen an Dritte oder an die Öffentlichkeit weiter.
  • Testaktivitäten dürfen die Serviceleistungen und Produkte von Bühler nicht beeinträchtigen. Führen Sie keine „Denial-of-Service“-Angriffe/-Tests durch.
  • Sie dürfen sich keine potenziell sensiblen Informationen verschaffen, diese ändern oder zerstören, wenn Ihnen eine identifizierte Sicherheitslücke die Möglichkeit dazu bieten sollte.
  • Stellen Sie ohne manuelle Überprüfung der Sicherheitslücke keine Berichte von automatischen Scannern zur Verfügung.
     

Wenn Sie diese Richtlinien einhalten, dann verpflichten wir uns:
 

  • Keine rechtlichen Schritte im Zusammenhang mit Ihrer Recherche zu ergreifen oder zu unterstützen.
  • Mit Ihnen zusammenzuarbeiten, um das Problem schnell zu verstehen und zu beheben, was eine erste Bestätigung Ihrer Meldung innerhalb von 5 Tagen nach Einreichung mit einschliesst.
  • Eine Prämie in Abhängigkeit von der Kritikalität des aufgedeckten Sachverhalts und den betroffenen Informationen/Systemen/Serviceleistungen zu erwägen; in jedem Fall werden wir Sie jedoch in unsere „Hall of Fame“ hier unten aufnehmen, wenn der Sachverhalt in den Geltungsbereich dieser Richtlinie fällt und Sie dies wünschen. Dies gilt, wenn Sie das Problem als Erster gemeldet haben und uns das Problem noch nicht bekannt ist.

Geltungsbereich

Sicherheitslücken innerhalb des Geltungsbereichs

Jedes Problem, mit dem die Vertraulichkeit oder Integrität von Informationen auf nachvollziehbare Weise (durchgängig) beeinträchtigt wird, fällt wahrscheinlich in diesen Geltungsbereich. Beispiele dafür sind:

  • Cross-Site-Scripting (XSS)
  • Cross-Site-Request-Forgery (CSRF)
  • Fehler bei der Authentifizierung oder Autorisierung
  • SQL-Einschleusung (SQLI)
  • Remote-Code-Ausführung (RCE)
  • Local-File-Inclusion oder Remote-File-Inclusion

 

Sicherheitslücken ausserhalb des Geltungsbereichs

Folgendes wird als ausserhalb des Geltungsbereichs befindlich betrachtet und nicht honoriert:

  • Ausfälle aufgrund von „Denial-of-Service“-Angriffen.
  • Fehler, welche die Vertraulichkeit, Integrität oder Verfügbarkeit von Informationen oder zugehörigen Serviceleistungen/Ressourcen nicht beeinträchtigen bzw. die kein direktes Sicherheitsrisiko darstellen.
  • Abfluss von nicht-kritischen Informationen.
  • DNS-Datensätze wie SPF, MARC, DKIM.
  • Logout-Cross-Site-Request-Forgery.
  • Probleme mit TLS/SSL-Zertifikaten wie etwa schwache Chiffren oder veraltete Protokolle.
  • Aspekte, die nur mit „Clickjacking“ ausgenutzt werden können.
  • Sicherheitslücken, bei denen ein Opfer dadurch angreifbar wird, indem es nicht-standardisierte Software installiert oder anderweitig aktiv Schritte unternimmt.
  • Sicherheitslücken, bei denen es unter anderem um die zwischenmenschliche Beeinflussung (Social Engineering) unserer Mitarbeitenden oder Kunden geht bzw. die dadurch entstehen.
  • Angriffe, die einen physischen Zugriff auf ein Gerät oder System erfordern.
  • Hypothetische Angriffsketten, bei denen eine identifizierte Sicherheitslücke nur in Kombination mit einer angenommenen/hypothetischen Situation zu einem Sicherheitsproblem führen würde.
  • Fehlende Cookie-Flags bei nicht-kritischen Cookies.
  • Fehlende HTTP-Sicherheits-Header, die nicht direkt zu einer Sicherheitslücke führen.
  • Vorhandene Banner oder Versionsinformationen, sofern sie nicht mit einer angreifbaren Version korrelieren.

Hall of Fame

Credits Date Description
Yunus Yildirim October 2021 Reported a valid vulnerability in a web application.
Mohammed Eldawody August 2021 Reported four valid findings with well documented explanations.