# Un modello di minaccia pratico per il tuo progetto ospitato | SwissOctet Insights https://swissoctet.com/it/insights/threat-model-a-hosted-project/ SwissOctet / Approfondimenti / Operazioni del day-two Operazioni del day-two Applicato · 6 min di lettura Un modello di minaccia pratico per il tuo progetto ospitato Mappa asset e confini di fiducia, scegli alcuni scenari di guasto realistici e trasformali in controlli che puoi testare. Di SwissOctet Editorial Salva guida Copia link IN QUESTA PAGINA 01 Definisci un ambito abbastanza piccolo da poter ragionare 02 Disegna i punti in cui la fiducia cambia 03 Scegli scenari di guasto concreti 04 Dai priorità in base all'impatto e a un percorso credibile 05 Testa i controlli in un ambiente autorizzato 06 Mantieni il modello collegato al cambiamento La tua checklist pratica Fonti e approfondimenti Torna alla libreria LA RISPOSTA DIRETTA Un modello di minaccia utile spiega cosa proteggi, chi o cosa può influenzarlo, dove cambia la fiducia e come ridurrai e testerai i rischi più importanti. Parti dal progetto reale invece che da un elenco generico di strumenti. 01 Definisci un ambito abbastanza piccolo da poter ragionare Inizia con un servizio funzionante: un portale clienti, un sito editoriale o un'applicazione interna. Annota i componenti che gestisci e i sistemi esterni su cui fai affidamento. Un modello di minaccia dovrebbe rendere visibili le ipotesi, non suggerire che ogni possibile attacco sia stato risolto. Mantieni la prima versione abbastanza piccola che le persone che distribuiscono l'applicazione possano spiegarla senza un consulente separato che interpreti il diagramma. Elenca i risultati e gli asset di valore. Questi possono includere dati dei clienti, accesso amministrativo, stato dei pagamenti, contenuti pubblicati e la capacità di ripristinare il servizio. La disponibilità può essere un asset anche quando le informazioni sono pubbliche. Decidi quali guasti sarebbero scomodi e quali danneggerebbero persone o l'organizzazione. Questa distinzione ti aiuta a dare priorità ai controlli invece di trattare ogni avviso allo stesso modo. 02 Disegna i punti in cui la fiducia cambia Le linee guida di OWASP sul modello di minaccia usano flussi di dati e confini di fiducia per rendere comprensibile un design. Per una piccola applicazione ospitata, disegna browser, processo web, database, amministratore, destinazione di backup e integrazioni esterne. Segna le informazioni che si spostano tra loro. Una richiesta che attraversa da un client non attendibile a un'operazione server privilegiata merita validazione e autorizzazione esplicite. Non presumere che trovarsi nella stessa macchina renda ogni componente ugualmente attendibile. Un processo di upload pubblico non dovrebbe avere gli stessi permessi dell'amministrazione del database. Un job di backup può aver bisogno di accesso in lettura senza la capacità di modificare i record applicativi attivi. Separare questi ruoli rende più facile contenere l'effetto di un componente compromesso e rivedere i permessi necessari. 03 Scegli scenari di guasto concreti Usa una manciata di eventi plausibili per mettere alla prova il design. Un attaccante ruba una password amministrativa; un utente richiede il record di un altro utente; un upload riempie il disco; un deployment espone un file di configurazione; una copia di ripristino non può essere ripristinata. Descrivi la condizione iniziale, il componente interessato e la conseguenza. Uno scenario specifico è più facile da testare di un'istruzione generica a migliorare la sicurezza. Includi errori e abusi legittimi del flusso di lavoro oltre alle intrusioni esterne. Un nuovo tentativo può creare due operazioni valide, oppure due richieste possono competere per modificare lo stesso oggetto. Le linee guida OWASP sulla logica di business evidenziano queste ipotesi di processo. Verifica chi è autorizzato a portare un flusso di lavoro allo stato successivo e se ripetere o riordinare una richiesta cambia il risultato in modo imprevisto. Scenario Controllo da esaminare Prove da raccogliere Credenziale amministrativa rubata Accesso limitato e un secondo fattore dove supportato Un accesso non autorizzato non può essere completato Oggetto di un altro utente richiesto Autorizzazione degli oggetti lato server Un test isolato restituisce un risultato di accesso negato Disco esaurito dagli upload Controlli su dimensione, quota e conservazione Un limite viene applicato prima del guasto del servizio Richiesta di flusso di lavoro duplicata Idempotenza e confini delle transazioni Una richiesta ripetuta crea un solo esito 04 Dai priorità in base all'impatto e a un percorso credibile Per ogni scenario, registra il suo impatto potenziale e le condizioni necessarie perché si verifichi. Evita di far finta che un punteggio numerico ipotizzato sia una probabilità precisa. Puoi comunque distinguere una password debole esposta a Internet da un evento locale altamente condizionato. Assegna un responsabile e un passo successivo pratico ai rischi importanti, così il modello crea lavoro che qualcuno può effettivamente completare. Considera il ciclo di vita delle informazioni oltre alla compromissione dell'applicazione. Un'esportazione diagnostica può divulgare dati non necessari durante un'operazione altrimenti normale. Un campo dell'account conservato può creare esposizione molto tempo dopo la fine del suo scopo. La revisione della privacy può quindi rimuovere informazioni o abbreviare la conservazione, mentre la revisione della sicurezza limita l'accesso a ciò che rimane. Entrambe le modifiche appartengono al modello quando proteggono il progetto. 05 Testa i controlli in un ambiente autorizzato Crea un ambiente di staging con autorizzazioni rappresentative e record fittizi. Verifica l'accesso negato, i limiti delle richieste, i nuovi tentativi del flusso di lavoro e il ripristino. Non usare dati reali dei clienti quando dati sintetici possono dimostrare il comportamento. L'obiettivo è verificare il controllo, non generare traffico di attacco impressionante. Rimani all'interno dei sistemi che possiedi o che sei esplicitamente autorizzato a valutare. Registra cosa è passato, cosa ha fallito e cosa rimane sconosciuto. Il risultato di uno scanner può contribuire come prova, ma non sostituisce un test delle regole di business dell'applicazione. Allo stesso modo, un'opzione di protezione di rete non verifica l'autorizzazione degli oggetti o la gestione dei file segreti. Allega i risultati utili allo scenario, così i futuri manutentori capiscono perché esiste un particolare controllo. 06 Mantieni il modello collegato al cambiamento Esamina le parti rilevanti quando aggiungi un'integrazione, esponi un nuovo endpoint, modifichi un privilegio o sposti dati verso un'altra destinazione. Non è necessario ridisegnare l'intera architettura per una piccola modifica di testo. L'innesco è un'ipotesi cambiata su accesso, informazioni o comportamento del sistema. Tieni il modello accanto alla documentazione di distribuzione e ripristino, invece di lasciarlo come risultato di un workshop una tantum. SwissOctet fornisce un catalogo di scelte infrastrutturali, non un modello di minaccia completo dell'applicazione. Scegli la configurazione e le opzioni che supportano i tuoi controlli, poi verifica la distribuzione che realizzi. Un modello piccolo e mantenuto con azioni testate è più utile di una grande raccolta di prodotti di sicurezza senza una chiara spiegazione dei rischi che affrontano. TRASFORMALO IN AZIONE La tua checklist pratica. ✓ Elenca gli asset e le conseguenze del guasto. ✓ Disegna i flussi di dati e i confini di fiducia. ✓ Scegli scenari specifici di intrusione, errore e flusso di lavoro. ✓ Assegna controlli e responsabili ai rischi importanti. ✓ Esegui test con dati sintetici in un ambiente autorizzato. ✓ Rivedi il modello quando cambia un'ipotesi rilevante. Scarica la checklist DOMANDE COMUNI I dettagli che contano. Serve un framework formale per iniziare? + No. Un piccolo diagramma e un insieme documentato di scenari possono essere utili. Un framework aiuta a garantire che i rischi vengano esaminati in modo coerente. Uno scanner di vulnerabilità sostituisce il threat modeling? + No. Gli scanner possono trovare debolezze tecniche, mentre un modello di minaccia esamina anche ipotesi di progettazione, autorizzazioni e flussi di lavoro aziendali. Con quale frequenza devo aggiornare il modello? + Aggiorna le parti interessate quando cambiano flussi di dati, integrazioni, privilegi o funzionalità esposte, e rivedi regolarmente i rischi irrisolti. RIFERIMENTI PRIMARI Vai alla fonte. Questi riferimenti supportano i concetti tecnici di questa guida. Segui la documentazione corrente prima di modificare un sistema di produzione. OWASP: Cheat Sheet sul Threat Modeling cheatsheetseries.owasp.org OWASP: Threat modeling nella pratica devguide.owasp.org OWASP: Sicurezza della logica di business cheatsheetseries.owasp.org Guida editoriale di SwissOctet. Gli esempi sono illustrativi. Le specifiche di servizio, le opzioni disponibili e le condizioni contrattuali devono essere verificate separatamente. COLLEGA LE CONOSCENZE Infrastruttura correlata. Vector VPS Svizzera Metal Atlas Svizzera Canvas Web Svizzera MANTIENI IL FILO Le tue prossime note sul campo. Esplora tutte le guide NOTA SUL CAMPO / 01 + Operazioni del day-two Applicato Costruisci un backup che puoi davvero ripristinare Scegli un obiettivo di ripristino, proteggi una copia indipendente e prova il ripristino prima che un incidente ti costringa a farlo. 4 min di lettura Leggi la guida NOTA SUL CAMPO / 02 + Operazioni del day-two Applicato Amministrazione sicura di Windows RDP senza perdere l'accesso Separa raggiungibilità di rete, autenticazione e privilegi, poi verifica un percorso di ripristino prima di restringere l'accesso remoto. 6 min di lettura Leggi la guida NOTA SUL CAMPO / 03 + Operazioni del day-two Applicato Una baseline di hardening di Linux VPS che puoi mantenere Amministrazione sicura, esponi solo i servizi necessari e stabilisci aggiornamenti e ripristino senza chiuderti fuori. 6 min di lettura Leggi la guida