SecRadar - Prozess-Stufen

Alle Stufen im Überblick:

Stufe 0 - Vorbereitung

Zur Vorbereitung wird eine Tabelle SecChannel angelegt, die alle relavanten Scurity-Channel klassizifiert. Darüberhinaus wird einmalig ein NVD-Mirror aller CVE-Meldungen angelegt, der lokal referenziert werden kann. Dieser Mirror, wird 1x täglich mit dem Bulk-Service und den neuesten Meldungen und Updates versorgt.

Rahmenparameter für Stufe 0:

• Kadenz, Initial: Einmalig oder OnDemand
• Kadenz, Mirror-Sync: Täglich
• Referenz: NVD-Database, Liste aller Sicherheitskanäle
• Ziel: SecChannel, SecMirrorNVD
• Retension: keine, Backup 1x pro Monat

Stufe 1: RAW

Hier werden die Erkenntnisse der Security-Kanäle ohne weitere Logik temporär gesammelt. Dazu gehört evt. auch, daß einzelne Security-Kanäle keine eigene Persistenz und/oder keine eigene intrinsische Kadenz (Schedule) besitzen. Beispiel Whitesource (keine eigene Scan-Schedule), Beispiel trive (keine Schedule, keine Persistenz).

Rahmenparameter für Stufe 1:

• Kadenz: je nach Kanal unterschiedlich, ggf. auch OnDemand.
• Referenz: SecChannel
• Ziel: SecRaw oder Kanalspezifisch, z.b. SecRawTrivy
• Retension: Für SecRaw: Bis zu vollständigen Verarbeitung durch ETL, dann kann/soll gelöscht werden. Für SecRaw[Channel]: Ohne Retension

Stufe 2: ETL

Dokumente aus der SecRaw Tabelle werden in einem ETL-Verfahren (ETL = Extract, Transform, Load) grundsätzlich in Findings (SecFinding) und Issues (SecIssues) aufgesplittet, harmonisiert, und im Falle von Schwachstellen auf einzelne CVE-ID's runtergebrochen und mit der grundlegenden Issue-Severity-Rating CRITICAL, HIGH, MEDIUM oder LOW versehen werden. Um die Severity-Ratings der Kanäle zu harmonisieren, wird ein Lookup gegen die Datenbestände von mitre und NVD durchgeführt, siehe auch Stufe 3: Lookup. Abschließend wird die Summary Pipeline aufgerufen um die verschiedenen Severities in verschiedenen Scopes, wie Teams, Channels, Status aufzubereiten und zur Navigation anzubieten. Weitere Details, siehe Wiki:SecRadar-ETL.

Rahmenparameter für Stufe 2:

• Kadenz: 1x Wöchentlich oder OnDemand
• Referenz: SecChannel, Asset
• Ziel: SecFinding, SecIssue, SecSummary
• Retension: Die Zieltabellen werden vor dem ETL-Prozess mit einem KW-Literal mit der DDB-Backup funktion gesichert. Namenskonvention dazu: "Backup_[Tabelle]_[KW]", Beispiel: "Backup_SecIssue_03". Nach einem Jahr wir das erste Backup überschrieben. Anschließend werden die Ziel-Tabellen gelöscht und neu angelegt.

Stufe 3: Lookup

Eng verzahnt mit dem ETL-Prozess ist der Lookup-Pozess. Aktuell wird er benutzt um Attributwerte für die Confidence-Ermittlung bereit zu stellen. Um Severities, Vektoren und weitergehende Status-Informationen zu aktualisieren bzw. zwischen den Kanälen zu harmonisieren. Hier wird ein "unified" Liste aller CVE-ID's von Schwachstellen-Kanälen erzeugt und diese gegen den lokalen NVD-Mirror, mitre, OWASP und evt. anderen geschickt.

Rahmenparameter für Stufe 3:

• Kadenz: 1x Wöchentlich oder OnDemand, einzelnd oder als Batch
• Referenz: NVD, bald mitre, später evt. auch owasp, mwe/cwe, evt. first.org
• Ziel: SecLookup (neu!)
• Retension: 1x pro Jahr wird ein Backup erstellt, anschließend kann ein Aufräumscript gelöste Issues entfernen.

Stufe 4: Rating

Zur neXt-seitigen Bewertung eines Finding wollen wir vier Haupt-Vektoren heranziehen:

1. Basis-Kritikalität, Quelle: Asset
2. Issue-Kritikalität (CVSS), Quelle: SecIssue & SecLookup
3. Location-Scope, Quelle: SecChannel und ggf. SecFinding
4. Confidence, Quelle: SecIssue/Lookup & SecFinding & more

Neu ab PI26: mitre-Status, CWSS (Schwachstellentypisierung)

Weitere Details, siehe Wiki:SecRadar - Klassifizierungsmatrix.

