L’obiettivo principale nello sviluppo di un sistema completo è rappresentato certamente dai requisiti di sicurezza. Una volta che un requisito è stato sviluppato, e quindi ha passato le sotto fasi di elicitazione, analisi, specifica e validazione, può accadere che possa cambiare perché magari qualcosa nel contesto di business, tecnologico, risorse umane ecc. è variato.
I cambiamenti ai requisiti sono inevitabili durante il ciclo di vita di un’architettura (software, di sicurezza, di dati, di rete ecc.) e così è necessario fare uso di un processo di Change Management.
Le modifiche proposte devono essere opportunamente vagliate, approvate e quindi implementate. È importante studiarne l’impatto, misurare il rischio introdotto dalle modifiche richieste e fare un’opportuna analisi costi-benefici.
Tutto ciò deve essere, ovviamente, opportunamente documentato.
Gestione dei requisiti: ecco come documentare le modifiche
Una Change Request (CR) o anche Request for Change (RFC) è un documento di dettaglio in cui si richiede una modifica alle specifiche.
La RFC viene, generalmente, presentata con alcuni attributi, come la priorità e un tipo o categoria, ad es. richiesta di modifica software, hardware, architetturale e così via.
La RFC, corredata di un’analisi di impatto sul sistema e di uno studio di fattibilità, viene sottoposta a un Change Manager, che la discute di concerto con la Change Advisory Board, per l’approvazione.
La modifica, a questo punto, se approvata, deve essere schedulata per la messa in opera.
Dopo ciò, il sistema, ormai dotato del cambiamento richiesto, deve essere monitorato per verificare un eventuale impatto negativo nell’ambiente in esercizio con un conseguente rollback della modifica effettuata.
Tra le funzionalità previste dal sistema di change management ci dovrebbero essere:
- possibilità di gestire/modificare la priorità della RFC
- possibilità di modificare il tipo della RFC
- possibilità di gestire nell’applicativo varie tipologie di utenti
- realizzazione di workflow di approvazione ad hoc
- possibilità di allegare alla RFC la documentazione a corredo
- gestire lo storico dei cambiamenti
Change Management: chi partecipa alla modifica dei requisiti di sicurezza
Le figure coinvolte nel processo di change management sono:
- il Change Initiator, colui che inserisce la RFC
- il Change Manager, che gestisce le attività di change management e riunisce e prepara il lavoro per la CAB
- il Change Advisory Board (CAB), che è un gruppo di persone coinvolte nell’ambito IT operations e che valuta, approva e rifiuta una RFC
- il Change Owner, è nominato dal Change Manager ed ha la responsabilità operativa del cambiamento
Il processo di Change Management
I software da utilizzare per la gestione dei requisiti di sicurezza
Passiamo ora a vedere gli strumenti software per la gestione dei requisiti. Ne esistono molti, sia commerciali che open source. Liste sufficientemente complete possono essere trovate qui e qui.
Più che fare una review, quello che ci interessa di più, in questa sede, è vederne le caratteristiche salienti.
Un Requirements Management System (RMS) ha come scopo quello di fornire un framework strutturato ad hoc per la gestione dei requisiti. In particolare, deve includere il versioning, la tracciabilità (in forward mode e backward mode), il change management, workflow di approvazione, la modellazione di use case a supporto dei requisiti, la collaboration tra gli stakeholder e la possibilità di aggiungere a corredo documentazione e note varie.
Come abbiamo detto in precedenza, i requisiti si esprimono in forma gerarchica:
- Stakeholder requirement: un requisito che esprime gli obiettivi di uno specifico stakeholder per il sistema da realizzare e i principi e i vincoli che saranno alla base del disegno architetturale
- System requirement: un requisito che esprime funzionalità, caratteristiche o qualità che il sistema deve esibire per soddisfare gli stakeholder requirements
- Sub-system requirement: un requisito che esprime funzionalità, caratteristiche o qualità che il sottosistema deve esibire per soddisfare i system requirements
- Design requirement: un requisito che esprime come il prodotto e/o il processo di installazione, sviluppo, costruzione o testing deve essere progettato, dati i vincoli, per soddisfare i Sub-system requirements
- Specifiche: documento che specifica i requisiti sul prodotto e/o il processo di installazione, sviluppo, costruzione o testing
Forma gerarchica dei requisiti
Visto che la qualità è misurata come l’aderenza ai requisiti, un RMS deve essere fortemente integrato con il sistema di gestione della qualità e, in particolare, con il testing e con il sistema di bug tracking che misura il discostamento dai requisiti. Va osservato che, quando si parla di sicurezza, i requisiti non sono sempre espressi in forma affermativa, del tipo cioè “il sistema deve…”, ma ve n’è uno che si esprime in forma sicuramente negativa e cioè” il sistema non deve esporre funzionalità indesiderate”. Un attacco che sfrutta una backdoor o la SQL Injection o l’escalation di privilegi, tanto per fare alcuni esempi, sicuramente sfrutta un aspetto del sistema che, nella maggior parte dei casi, lo sviluppatore non aveva previsto e certamente non voleva.
Il compito di un architetto è quello di immaginarsi come far funzionare un sistema. Il suo lavoro si concentra, quindi, sulle funzionalità che il sistema deve esporre ai suoi utilizzatori.
Il compito di un architetto della sicurezza, invece, è quello di capire come non far funzionare un sistema, cioè scoprire tutte quelle modalità attraverso le quali è possibile ottenere un comportamento non voluto, che può andare dalla rilevazione di un malfunzionamento alla scoperta di una funzionalità nascosta, come una backdoor, a una funzionalità legittima che viene usata in modo illegittimo, come una form web che viene utilizzata per condurre un attacco di SQL Injection.
Il processo di testing ha lo scopo di ridurre il rischio che un sistema funzioni in modo diverso rispetto alle sue specifiche ad un livello considerato accettabile.
