Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Quando si stabilisce la disciplina Architettura di sicurezza, questo articolo fornisce indicazioni su come applicare 10 leggi non modificabili del rischio di sicurezza come suggerimenti pratici durante la definizione e la modernizzazione della disciplina Architettura di sicurezza.
Esaminare le leggi non modificabili della sicurezza
L'architettura esiste per identificare i requisiti complessi e convertirli in linee guida utili per ridurre i rischi di sicurezza, limitare i danni e mantenere i sistemi disponibili nel tempo. Alla base di questo lavoro sono le leggi immutabili della sicurezza.
Queste leggi descrivono verità scomode sulla sicurezza che consentono di pianificare un controllo efficace, evitare errori comuni che minano l'architettura della sicurezza e creano rischi aziendali.
| Legge immutabile | Impatto sull'architettura |
|---|---|
| 1. Se un cattivo attore può convincere voi a eseguire il loro programma, non è il vostro computer | L'esecuzione di codice non autorizzato causa la perdita di controllo. La prevenzione da sola non è sufficiente. |
| 2. Se un malintenzionato può modificare il sistema operativo, non è il tuo computer | La compromissione del piano di controllo è un rischio sistemico. Questo vale se il piano di controllo è un sistema operativo locale, un sistema di gestione delle identità, uno strumento di sicurezza o qualsiasi altro elemento con l'accesso a livello di sistema/radice. |
| 3. Se un malintenzionato ha accesso fisico senza restrizioni, non è il tuo computer | L'esposizione fisica deve essere considerata, non considerata come un'eccezione. |
| 4. Se un attore malintenzionato può eseguire contenuti attivi sul tuo sito Web, non è il tuo sito Web | I limiti di esecuzione definiscono i limiti di attendibilità. |
| 5. Le password deboli superano la sicurezza avanzata | Gli errori di identità superano i controlli a più livelli. |
| 6. Un computer è sicuro solo quanto il suo amministratore | L'accesso con privilegi è una priorità di sicurezza fondamentale. |
| 7. I dati crittografati sono sicuri come la chiave di decrittografia | La crittografia senza governance è fragile. |
| 8. Uno scanner antimalware non aggiornato è marginalmente migliore di nessuno | Le difese statiche decadono. |
| 9. L'anonimato assoluto non è raggiungibile | La visibilità è inevitabile. |
| 10. La tecnologia non è una panacea | È necessario presupporre gli errori di persone e processi. |
Applicare le dieci leggi del rischio di cybersecurity
Anche dopo aver compreso il modo in cui il controllo di sicurezza è potenzialmente perso e l'impatto sull'architettura di sicurezza, queste informazioni non sono sufficienti per progettare un sistema. Gli architetti della sicurezza devono anche comprendere:
- Per cosa stiamo ottimizzando? - Dove ci concentriamo? - Quali compromessi sono accettabili?
Per capire queste domande, possiamo applicare 10 leggi comuni sul rischio di cybersecurity. Ogni serie di leggi riguarda diversi aspetti della cybersecurity.
| Legge | Implicazione dell'architettura | Linee guida per la modernizzazione |
|---|---|---|
| 1. I successi in ambito sicurezza stanno riducendo il ROI dell'attaccante | Progettare architetture che aumentino i costi per gli utenti malintenzionati e riducano il guadagno, soprattutto per le risorse di alto valore. | - Concentrare i controlli relativi all'identità, all'accesso con privilegi e ai dati sensibili. - Ridurre le zone di fiducia piatte; segmentare i sistemi in modo che una compromissione non si propaghi. - Dare priorità alle protezioni che interrompono le sequenze di attacco più comuni, non i casi speciali. |
| 2. Non stare al passo significa restare indietro | Le architetture statiche hanno esito negativo. L'architettura deve presupporre un'evoluzione continua. | - L'architettura di sicurezza non viene mai eseguita. Deve essere operativamente sostenibile e costantemente migliorata. - Progettare per l'aggiornamento continuo (applicazione di patch, configurazione, criteri). - Preferisce servizi nativi del cloud e gestiti che si evolvono più velocemente rispetto ai sistemi locali o su misura. - Garantire che la visibilità e l'inventario siano requisiti architetturali, non elementi secondari. |
| 3. La sicurezza è un abilitatore aziendale (la produttività vince sempre) | Se l'architettura crea attrito, viene ignorata. | - Una buona architettura di sicurezza consente la produttività per impostazione predefinita. - Favorire l'accesso basato sull'identità rispetto alla complessità della rete. - Integrare i controlli di sicurezza in flussi di lavoro standard per utenti e sviluppatori. - Rendere i percorsi sicuri i percorsi più semplici. |
| 4. Agli aggressori non importa | Gli attaccanti sfruttano qualsiasi percorso di accesso disponibile nell'ambiente. L'architettura deve eliminare i percorsi più economici, non difendere solo quelli ovvi. | - L'architettura deve riflettere il comportamento reale degli utenti malintenzionati, non le convinzioni idealizzate nei singoli controlli. - Presupponi una compromissione dovuta a phishing, configurazioni errate o protocolli obsoleti. - Rimuovere singoli punti architetturali di errore irreversibile. - Protezione contro il ciclo di vita completo degli attacchi (spostamento laterale, esecuzione su obiettivi), non solo l'accesso iniziale. |
| 5. La priorità spietata è un'abilità di sopravvivenza | Non puoi proteggere tutto. | - L'architettura riguarda la scelta di cosa non fare. - Identificare gli asset più critici e progettare una difesa in profondità per essi. - Accettare una garanzia più bassa in cui l'impatto aziendale è inferiore. - Usare gli scenari aziendali per guidare gli investimenti architetturali. |
| 6. Cybersecurity è uno sport di squadra | L'architettura deve integrare il lavoro tra discipline e team. | - Gli architetti progettano il coordinamento, non solo i controlli. - Allineare l'architettura ai team della piattaforma, agli sviluppatori e alle operazioni. - Delegare i controlli alle piattaforme che possono migliorarle (provider di servizi cloud, sistemi di gestione delle identità). - Evitare soluzioni personalizzate in cui sono sufficienti servizi condivisi. |
| 7. La tua rete non è affidabile come pensi che sia | Il trust di rete non deve mai essere il piano di controllo primario o solo. | - Questa legge è alla base del passaggio dal design incentrato sul perimetro. - Spostare le decisioni di trust in identità, dispositivo e contesto dell'applicazione. - Progettare architetture che presuppongono che la rete sia osservabile e ostile. - Mantenere controlli efficaci, ad esempio firewall/web app firewall (WAF), ma non basarsi su di essi per rilevare/bloccare tutto. - Utilizzare modelli di accesso Zero Trust in modo coerente in tutti gli ambienti. |
| 8. Le reti isolate non sono automaticamente protette | L'isolamento è efficace solo se rigorosamente progettato e mantenuto. | - Mantenere l'isolamento della rete che funziona correttamente. Assicurati di mantenerlo e che gli attaccanti non possano aggirarlo facilmente. - L'architettura deve tenere conto delle persone e del processo, non solo della topologia. - Considera l'isolamento come un sistema, non una regola di filtro di rete. - Mettere in sicurezza tutti i punti di collegamento (mezzi rimovibili, accessi dei fornitori, amministratori). - Presupporre compromessi e applicare controlli operativi e di identità forti, anche nella progettazione "air-gapped". |
| 9. La crittografia da sola non è una soluzione di protezione dei dati | La cryptologia è sicura come le chiavi che lo sbloccano. | - La crittografia è importante, ma è inefficace senza implementazione e funzionamento sicuri. - Progettare la gestione centralizzata delle chiavi e la governance degli accessi. - Proteggere i percorsi di decrittografia in modo aggressivo come l'archiviazione crittografata. - Combinare la crittografia con identità, monitoraggio e applicazione dei criteri. |
| 10. La tecnologia non risolve le persone e i problemi di elaborazione | L'architettura deve presupporre esseri umani e processi imperfetti. | - Modernizzare l'architettura di sicurezza per ridurre il raggio di esplosione dell'errore umano. Non lasciare che clic su un singolo messaggio di posta elettronica di phishing causi un errore del comportamento di sicurezza. - Progettare sistemi resilienti agli errori. - Automatizzare le protezioni dove possibile. - Evitare architetture che dipendono da un'operazione manuale impeccabile. |
Creare un'architettura
In qualità di progettista della sicurezza, è possibile usare queste due tabelle come lenti complementari. Uno per convalidare la correttezza tecnica e l'altro per favorire la definizione di priorità basata sul rischio. In combinazione, formano un quadro decisionale pratico per la progettazione e la modernizzazione dell'architettura.
| Leggi | Obiettivo | Uso architettonico | Domande |
|---|---|---|---|
| Leggi immutabili della sicurezza | Cattura le verità tecniche che sono sempre valide. | Assicurarsi che le architetture non violano la realtà tecnica. Ipotesi di test Convalidare i limiti di attendibilità. Evita la falsa sicurezza. |
L'architettura è fondamentalmente solida? La progettazione si basa su qualcosa che può essere facilmente ignorato? Si presume che la tecnologia possa compensare amministratori non affidabili, password deboli o modalità di accesso fisico? Stiamo scambiando la crittografia, l'isolamento o gli strumenti per un controllo effettivo? |
| Leggi del rischio di cybersecurity | Decidere cosa conta di più. | Individua dove investire gli sforzi di architettura. Definisci le roadmap di modernizzazione. Giustificare i compromessi con i responsabili aziendali. |
Dove ottengono il maggior guadagno gli attaccanti con il minimo sforzo? Quali controlli modificano effettivamente il comportamento degli utenti malintenzionati? Che lavoro non vale più la pena fare? |
Example
Quindi, se prendiamo un esempio che applica entrambe le tabelle insieme.
| Decisione di progettazione | Lente di leggi immutabili | Lente delle dieci leggi |
|---|---|---|
| Ridurre la dipendenza da ACL di rete all'accesso basato sull'identità | Le reti non sono attendibili, l'identità è importante. | Aumenta il costo per gli attaccanti ed è in linea con i principi dello Zero Trust. |
| Classificare in ordine di priorità l'autenticazione a più fattori per gli amministratori prima di rafforzare i firewall perimetrali. | Le password deboli superano la sicurezza avanzata. | Modo più economico per interrompere le catene di attacco comuni. |
| Segmentare i carichi di lavoro invece di affidarsi agli “air gap” | L'isolamento non è protetto automaticamente. | Riduce l'impatto quando gli attaccanti riescono a entrare. |
| Automatizza l'applicazione delle patch e il rilevamento delle deviazioni della configurazione | Le difese non aggiornate hanno esito negativo. | Non tenere il passo significa restare indietro |
L'uso di entrambe le tabelle consente di ottenere architetture di sicurezza che:
- Partite dal presupposto di una compromissione, concentratevi sulla riduzione del rischio e sulla limitazione dei danni, invece di promettere una prevenzione assoluta.
- Concentrarsi sull'identità, sui privilegi e sul movimento laterale, non solo sulla difesa perimetrale.
- Presupponete un cambiamento e un’evoluzione continui, e non diagrammi statici.
- Bilanciare la produttività aziendale con la riduzione dei rischi. Allineare i controlli di sicurezza al valore aziendale.
- Integrare persone, processi e tecnologie.
- Riduci il ROI degli attaccanti invece di inseguire la sicurezza perfetta.
- Applica i principi Zero Trust da un capo all'altro.
Passaggi successivi
Assicurarsi di esaminare le altre discipline di sicurezza.