# Un model de amenințare practic pentru proiectul dvs. găzduit | SwissOctet Insights https://swissoctet.com/ro/insights/threat-model-a-hosted-project/ SwissOctet / Perspective / Operațiuni din ziua a doua Operațiuni din ziua a doua Aplicat · 6 min de citire Un model practic de amenințare pentru proiectul dumneavoastră găzduit Cartografiați activele și limitele de încredere, alegeți câteva scenarii realiste de eșec și transformați-le în controale pe care le puteți testa. De SwissOctet Editorial Salvați ghidul Copiați linkul PE ACEASTĂ PAGINĂ 01 Definiți un domeniu suficient de restrâns pentru a putea raționa asupra lui 02 Desenați locurile în care se schimbă încrederea 03 Alegeți scenarii concrete de eșec 04 Prioritizați după impact și o cale credibilă 05 Testați controalele într-un mediu autorizat 06 Mențineți modelul conectat la schimbare Lista dumneavoastră practică de verificare Surse și lecturi suplimentare Înapoi la bibliotecă RĂSPUNSUL DIRECT 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. 01 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. 02 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. 03 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 04 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. 05 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. 06 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ă. TRANSFORMAȚI-O ÎN ACȚIUNE 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ă. Descărcați lista de verificare ÎNTREBĂRI FRECVENTE 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. REFERINȚE PRINCIPALE 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. CONECTAȚI CUNOAȘTEREA Infrastructură conexă. Vector VPS Elveția Metal Atlas Elveția Canvas Web Elveția PĂSTRAȚI FIRUL Următoarele dumneavoastră note de teren. Explorați fiecare ghid NOTĂ DE TEREN / 01 + Operațiuni din ziua a doua Aplicat Construiți o copie de siguranță pe care o puteți restaura cu adevărat Alegeți o țintă de recuperare, protejați o copie independentă și exersați restaurarea înainte ca un incident să forțeze problema. 4 min de citit Citiți ghidul NOTĂ DE TEREN / 02 + Operațiuni din ziua a doua Aplicat Administrare securizată Windows RDP fără a pierde accesul Separați accesibilitatea în rețea, autentificarea și privilegiile, apoi verificați o rută de recuperare înainte de a restricționa accesul la distanță. 6 min de citire Citiți ghidul NOTĂ DE TEREN / 03 + Operațiuni din ziua a doua Aplicat O bază de întărire Linux VPS pe care o puteți menține Administrare securizată, expuneți doar serviciile necesare și stabiliți actualizări și recuperare fără a vă bloca accesul. 6 min de citire Citiți ghidul