Come si spiega agli esperti che un server di database non deve risiedere nella DMZ?

SANS "" Rendere sicura la tua rete per i database "( link ) si legge un po 'datato in alcune sezioni, ma fornisce un discreto livello di guida "per principianti" nella direzione che stai cercando.

Potresti anche sfogarti nel centro risorse del NIST americano ( link ). Penso che la ISO ISO / IEC 27033-2: 2012 sia in argomento, ma non ho una copia a portata di mano per essere sicuro.

Stai provando a separare / isolare i server più sensibili (i server del database) dai più esposti (e quindi vulnerabili).

Stai proponendo un approccio di "difesa in profondità", che cerca di a) prevenire gli attacchi ove possibile, e b) ritardare il loro progresso (e l'accesso alle cose importanti) quando no.

Idealmente, tutto è sempre temprato e aggiornato, i server ascoltano solo il traffico sulle porte richieste e solo dai dispositivi consentiti, tutto il traffico "in volo" è inaccessibile agli ascoltatori non autorizzati (tramite crittografia e / o isolamento) e tutto è monitorato per intrusione e integrità.

Se tutto ciò è a posto con certezza del 100%, allora grande, la tua "opposizione" ha indirizzato il punto a) sopra, il più possibile . Ottimo inizio, ma per quanto riguarda il punto b)?

Se un server Web viene compromesso, l'architettura proposta si trova in una posizione migliore. La loro impronta di attacco potenziale e il loro vettore sono molto più grandi di quanto debbano essere.

La giustificazione per un database separato dai server Web non è diversa dalla giustificazione che hanno accettato per separare i server Web dalla LAN. Più senza mezzi termini: se sono così convinti che un server Web compromesso non presenti alcun pericolo per altri sistemi nella stessa zona di sicurezza, perché pensano che sia necessaria una DMZ?

È terribilmente frustrante essere nella tua situazione. Per lo meno, nella tua posizione creerei una nota di rischio che delinea le tue preoccupazioni e i tuoi suggerimenti, e assicurati che la riconoscano. CYA, comunque.

It's like, "Put the jewelry box outside the house so that robbers won't bother getting in for the TV?"

Sì, è esattamente così.

Se non ti interessa il valore del database, relativamente parlando, allora è logico lasciarlo fuori - se l'ipotesi è che l'applicazione sia terribilmente insicura, ma devi comunque metterla in pratica per qualsiasi cosa ragione, e non voglio metterlo al sicuro, allora è logico come un modo per isolare questo orribile sistema insicuro da tutti gli altri sistemi interni.

D'altra parte, non c'è davvero alcuna scusa per aspettarsi di avere TROVARE un'applicazione insicura che consente l'acquisizione completa del server del database. Inoltre non esiste una vera ragione per usare "esposizione" come alternativa all '"isolamento" - esistono anche soluzioni semplici per farlo.

Quando si tratta di esso, sembra che questa sia una delle 2 possibili situazioni:

1. Questi cosiddetti "esperti" sono davvero incapaci.
2. Ci sono altri requisiti aziendali che vengono scambiati qui.

Penso che la tua analogia funzioni perfettamente. Se poi ti dicono l'equivalente di "In realtà, quei gioielli sono falsi, oh, beh, la TV è davvero un 60" 5K lavoro personalizzato con cerchi d'oro ", quindi quello potrebbe essere un compromesso ragionevole (ancora meglio farlo bene, anche se ).
Altrimenti, è probabile che non ci sia modo di spiegarlo, dal momento che stanno lavorando da una mancanza di conoscenza.

Se il database contiene i dettagli della carta, si può facilmente sostenere che non si soddisfa il requisito PCI DSS sulla protezione appropriata.

Inoltre, non supera i controlli di integrità su singoli punti di errore e protegge le risorse principali.

Se i dati valgono miliardi, perché non ne spenderei qualche migliaio per aggiungere livelli di protezione? Le buone pratiche del settore sono le zone di sicurezza a più livelli.

Potresti puntarli su PCI, Guida alle buone pratiche ISF e molti altri.

Se stai suggerendo che il server del database viene spostato dall'essere nella stessa zona di sicurezza del server web per essere nella stessa zona di sicurezza di alcuni sistemi interni, allora si potrebbe ragionevolmente concludere che stai riducendo la sicurezza.

