Überblick
Ottili ONE nimmt gemeldete Schwachstellen und Sicherheitsvorfälle ernst. Dieser Artikel erklärt, wie Sie eine Sicherheitslücke verantwortungsvoll melden und wie Ottili auf Vorfälle reagiert, die die Plattform und Ihren Unternehmens-Workspace betreffen. Alle Angaben auf dieser Seite entsprechen der veröffentlichten Ottili-Policy — sie werden aus einer einzigen, kanonischen Quelle gerendert und nicht hartkodiert oder frei ergänzt.
Die übergeordnete Sicherheitsarchitektur (Mandanten-Isolation, Authentifizierung, Berechtigungen, Verschlüsselung, Secrets-Management, Audit) beschreibt die [Sicherheitsübersicht](/docs/security-overview). Dieser Artikel konzentriert sich auf das Melden von Schwachstellen und den Incident-Response-Prozess.
Schwachstellen verantwortungsvoll melden
Ottili betreibt einen koordinierten Disclosure-Kanal für Sicherheitsforscher:innen und Kund:innen.
- Disclosure-Kanal:* Berichte richten Sie an security@ottili.one*. Das ist die einzige, kanonische Adresse für Schwachstellenmeldungen.
- Bestätigung:* Ottili bestätigt eine gut formulierte Meldung innerhalb von 72 Stunden* (Acknowledgment-SLA).
- Verschlüsselte Berichte (optional):* Berichte können verschlüsselt eingereicht werden. Derzeit ist kein PGP-Fingerprint veröffentlicht; die Seite blendet den PGP-Block entsprechend aus, anstatt einen erfundenen Fingerabdruck anzuzeigen.
Was Ihre Meldung enthalten sollte
- Eine klare Beschreibung der Schwachstelle und des betroffenen Produkts oder der betroffenen Oberfläche.
- Schritte zur Reproduktion oder — falls vorhanden — ein Proof-of-Concept.
- Die von Ihnen identifizierte potenzielle Auswirkung.
- Ihre Kontaktdaten (optional, damit wir Rückfragen klären können).
Geltungsbereich
- Die Ottili-ONE-Plattform und die öffentlichen Ottili-Oberflächen (Website, Statusseite, öffentliche Docs).
- Ottili Auth und die öffentliche Grenze der Unified API.
Außerhalb des Geltungsbereichs
- Social-Engineering-Angriffe gezielt auf Ottili-Mitarbeiter:innen.
- Physische Sicherheit von Ottili-Büros oder -Einrichtungen.
Bitte nicht
- Führen Sie keine hochintensiven automatisierten Scanner gegen die Produktion aus.
- Greifen Sie nicht auf Kundendaten zu, ändern oder löschen Sie diese.
- Veröffentlichen Sie die Schwachstelle nicht öffentlich, bevor sie behoben ist.
Schweregradmodell
Jeder Vorfall wird nach einem festen Schweregradmodell bearbeitet. Die Reaktionsziele und Update-Rhythmen sind Teil der veröffentlichten Policy:
| Schweregrad | Beschreibung | Reaktionsziel | Update-Rhythmus |
|---|---|---|---|
| Critical* | Aktive Ausnutzung, Datenoffenlegung oder Verlust der Verfügbarkeit eines Kern-Dienstes. | Erkennen und mit der Eindämmung beginnen innerhalb von 1 Stunde. | Status-Updates mindestens alle 4 Stunden bis zur Lösung. |
| High* | Ernsthafte Schwachstelle mit plausiblem Ausnutzungsweg oder Teilausfall eines Kern-Dienstes. | Erkennen innerhalb von 4 Stunden und mit der Eindämmung beginnen. | Status-Updates mindestens zweimal täglich bis zur Lösung. |
| Medium* | Begrenzte Auswirkung oder Ausnutzung erfordert spezifische Bedingungen. | Erkennen innerhalb von 1 Werktag. | Tägliche Status-Updates bis zur Lösung. |
| Low* | Minimale Auswirkung, Härtung oder Defense-in-Depth-Verbesserung. | Erkennen innerhalb von 2 Werktagen. | Updates entsprechend dem Fortschritt der Arbeit. |
Incident-Response-Prozess
Unabhängig vom Schweregrad durchläuft jeder Vorfall dieselben vier Phasen:
1. Detection & Triage (Erkennung & Triage)
Vorfälle werden über Monitoring, Kundenmeldungen und den Schwachstellen-Disclosure-Kanal erkannt und anschließend nach Schweregrad triagiert.
2. Containment (Eindämmung)
Betroffene Komponenten werden isoliert; missbrauchte Credentials oder Tokens werden widerrufen, um laufende Auswirkungen zu stoppen.
3. Communication (Kommunikation)
Betroffene Unternehmen werden über die Statusseite und direkte Kanäle informiert, während sich die Situation entwickelt.
4. Resolution & Post-Incident Review (Lösung & Nachbereitung)
Die Grundursache wird behoben. Wo angemessen, wird eine transparente Post-Incident-Review mit den betroffenen Kund:innen geteilt.
Kommunikation während eines Vorfalls
- Der Echtzeit-Status wird auf der [Ottili-Statusseite](https://status.ottili.one) veröffentlicht.
- Betroffene Unternehmen werden direkt kontaktiert, wenn ein Vorfall ihren Workspace betrifft.
- Post-Incident-Reviews werden auf Wunsch mit den betroffenen Kund:innen geteilt.
Bei bekannten Ausfällen prüfen Sie zuerst die Statusseite, bevor Sie den Support kontaktieren. Den allgemeinen Support erreichen Sie unter [ottili.one/support](https://ottili.one/support); für Sicherheitsfragen nutzen Sie weiterhin security@ottili.one*.
Koordinierte Offenlegung
- Wir stimmen die Offenlegung mit den Meldenden ab und nennen keine Personen beim Namen.
- Wir leiten keine rechtlichen Schritte gegen Forschende ein, die in gutem Glauben handeln.
- Wir nennen Forschende, die genannt werden möchten, in der Anerkennung.
Statusbegriffe
Die Incident-Response-Policy und die öffentliche Seite /security/response sind Live (General Availability)*. Ottili ONE unterscheidet klar zwischen Live, Beta, Private Beta, In Development, Planned und Concept. Was diese Begriffe bedeuten, beschreibt [Feature-Status-Labels verstehen](/docs/understand-feature-status-labels).
Verwandte Artikel
- [Sicherheitsübersicht](/docs/security-overview) — die gesamte Sicherheitsarchitektur im Überblick.
- [Secrets-Management](/docs/secrets-management) — wie Konfigurations- und Integrations-Secrets geschützt werden.
- [Mandantenisolation](/docs/tenant-isolation) — wie Ihr Unternehmen von anderen getrennt bleibt.
- [Konto- und Datensicherheit](/docs/account-and-data-security) — Authentifizierung, Sitzungen, Isolation, Audit.
- [Rollen und Berechtigungen](/docs/roles-and-permissions) — wer was darf.
- [Approval Queue](/docs/approval-queue) — menschliche Freigabe sensibler Aktionen.
- [Support-Eskalation](/docs/support-escalation) — wie Sie den Support eskalieren.
- [Feature-Status-Labels verstehen](/docs/understand-feature-status-labels) — was die Statusbegriffe bedeuten.
- [Audit-Logs](/docs/audit-logs) — Nachvollziehbarkeit über alle Module hinweg.
War dieser Artikel hilfreich?