Analizzare e risolvere i conflitti nello sviluppo software: le metodologie da seguire

I requisiti di sicurezza nello sviluppo di un sistema sicuro rappresentano, ovviamente, il nostro obiettivo principale, il traguardo da raggiungere. Una volta identificati, dovremo quindi definirli e risolvere gli immancabili conflitti tra un requisito e l’altro usando particolari metodologie di sviluppo.

Per quanto riguarda il processo di elicitazione (identificazione, analisi e risoluzione dei conflitti) dei requisiti descriveremo, adesso, la metodologia SQUARE.

SQUARE (Security Quality Requirements Engineering) è stata creata a fine 2005 dal CERT (Computer Emergency Response Team) americano, allo scopo di introdurre la sicurezza sin dalle prime fasi del processo di sviluppo del software.

Le attività sono condotte da un gruppo di Ingegneri dei Requisiti, con competenze di sicurezza, insieme agli stakeholder di progetto.

Metodologia SQUARE: definiamo la lista dei requisiti di sicurezza minimi

Tale metodologia è basata su 9 step che hanno come obiettivo finale la generazione di una lista di requisiti, suddivisi per categorie e priorità:

1. Accordo sulle definizioni: il primo passo, ovviamente, consiste nello stabilire un vocabolario di termini comuni tra i partecipanti all’attività. Tale vocabolario può essere estratto da standard, normative, terminologie di settore ecc.;
2. Identificazione degli obiettivi di sicurezza: si parte dall’analisi delle esigenze di business, delle policy, delle procedure e delle normative per arrivare a stabilire quali sono i bisogni di sicurezza dell’organizzazione;
3. Sviluppo di documentazione appropriata a supporto della definizione dei requisiti di sicurezza: in questa fase, il team produce tutti quei documenti, diagrammi di rete, attack tree, diagrammi di flusso, Use/Misure Case ecc., che possono essere utili per chiarire meglio i concetti esposti e per fornire il livello di dettaglio sufficiente al lavoro di analisi;
4. Risk assessment: si utilizzano metodologie di analisi del Rischio, come ad esempio Octave, per identificare le minacce, disegnare degli scenari di utilizzo, e stabilire il livello di esposizione ai pericoli;
5. Selezione delle tecniche di elicitazione: si tratta di decidere quali metodologie di analisi dei requisiti possano essere più appropriate per l’organizzazione, come ad esempio forum, interviste, workshops ecc.;
6. Elicitare i requisiti di sicurezza: è importante che i requisiti in questa fase vengano espressi in modo che siano verificabili e tracciabili. Per fare questo, si può utilizzare uno strumento apposito che è la Matrice di Tracciabilità (Traceability Matrix), che collega tra loro le varie tipologie di requisiti. Il fatto, ad esempio, che un utente non debba aspettare una pagina web per più di due secondi può tradursi in un certo numero di altri requisiti di natura tecnica, come il fatto che il server debba avere certe capacità di processamento (RAM e CPU) o che il linguaggio utilizzato per renderizzare le pagine abbia certe caratteristiche (ad esempio pagine statiche piuttosto che dinamiche). La matrice di tracciabilità deve permettere di ricavare le informazioni sia in forward-mode cioè progredendo in avanti lungo il ciclo di sviluppo, dai requisiti ai prodotti, e sia in backward-mode, dai prodotti ai requisiti;
7. Categorizzazione dei requisiti: occorre capire se i requisiti estratti sono requisiti applicativi, tecnologici, di sistema, utente ecc. Deve anche essere stabilita un eventuale gerarchia o dipendenza tra i requisiti (ad es. tra i requisiti utente e i requisiti di sistema);
8. Dare una priorità ai requisiti: ogni requisito deve ricevere una priorità. Un metodo che si può utilizzare è ad esempio MoSCoW che è l’acronimo per: M – MUST è un requisito che deve necessariamente essere tenuto di conto affinché il progetto abbia successo. In linea di massima, si può considerare che consumi il 60% dell’effort; S – SHOULD sono requisiti importanti e che dovrebbero essere rispettati dalla soluzione finale, benché non vadano a impattare il successo o meno del progetto. In linea di massima, si può considerare che consumino il 20% dell’effort; C – COULD sono requisiti che sarebbe interessante o auspicabile venissero rispettati nei deliveries di progetto. In linea di massima, si può considerare che consumino il 20% dell’effort; W – WOUN’T sono requisiti a bassa priorità che possono essere rinviati ad una fase di progetto successiva
9. Ispezionare i requisiti: l’obiettivo di questa fase è quello di mettere in evidenza la presenza di inconsistenze, ambiguità o conflitti tra i requisiti. Quest’ultimo punto è importante perché potrebbe capitare che ci siano requisiti discordanti per i vari stakeholders (ad. es. necessità di autenticare gli utenti per uno e l’anonimità per un altro). A tale scopo si può utilizzare il metodo ATAM per la gestione dei conflitti, che vedremo tra poco.

