Mi hanno chiesto un «audit di sicurezza delle informazioni» — cos'è? È davvero indispensabile?

La società che farà l'audit vi chiederà l'accesso al repository del codice, i log dei server e la topologia di rete. Nel codice controlleranno come vengono cifrati i dati sensibili, sui server guarderanno dove sono salvate le chiavi SSH e le password di connessione ai database. Se preparate queste cose in anticipo il processo sarà molto più veloce.

Non firmare subito con una società di audit costosissima. Chiedi direttamente al direttore IT del cliente: «Basta un normale report di penetration test con relativo piano di correzione?». Nella maggior parte dei casi non cercano una certificazione aziendale a 360 gradi, vogliono solo la prova che il sistema non sia bucabile.

L'anno scorso abbiamo speso 400.000 RUB per farlo. L'auditor ha trovato 9 vulnerabilità, di cui 2 critiche. Ci abbiamo messo 10 giorni a chiuderle e poi abbiamo ottenuto il report pulito. Grazie a quel documento il cliente ha firmato un triennale in un solo giorno, soldi recuperati alla grandissima.

Ci sono ditte sul mercato che per 150 mila rubli lanciano due tool automatici e ti stampano un PDF. Non cascarci: gli esperti di sicurezza della grande catena se ne accorgeranno subito che è fuffa e ci perdi tutta la credibilità.

Le grandi aziende rischiano sanzioni legali e finanziarie pesanti se si verificano violazioni di dati lungo la supply chain. Per questo motivo richiedere un audit fa parte della normale prassi di procurement nell'ambito della gestione del rischio di terze parti.

Il team di auditor che verrà vi chiederà 3 punti fondamentali: 1) I risultati dei penetration test sui server, 2) I log di accesso dei dipendenti ai dati aziendali e l'obbligo dell'autenticazione a due fattori, 3) Il piano di disaster recovery che mostri con quale frequenza e dove vengono effettuati i backup dei dati.

Per un lavoro da 14 milioni, un costo di audit di 400 mila ne vale assolutamente la pena; non è un ostacolo, è il biglietto d'ingresso per la serie A del mondo enterprise.

Ho lavorato a lungo su questo. Se ricevete tre risposte diverse su un argomento, la domanda è posta male.

Se scrivete qui il risultato, sarà utile anche ad altri.

La risposta sopra ha colto l'essenza della questione. Quando decidiamo senza misurare, finiamo sempre nello stesso punto.

Lascio una nota, potrebbe servire.

Avrei una domanda, non vorrei deviare dall'argomento, ma... Se rimproverate i falsi allarmi, nessuno segnalerà più nulla.

Se scrivete qui il risultato, sarà utile anche ad altri.

Hai fatto bene ad aprire questo thread. Se è la prima volta inizia in piccolo, il ridimensionamento viene dopo.

La risposta varia molto in base al settore, non esiste una regola generale. Se scrivete qui il risultato, sarà utile anche ad altri.

Sono d'accordo. Se permessi e ambito non sono scritti, quel test non deve iniziare.

È tutto, scusate se mi sono dilungato.

Sono della stessa opinione. Un report di scansione automatica e un penetration test non sono la stessa cosa.

Se scrivete qui il risultato sarà utile anche ad altri.

Sono della stessa opinione. Se è la prima volta, inizia in piccolo, il ridimensionamento viene dopo.

Se scrivete qui il risultato, sarà utile anche ad altri.

Sono della stessa opinione. Se la verifica in due passaggi è attiva, una password rubata da sola non serve a nulla.

Un report di scansione automatica e un penetration test non sono la stessa cosa. È tutto, scusate se mi sono dilungato.

A me è successo l'esatto contrario, per questo scrivo. La maggior parte degli incidenti non inizia da una vulnerabilità, ma da una password trapelata.

Sono curioso di sapere se qualcuno lo fa in modo diverso.

Esattamente così. Se cerchi di cambiare tutto insieme, niente si stabilizza.

Buon lavoro.

sono della stessa opinione.. poi comunque le soluzioni che funzionano su piccola scala crollano quadno si cresce, l'ho imparato tardi.