Le informazioni sensibili sono state inserite in una cartella accessibile al pubblico. Chi è responsabile e come procedere?

Sarei riluttante a parcellizzare la colpa, in particolare quando è chiaramente un errore onesto. Troppa concentrazione sulla colpa di un incidente può avvelenare il pozzo e rendere le persone più riluttanti a segnalare incidenti di sicurezza in futuro. Anche senza alcuna colpa coinvolta, è già abbastanza imbarazzante dover riferire che si è rovinato e che potrebbe aver contribuito a un'esposizione alla sicurezza. Mi piace che tu dica "Sono principalmente interessato a imparare da questa esperienza" - Penso che sia un atteggiamento molto salutare e costruttivo, e ti incoraggio a ripeterlo ampiamente così che tutti gli interessati lo sappiano e agiscano in modo corrispondente. / p>

A proposito, puoi pensare a questa come un'opportunità per modellare come reagisci ai problemi di sicurezza. La cultura viene impostata non dalle parole che dicono i dirigenti della compagnia, ma dal modo in cui agiscono, specialmente dal modo in cui agiscono quando si trovano in un punto difficile. Modellare il "non si tratta di incolpare, si tratta di imparare dall'esperienza" l'atteggiamento sembra un bel modo per dare un contributo a una cultura sana che ti servirà bene in futuro.

Torna alla tua domanda principale. Penso che la risposta principale a questa domanda sia probabilmente: la comunicazione. Il primo passo è per le persone coinvolte per parlare di questo, e concordare su chi sia la responsabilità. È responsabilità dell'amministratore web confermare che tutto il contenuto che viene inserito nel server Web pubblico è destinato a essere pubblico? È la responsabilità della persona che sta postando il contenuto? Come potrebbero queste persone sapere di chi è la responsabilità?

Forse una possibile lezione che potresti prendere in considerazione è: sii prudente su quali filesystem / mount point / directory condivise vengono montate sul tuo server web pubblico. Potresti avere una regola generale che esiste una separazione: ogni file system / directory condivisa è (a) public, o (b) internal, ed etichetta la directory filesystem / shared di conseguenza. Con questo approccio eviterai di avere un filesystem che contiene alcuni file pubblici e alcuni file non pubblici - e quando aggiungi un nuovo file system / directory condivisa al server web pubblico, potresti fare un rapido controllo di integrità per vedere se quello il filesystem è infatti contrassegnato come pubblico. Questa è solo un'idea e, naturalmente, potrebbe essere o non essere adatta a te. Non lasciarti coinvolgere dai dettagli di questa particolare idea; se non sembra utile, ignoralo. Il punto più importante è pensare un po 'ai processi che possono aiutarti a evitare questi errori, senza impantanarti in inutili burocrazie. Saprai meglio quali sono la cultura e le esigenze della tua azienda; dovresti essere in una buona posizione per scambiare idee e iniziare quella conversazione con i tuoi colleghi.

Was I at fault for assuming that either the IT staff or the web developer should have dealt with this?

Di solito, cerchi di mantenere gli affari interni irraggiungibili dal mondo esterno. Tutto ciò che va in produzione deve essere controllato e verificato (almeno dall'amministratore). Bene, quindi ricontrolla.

Who is responsible for making sure that sensitive information is properly secured?

Dipende dalle dimensioni dell'organizzazione e dalla politica interna. Questo potrebbe essere amministratore di sistema, sviluppatore software, responsabile delle informazioni ecc.

Are there steps beyond checking logs that I should take?

Sì! Mai, mai memorizzare le password in testo semplice o crittografate. Le password devono essere sottoposte a hash e salate prima di essere mantenute in un database. Comunicare ai clienti la perdita e fornire mezzi per modificare i propri dati privati. Questo può diventare molto serio se hai clienti reali , parla con un avvocato.

Modifica la configurazione sensibile, se non è stata eseguita prima, quindi crittografane le sezioni private.

Controlla i motori di ricerca per vedere se i tuoi contenuti sono stati incassati.

Are there steps beyond checking logs that I should take?

Anche se sono sicuro che stai chiedendo quali azioni operative specifiche dovrebbero essere fatte per cercare di garantire che il materiale sensibile non sia stato divulgato o modificato, ho intenzione di rispondere a questo a un livello più alto di astrazione.

In casi come questo, mi piace chiedermi Five Whys . Lavorare all'indietro dall'incidente e determinare la causa principale. Sembra che tu abbia fatto qualche progresso, ma non lo hai ancora fatto completamente.

Ad esempio, se si sta eseguendo il back-tracking attraverso l'incidente e si è determinato che il gruppo di sviluppo ha inavvertitamente inserito materiale di sviluppo sensibile in un ambiente di produzione, questo si interrompe nei controlli di sicurezza attorno al sistema di configurazione mgmt.

Installa un nuovo sistema di gestione della configurazione (o modifica il tuo esistente) che assicuri che l'ambiente di produzione non possa essere modificato dal gruppo di sviluppo. È considerata una buona pratica avere un'area di sviluppo e un'area di produzione (come minimo, altri come un test, un'integrazione o un terreno di sosta sono anche possibili ambienti). Gli sviluppatori non hanno accesso alla produzione NOR hanno uno strumento che consente loro di modificare l'ambiente di produzione senza passare attraverso un processo verificabile.

Sembra anche che ci sia un errore nell'auditing che potrebbe essere un problema di sicurezza molto più grande. Potresti voler capire perché (ancora, 5 perché) non sai chi l'ha messo lì. Forse è perché tutti usano l'account di root. Trova un altro modo per ottenere i privilegi di cui hai bisogno (ad esempio sudo).

Oh. E cambia le tue password.

La prima cosa da capire è che anche nel migliore dei casi si verificheranno errori. La buona notizia è che il tuo sviluppatore web ha fatto un buon lavoro nell'individuare il problema e segnalarlo immediatamente.

"Ero in colpa per averlo assunto" - ti ricordi cosa dicono di assumere? ass_u_me ....

La salvaguardia delle risorse aziendali (di tutti i tipi) è una responsabilità della gestione di livello superiore e deve essere verificata dal dipartimento di revisione interno.

"Chi è responsabile dell'accertarsi che le informazioni sensibili siano correttamente protette?" L'amministratore delegato e il consiglio di amministrazione. Questa è una responsabilità che non può essere delegata. Per le società quotate in borsa i giorni in cui un amministratore delegato poteva difendere l'ignoranza si è conclusa con Sarbanes-Oxley.

"Ci sono dei passaggi oltre i log di controllo che dovrei prendere?" Controllare i registri dopo il fatto (qualsiasi cosa dopo il fatto per quella questione) è troppo tardi. Quello che devi fare è sviluppare politiche e procedure per salvaguardare le tue risorse e la verifica della conformità.