Se lo status quo è che il server web e il server database sono entrambi nella DMZ e non sono consentite connessioni da DMZ a rete interna, spostare il server database da DMZ a rete interna richiederebbe connessioni da DMZ a rete interna. Ciò significherebbe che stai riducendo la sicurezza della rete interna senza ottenere una protezione significativamente migliore per il database.

Se ritieni che il database sia più sensibile della rete interna (che potrebbe essere vero), non vorrai compromettere la rete interna per ottenere l'accesso diretto al database.

Quindi il punto che devi fare è che non vuoi spostare il server del database da una zona di sicurezza a un'altra, invece quello che vuoi fare è creare una zona di sicurezza completamente nuova. Per seguire davvero ciò, dovresti effettivamente comprare un firewall aggiuntivo e metterlo tra la DMZ e la rete extra protetta.

Quindi si riduce alla valutazione del costo di acquisto e mantenimento di questo firewall aggiuntivo rispetto alla sicurezza aggiuntiva che fornisce.

AvID ha già coperto la domanda principale, ma arrivando da un'angolazione leggermente diversa la maggior parte dei firewall supporterà più interfacce e può fornire il controllo del traffico tra le interfacce.

La configurazione delle interfacce multiple per ospitare ciascuno degli aspetti della soluzione (frontend, middleware, backend) ridurrebbe il rischio di una continua compromissione del database dal server web senza la necessità di più firewall fisici (se questo è ciò che gli altri team hanno sono preoccupati per ... è un problema di costi?) e senza introdurre una rotta verso la rete interna.

Ti stai chiedendo se questo ti darebbe una "leva" pratica per supportare l'argomento per implementare una separazione, cioè porta qualcosa di diverso nella discussione che devono contrastare?

Se non si tratta di uno scenario what-if basato su una vulnerabilità del server Web storico, che avrebbe comportato un ulteriore compromesso su qualsiasi altro server sullo stesso segmento di rete (incluso il database) e su come un DMZ con livelli avrebbe impedito il proseguimento compromesso, presumibilmente ci sarebbe un costo monetario quindi sarebbe "facile" illustrare il vantaggio in termini di costi / sforzi?

Supponendo che tu stia tentando di persuaderli a farlo piuttosto che (necessariamente) convincerli che è corretto:

Spiega che quando i loro grandi clienti e potenziali clienti vengono a fare un controllo di sicurezza, falliranno.

Se l'ostacolo è l'impresa, quella sarà l'unica ragione sufficiente e solo necessaria.

@Craig ... buona risposta pratica e sensata. Poiché bruce_bana ha affermato che il costo non dovrebbe essere un problema, questo dovrebbe essere realistico da implementare dopo aver usato la risposta @DerekM (che è anche buona) per convincere i presunti esperti di sicurezza. @ DK ... buona risposta CYA business. Questo lo implementerei sicuramente se fossi bruce_bana. @bruce bana ... prova questo link da questo sito per un problema / soluzione comparabile / correlato ... Qual è la procedura migliore per collocare i server di database in topologie di rete protette

Una buona argomentazione è che la barra non è così elevata da separare i server Web e i server di database in DMZ separati.

Utilizzare un router / firewall reale e posizionare i server Web ei server di database su VLAN separate, entrambi al di fuori della LAN interna sicura, con regole firewall che controllano l'accesso alle porte obbligatorie minime richieste da Internet ai server Web, dai server Web ai server di database e nessun accesso proveniente dai server Web alla LAN sicura.

Il firewall impedirebbe anche qualsiasi accesso diretto da Internet ai server di database e controllerebbe strettamente qualsiasi accesso dai server di database verso la LAN sicura (per scopi di autenticazione o altro).

In questo modo, l'attaccante non può nemmeno accedere direttamente alla rete che contiene i server del database.

Se ottengono una testa di ponte su uno dei tuoi server web, non si trovano ancora sulla stessa rete con accesso illimitato per attaccare i server del database e se hai qualche tipo di monitoraggio dei registri sul posto dovresti ricevere notifiche sulla violazione dei server web prima che gli aggressori abbiano avuto molto tempo per attaccare qualsiasi altra cosa.

Anche se poi riescono a violare i server del database dopo un certo periodo di tempo attraverso l'unica porta aperta che il server Web può usare per comunicare con il database, hanno perso tutto quel tempo ottenendo relativamente poco, durante il quale tempo sei stato a conoscenza del loro attacco, invece di passare tutto questo tempo a entrare nella tua LAN sicura.