La metodologia SQUARE

Tra gli strumenti comunemente utilizzati nell’analisi dei requisiti, ci sono gli Use Case Diagrams che rappresentano le modalità di interazione dell’utente con il sistema e i Misuse Case Diagrams. Questi ultimi sono specifici dell’analisi di sicurezza. Il concetto è semplice: se un diagramma UML può descrivere un’interazione legittima dell’utente con il sistema, perché non utilizzarli anche per descrivere un’interazione problematica per la sicurezza?

A questo scopo sono stati introdotti degli opportuni simboli grafici, corrispondenti a un profilo UML opportunamente definito. Un utile tool per disegnare i diagrammi è liberamente scaricabile qui.

Un esempio di analisi SWOT (Strength, Weakness, Opportunity e Threat)

Il metodo ATAM per la risoluzione dei conflitti tra requisiti di sicurezza

Il metodo ATAM (Architecture Tradeoff Analysis Method) è nato nel 1998 a opera del SEI (Software Engineering Institute).

Lo scopo del metodo è quello di risolvere i conflitti tra i requisiti, determinando l’impatto che un cambiamento sugli attributi di qualità (ad esempio performances, sicurezza, usabilità, modificabilità ecc.) ha sull’architettura.

È, di fatto, un metodo strutturato per arrivare a dei compromessi sui requisiti, qualora essi siano in discordanza gli uni con gli altri. Un esempio è quello di un requisito di sicurezza della soluzione architetturale che potrebbe contrastare con un requisito di performance o uno di usabilità, come il fatto che, dover fornire i propri dati personali su un sito web potrebbe portare all’abbandono da parte dell’utente.

Lo scopo di un’architettura (software, di rete, di processo, dei dati ecc.) è sostanzialmente quello di accertarsi che la soluzione disegnata soddisfi gli attributi, determinati dai requisiti.

In realtà, d’altronde, gli attributi non sono isolati tra di loro, ma interagiscono. Un aumento di performance potrebbe portare, ad esempio, alla necessità di rilassare i requisiti di sicurezza o i requisiti sui costi.

È necessario, quindi, sapere gestire i compromessi tra gli attributi, facilitando l’armonizzazione dei vari punti di vista, dovuti ai differenti stakeholder.

Ciascun attributo di qualità è interdipendente dagli altri. Tale situazione si verifica attraverso opportuni punti di interconnessione chiamati elementi.

Un elemento è un componente, una proprietà di un componente o della relazione tra più componenti che può determinare modifiche di un attributo.

Un esempio di elemento potrebbe essere il numero di server in load balancing che aumentano le performance complessive ma diminuiscono la sicurezza, in quanto aumentano le probabilità di attacco o di malfunzionamento di uno dei server.

Un altro esempio potrebbe essere la frequenza di heartbeat tra i componenti di un cluster che, se troppo bassa, può portare a un miglioramento di performance in quanto comunque la gestione dell’heartbeat consuma risorse sulla macchina, ma può portare a un deterioramento dei dati, in quanto un malfunzionamento di uno dei server del cluster potrebbe essere avvertito più tardi dal sistema nel suo complesso.

ATAM aiuta a identificare le dipendenze tra gli attributi che costituiscono i cosiddetti Tradeoff Points (Punti di Compromesso).

Il metodo segue un modello di disegno a spirale.

Ogni iterazione porta a una migliore comprensione del sistema, a un rischio ridotto e a una gestione dei requisiti più efficace.

Il metodo è diviso in quattro fasi e in sei steps:

FASE I: Raccolta dei requisiti e individuazione degli scenari d’uso

     – Step 1   Raccolta degli scenari d’uso

     – Step 2   Raccolta dei requisiti e dei vincoli e identificazione dell’ambiente in cui opererà il sistema