In einer Tabelle SecSolving sollen alle Findings mit dem Severity-Rating "CRITICAL" und "HIGH" mit einer Issue-Confidence > 1 übertragen werden. In dieser Tabelle sollen dann alle vier Vektoren ergänzt werden. Vektor (1) bis (3) sind statische Werte und können nahezu 1:1 geschrieben werden. Für Confidence werden Sub-Vektoren benötigt, die vorab in SecConfidence gespreichert werden.

Übersteuerung durch Confidence

Für die Confidence soll es zwei "Übersteuerungen" geben:

1. Dringende Notwendigkeit

   Durch Einsteuerung z.b. durch eine Security-Authorities, z.b. CISO, SOC-Team, VISTA können die ermtittelten Ratings übersteuert werden. Hierzu wird der Wert von Confidence auf (+4) in SecConfidence gesetzt. Eine Referenz auf Issue/Finding aus einem manuellen Eingang oder aber mindesten ein Eintrag im Kommentarfeld "vComment" wird erwartet.

2. Known Issue

   Auf der anderen Seite, kann ein Issue auch als "Known Issue" eingestuft werden.

   • Dies kann der Fall, wenn ein Issue z.b. nicht gelöst werden kann, oder es von anderer Seite gelöst wird.
   • Ein anderer Grund kann sein, daß ein Security-Channel ein "False Positive" Issue übermittelt, ohne daß es hierzu einen zweiten Kanal im selben Scope gibt, der dies mitigieren könnte. Siehe SecondOpinion.
   • Ein dritter Grund: Es wurde ein unerwünschtes Verhalten eines Security-Channels entdeckt. Dies müssen wir uns vom Hersteller bestätigen lassen, und ggf. eine Lösung beantragen. Wir sollten vermeiden "Fehlveralten" von Security-Channels auf Findindgs-Ebene mit work-a-rounds gangbar zu machen.

   In beiden Fällen wird in "vComment" ein Kommentar erwartet, der eine nachvollziehbare Begründung liefert, der zwischen DevOps-Team und Architektur und/oder SystemTeam abgestimmt ist.

   Unabhängig von allen Rankings & Ratings wird die Confidence des Issue in SecConfidence auf (-4) gesetzt.

Die vorab gerechnet Confidence kann über die Sub-Vektoren SecConfidence weiterhin abgelesen werden.

Rahmenparameter für Stufe 4:

• Kadenz: 1x Wöchentlich oder OnDemand
• Referenz: siehe oben
• Ziel: SecConfidence, SecSolving
• Retension: SecConfidendence wie SecIssue / Finding. SecSolving wie SecLookup

Stufe 5: Solving

Eine wöchentliche Security-Runde, derzeit Mittwochs 15:00 - 16:00 soll über die Findings & Ratings befinden und zunächst, manuell Sicherheitsrelevante Lösungsempfehlungen ausgegeben werden. Im Laufe der Entwicklung kommen iterativ, inkrementell immer mehr halb- und vollautomatische Lösungen hinzu:

• Dashboards (Web),
• Alerts (Teams-Channels),
• Advices (Emails) oder auch
• Tickets (Gitlab-Issues/Jira) hinzu.

Da die SecFinding erwartungsgemäß Umfangreich wird, geschätzt etwa 7000 Einträge bei den ersten beiden Kanälen, und wir zunächst eine Query-Middleware noch nicht implementieren wollen, sollen die statischen SecFinding-JSONS aufgesplittet werden:

• SecFindingCritHigh_data.json
• SecFindingMedium_data.json
• SecFindingLow_data.json

Das Dashboard wird um einen Solving-Use-Case ergänzt. Hier wird anstatt der Kombination aus SecSummary, Details-View & SecFindings eine Kombination von SecSolving (Liste) & Details-View per Issue eingeblendet.

Einmal pro Woche, z.b. Mittwochs morgens, wird SecSolving mit dem aktuellen Stand von SecFinding synchronisiert. Wird ein Issue nicht mehr gefunden und der Status ist ungleich "to be solved", wird das FirstSolved Datum gesetzt. LastFound bleibt unberührt. Status wird auf "to be solved" gesetzt. Wird ein Issue nicht mehr gefunden und der Status ist bereits "to be solved" wird das Issue auf solved gesetzt.

Darüberhinaus werden Auswertungen aus der SecSolving, vergleichbar zur SecSummery im Elk in einen eigenen Index geschrieben um die zeitliche Entwicklungen im Überblick zu haben.

Da die Möglichkeit besteht, daß ein Finding auch nach einem vermeintlichem Solving wieder auftaucht, wird das Issue in SecSolving erst mit der jährlichen Retension gelöscht. Bis dahin werden Status- und Datums-Attribute erneut gefplegt. Bei "Wiederöffnung" wird zudem dem "vComment"-Feld zudem das literal "reopen" voran gestellt.

Rahmenparameter für Stufe 5:

• Kadenz: OnDemand bei Solving-Status-Wechsel, Sync 1x Wöchentlich
• Referenz: SecSolving
• Ziel: SecSolving
• Retension: wie SecLookup