Non riescono nemmeno a raggiungere la LAN dalla DMZ in cui vivono i server Web, quindi la loro unica via di accesso alla LAN in qualsiasi forma è di saltare sui server di database, protetti nell'altra DMZ. Le probabilità sono che i server di database siano o saranno collegati a una sorta di sistema di autenticazione aziendale (Active Directory o qualsiasi altra cosa). Vuoi questa funzionalità nella stessa DMZ con i tuoi server web pubblici?

Se posso essere abbastanza interessato ai problemi di sicurezza per creare subnet guest e DMZ nella mia home , avere un posto dove mettere "cose" ("Internet of Things") senza averli direttamente su la mia LAN, una preoccupazione che vale miliardi può sicuramente permetterci di condividere la mente e il tempo di fare la stessa cosa con server Web e server di database importanti. Lo sto facendo in ufficio con una combinazione di una serie di switch L2 / L3 gestiti da parecchie migliaia di dollari, un SonicWall UTM e un router Ubiquiti EdgeMax. A home , ho un Ubiquiti EdgeRouter Lite da 100 $, uno switch HP a 8 porte gestito da $ 100 e un Ubiquiti Unifi AP che supporta più VLAN e la mia configurazione è totalmente in grado di fare quello di cui stiamo parlando .

E ho la tranquillità di non preoccuparmi del fatto che il mio DVR connesso alla rete, la stampante, il lettore BluRay, il termostato e qualsiasi altra cosa, esegua chi sa che cosa è un bug scaduto con chi sa cosa non è stato scoperto exploit, potrebbero essere violati e raggiungere il mio computer e i miei file personali attraverso la rete.

Non è molto difficile per gli esperti di sicurezza configurare questo tipo di cose, e certamente non deve coinvolgere l'hardware fisico separato per ogni firewall. SDN (software defined networking) è di gran moda al giorno d'oggi, giusto?

Anche i $ 100 EdgeRouter Lite possono inoltrare quasi 1 Gbps attraverso il router, con il supporto di più interfacce virtuali e regole firewall tra tutte queste interfacce.

Una piccola scatola è davvero un intero cestino pieno di firewall.

Quindi, se spendi soldi veri su un router di fascia alta, otterrai tutte queste funzionalità e altre ancora con prestazioni di routing più elaborate.

Anche qualcosa come Ubiquiti EdgeRouter Pro 8 ti offre 2 milioni di pacchetti al secondo per soli $ 375, con 8 interfacce fisiche e subinterfacce VLAN su ciascuno di questi se ne hai bisogno. Se hai bisogno di prestazioni più elevate, guarda su Brocade (Vyatta), Cisco, Juniper, ecc. Per hardware più grande. O qualcosa come la serie SuperMassive di Dell / Sonicwall. Oppure esegui il router virtuale Vyatta su un potente server multi-core Xeon.

Non sto cercando di spacciare i router, solo facendo in modo che la barra non sia effettivamente così alta da ottenere il tipo di separazione di sicurezza che probabilmente dovresti avere e ovviamente vuoi qui.

Informa il tuo diretto superiore che non sei autorizzato ad accettare tale rischio per conto dell'azienda. Fai notare che il valore dei dati nel database è $ xxx e che quel livello di accettazione del rischio deve provenire da qualcuno autorizzato a farlo, e chiedergli di difendere il fatto che un membro del management esecutivo si impegni a sottoscrivere l'accettazione del rischio.

Per stimare il valore dei dati, determinare se si tratta di dati legati a PCI DSS (se sì, guarda il costo per cliente che Target / Home Depot ha subito in vendite perse, monitoraggio del credito, frode), o se è PII (se è così, guarda il danno finanziario per paziente che i sistemi medici hanno subito in perdita di fiducia, monitoraggio furto d'identità, perdita di reputazione), o se è il vantaggio competitivo della tua azienda (segreti commerciali, non ancora liberati finanziari, proprietà intellettuale) quindi il valore dei dati potrebbe essere la valutazione corrente dell'azienda.

Se ti viene dato un ordine diretto di accettare il rischio per conto della società, ti potrebbe essere chiesto di iniziare ad agire in qualità di funzionario della società, e come tale, hai un obbligo (probabilmente un obbligo legale) di Fai notare che sei una persona non nominata che ha chiesto di esibirsi come tale e che dovrebbe riassumere la catena di gestione al consiglio di amministrazione della società. Preparatevi a un significativo respingimento e spendete un capitale politico significativo per renderlo noto.

Buona fortuna!