Piano di Risposta agli Incidenti

Efficacia: 2 giugno 2026

Questo Piano di Risposta agli Incidenti ("Piano") definisce come STANDOUT Inc. ("noi") rileva gli incidenti di sicurezza, le interruzioni del servizio e le violazioni di dati che interessano il servizio VATES ("Servizio"), risponde a essi, ne recupera e ne trae insegnamenti. Il Piano fa riferimento a NIST SP 800-61 Rev.2 e ISO/IEC 27035, e si basa sul principio di design secondo cui gli strumenti di monitoraggio automatizzati fungono da prima linea di rilevamento.

1. Scopo e ambito

Gli obiettivi di questo Piano sono:

• Rilevare tempestivamente gli eventi che possono influire sulla disponibilità, sulla riservatezza o sull'integrità del Servizio.
• Definire procedure di contenimento e ripristino che minimizzino l'impatto.
• Adempiere agli obblighi di notifica verso i Clienti interessati e le autorità di regolamentazione.
• Consentire il miglioramento continuo della qualità operativa tramite un'analisi post-incidente strutturata.

Questo Piano si applica all'ambiente di produzione del Servizio (EC2, Cloudflare e i fornitori SaaS associati), al percorso di comunicazione dal Servizio verso i fornitori di IA upstream, e a tutto lo storage che contiene dati dei Clienti.

2. Definizione di incidente e classificazione di gravità

2.1 Definizione di incidente

Ai fini di questo Piano, un incidente è qualsiasi evento che corrisponda a uno o più dei seguenti:

• Sospetto di accesso non autorizzato, compromissione di credenziali o intrusione nel sistema.
• Divulgazione, alterazione o perdita non autorizzate di dati dei Clienti, inclusi dati personali.
• Interruzione o degrado significativo delle prestazioni che interessi la funzionalità principale del Servizio.
• Minacce alla sicurezza, incluse infezioni da malware, ransomware o attacchi alla catena di fornitura.
• Errore operativo, configurazione errata o difetto software con impatto su larga scala.

2.2 Classificazione di gravità

Ogni incidente viene classificato al momento del rilevamento in uno dei seguenti livelli di gravità:

• P1 (Critico): Interruzione totale del Servizio, o violazione di dati confermata che interessa dati personali. Richiede risposta immediata.
• P2 (Alto): Deterioramento significativo della funzionalità principale, indisponibilità per Clienti specifici o anomalie di autenticazione. Risposta iniziale richiesta entro un'ora.
• P3 (Medio): Deterioramento funzionale parziale o degrado delle prestazioni con soluzioni alternative disponibili. È accettabile la risposta entro l'orario lavorativo.
• P4 (Basso): Eventi con impatto limitato sugli utenti, deviazione minore dell'integrità dei log o ridondanza ridotta degli strumenti di monitoraggio. Trattati nel successivo ciclo di revisione programmato.

3. Struttura di risposta

3.1 Parte responsabile

La parte responsabile di questo Piano è Takuya Aoki, Managing Director di STANDOUT Inc. e capo dello sviluppo di VATES. Tutta l'autorità decisionale e di notifica esterna durante un incidente è consolidata nella parte responsabile.

3.2 Strumenti di rilevamento automatizzati

Il Servizio opera una postura di monitoraggio continuo interamente automatizzata composta dai seguenti strumenti. Funzionano indipendentemente dalla parte responsabile e attivano una notifica immediata quando le condizioni di soglia sono soddisfatte.

• Cloudflare Health Check: Sonda l'origine di produzione da più punti geografici a intervalli di 60 secondi.
• HetrixTools: Monitora gli endpoint di produzione da più punti globali attraverso un percorso indipendente da Cloudflare.
• Sentry: Cattura le eccezioni dell'applicazione in tempo reale e notifica la parte responsabile.
• Cloudflare WAF (Managed Rules + OWASP Core Ruleset): Blocca i pattern di attacco noti in modalità Block.
• Cloudflare DDoS Protection: Mitiga in modo continuo e automatico gli attacchi DDoS sul livello di rete, sul livello SSL/TLS e sul livello HTTP.
• Batch di rilevamento delle anomalie (systemd timer): Scansiona i registri di audit ogni cinque minuti e rileva tre categorie: tasso di richieste elevato, tasso di negazioni di autorizzazione elevato e tentativi di forza bruta.
• Rate Limiting: Limitazione di frequenza delle richieste per tenant sugli endpoint di utilizzo e limitazione di frequenza basata su IP sugli endpoint di autenticazione, con rifiuto automatico del traffico eccessivo.
• Avvisi di sicurezza configurabili: I Clienti possono scegliere quali eventi operativi (saldo basso, accesso da una nuova posizione, accesso bloccato, ripetuti tentativi di accesso falliti) attivano notifiche via email, con soglie di sensibilità per evento.
• Infrastruttura del registro di audit: Registra ogni chiamata API in un registro di audit con catena di hash ed evidenza di manomissione (SHA-256, sequenza per tenant) e consolida le voci per la verifica indipendente.
• Pannello di stato (9 indicatori di salute): Visualizza in un'unica schermata l'audit, le anomalie, il GeoIP, i backup, il batch di eliminazione, la copertura del catalogo, la deviazione di riconciliazione, il killswitch e la salute del servizio.
• Backup automatizzato: Crittografa gli snapshot di SQLite con GPG AES-256 e conserva 30 generazioni giornaliere.

3.3 Delega della risposta di prima linea all'automazione

