# Institutionelle Sicherheit und Kontrolle (https://docs.akollo.com/de/trust/institutional-security)



<Callout title="Geplant">
  Dieser Bereich ist geplant. Er wird hier beschrieben, damit Sie sich vorbereiten können; im aktuellen Release ist er noch nicht enthalten.
</Callout>

## Worum es geht [#worum-es-geht]

Dieser Bereich umfasst, wie Akollo installiert wird, welche Daten die Institution verlassen dürfen, wie lange Datensätze aufbewahrt werden, wie Löschungen geprüft werden und einen Prüfpfad, der sich unverändert vorlegen lässt.

Beschäftigte werden informiert, welche Daten erfasst werden, und können Einsicht in ihre Datensätze oder deren Berichtigung verlangen.

Gesonderte Kontrollen decken sensible Inhalte, angeschlossene Geräte, Dateiübertragungen, gesperrte Websites und geschlossene Anwendungen ab. Sie sind nur aktiv, wenn eine Richtlinie sie einschaltet. Eine Live-Ansicht eines Bildschirms erfordert eine zweite freigebende Person, eine Zeitbegrenzung und ein sichtbares Zeichen für die betroffene Person.

## Weiterleitung von Sicherheitsereignissen an das SIEM [#weiterleitung-von-sicherheitsereignissen-an-das-siem]

Sicherheitsereignisse gelangen über eine verschlüsselte Verbindung in das SIEM der Institution.

| Übertragungsweg | Formate                     |
| --------------- | --------------------------- |
| Syslog über TLS | CEF, LEEF oder RFC 5424     |
| Splunk HEC      | Splunk HTTP Event Collector |

* Jedes Ereignis wird mindestens einmal zugestellt und trägt eine eigene ID, sodass das SIEM Wiederholungen verwerfen kann.
* Ein Eintrag, den das SIEM ablehnt, wird in Quarantäne gestellt und kann erneut gesendet werden.
* Eine Verzögerung von mehr als 15 Minuten löst ein Warnereignis aus.
* Die Institution kann die Ereignisse zusätzlich seitenweise mit einem API-Schlüssel abrufen, nur für ihre eigene Organisation.

<Mermaid
  title="Wie ein Sicherheitsereignis das SIEM erreicht"
  chart="`flowchart LR
