SSL è assolutamente il primo suggerimento corretto qui, ma SSL da solo non ti protegge da:
-
Attacchi diretti come XSS, SQL injection, inclusione di file remoti
Se la tua app è vulnerabile a un attacco XSS, il codice javascript può essere recapitato tramite la connessione SSL al client, dove può trasferire i dati sensibili a un altro server controllato dagli hacker pur consentendo le normali richieste di accadere tramite SSL link, o potrebbe rubare le credenziali del cliente e accedere come loro. L'iniezione SQL può consentire all'utente malintenzionato di recuperare i dati direttamente dal database o ignorare l'autenticazione e accedere come utente in questione. RFI potrebbe fornire all'attaccante un account di shell sul tuo sistema che consentirebbe uno o tutti i precedenti.
-
Attacchi fuori banda come keylogger e virus, sia sui sistemi client che sul server.
Se sul sistema è in esecuzione un servizio vulnerabile non correlato, ad esempio un server di posta obsoleto, un utente malintenzionato potrebbe effettuare il targeting e ottenere un account di shell sul sistema. Un virus sul tuo desktop di lavoro potrebbe rubare le tue credenziali al prossimo accesso al tuo server. Un keylogger sul sistema del client potrebbe rubare le proprie credenziali e, sebbene tecnicamente non sia colpa tua, il cliente ti incolperà comunque e potresti avere difficoltà a dimostrare che non ti è stato rubato.
-
Attacchi di recente sviluppo contro SSL come BEAST, CRIME e Lucky Thirteen.
È inevitabile che ci sia un periodo di tempo in cui sei vulnerabile a questo genere di attacchi. Il tuo compito di proteggere i dati del tuo cliente è:
- Mantieni aggiornati i nuovi attacchi noti che interessano qualsiasi prodotto che utilizzi.
- Valutare ciascuno al più presto possibile e decidere se continuare a eseguire il servizio interessato o chiuderlo fino a quando non è disponibile una patch. (Potresti essere in grado di delegare questa decisione ai tuoi clienti.)
- Aggiorna e / o patch il prima possibile.
Sembra che tu sia un amministratore di sistema solitario che si prende cura della sicurezza, piuttosto che un dipendente dedicato esclusivamente alla sicurezza, il che significa che tutto ciò è probabilmente scoraggiante. Un buon modo per avvicinarsi a questo sarebbe quello di classificare ognuno dei suggerimenti che si ricevono in termini di valore e provare ad implementarne uno ogni mese o giù di lì. Imposta un intervallo di tempo realistico e prova ad attenervisi.
- Verifica del codice / test di penetrazione del codice scritto dalla tua organizzazione.
- Rilevamento delle intrusioni.
- Rilevamento anomalo del comportamento del client (indirizzo IP sconosciuto, agente utente sconosciuto, ecc.)
- Aggiornamenti regolari e rapidi del sistema operativo e del prodotto.
- Riduci al minimo la superficie di attacco (rimuovi i servizi non necessari dal tuo server).
- Crittografia dei dati quando vengono archiviati nel database e in qualsiasi backup.
- Registrazione di qualsiasi tipo di accesso ai dati. Un buon software di database e controlli OS appropriati possono far rispettare questo. Questo può aiutare ad assolvere la colpa se una violazione non è stata colpa tua e rintracciare chi è il colpevole e come sono entrati se è stata colpa tua.
- Sicurezza pervasiva in tutta la tua organizzazione.
Il PCI-DSS contiene una buona lista di cose che possono migliorare la resistenza generale agli attacchi.
Quale di questi implementa effettivamente dipenderà dall'analisi costi / benefici e di rischio:
- Quanto vale il dato (o il cliente)?
- Qual è la probabilità di una violazione?
- Quanto costa la misura di sicurezza?
- Quanto riduce la probabilità di una violazione?