Kunde will den Report auf Englisch – wie sollen wir die Schwachstellenmanagement-Dokumente aufbereiten?

Bei Unternehmenskunden schauen besonders die Prüfungsausschüsse eher auf gemeinsame englische Formate als auf die Landessprache. Fallt bloß nicht in die Falle, auf Türkisch zu schreiben und es dann an ein Übersetzungsbüro zu schicken; ein Übersetzer, der die Fachbegriffe nicht kennt, kann Sicherheitsbeschreibungen unkenntlich machen. Das Team sollte sich daran gewöhnen, direkt auf Englisch zu dokumentieren.

Beim Erstellen des Reports empfehle ich, diese fünf Standards vollständig einzuhalten: 1) Die Executive Summary muss unbedingt risikoorientiert sein, 2) jedes Finding muss den offiziellen CVSS-Vektorstring enthalten, 3) die Proof-of-Concept-Schritte müssen mit Screenshots klar gezeigt werden, 4) der Lösungsvorschlag darf keine allgemeine Empfehlung sein, sondern muss umsetzbare Befehle oder Code-Korrekturen enthalten, 5) die relevanten CWE- und CVE-Nummern müssen referenziert werden.

Edit: Ich habe oben etwas falsch geschrieben, entschuldigung.

Die Stelle, an der in der Terminologie die meisten Fehler gemacht werden, ist die Risikobewertung. Statt nach eigenem Ermessen mittel oder hoch zu sagen, gebt die Parameter CVSS Base Score und Temporal Score klar an. Wenn ihr zum Beispiel Vektorkomponenten wie Attack Vector: Network oder Privileges Required: Low im englischen Text im Originalformat lasst, erleichtert das die Arbeit des Prüfers enorm.

Letztes Jahr hatten wir eine ähnliche Anfrage und haben den türkischen Report zunächst an eine professionelle technische Übersetzung gegeben. Die Übersetzung eines einzigen 40-seitigen Reports kostete 850 Euro und unser Team verbrachte zwei volle Tage damit, Terminologiefehler zu korrigieren. Danach sind wir auf eine fertige englische Security-Vorlage umgestiegen; unsere Reporting-Zeit war anfangs etwas länger, aber wir haben die Kosten auf null gebracht.

Achtet auf das Englisch-Niveau eures Teams. Wenn eure Security-Experten beim Schreiben auf Englisch Schwierigkeiten haben, kann die Wirkung eines technischen Findings oder die Lösungsmethode unvollständig oder falsch vermittelt werden. Auch wenn die Vorlage auf Englisch ist, müssen die Finding-Texte unbedingt von einer erfahrenen Person im Haus auf sprachliche und technische Konsistenz geprüft werden.

die chefs lesen die technischen details eh nicht... wenn ihr auf die erste seite ein buntes risiko-verteilungsdiagramm und eine saubere executive summary mit 3 absätzen packt, ist das management auf kundenseite sofort überzeugt die detaiils schauen sich eh deren eigene technische teams an.

Die mit dem Kunden unterzeichneten Geheimhaltungsvereinbarungen und Datensicherheitsprotokolle müssen beachtet werden. Die Weitergabe sensibler Dokumente mit Sicherheitslücken und Systemschwachstellen zu Übersetzungszwecken an KI-Tools Dritter oder externe Dienstleister kann rechtliche Risiken bergen; die gesamte Dokumentation muss in einer sicheren internen Umgebung erstellt werden.

müssen wir im englischen Report jeden kleinen Konfigurationsfehler melden den wir feststellen? oder sollten nur kritische und hoch eingestufte Findings mit einem CVSS-Score von 7 und höher in den Report aufgenommen werden?

ich bin ein kleines Unternehmen ich erzähle es aus meiner Sicht aber wenn der Benachrichtigungsweg lang ist, kommen keine Benachrichtigungen; keine Benachrichtigung bedeutet spät erkannte Vorfälle.

wenn deine Situation anders ist ändert sich das natürlich.

Ich spreche mal aus der Gegenperspektive ich bin auf der Lieferantenseite. Schreibe bei Entscheidungen auch das Worst-Case-Szenario auf, nicht nur das Beste.

Das war's, entschuldige wenn ich zu lang war.

Wenn wir ins Detail gehen: Wenn der Benachrichtigungsweg lang ist kommen keine Benachrichtigungen; keine Benachrichtigung bedeutet spät erkannte Vorfälle.

Viel Erfolg.

Ich erkläre mal die technische Seite. Der meiste Zeitverlust entsteht durch Arbeiten, die auf Freigaben warten.

Aus Erfahrung weiß ich das.

Da ist mir noch ein Punkt unklar. Wenn man Fehlalarme anschreit meldet sich danach niemand mehr.

Ich hoffe, das hilft dir weiter.

wenn du so vorgehst, kläre das vorher dann der meiste Zeitverlust entsteht durch Arbeiten die auf Freigaben warten.

jeder nicht schriftlich festgehaltene Punkt ist ener an den sich beide Parteien später unterschiedlich erinnern.

Ich habe diesen Weg schon hinter mir, ich erzähl mal. Das allein zu versuchen, ist der teuerste Weg.

Korrigiert mich, falls ich falsch liege.

Bei Schwachstellenmanagement Englisch ist es meiner Meinung nach schwierig, so eindeutig zu sprechen. Vergessene Testumgebungen sind häufiger das Einfallstor als das Live-System.

Wenn deine Situation anders ist, ändert sich das natürlich.

Nach diesem Erlebnis hat sich meine Sichtweise geändert. Sicherheit ist nicht absolut; es bedeutet, den Angriff so aufwendig zu machen, dass er sich nicht lohnt.

Wenn deine Situation anders ist, ändert sich das natürlich.

Ich spreche mal aus der Gegenperspektive, ich bin auf der Lieferantenseite. Überstürzte Entscheidungen sind oft solche, die man sechs Monate später korrigieren muss.

Das allein zu versuchen, ist der teuerste Weg. Nur als Notiz, könnte nützlich sein.