nis2-agile/application/cli/_docs_cons/c11.html

<!--META|doc_type=procedura_operativa_sviluppo|title=Procedura di Gestione Operativa e Sviluppo Sicuro|status=approved|version=2.0-->

<h2>1. Scopo</h2>
<p>La presente procedura stabilisce come <strong>Nuova Agile Technology srl</strong> integra la sicurezza nel ciclo di vita dello sviluppo software (Secure SDLC), governa i cambiamenti ai propri sistemi, gestisce le vulnerabilità tecniche e le patch, e presidia logging e monitoraggio. L'obiettivo è garantire che i prodotti — sia in <strong>licenza d'uso installati sui server dei clienti (on-premise)</strong>, sia il <strong>SaaS multi-tenant in cloud</strong> — siano progettati, sviluppati, rilasciati e mantenuti in modo da ridurre vulnerabilità e proteggere i dati, e che ogni cambiamento avvenga in modo controllato e tracciabile. Soddisfa i requisiti di sicurezza nell'acquisizione, sviluppo e manutenzione previsti dall'<strong>art. 24 del D.Lgs. 138/2024</strong> (NIS2).</p>

<h2>2. Ambito</h2>
<p>Si applica a tutte le attività di analisi, progettazione, codifica, test, rilascio e manutenzione del software, e ai relativi cambiamenti, vulnerabilità, patch e log su: ambienti <strong>cloud</strong> (Aruba IT, Hetzner DE), configurazioni di rete e di sicurezza, servizi <strong>SaaS</strong> multi-tenant e prodotti <strong>on-premise</strong> presso i clienti, dipendenze e librerie di terze parti, pipeline di build/deploy, integrazioni con <strong>piattaforme AI</strong> via API (es. LLM Anthropic) ed <strong>endpoint</strong> (PC portatili cifrati). Riguarda tutto il personale tecnico (9 dipendenti, 2 collaboratori esterni a P.IVA) ed eventuali fornitori che contribuiscono allo sviluppo. L'attività si svolge esclusivamente da PC portatili cifrati, senza alcun server in sede.</p>