Le fasi di rilevamento e triage sono svolte dagli strumenti automatizzati descritti sopra come prima linea. La parte responsabile interviene solo al ricevimento di notifiche di superamento delle soglie. Questo design garantisce che la copertura di rilevamento 24/7 sia fisicamente stabilita senza dipendere dalla posizione o dalla disponibilità della parte responsabile.

4. Processo di risposta

4.1 Rilevamento

Quando uno o più degli strumenti automatizzati descritti nella Sezione 3.2 rilevano un'anomalia, la parte responsabile viene notificata immediatamente tramite Sentry, email e avvisi del pannello. Le segnalazioni dei Clienti vengono ricevute a [email protected] e convertite in ticket all'interno dello stesso flusso.

4.2 Triage

Al ricevimento di una notifica, la parte responsabile conferma la gravità esaminando:

• L'ambito dell'impatto (tutti i Clienti / un Cliente specifico / una singola Istanza).
• Se sono interessati dati personali, credenziali di autenticazione o informazioni di fatturazione.
• Il coinvolgimento di fattori esterni (interruzioni dei fornitori di IA upstream, interruzioni di Cloudflare, interruzioni di AWS).
• La correlazione con pattern di attacco noti (log del WAF, risultati del rilevamento delle anomalie, avvisi di GeoIP).

4.3 Contenimento

A seconda della gravità, vengono applicate una o più delle seguenti misure di contenimento:

• Sospensione delle Istanze interessate tramite la macchina a stati per l'isolamento immediato.
• Aggiunta degli indirizzi IP di origine a una lista di negazione (per Cliente o globale).
• Revoca in massa delle sessioni tramite JWT jti.
• Attivazione del killswitch (arresto totale del traffico, misura di ultima istanza).
• Attivazione dell'"Under Attack Mode" di Cloudflare contro gli attacchi L7.

4.4 Ripristino

Dopo il contenimento, le cause profonde vengono eliminate e viene svolto quanto segue:

• Ripristino da backup secondo necessità (procedure documentate in docs/RESTORE.md).
• Rotazione delle credenziali interessate (chiavi API, segreti JWT, chiavi di crittografia dei backup ecc.).
• Applicazione di patch, correzioni di configurazione e correzioni di codice in produzione.
• Verifica negli ambienti di staging e produzione.
• Osservazione continuata per almeno 24 ore tramite gli strumenti di monitoraggio.

4.5 Post-incidente

Una volta confermato il ripristino, la parte responsabile:

• Documenta la cronologia, la causa profonda, l'ambito dell'impatto e le azioni di risposta.
• Identifica misure preventive e le incorpora nella roadmap di implementazione.
• Quando applicabile, notifica i Clienti interessati e le autorità di regolamentazione (vedi Sezione 5).
• Riporta i miglioramenti a questo Piano e ai documenti operativi correlati.

5. Notifica a Clienti e autorità

5.1 Notifica delle violazioni di dati personali

Se l'acquisizione, la perdita o la divulgazione non autorizzate di dati personali vengono confermate, forniamo notifica in conformità con:

• Regolamento Generale sulla Protezione dei Dati dell'UE (GDPR) Article 33: Notifica all'autorità di controllo entro 72 ore dalla presa di conoscenza.
• GDPR Article 34: Quando viene identificato un rischio elevato, notifica agli interessati coinvolti senza ingiustificato ritardo.
• Legge sulla Protezione delle Informazioni Personali (Giappone): Rapporto alla Commissione per la Protezione delle Informazioni Personali e notifica agli interessati, in conformità con le ordinanze e le regole applicabili.
• Altre giurisdizioni applicabili: Le notifiche richieste dalle leggi sulla protezione dei dati nazionali o regionali applicabili.

5.2 Notifica delle interruzioni del servizio

Per le interruzioni del servizio classificate come P1 o P2, notifichiamo i Clienti interessati senza ingiustificato ritardo, includendo i tempi di ripristino previsti e qualsiasi mitigazione provvisoria. I canali di notifica sono [email protected] e la console di amministrazione del Servizio.

5.3 Metodo di notifica

Le notifiche vengono consegnate principalmente via email all'indirizzo registrato del Cliente, integrate secondo necessità da banner all'interno della console di amministrazione.

6. Post-Mortem e ciclo di apprendimento

Dopo un incidente P1 o P2, la parte responsabile svolge un Post-Mortem e documenta i seguenti elementi. Il documento viene conservato internamente e divulgato ai Clienti e ai revisori su richiesta.

• La cronologia degli eventi dal rilevamento al ripristino.
• L'analisi della causa profonda (fattori tecnici e operativi).
• L'ambito quantificato dell'impatto.
• La valutazione del processo di risposta.
• Le misure preventive e le scadenze obiettivo.

I Post-Mortem vengono svolti come Blameless Post-Mortems, incentrati sul miglioramento strutturale e non sulla responsabilità individuale.

7. Manutenzione e revisione del Piano

7.1 Revisione periodica

Questo Piano viene rivisto almeno una volta all'anno, nonché dopo qualsiasi incidente significativo, di fronte a cambiamenti sostanziali nell'architettura del Servizio e di fronte a modifiche delle leggi e normative applicabili.

7.2 Cronologia delle revisioni

La cronologia delle revisioni di questo Piano viene mantenuta internamente e divulgata ai Clienti e ai revisori su richiesta.

8. Contatto

Per segnalare un incidente o porre domande su questo Piano:

STANDOUT Inc.
Email: [email protected]

Ultimo aggiornamento: 2 giugno 2026