Politica di Risposta agli Incidenti

1. Introduzione

Il presente documento descrive la Politica di Risposta agli Incidenti per l’applicazione DeskCamera. DeskCamera è un’applicazione on-premise per la trasmissione dello schermo, progettata per funzionare all’interno della rete locale del cliente. Non offre servizi cloud, non memorizza né elabora dati degli utenti e non trasmette alcun contenuto live ai server DeskCamera.

2. Scopo

Garantire che DeskCamera adotti un approccio strutturato per identificare, gestire e risolvere gli incidenti di sicurezza che possono influenzare lo sviluppo del software, la distribuzione o l’infrastruttura di supporto.

3. Ambito di applicazione

Riguarda gli incidenti di sicurezza legati al codice sorgente di DeskCamera, al processo di build, alle dipendenze di terze parti, ai sistemi di distribuzione e agli strumenti di sviluppo interni.

4. Tipologie di Incidenti Coperti

  • Accesso non autorizzato ai repository di codice
  • Compromissione di certificati di firma o dell’ambiente di build
  • Vulnerabilità nella supply chain (librerie di terze parti)
  • Errori di configurazione che compromettono l’integrità degli installer distribuiti
  • Vulnerabilità negli strumenti utilizzati durante il ciclo di vita dello sviluppo software (SDLC)

5. Ruoli e Responsabilità

  • CTO – Supervisiona la gestione dell’incidente e approva le azioni critiche
  • Team di Sviluppo – Valuta i dettagli tecnici, corregge il codice e ripristina i sistemi
  • Responsabile della Sicurezza – Coordina le indagini, mantiene i log ed assicura la comunicazione

6. Processo di Gestione degli Incidenti

6.1. Identificazione

  • Monitoraggio automatico delle CVE (Common Vulnerabilities and Exposures) tramite feed di sicurezza
  • Revisione manuale del codice e rilevamento di anomalie durante le operazioni di routine

6.2. Valutazione

  • Classificazione dell’incidente per gravità (Critico, Alto, Medio, Basso)
  • Verifica se il software distribuito è stato interessato

6.3. Contenimento e Mitigazione

  • Revoca immediata delle credenziali compromesse
  • Isolamento degli ambienti o dei pipeline compromessi
  • Rimozione o aggiornamento delle librerie di terze parti vulnerabili

6.4. Ripristino

  • Ripristino dell’ambiente pulito da backup sicuri
  • Nuova firma delle build con chiavi pulite e verificate
  • Nuovi test e convalida dell’integrità degli installer rilasciati

7. Comunicazione

  • Interna: Tutti gli incidenti sono registrati e condivisi con il management
  • Esterna: I clienti vengono informati entro 24 ore solo se l’integrità delle build distribuite o dei meccanismi di aggiornamento risulta compromessa

8. Revisione Post-Incidente

  • Analisi della causa radice entro 5 giorni lavorativi
  • Aggiornamento delle procedure di sicurezza se necessario
  • Il report dell’incidente viene conservato internamente e utilizzato durante la formazione annuale sulla sicurezza

9. Revisione e Test

  • Questa politica viene revisionata annualmente dal CTO
  • Vengono condotti periodicamente test interni (tabletop) di risposta agli incidenti