Categorie di sicurezza durante la valutazione di servizi e protocolli

1

Sto creando alcuni servizi accessibili esternamente per una piccola azienda e valutando alcune delle diverse opzioni che ho. Questo è tutto nuovo per me. Ho trovato la domanda "è sicuro?" essere molto vago e fuorviante. Quindi, per valutare i pro e i contro di queste opzioni in termini di sicurezza, sto cercando di suddividere questa domanda in categorie più ragionevoli.

Pensandoci, ho diviso il problema della "sicurezza" nelle seguenti quattro categorie:

  • Sicurezza dell'accesso: il sistema è vulnerabile a accessi corretti ma non autorizzati, ad es. le password sono troppo facili da indovinare, sono vulnerabili agli attacchi dei dizionari, sono configurate correttamente per impedire l'accesso anonimo, il sistema obbliga un utente a utilizzare le stesse credenziali per molti servizi, mentre le credenziali vengono condivise con altri mezzi (ad es. e-mail di promemoria password), il lato client è soggetto a problemi (ad esempio un servizio basato sul Web lascia le password nelle richieste HTTP get nella cronologia del browser), ecc.

  • Sniffing / intercettazione / modifica del traffico: Il sistema è vulnerabile a un utente malintenzionato (o un utente malintenzionato che cerca solo di causare problemi casuali, ad esempio il monitoraggio del traffico wifi in un luogo pubblico) può ottenere credenziali o altre informazioni guardando il traffico di rete (ad es. le credenziali e / o i dati trasmessi con crittografia scarsa o nulla) o intercettandolo e modificandolo (ad es. attacchi mitm)?

  • Exploits / holes: Il sistema è vulnerabile a difetti nelle applicazioni di servizio o nei protocolli sottostanti (cose che in genere finiscono per essere scoperte e riparate, ma che sono fuori dal mio controllo)? Questa categoria non include gli exploit realizzati dagli attacchi basati su mitm , ma piuttosto, le cose che possono essere sfruttate senza intercettare il traffico esistente (ad esempio il il codice exploit rosso ha sfruttato ).

  • Accesso "interno": (non sai come chiamarlo) Se un utente malintenzionato accede a un servizio, può facilmente ottenere altre informazioni da quel servizio o da altri ( ad esempio un servizio con vulnerabilità di SQL injection, accesso root ad altre macchine su una LAN dopo un accesso VPN non autorizzato, ecc.)

Ho quindi tentato di analizzare i pro e i contro di varie opzioni di servizio in termini di categorie sopra. Le categorie di cui sopra, a mio avviso, presentano livelli di rischio chiaramente diversi a loro associati.

La mia domanda è: la mia categorizzazione è corretta, o almeno ragionevole? In caso contrario, tenendo presente che si tratta di una piccola impresa che è improbabile che sia un bersaglio esplicito per gli aggressori ( esplicito ), ovviamente sembra che ci sia ancora il flusso di indirizzi IP stranieri casuali che sembrano essere costantemente e inspiegabilmente cercando di ottenere accessi SSH e richiedere strane pagine web casuali), come viene solitamente suddivisa e analizzata la questione della "sicurezza" quando si valuta l'aggiunta di un nuovo servizio?

Sono costantemente frustrato da affermazioni come "X non è sicuro" senza ulteriori spiegazioni. Ho trovato che certe cose sono sicure abbastanza per certi usi; e i miei obiettivi principali sono: 1) trovare un modo per valutare oggettivamente se un servizio o un protocollo è abbastanza buono per una data situazione - soppesare i suoi rischi rispetto ai benefici, e 2) essere in grado di rispondere in modo chiaro e adeguato agli utenti domande sulla sicurezza delle opzioni che scelgo.

Il motivo è che sto cercando di classificare queste cose in base all'ambiente in cui un utente malintenzionato dovrebbe trovarsi, agli strumenti e alle competenze richieste e alla probabilità stimata che qualcuno lo stia effettivamente provando.

    
posta Jason C 18.02.2015 - 23:13
fonte

1 risposta

1

Risolvere piccoli problemi è certamente più facile che risolvere grossi problemi. Ma potresti voler pensare a come decomponesti ulteriormente queste categorie in una gerarchia (decomponi ulteriormente i problemi prima di cercare di trovare una risposta). per esempio. in genere quello che hai descritto come sicurezza di accesso è scomposto in accesso, autenticazione e autorizzazione.

Probabilmente scoprirai che vorrai rivisitare e sviluppare questa gerarchia mentre lavori sull'analisi.

Un buco abbastanza ovvio nel tuo modello attuale è che stai considerando solo uno scenario "noi e loro", ma come fornitore di servizi, ci sono più parti coinvolte. Il sistema che stai valutando (ad esempio) fornisce un mezzo per attribuire attività a individui specifici o per lo meno differenziare tra i tuoi clienti e te stesso?

Un altro approccio (complementare - non esclusivo) è quello di buttarti nel ruolo dell'attaccante e considerare in che modo il sistema che stai valutando ti impedisce di realizzare scopi nefandi: leggere la posta di qualcuno, modificare una proposta di progetto, sfigurare un sito web. ... Dato un risultato specifico che facilita le scelte informate sul fatto che una soluzione che non sia completamente sicura (cioè tutte quante;)) valga il rischio - fai una congettura sulla probabilità che qualcuno voglia raggiungere il risultato, moltiplicare per un indovina la probabilità che la soluzione possa essere sfruttata e moltiplicata per l'impatto sui costi. (Esistono modelli più complessi per la valutazione del rischio).

    
risposta data 19.02.2015 - 14:27
fonte

Leggi altre domande sui tag