Richtlinie zur Meldung von Sicherheitslücken

Sicherheitsrichtlinie zur Offenlegung von Schwachstellen

Bei Accesa setzen wir alles daran, sichere und zuverlässige Software bereitzustellen. Diese Richtlinie beschreibt die Grundsätze und Verpflichtungen für die verantwortungsvolle Offenlegung potenzieller Sicherheitslücken an die Sicherheitsexperten von Accesa.

Sicherheitsforscher

In Anerkennung des wertvollen Beitrags von Sicherheitsforschern fördern wir die verantwortungsvolle und transparente Offenlegung potenzieller Sicherheitslücken. Wir begrüßen Meldungen über Schwachstellen unabhängig von ihrer Quelle.

Unser Engagement

Accesa untersucht berechtigte Meldungen und unternimmt alle angemessenen Anstrengungen, um identifizierte Schwachstellen zeitnah zu beheben.

Bitte handeln Sie nach Treu und Glauben und vermeiden Sie Datenschutzverletzungen, Datenzerstörung sowie Unterbrechungen oder Beeinträchtigungen der Dienste von Accesa.

Accesa wird keine zivilrechtlichen Schritte einleiten oder Strafverfolgungsbehörden einschalten, sofern Sie:

  • Tests unserer Produkte, Dienstleistungen und IT-Infrastruktur durchführen, ohne Schäden zu verursachen, die Sicherheit oder Privatsphäre zu beeinträchtigen oder anderweitig negative Auswirkungen auf uns, unsere Kunden, Lieferanten, Partner oder andere natürliche oder juristische Personen zu haben.

  • geltende Gesetze und Vorschriften einhalten, keine Straftaten im Rahmen der Tests begehen und keine geistigen Eigentumsrechte verletzen.

  • Auswirkungen auf die Sicherheit, die Vertraulichkeit geschäftskritischer Informationen oder die Privatsphäre natürlicher oder juristischer Personen vermeiden.

  • keine Schäden an den getesteten Informationen oder der getesteten IT-Infrastruktur verursachen.

  • den Umfang der Tests auf das zur Demonstration der Schwachstelle erforderliche Mindestmaß beschränken.

  • technische Details zur Ausnutzung der Schwachstelle vertraulich behandeln.

  • keine finanzielle Gegenleistung als Voraussetzung für die Offenlegung einer potenziellen Schwachstelle verlangen.

Accesa betrachtet Aktivitäten, die im Einklang mit dieser Richtlinie durchgeführt werden, als „autorisiertes“ Verhalten.

Accesa wird keine rechtlichen Schritte gegen Sie einleiten, nur weil Sie einen Proof of Concept für eine Sicherheitslücke bereitstellen. Bitte beachten Sie die im Abschnitt Proof of Concepts aufgeführten Richtlinien, um sicherzustellen, dass Ihr Proof of Concept ausreichend detailliert ist, um das Problem nachzuweisen, und gleichzeitig den Vorgaben dieser Offenlegungsrichtlinie entspricht.

Falls Sie Fragen oder Bedenken hinsichtlich dieser Offenlegungsrichtlinie haben, kontaktieren Sie uns bitte per E-Mail unter security [a t] accesa [d o t] eu.

Geltungsbereich

Die folgenden Unternehmensressourcen fallen in den Geltungsbereich dieser Richtlinie zur Offenlegung von Schwachstellen:

Sollten weitere Ressourcen entdeckt werden, die hier nicht aufgeführt sind, setzen Sie sich bitte mit uns in Verbindung, bevor Sie weitere Schritte unternehmen.

Von der Offenlegung von Schwachstellen ausgeschlossene Bereiche

Die folgenden Bereiche sind vollständig vom Geltungsbereich ausgeschlossen und werden nicht validiert, wenn eine Meldung eingereicht wird:

  • Erkenntnisse aus physischen Tests, wie z. B. Zutritt zu Bürogebäuden (offene Türen, Tailgating usw.).

  • Erkenntnisse, die hauptsächlich auf Social-Engineering-Methoden beruhen (z. B. Phishing oder Vishing).

  • Erkenntnisse aus Anwendungen oder Systemen, die nicht im Abschnitt „Geltungsbereich“ aufgeführt sind. Accesa kann schwerwiegende Schwachstellen außerhalb des Geltungsbereichs akzeptieren, sofern diese das Unternehmen direkt betreffen.

  • Schwachstellenmeldungen, die ausschließlich einen Video-Proof-of-Concept enthalten.

  • Meldungen, die lediglich darauf hinweisen, dass Software veraltet oder potenziell verwundbar ist, ohne einen Proof of Concept oder vollständige Validierungsschritte bereitzustellen.

  • Hochgradig spekulative Berichte über theoretische Schäden.

  • Schwachstellenmeldungen, die ausschließlich auf Ergebnissen automatisierter Tools basieren, ohne zusätzliche Analyse oder Erläuterung der tatsächlichen Auswirkungen.

  • Probleme in Diensten von Drittanbietern. Diese sollten direkt an die jeweiligen Anbieter gemeldet werden.

Die folgenden Kategorien von Schwachstellen sind ebenfalls vom Geltungsbereich ausgeschlossen:

  • Netzwerkbasierte Denial-of-Service-Schwachstellen (DoS/DDoS).

  • Schwachstellen mit geringer Kritikalität, die mit Tools wie Hardenize oder Security Headers identifiziert werden können.

  • Content-Injection-Probleme.

  • Cross-Site Request Forgery (CSRF) mit geringen Sicherheitsauswirkungen (z. B. Logout-CSRF).

  • Fehlende Cookie-Flags.

  • UI- und UX-Fehler (einschließlich Rechtschreibfehlern).

  • Stack-Traces, die keine sensiblen Informationen offenlegen.

  • Host-Header-Probleme ohne entsprechenden Proof of Concept, der die Schwachstelle nachweist.

  • Offene Ports ohne entsprechenden Proof of Concept, der die Schwachstelle nachweist.

  • Banner-Grabbing-Probleme (z. B. die Ermittlung des verwendeten Webservers).

  • Fehlende X-Frame-Options-Header (Clickjacking).

  • Offenlegung der Datei robots.txt.

  • E-Mail-Spoofing aufgrund von SPF-Fehlkonfigurationen.