A.10 Security Response
Objective: Nach dem Ausrollen von Software ist der Umgang mit Sicherheitslücken elementarer Bestandteil des sicheren Entwicklungsprozesses. Bewertung, Beseitigung und Kommunikation von Sicherheitslücken müssen im Vorfeld definiert sein, um im Schadensfall unverzüglich und angemessen reagieren zu können.
Control 10.1: Response-Policy
Es sollte eine Response-Policy existieren, die den Umgang mit nach dem Release bekannt gewordenen Sicherheitslücken und die Kommunikation mit Kunden regelt.
Control 10.2: Umgang mit Sicherheitslücken
Bekannt gewordene Sicherheitslücken sollten je nach Schwere entweder umgehend über ein Emergency-Update behoben oder in den regulären Wartungsprozess eingebunden werden. Maßgeblich für beide Varianten ist die Aufnahme als Security-Bug in ein Bugtracking-System.
Control 10.3: Ursachen von Sicherheitslücken
Bei jeder bekannt gewordenen Sicherheitslücke sollte ermittelt werden, welche Stelle des Entwicklungsprozesses dafür verantwortlich ist. Das Ergebnis der Untersuchung muss in den PDCA-Zyklus einfließen. Der Security-Advisor ist in diesen Prozess einzubeziehen.
Control 10.4: Erkennen von Sicherheitslücken
Rollen, die für das Annehmen von Bug-Reports zuständig sind, müssen ausreichend geschult sein, um Sicherheitslücken in Fehlermeldungen erkennen und entsprechend klassifizieren zu können.
Control 10.5: Kontaktmöglichkeit
Es muss eine öffentlich erkennbare und funktionierende Kontaktmöglichkeit für das Melden von Sicherheitslücken geben. Diese Kontaktmöglichkeit muss in Incident-Management-Prozesse eingebunden sein, um die angemessene Behandlung von Benachrichtigungen gewährleisten zu können.
Ihr Kommentar
Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.
