Risposta.

Storia della domanda:

I requisiti di sicurezza informatica sono una componente fondamentale dei grandi progetti IT sin dai tempi in cui sono comparsi i primi standard di audit della sicurezza (ad esempio, ISO 27001 o i requisiti della legge Federale 152 in Russia). Senza un'analisi chiara e una formalizzazione dei requisiti, la sicurezza del sistema rischia di essere dichiarativa e non applicabile nella pratica.

Problema:

I requisiti di sicurezza spesso vengono formulati in modo astratto ("tutto deve essere protetto"), non tengono conto dei reali processi aziendali e dell'architettura, e non sono chiariti in livelli: organizzativo, tecnologico e utente. Inoltre, i clienti e gli sviluppatori possono interpretare in modo diverso gli stessi requisiti, creando una discrepanza tra attuabilità e conformità normativa.

Soluzione:

L'analista di sistema inizia studiando gli standard aziendali, governativi e di settore (ad esempio: GOST, GDPR, PCI DSS, ISO 27001). Poi, insieme all'architetto e ai responsabili della sicurezza, identifica i processi aziendali critici, i punti di archiviazione e trasferimento dei dati, le possibili minacce e determina l'elenco dei rischi pertinenti. Sulla base di ciò, l'analista prepara una matrice dettagliata dei requisiti per accesso, archiviazione, registrazione, crittografia e scenari di incidenti. Dopo l'approvazione, formalizza questi requisiti in documenti, in modo che ciascun requisito possa essere verificato attraverso test o audit.

Caratteristiche chiave:

I requisiti di sicurezza vengono formalizzati tenendo conto dell'architettura, dei processi aziendali e delle normative RegTech.
È necessario distinguere le politiche di sicurezza organizzative, tecnologiche e degli utenti.
È obbligatorio collaborare strettamente con i responsabili della sicurezza, gli architetti, i legali e gli ingegneri QA.

Domande trabocchetto.

Perché non ci si può fidare solo dei mezzi tecnici di sicurezza informatica (antivirus, firewall, SIEM)?

Perché la sicurezza informatica è un processo, non solo un insieme di sistemi. Un ruolo fondamentale è svolto dalle procedure organizzative, dal fattore umano, dai controlli regolari e dalla formazione degli utenti.

Si possono considerare i requisiti soddisfatti se il sistema ha superato solo i test interni?

No — spesso per conformità alle normative è necessario un audit esterno, una certificazione e talvolta persino stress test sotto la supervisione del regolatore.

È sufficiente semplicemente includere nella specifica il requisito "il sistema deve essere protetto secondo la legge 152-FZ"?

Non è sufficiente — è necessario specificare misure concrete (controllo degli accessi, archiviazione dei log degli eventi, crittografia dei dati), luoghi di attuazione e criteri di verifica.

Errori tipici e anti-pattern

Formulazione di requisiti vaghi o dichiarativi ("deve essere sicuro")
Separazione del processo di sicurezza dall'analisi architettonica e aziendale (lavorano "in parallelo", non interagiscono)
Sottovalutazione del ruolo dei mezzi tecnici senza considerare le variabili umane e processuali
Mancanza di controlli regolari sulla validità dei requisiti di sicurezza informatica

Esempio dalla vita reale

Casi negativi: In un progetto di internet banking, l'analista ha incluso nella specifica solo la frase generica "devono essere rispettati i requisiti della legge 152-FZ". I contraenti hanno implementato una normale autorizzazione e un certificato SSL, ma durante l'audit esterno è emersa l'assenza di controllo sull'archiviazione dei dati e un log di autenticazione non protetto.

Vantaggi:

Sviluppo rapido

Svantaggi:

Insoddisfazione del regolatore
Rischio di blocco del lancio

Casi positivi:

All'inizio del progetto, l'analista di sistema ha concordato con i responsabili della sicurezza e il cliente un elenco di minacce, ha sviluppato i requisiti dettagliati per la crittografia e l'audit per ciascun scenario, e ha identificato i responsabili. Alla fine, il sistema ha superato l'audit senza osservazioni.