<h2>3. Riferimenti</h2>
<ul>
<li>ISO/IEC 27001:2022 – Annex A: A.5.7 (threat intelligence), A.8.7 (protezione dai malware), A.8.8 (gestione delle vulnerabilità tecniche), A.8.9 (gestione della configurazione), A.8.15 (logging), A.8.16 (monitoraggio), A.8.25–A.8.33 (sviluppo sicuro, requisiti applicazioni, architettura e codifica sicura, test, sviluppo esterno, separazione ambienti, gestione cambiamenti, dati di test), A.5.17 (autenticazione).</li>
<li>ISO/IEC 27017:2015 e ISO/IEC 27018:2019 – sicurezza dello sviluppo, dei cambiamenti e delle vulnerabilità nei servizi cloud e protezione dei PII (privacy by design).</li>
<li>D.Lgs. 4 settembre 2024, n. 138 (NIS2): art. 24 (sicurezza nell'acquisizione/sviluppo/manutenzione, gestione delle modifiche e divulgazione delle vulnerabilità) e art. 25 (notifica incidenti significativi).</li>
<li>Regolamento (UE) 2016/679 (GDPR), artt. 25 e 32 (privacy by design e by default, sicurezza del trattamento).</li>
<li>Procedura di Gestione degli Incidenti dell'Azienda.</li>
</ul>

<h2>4. Ruoli e responsabilità</h2>
<table>
<tr><th>Ruolo</th><th>Responsabilità</th></tr>
<tr><td>Presidente / Direzione (Silvia Garretto)</td><td>Approva la procedura e assegna le risorse; autorizza i cambiamenti ad alto impatto e le finestre di rilascio critiche; approva tempistiche di rimedio e deroghe motivate.</td></tr>
<tr><td>RSGSI (Massimo Tagliavini)</td><td>Mantiene la procedura, verifica che i cambiamenti e le vulnerabilità rilevanti siano valutati nel rischio e documentati, controlla il rispetto dei tempi di rimedio e registra le non conformità.</td></tr>
<tr><td>Resp. IT/Sicurezza (Simon Fattori)</td><td>Definisce gli standard tecnici; gestisce code review, analisi e prioritizzazione delle vulnerabilità, patch e test; valuta e attua i cambiamenti con il piano di rollback; esegue la revisione di log e accessi.</td></tr>
<tr><td>Sviluppatori (dipendenti e collaboratori)</td><td>Applicano le regole di codifica sicura, eseguono test e gestiscono le segnalazioni di vulnerabilità.</td></tr>
<tr><td>Richiedente del cambiamento</td><td>Apre la richiesta di cambiamento (RFC) descrivendo finalità e impatto atteso.</td></tr>
<tr><td>DPO (consulente esterno)</td><td>Valida i requisiti di privacy by design quando si trattano dati personali.</td></tr>
</table>

<h2>5. Sviluppo sicuro (Secure SDLC)</h2>
<h3>5.1 Requisiti e progettazione sicura</h3>
<ul>
<li>I requisiti di sicurezza e privacy sono definiti già in fase di analisi, considerando il modello di minaccia, la separazione tra tenant nel SaaS e l'isolamento delle istanze on-premise.</li>
<li>Si applicano i principi di <strong>privacy by design e by default</strong> (GDPR artt. 25 e 32) e di minimizzazione dei dati.</li>
</ul>
<h3>5.2 Codifica sicura e dipendenze</h3>
<ul>
<li>Si seguono regole di secure coding per prevenire le vulnerabilità più comuni (injection, autenticazione/sessione, controllo accessi, gestione errori, esposizione di dati).</li>
<li>I segreti (credenziali, chiavi API, incluse quelle dei servizi AI) non sono mai inseriti nel codice né nei repository: si usano meccanismi di gestione segreti dedicati. Gli ambienti di sviluppo risiedono su PC portatili cifrati con accesso autenticato.</li>
<li>Le librerie e i componenti open source sono censiti e tenuti aggiornati; si monitorano gli avvisi di vulnerabilità note e si applicano le patch in tempi proporzionati al rischio.</li>
</ul>
<h3>5.3 Test di sicurezza e separazione degli ambienti</h3>
<ul>
<li>Sono previsti test funzionali e di sicurezza prima del rilascio; per le componenti più esposte si eseguono verifiche statiche/dinamiche e, ove opportuno, test di penetrazione. Gli ambienti di test usano dati anonimizzati o sintetici (mai PII reali dei clienti).</li>
<li>Ambienti di sviluppo, test e produzione sono separati (A.8.31); il codice è versionato e le modifiche sono sottoposte a code review tra pari prima dell'integrazione.</li>
</ul>
<h3>5.4 Componenti di intelligenza artificiale</h3>
<p>L'uso di API LLM esterne è valutato per i rischi su confidenzialità dei dati inviati e affidabilità degli output; i dati personali e riservati inviati ai servizi AI sono minimizzati e protetti coerentemente con i contratti e i DPA dei fornitori.</p>

<h2>6. Gestione dei cambiamenti</h2>
<ol>
<li><strong>Richiesta (RFC).</strong> Il richiedente apre una richiesta di cambiamento descrivendo obiettivo, sistemi coinvolti, impatto atteso e urgenza.</li>
<li><strong>Valutazione di impatto e rischio.</strong> Simon Fattori classifica il cambiamento (standard a basso rischio / normale / emergenza) e ne valuta gli effetti su sicurezza, dati personali e continuità; i cambiamenti rilevanti sono registrati nel <strong>modulo "Rischi"</strong> ove pertinente.</li>
<li><strong>Autorizzazione.</strong> I cambiamenti standard a basso rischio sono approvati da Simon Fattori; quelli normali ad alto impatto richiedono l'autorizzazione della Direzione. Va sempre definito un <strong>piano di rollback</strong>.</li>
<li><strong>Test in ambiente separato.</strong> Le modifiche software sono validate in ambienti di sviluppo/test separati dall'esercizio (A.8.31), con test funzionali e di sicurezza (A.8.29) prima del rilascio.</li>
<li><strong>Attuazione.</strong> Il cambiamento è applicato in una finestra concordata; per il SaaS si privilegiano rilasci controllati. Per i prodotti on-premise, l'azienda fornisce ai clienti note di rilascio e indicazioni di aggiornamento, nel rispetto degli obblighi contrattuali di supply chain.</li>
<li><strong>Verifica post-cambiamento.</strong> Si verifica il corretto funzionamento e l'assenza di effetti collaterali; in caso di esito negativo si attiva il rollback.</li>
<li><strong>Chiusura.</strong> Esito e documentazione sono registrati; eventuali anomalie alimentano <strong>non conformità</strong> e azioni correttive.</li>
</ol>
<h3>6.1 Cambiamenti di emergenza</h3>
<p>Per cambiamenti urgenti (es. mitigazione di una vulnerabilità critica), l'attuazione può precedere l'autorizzazione formale, ma <strong>deve essere documentata a posteriori entro il giorno lavorativo successivo</strong> e ratificata dalla Direzione.</p>

<h2>7. Gestione delle vulnerabilità e delle patch</h2>
<h3>7.1 Identificazione</h3>
<ul>
<li>Simon Fattori monitora con continuità le fonti di vulnerabilità: bollettini dei fornitori cloud, avvisi CSIRT/ACN, advisory delle librerie/dipendenze usate dai prodotti, scansioni periodiche e avvisi automatici delle piattaforme (A.5.7, A.8.16).</li>
<li>Si mantiene un inventario aggiornato dei componenti software e delle dipendenze per correlare rapidamente le vulnerabilità ai sistemi interessati.</li>
</ul>
<h3>7.2 Valutazione, prioritizzazione e tempi di rimedio</h3>
<ul>
<li>Ogni vulnerabilità è valutata per <strong>gravità</strong> (es. punteggio CVSS), <strong>esposizione</strong> e <strong>impatto</strong> su dati e servizi, e registrata se rilevante nel <strong>modulo "Rischi"</strong>.</li>
<li>Si assegna una priorità con relativi <strong>tempi target di rimedio</strong>, ad esempio: critiche <strong>entro 48–72 ore</strong>, alte <strong>entro 7 giorni</strong>, medie <strong>entro 30 giorni</strong>, basse alla successiva finestra pianificata. <em>[I valori esatti sono da confermare nel piano di trattamento del rischio e negli SLA interni.]</em></li>
</ul>
<h3>7.3 Rimedio (applicazione delle patch)</h3>
<ul>
<li>L'applicazione delle patch segue la gestione dei cambiamenti (test in ambiente separato e piano di rollback); per le vulnerabilità critiche si attiva il percorso di cambiamento di emergenza. Dove la patch non è immediatamente disponibile si adottano <strong>misure compensative</strong> (restrizione accessi, isolamento, disattivazione della funzione vulnerabile).</li>
<li>Aggiornamenti automatici abilitati su sistema operativo (Windows Update, aggiornamenti macOS, gestore pacchetti Linux) e browser dei portatili; applicazioni (editor, strumenti di sviluppo, client VPN, antimalware, estensioni browser) tenute aggiornate; software non supportato rimosso o sostituito; riavvio del portatile almeno settimanale e quando richiesto.</li>
<li>Per i prodotti SaaS e on-premise si monitorano le dipendenze (librerie, container, runtime), si aggiornano le immagini e si ricostruiscono gli artefatti; sui servizi cloud (Aruba, Hetzner) si applicano gli aggiornamenti delle console e dei servizi gestiti annotando le finestre di manutenzione.</li>
<li>Per i prodotti on-premise, l'azienda rilascia la patch e <strong>informa tempestivamente i clienti impattati</strong> con le istruzioni di aggiornamento (obblighi contrattuali di supply chain), verificandola in ambiente di prova prima del rilascio per evitare regressioni.</li>
</ul>
<h3>7.4 Verifica, chiusura e registrazione</h3>
<ul>
<li>Si verifica l'effettiva risoluzione (riscansione/test) e si chiude la vulnerabilità; gli scostamenti dai tempi target sono registrati come <strong>non conformità</strong> con azione correttiva.</li>
<li>Patch, date e versioni sono tracciate nel registro aggiornamenti/asset; nessuna vulnerabilità critica nota resta non gestita oltre lo SLA interno.</li>
<li>Se una vulnerabilità è stata sfruttata, si attiva la Procedura di Gestione degli Incidenti. In caso di dubbio su un aggiornamento fallito o su una vulnerabilità segnalata si contatta il Resp. IT/Sicurezza Simon Fattori, senza disinstallare patch di sicurezza per "far funzionare" un'applicazione.</li>
</ul>

<h2>8. Logging e monitoraggio</h2>
<p>In assenza di server in sede, i log dei servizi cloud sono la principale fonte di visibilità. Il logging è attivo su tutti i servizi critici (posta, console Aruba/Hetzner, repository, piattaforme AI, password manager, prodotti SaaS), con orari di riferimento coerenti (Europe/Rome o UTC documentato) per correlare gli eventi.</p>
<ol>
<li><strong>Verifica giornaliera rapida.</strong> Controllo degli avvisi di sicurezza automatici dei fornitori (nuovi accessi, login da nuovi dispositivi/paesi, blocchi MFA); ogni avviso è da valutare, non da ignorare.</li>
<li><strong>Revisione settimanale degli accessi.</strong> Esame dei log di autenticazione dei servizi critici cercando login falliti ripetuti, accessi da località/orari inusuali, accessi notturni non giustificati, sessioni o dispositivi non riconosciuti.</li>
<li><strong>Controllo dei cambiamenti privilegiati.</strong> Verifica di modifiche a ruoli/permessi, creazione di account, generazione/rotazione di chiavi API e token; ogni cambiamento deve essere riconducibile a una richiesta legittima.</li>
<li><strong>Log dei prodotti SaaS.</strong> Controllo degli audit log applicativi per accessi anomali ai dati dei clienti ed errori ricorrenti.</li>
<li><strong>Correlazione degli eventi.</strong> A fronte di un'anomalia si ricostruisce la sequenza tra servizi diversi usando orari allineati, per distinguere un evento singolo da una catena.</li>
<li><strong>Conservazione e protezione dei log.</strong> I registri non sono modificabili dagli utenti finali e sono conservati per un periodo adeguato secondo le impostazioni dei fornitori <em>[da verificare rispetto alla policy di retention interna]</em>.</li>
<li><strong>Documentazione della revisione.</strong> Si annotano data, servizi controllati, anomalie rilevate ed esito (chiusa come falso positivo o escalata a incidente) nel registro delle revisioni.</li>
</ol>
<p>In presenza di accesso non autorizzato confermato o sospetto, chiave compromessa o attività anomale sui dati dei clienti, si avvia la Procedura di Gestione degli Incidenti (referente: Simon Fattori); per incidenti che possono ricadere sotto NIS2 si rispettano i tempi di notifica al CSIRT Italia (pre-allarme 24h, notifica 72h, relazione finale 1 mese).</p>

<h2>9. Controlli ISO collegati e riferimenti NIS2</h2>
<ul>
<li><strong>A.8.25</strong> – Ciclo di vita di sviluppo sicuro; <strong>A.8.26</strong> – requisiti di sicurezza delle applicazioni; <strong>A.8.27 / A.8.28</strong> – architettura e codifica sicura; <strong>A.8.29</strong> – test di sicurezza in sviluppo e accettazione; <strong>A.8.30</strong> – sviluppo affidato all'esterno; <strong>A.8.31</strong> – separazione ambienti; <strong>A.8.32 / A.8.33</strong> – gestione dei cambiamenti e dati di test.</li>
<li><strong>A.8.8</strong> – gestione delle vulnerabilità tecniche; <strong>A.8.7</strong> – protezione dai malware; <strong>A.8.9</strong> – gestione della configurazione; <strong>A.5.7</strong> – threat intelligence; <strong>A.8.16</strong> – monitoraggio; <strong>A.8.1</strong> – endpoint.</li>
<li><strong>A.8.15</strong> – logging; <strong>A.5.17</strong> – informazioni di autenticazione.</li>
<li>Controlli cloud di ISO/IEC 27017 e ISO/IEC 27018 per gli aspetti cloud e PII.</li>
<li><strong>NIS2 – D.Lgs. 138/2024, art. 24</strong>: sicurezza nell'acquisizione, sviluppo e manutenzione dei sistemi, gestione delle modifiche e delle vulnerabilità. Una vulnerabilità sfruttata o un cambiamento fallito che causino un incidente significativo attivano gli obblighi di notifica dell'<strong>art. 25</strong> (early warning 24 ore, notifica completa 72 ore, relazione finale 1 mese).</li>
</ul>

<h2>10. Registrazioni ed evidenze</h2>
<ul>
<li>Requisiti di sicurezza documentati per progetto/prodotto; registri delle code review e dei test di sicurezza; inventario delle dipendenze.</li>
<li>Richieste di cambiamento (RFC) e autorizzazioni; esiti di test e rilasci; note di rilascio per i clienti on-premise; documentazione dei cambiamenti di emergenza e relativa ratifica.</li>
<li>Registro delle vulnerabilità con gravità, priorità e tempi di rimedio; report delle scansioni e degli aggiornamenti applicati; registro aggiornamenti/asset; comunicazioni di patch ai clienti on-premise.</li>
<li>Registro delle revisioni dei log/accessi con anomalie ed esiti; non conformità e azioni correttive per cambiamenti falliti o ritardi di rimedio.</li>
</ul>

<h2>11. Riesame e versionamento</h2>
<p>La procedura è riesaminata almeno annualmente o a fronte di cambiamenti tecnologici significativi, nuove minacce, modifiche del processo di rilascio o degli strumenti di scansione, cambiamenti del parco software o requisiti contrattuali dei clienti. Versione corrente: <strong>2.0</strong>, approvata dalla Presidente. Le revisioni sono tracciate nel sistema documentale del SGSI a cura del RSGSI.</p>