FASE II: Identificazione e disegno delle varie viste architetturali e realizzazione degli scenari

     – Step 3   descrizione dei modelli architetturali candidati che potrebbero soddisfare i requisiti

FASE III: Costruzione del modello e analisi degli attributi

     – Step 4   analisi separata dei vari attributi nelle varie architetture candidate (ad esempio analisi delle performance di un particolare modello o della sua resistenza ai guasti)

FASE IV: Individuazione dei compromessi tra gli attributi

     – Step 5   valutazione della sensibilità degli attributi a una particolare modifica architetturale (ad esempio cosa occorre variare nell’architettura corrente per passare da un 99% di disponibilità a un 99.9%).  Ogni parametro nell’architettura che è fortemente correlato con un attributo del sistema viene detto Punto di Sensibilità. Nel caso di una VPN, ad esempio, la lunghezza della chiave usata è un punto di sensibilità, perché da essa dipende l’attributo della riservatezza. Un punto di sensibilità rappresenta un punto di attenzione del sistema quando si cerca di raggiungere un certo obiettivo di qualità.

     – Step 6   identificazione dei Punti di compromesso, come elementi architetturali ai quali più attributi sono sensibili. Un esempio è quello delle performance di un sistema di server in load balancing che aumentano all’aumentare del numero di server, mentre la sicurezza ne è negativamente influenzata.

Una rappresentazione grafica del Metodo ATAM

Nella Fase I, è importante esprimere gli obiettivi di qualità con cui l’architettura sarà confrontata tramite gli scenari.

Uno scenario rappresenta un’interazione di uno stakeholder col sistema: potrebbe trattarsi di un utente che vuole acquistare un prodotto via web o di un amministratore che deve aggiungere un prodotto a catalogo oppure ancora di un redattore che deve inserire una notizia.

In ATAM esistono tre tipi di scenari:

• use case scenarios (scenari d’uso) che rappresentano usi tipici di un sistema esistente
• growth scenarios (scenari di crescita) che rappresentano modifiche anticipate al sistema
• exploratory scenarios (scenari esploratori) che coprono eventi estremi che possono portare stress al sistema, come per esempio la sostituzione di un sistema operativo con un altro su un server, una drastica riduzione di risorse o un improvviso incremento di traffico causato da un Denial of Service

A ogni scenario deve essere attribuita una priorità. Uno strumento che può essere utilizzato è quello degli Utility Trees.

Gli utility trees aiutano a concretizzare e a dare una priorità agli obiettivi di qualità.

Considerando, ad esempio, un sistema software, una utility tree potrebbe essere fatto come in figura.

Seguendo lo standard ISO/IEC 9126 (modello di requisiti qualitativi del software), “Utility”, che rappresenta la “bontà” complessiva del software, è il nodo primario, seguito dalle caratteristiche come nodi secondari e dalle sotto caratteristiche come nodi terziari. Le priorità possono essere espresse come Low, Medium e High. Gli elementi tra parentesi rappresentano due cose: l’importanza del nodo per il successo del sistema e il grado di rischio percepito dal raggiungimento di quell’obiettivo, cioè sostanzialmente quanto è “facile” ottenerlo.

Con questa procedura si arriva così a dare una priorità a tutti gli attributi dei requisiti del sistema. Ogni attributo, come si vede dall’utility tree, viene tradotto in uno scenario (ad esempio crash del disco o utente che richiede una pagina web ecc.)  che può quindi essere contrassegnato da una priorità.

Fatto questo, è possibile confrontare i vari modelli architetturali candidati a fronte dell’analisi del comportamento rispetto ai vari scenari.

Poniamo l’esempio di un utente che richiede una pagina web. Questo scenario potrebbe essere realizzato con un solo server web, oppure con un server web e un application server, oppure con un application server e due server web in load balancing ecc.

Ognuna di queste “soluzioni” contribuirà in modo differente ai vari attributi. Ad esempio, la soluzione con i due web server in load balancing sarà più performante e più resistente al guasto del singolo server rispetto al caso del singolo server web che, d’altronde, sarà meno costoso, più facile da mettere in piedi e meglio gestibile dal sistem manager.

Lo schema di un Utility Tree