A[Sicherheitsereignis] --> B[&#x22;Verschlüsselte Zustellung (Syslog über TLS oder Splunk HEC)&#x22;]
B --> C{SIEM nimmt an?}
C -->|Ja| D[&#x22;Im SIEM gespeichert, Wiederholungen per Ereignis-ID verworfen&#x22;]
C -->|Nein| E[In Quarantäne]
E -->|Erneut senden| B`"
/>

## Warnungen und Sicherheitsvorfälle [#warnungen-und-sicherheitsvorfälle]

Das Sicherheitsteam bearbeitet Warnungen und Vorfälle auf zwei Seiten unter **Governance**.

Die Seite **Warnungen** listet die von Regeln ausgelösten Warnungen nach Status. Eine geprüfte Warnung wird entweder bestätigt und mit einem Vorfall verknüpft oder mit Begründung verworfen.

Die Seite **Sicherheitsvorfälle** filtert Vorfälle nach Schweregrad, Status, Quelle, bearbeitender Person und Lösungsfrist. Neue Vorfälle lassen sich gemeinsam in die Triage verschieben. Die Seite eines Vorfalls enthält eine Zusammenfassung, eine Zeitleiste, die Nachweise, das eigene Protokoll des Vorfalls und einen Export.

<Mermaid
  title="Von der Warnung zum gelösten Vorfall"
  chart="`flowchart LR
A[Regel löst Warnung aus] --> B{Prüfung}
B -->|Mit Begründung verwerfen| C[Warnung geschlossen]
B -->|Bestätigen| D[Mit Vorfall verknüpft]
D --> E[Triage]
E --> F[Gelöst und eingestuft]`"
/>

Wird ein Vorfall gelöst, wird er als echter Vorfall, erwartetes Verhalten, Fehlalarm oder harmlos eingestuft.

### Schutz der betroffenen Person [#schutz-der-betroffenen-person]

Die betroffene Person erscheint überall unter einem Pseudonym. Wer sehen will, um wen es sich handelt, muss eine schriftliche Begründung angeben. Die Identität wird nur auf diesem Bildschirm angezeigt, und die Anfrage wird im Prüfpfad festgehalten.

Die exportierte Datei enthält die Angaben zum Vorfall und Prüfsummen der Nachweise, nie die Nachweise selbst oder die Identität der Person.

Auf dem Smartphone erscheinen die Listen als Karten, und die Aktionen öffnen sich in einem Bereich vom unteren Rand.

## Maßnahmenregister [#maßnahmenregister]

Das Maßnahmenregister listet Schwachstellen und Prüfungsbefunde, jeweils mit Fälligkeitsdatum.

* Ein Scanergebnis lässt sich als SARIF-Datei importieren, ein Penetrationstest-Ergebnis als CSV-Datei.
* Die Annahme eines Risikos erfordert eine Begründung und ein Enddatum.
* Wer für den Befund verantwortlich ist, kann das Risiko nicht selbst annehmen.
* Ist das Enddatum der Annahme überschritten, wird der Befund wieder als offen angezeigt.

## Kontrollregister [#kontrollregister]

Das Kontrollregister zeigt Rahmenwerke, Anforderungen, Kontrollen und Nachweise zusammen. Es lässt sich als Excel oder JSON herunterladen. Die Datei ist ein Control-Mapping, keine Zertifizierung.

Das Register enthält diese Anforderungskataloge:

* ISO/IEC 27001:2022 Anhang A (nur Kontrollnummer und Kurzbezeichnung);
* die BDDK-Verordnung über Informationssysteme (31069) der türkischen Bankenaufsicht;
* Anforderungen der KVKK (türkisches Datenschutzgesetz).

Eine Organisation kann 16 vorgefertigte Kontrollen mit ihren Zuordnungen und Nachweispositionen in einem Schritt laden oder die eigene Anforderungsliste der Institution als CSV importieren. Das Dokument „Control mapping“ erläutert, welche Kontrolle zu welcher Anforderung beiträgt.

<Callout type="warn" title="Achtung">
  Das Kontrollregister ist ein Mapping. Akollo beansprucht keine Zertifizierung.
</Callout>

## Governance-Übersicht [#governance-übersicht]

Die Governance-Übersicht zeigt Sicherheitsbeauftragten, Datenschutzbeauftragten und Prüfern auf einen Blick, was gemessen wird und was nicht. Jede Karte fasst ein Thema zusammen und verlinkt auf dessen Seite:

* externe Ziele und die Regel für die Datenweiterleitung;
* Verschlüsselungsschlüssel;
* die letzte Prüfung des Prüfpfads;
* abgelehnte externe Anfragen;
* offene Sicherheitsvorfälle;
* Fristen für Betroffenenanfragen;
* Bestätigungen von Hinweisen;
* Compliance-Bereitschaft und Befunde.

Die Karten zu Datensicherung und SIEM-Weiterleitung sind für den Administrator der Installation bestimmt. Jede Person sieht die Karten, die ihr Zugriff abdeckt.

Ein noch nicht gemessener Sachverhalt erscheint grau. Grün steht nur für etwas, das gemessen wurde und in Ordnung ist. Karten enthalten nur Zahlen und Daten, nie den Namen einer Person.

## Häufige Fragen [#häufige-fragen]

<Accordions type="single">
  <Accordion title="Kann ich diesen Bereich heute nutzen?">
    Nein. Er ist geplant und noch nicht Teil des aktuellen Release. Er wird hier beschrieben, damit Sie sich vorbereiten können.
  </Accordion>

  <Accordion title="Welche SIEM-Formate werden unterstützt?">
    Syslog über TLS im Format CEF, LEEF oder RFC 5424 sowie Splunk HEC. Die Institution kann Ereignisse zusätzlich seitenweise mit einem API-Schlüssel abrufen.
  </Accordion>

  <Accordion title="Sieht das Sicherheitsteam bei einem Vorfall den Namen der betroffenen Person?">
    Nein. Die Person erscheint unter einem Pseudonym. Die Identität zu sehen erfordert eine schriftliche Begründung; sie wird nur auf diesem Bildschirm gezeigt, und die Anfrage wird im Prüfpfad festgehalten.
  </Accordion>

  <Accordion title="Macht uns das Kontrollregister zertifiziert?">
    Nein. Das Register und sein Export sind ein Control-Mapping. Akollo beansprucht keine Zertifizierung.
  </Accordion>

  <Accordion title="Kann die verantwortliche Person eines Befunds das Risiko selbst annehmen?">
    Nein. Die Risikoannahme erfordert eine Begründung und ein Enddatum, und die verantwortliche Person kann sie nicht selbst erteilen. Nach dem Enddatum erscheint der Befund wieder als offen.
  </Accordion>
</Accordions>