Un model de amenințare util explică ce protejați, cine sau ce poate afecta acest lucru, unde se schimbă încrederea și cum veți reduce și testa cele mai importante riscuri. Începeți cu proiectul real, nu cu o listă generică de instrumente.
Definiți un domeniu suficient de restrâns pentru a putea raționa asupra lui
Începeți cu un singur serviciu funcțional: un portal pentru clienți, un site de publicare sau o aplicație internă. Notați componentele pe care le operați și sistemele externe pe care vă bazați. Un model de amenințare ar trebui să facă vizibile ipotezele, nu să sugereze că fiecare atac posibil a fost rezolvat. Păstrați prima versiune suficient de mică încât persoanele care implementează aplicația să o poată explica fără un consultant separat care să interpreteze diagrama.
Enumerați rezultatele și activele valoroase. Acestea pot include datele clienților, accesul administrativ, starea plăților, conținutul publicat și capacitatea de a restabili serviciul. Disponibilitatea poate fi un activ chiar și atunci când informațiile sunt publice. Decideți ce defecțiuni ar fi incomode și care ar dăuna persoanelor sau organizației. Această distincție vă ajută să prioritizați controalele în loc să tratați fiecare avertisment în mod egal.
Desenați locurile în care se schimbă încrederea
Îndrumările OWASP privind modelarea amenințărilor folosesc fluxuri de date și limite de încredere pentru a face un design ușor de înțeles. Pentru o aplicație mică găzduită, desenați browserul, procesul web, baza de date, administratorul, destinația de backup și integrările externe. Marcați informațiile care circulă între ele. O cerere care trece de la un client neîncrezut către o operațiune privilegiată pe server merită validare și autorizare explicite.
Nu presupuneți că faptul de a fi în aceeași mașină face fiecare componentă la fel de demnă de încredere. Un proces public de încărcare nu ar trebui să aibă aceleași permisiuni ca administrarea bazei de date. O sarcină de backup poate avea nevoie de acces de citire fără capacitatea de a modifica înregistrările aplicației live. Separarea acestor roluri face efectul unei componente compromise mai ușor de izolat și permisiunile necesare mai ușor de verificat.
Alegeți scenarii concrete de eșec
Folosiți câteva evenimente plauzibile pentru a provoca designul. Un atacator fură o parolă de administrator; un utilizator solicită înregistrarea altui utilizator; o încărcare umple discul; o implementare expune un fișier de configurare; o copie de recuperare nu poate fi restaurată. Descrieți condiția de pornire, componenta afectată și consecința. Un scenariu specific este mai ușor de testat decât o instrucțiune generală de îmbunătățire a securității.
Includeți greșelile și abuzul de fluxuri de lucru legitime, precum și intruziunea externă. O reîncercare poate crea două operațiuni valoroase sau două cereri se pot întrece pentru a modifica același obiect. Îndrumările OWASP privind logica de business evidențiază aceste ipoteze de proces. Verificați cine are voie să treacă un flux de lucru în starea următoare și dacă repetarea sau reordonarea unei cereri schimbă rezultatul în mod neașteptat.
| Scenariu | Control de investigat | Dovezi de colectat |
|---|---|---|
| Credențială de administrare furată | Acces restricționat și un al doilea factor acolo unde este acceptat | O autentificare neautorizată nu se poate finaliza |
| Obiectul altui utilizator solicitat | Autorizarea obiectelor pe partea de server | Un test izolat returnează un rezultat de refuz |
| Disc epuizat de încărcări | Controale de dimensiune, cotă și retenție | O limită este aplicată înainte de defectarea serviciului |
| Cerere de flux de lucru duplicată | Idempotență și limite de tranzacție | O cerere repetată creează un singur rezultat |
Prioritizați după impact și o cale credibilă
Pentru fiecare scenariu, înregistrați impactul său potențial și condițiile necesare pentru ca acesta să se producă. Evitați să pretindeți că un scor numeric presupus este o probabilitate precisă. Puteți totuși distinge o parolă slabă expusă pe internet de un eveniment local foarte condiționat. Atribuiți un proprietar și un pas următor practic riscurilor importante, astfel încât modelul să creeze o activitate pe care cineva o poate finaliza efectiv.
Luați în considerare ciclul de viață al informațiilor, precum și compromiterea aplicației. Un export de diagnostic poate divulga date inutile în timpul unei funcționări altfel normale. Un câmp de cont păstrat poate crea expunere mult timp după încheierea scopului său. Prin urmare, analiza confidențialității poate elimina informații sau scurta retenția, în timp ce analiza securității restricționează accesul la ceea ce rămâne. Ambele modificări fac parte din model atunci când protejează proiectul.
Testați controalele într-un mediu autorizat
Creați un mediu de testare cu permisiuni reprezentative și înregistrări fabricate. Testați accesul refuzat, limitele de cereri, reîncercările fluxurilor de lucru și recuperarea. Nu folosiți date reale ale clienților atunci când datele sintetice pot demonstra comportamentul. Obiectivul este de a verifica controlul, nu de a genera trafic de atac impresionant. Rămâneți în sistemele pe care le dețineți sau pe care sunteți autorizat în mod explicit să le evaluați.
Înregistrați ce a trecut, ce a eșuat și ce rămâne necunoscut. Rezultatul unui scanner poate contribui cu dovezi, dar nu înlocuiește un test al regulilor de business ale aplicației. De asemenea, o opțiune de protecție a rețelei nu verifică autorizarea obiectelor sau gestionarea fișierelor secrete. Atașați rezultatele utile scenariului, astfel încât viitorii responsabili de întreținere să înțeleagă de ce există un anumit control.
Mențineți modelul conectat la schimbare
Verificați părțile relevante atunci când adăugați o integrare, expuneți un nou endpoint, modificați un privilegiu sau mutați datele către o altă destinație. Nu este nevoie să redesenați întreaga arhitectură pentru o modificare minoră de text. Declanșatorul este o ipoteză schimbată despre acces, informații sau comportamentul sistemului. Păstrați modelul alături de documentația de implementare și recuperare, în loc să îl lăsați ca rezultat al unui atelier unic.
SwissOctet oferă un catalog de opțiuni de infrastructură, nu un model de amenințare complet al aplicației. Alegeți configurația și opțiunile care susțin controalele dvs., apoi verificați implementarea pe care o construiți. Un model mic și întreținut, cu acțiuni testate, este mai util decât o colecție mare de produse de securitate fără o explicație clară a riscurilor pe care le abordează.
Lista dumneavoastră practică de verificare.
- Enumerați activele și consecințele eșecului.
- Desenați fluxurile de date și limitele de încredere.
- Alegeți scenarii specifice de intruziune, greșeală și flux de lucru.
- Atribuiți controale și proprietari riscurilor importante.
- Testați cu date sintetice într-un mediu autorizat.
- Verificați modelul atunci când se schimbă o ipoteză relevantă.
Detaliile care contează.
Am nevoie de un cadru formal pentru a începe?+
Nu. O diagramă mică și un set documentat de scenarii pot fi utile. Un cadru ajută la asigurarea că analizați riscurile în mod consecvent.
Înlocuiește un scanner de vulnerabilități modelarea amenințărilor?+
Nu. Scanerele pot găsi slăbiciuni tehnice, în timp ce un model de amenințare examinează și ipotezele de design, permisiunile și fluxurile de lucru de business.
Cât de des ar trebui să actualizez modelul?+
Actualizați părțile afectate atunci când se modifică fluxurile de date, integrările, privilegiile sau funcționalitatea expusă și verificați periodic riscurile nerezolvate.
Mergeți la sursă.
Aceste referințe susțin conceptele tehnice din acest ghid. Urmați documentația actuală înainte de a modifica un sistem de producție.
- OWASP: Fișă practică pentru modelarea amenințărilor cheatsheetseries.owasp.org
- OWASP: Modelarea amenințărilor în practică devguide.owasp.org
- OWASP: Securitatea logicii de business cheatsheetseries.owasp.org
Îndrumare editorială de SwissOctet. Exemplele sunt ilustrative. Specificațiile serviciilor, opțiunile disponibile și condițiile contractuale trebuie verificate separat.