Cum scriu o constatare de risc pe care afacerea va actiona?

Majoritatea constatărilor de securitate mor într-un spreadsheet pentru că sunt scrise pentru alți oameni de securitate, nu pentru persoana care aprobă bugetul. Dacă raportul tău spune "CVE-2023-XXXX, CVSS 9.8, patch imediat," ai descris o vulnerabilitate, nu un risc. Afacerea nu acționează asupra vulnerabilităților. Acționează asupra consecințelor pe care le poate vizualiza.

De ce scorurile de severitate singure nu determină pe nimeni să se mute

CVSS îți spune cât de grav este o defecțiune în izolare. Nu spune nimic despre faptul dacă acea defecțiune este accesibilă, dacă activul din spatele ei contează pentru venit sau dacă controlurile compensatorii o atenuează deja. Un 9.8 pe o cutie dev internă fără cale de internet și fără date sensibile nu este aceeași discuție ca un 7.5 pe gateway-ul de plată. Dacă clasifici constatările pur și simplu după CVSS îți vei cheltui credibilitatea reparând lucruri pe care nimeni nu a putut exploata vreodată, iar constatarea care chiar conta se pierde în zgomot.

Riscul care primește atenție are trei ingrediente: o cale plauzibilă către impact, un cost în bani sau operațional atașat acelui impact și un proprietar care de fapt poate să o remedieze. Ratezi oricare dintre acestea și constatarea stă în backlog.

Construiește constatarea în jurul unui scenariu, nu al unei ieșiri de scanner

In loc de "SQL injection găsit pe /login endpoint," scrie scenariul: "Un atacator neautentificat poate extrage tabelul complet al clienților, inclusiv parole hash-uite și adrese de facturare, prin formularul de conectare. Acest tabel susține 40.000 de conturi active și aceeași bază de date conține istoricul comenzilor legate de domeniu PCI." Acum cititorul nu analizează o clasă de vulnerabilitate, și-o imaginează o scrisoare de notificare de încălcare și un apel de conformitate.

O structură utilă pentru fiecare constatare:

• Ce se poate întâmpla — calea de atac în limbaj simplu, una sau două propoziții.
• Ce atinge — sistem specific, date specifice, proces business specific.
• Ce costă — ore de indisponibilitate, expunere reglementară, încredere clienți, penalități contractuale. Folosește numere reale acolo unde le ai (clauze de penalitate SLA, costuri ale incidentelor anterioare, deductibil de asigurare cibernetic).
• Ce trebuie pentru a o remedia — efort, nu doar "patch-o." Uneori remedierea este o regulă WAF astazi și o schimbare de cod în viitorul sprint.
• Cine este proprietarul remedierii — un nume sau o echipă, nu "IT."

Leagă constatarea de ceva ce afacerea deja urmărește

Fiecare companie are metrici pe care conducerea deja le urmărește: SLA-uri de timp de funcționare, churn, constatări de audit din ultimul ciclu SOC 2, prime de asigurare cibernetic, un contract client specific cu o clauză de securitate. Dacă poți conecta constatarea ta la una din acele linii existente — "aceasta este aceeași clasă de problemă pe care asiguratorul nostru a marcat-o la ultima reînnoire" sau "acest flux de date este în domeniu pentru auditul SOC 2 în Q3" — nu le ceri să-și pese de ceva nou. Le arăți o amenință la ceva pentru care sunt deja responsabili.

Aceasta este, de asemenea, locul unde vorbirea cu partea din afacere plătește înainte de a finaliza raportul. O conversație de zece minute cu finanțe sau operații despre ce costă de fapt o pană de patru ore pe un sistem specific bate orice linie generică "daune reputaționale". Obține numărul, citează-l, treci mai departe.

Clasifică după exploatabilitate și rază de acțiune, nu doar după CVSS

O abordare de prioritizare care funcționează:

1. Este accesibilă prin internet sau necesită mai întâi acces intern?
2. Există o exploatare publică sau este teoretică?
3. Atinge date reglementate (PCI, PHI, PII) sau sisteme de comoară?
4. Care este costul și timpul efectiv de remediere versus costul lăsării-o?

Constatările care punctează mare pe accesibilitate și rază de acțiune dar doar mediu pe CVSS adesea merită să sară peste o eroare critică îngropată la trei hopuri de rețea în spate după o cutie de salt cu MFA.

Scrie cererea, nu doar problema

Termină fiecare constatare cu o cerere specifică: o linie de buget, o fereastră de schimbare, o excepție de politică de închis sau o decizie numită necesară pînă la o anumită dată. "Recomandăm remedierea" este ignorat. "Avem nevoie de o fereastră de întreținere de patru ore înainte de 15 pentru a patch-a gateway-ul de plată, sau acceptăm riscul rezidual în scris" forțează o decizie într-un fel sau altul. Oferind conducerii o opțiune explicită de accept-the-risk, în scris, cu numele lor pe ea, este adesea ceea ce în final obține aprobarea remedierii în loc să nu o obțintă.

Dacă vrei să exersezi transformarea ieșirii brute a unui scanner în constatări ca aceasta, lucrează prin segmentele Blue Team și Offensive ale Korra Studio împreună — împerecherea contextului exploatării cu exerciții de raportare este locul în care această abilitate se ascuțește de fapt.