Richtlinie zur Reaktion auf Sicherheitsvorfälle

1. Einleitung

Dieses Dokument beschreibt die Richtlinie zur Reaktion auf Sicherheitsvorfälle für die DeskCamera-Anwendung. DeskCamera ist eine lokal installierte Anwendung zur Bildschirmübertragung, die innerhalb des lokalen Netzwerks des Kunden betrieben wird. Es bietet keine Cloud-Dienste an, speichert oder verarbeitet keine Benutzerdaten und überträgt keine Inhalte an Server von DeskCamera.

2. Zweck

Sicherstellen, dass DeskCamera über einen strukturierten Ansatz zur Identifizierung, Verwaltung und Behebung von Sicherheitsvorfällen verfügt, die die Softwareentwicklung, den Vertrieb oder die Support-Infrastruktur beeinträchtigen können.

3. Geltungsbereich

Diese Richtlinie gilt für Sicherheitsvorfälle im Zusammenhang mit dem DeskCamera-Quellcode, dem Build-Pipeline, Drittanbieter-Abhängigkeiten, Verteilungssystemen und internen Entwicklungstools.

4. Abgedeckte Vorfalltypen

• Unbefugter Zugriff auf Quellcode-Repositories
• Kompromittierung von Signaturzertifikaten oder der Build-Umgebung
• Sicherheitslücken in der Lieferkette (Drittanbieter-Bibliotheken)
• Fehlkonfigurationen, die die Integrität verteilter Installer beeinträchtigen
• Schwachstellen in Tools, die im Softwareentwicklungszyklus (SDLC) verwendet werden

5. Rollen und Verantwortlichkeiten

• CTO – Überwacht das Vorfallmanagement und genehmigt kritische Maßnahmen
• Entwicklungsteam – Bewertet technische Details, behebt Codefehler und stellt Systeme wieder her
• Sicherheitsverantwortlicher – Koordiniert Untersuchungen, führt Protokolle und sorgt für Kommunikation

6. Vorgehen bei Vorfällen

6.1. Identifikation

• Automatisches Monitoring von CVEs (Common Vulnerabilities and Exposures) über Sicherheitsfeeds
• Manuelle Codeprüfungen und Erkennung von Anomalien im täglichen Betrieb

6.2. Bewertung

• Priorisierung basierend auf Schweregrad (Kritisch, Hoch, Mittel, Niedrig)
• Prüfung, ob verteilte Software betroffen ist

6.3. Eindämmung und Abmilderung

• Sofortige Sperrung kompromittierter Zugangsdaten
• Isolierung betroffener Umgebungen oder Pipelines
• Entfernung oder Patchen betroffener Drittanbieter-Bibliotheken

6.4. Wiederherstellung

• Wiederherstellung der Umgebung aus sauberen Backups
• Neue Signierung der Builds mit überprüften Schlüsseln
• Retests und Validierung der Integrität der veröffentlichten Installer

7. Kommunikation

• Intern: Alle Vorfälle werden protokolliert und dem Management gemeldet
• Extern: Kunden werden innerhalb von 24 Stunden benachrichtigt, aber nur, wenn die Integrität der verteilten Builds oder Update-Mechanismen kompromittiert ist

8. Nachbearbeitung des Vorfalls

• Ursachenanalyse innerhalb von 5 Arbeitstagen
• Aktualisierung der Sicherheitsverfahren bei Bedarf
• Der Vorfallbericht wird intern gespeichert und für jährliche Sicherheitsschulungen verwendet

9. Überprüfung und Tests

• Diese Richtlinie wird jährlich vom CTO überprüft
• Interne Planspiele zur Reaktion auf Vorfälle werden regelmäßig durchgeführt