PO27 - Gestione Eventi e Incidenti

Politica di Gestione Eventi e Incidenti

Revisioni


Rev.	Data	Descrizione	Redatto	Approvato
0.0	24/04/2026	Prima emissione	CISO	Amministratore Unico
0.1	16/07/2026	Revisione assistita da IA: corretto un riferimento a documento inesistente ("PR A16.1" → PR27.1)	CISO	Amministratore Unico

Indice 2

1 Introduzione 3

1.1 Scopo 3

1.2 Campo di applicazione 3

1.3 Riferimenti e Allegati 3

1.4 Definizioni, Acronimi, Abbreviazioni 4

1.5 Responsabilità 4

1.6 Violazione della Politica 5

1.7 Riesame 5

2 Politica di Gestione Eventi e Incidenti 5

2.1 Categorizzazione degli eventi di sicurezza 6

2.2 Rilevamento e analisi degli incidenti di sicurezza 7

2.3 Risposta agli incidenti di sicurezza 8

2.4 Risoluzione degli incidenti di sicurezza 9

2.5 Gestione di Data Breach 9

2.6 Comunicazione e reportistica degli incidenti di sicurezza 12

2.7 Tracciamento 12

2.8 Lezione appresa 12

Introduzione
1. Scopo

Questo documento descrive la politica di Gestione Eventi e Incidenti in Vectorlab, comprendendo tutte le attività e i sistemi aziendali coinvolti.

Vengono definite le linee guida inerenti alle attività di gestione degli incidenti di sicurezza mirate a identificare prontamente e in maniera efficiente, comunicare, contenere, gestire, registrare e minimizzare l’impatto di eventi inattesi che possano avere effetti sulla riservatezza, l'integrità e la disponibilità delle informazioni nonché sulla protezione dei dati personali.

Campo di applicazione

La presente politica comprende l’insieme di tutte le attività mirate all'individuazione e gestione di eventi di qualsiasi natura in grado di causare inefficienze nel SGSI, nell'erogazione dei servizi o la compromissione della sicurezza delle informazioni in termini di perdita di RID fino alla gestione di un Data Breach. A tal fine il presente documento identifica i criteri e le regole per:

identificare le modalità di rilevazione degli incidenti (avvisi, apertura ticket, strumenti automatici di monitoraggio, ecc.);
analizzare l'evento verificatosi (valutazione della gravità e della priorità, identificazione se categorizzabile come Data Breach, registrazione dell'incidente, identificazione della soluzione e delle contromisure);
reagire all'incidente (attuazione delle contromisure pianificate, monitoraggio delle attività e verifica dell'efficacia);
comunicare l'incidente (alla Direzione e a tutte le aree coinvolte, alle autorità ed agli interessati nel caso di Data Breach, rapporto finale e periodico);
ridurre la probabilità e l’impatto di futuri incidenti similari (analisi ex-post e azioni di miglioramento).

Tutto il personale di Vectorlab, incluse le terze parti che hanno accesso al sistema informativo della società, è tenuto a rispettare i principi definiti in tale documento e a comunicare prontamente e senza ingiustificato ritardo qualunque tipologia di evento rilevato che possa inficiare la sicurezza delle informazioni e/o che possa comportare la violazione di dati personali.

Riferimenti e Allegati

MDPO07.A - Piano di Comunicazione

PO07 - Gestione delle Comunicazioni

PR27.1 - Gestione Incidenti e Data Breach

Definizioni, Acronimi, Abbreviazioni

CEO - Chief Executive Officer

CISO - Chief Information Security Officer

DPO - Data Protection Officer (Responsabile per la Protezione dei Dati)

RID - Riservatezza Integrità Disponibilità

RSGI - Responsabile del Sistema di Gestione Integrato

SGI -Sistema di Gestione Integrato (Sicurezza delle Informazione e Protezione dei dati personali)

SGSI - Sistema di Gestione della Sicurezza delle Informazioni.

Responsabilità

Il CISO ha la responsabilità di redigere, mantenere aggiornata e comunicare la presente politica.

Il personale, a qualsiasi livello, e i collaboratori esterni devono attenersi alle procedure definite dall’Organizzazione per assicurarsi che la presente Politica sia correttamente applicata.

I responsabili dell’attuazione della presente politica sono:

la Direzione di Vectorlab, che fornisce le risorse necessarie per garantire la corretta applicazione della politica, garantisce il pieno supporto nell’attuazione della presente politica, affidando alle diverse funzioni compiti di implementazione, gestione e monitoraggio dell’efficacia ed efficienza del sistema;
il Responsabile del SGI, che facilita l’attuazione della presente politica attraverso norme e procedure appropriate;

tutto il personale di Vectorlab, a cui sono assegnati precisi ruoli e responsabilità. Esso deve avere un’adeguata competenza per comportarsi in maniera adeguata e tempestiva in caso di incidente e svolgere i compiti richiesti. Tutto il personale ha la responsabilità di reagire tempestivamente agli incidenti di sicurezza e a segnalare al RSGI qualsiasi punto debole individuato nel sistema;

Clienti e Fornitori coinvolti nella gestione dei prodotti/servizi implementati, che rientrano nel perimetro di applicazione del SGI. Essi sono tenuti al rispetto della Politica per garantire la sicurezza delle informazioni trattate e la protezione dei dati personali e contribuire in maniera attiva alla segnalazione e gestione degli incidenti sulla sicurezza delle informazioni e in particolare dei Data Breach.
1. Violazione della Politica

Qualsiasi azione non conforme alla politica aziendale di Vectorlab sarà considerata una violazione della sicurezza e come tale si tradurrà nella revoca dell'accesso alle aree e alle risorse informatiche, rete e documenti. L'uso improprio degli strumenti aziendali costituisce una grave violazione del dovere di correttezza e può comportare l'adozione di provvedimenti disciplinari in conformità alla normativa vigente.

Riesame

La revisione di tale politica, e delle procedure ad essa afferenti, è effettuata dal CISO almeno una volta all'anno, prima del Riesame della Direzione, e in risposta a cambiamenti significativi dell'ambiente organizzativo, del business, di riferimenti normativi o dell’ambiente tecnologico aziendale. Il riesame è condotto per valutare l'efficienza e l'efficacia del sistema e per assicurare che siano implementate le azioni necessarie per consentire il miglioramento continuo secondo i requisiti definiti dai sistemi di gestione e in tutte le situazioni per le quali è richiesta una modifica dell'attività aziendale che possa anche avere impatto sulla sicurezza delle informazioni o sull'operatività.

Politica di Gestione Eventi e Incidenti

La protezione delle informazioni e dei dati personali ha un'importanza cruciale per l'attività di Vectorlab; pertanto, è essenziale stabilire una politica di sicurezza volta a proteggere i dati memorizzati ed elaborati nei sistemi informativi.

La prima cosa essenziale è distinguere il significato di “evento” da quello di “incidente” relativi alla sicurezza delle informazioni:

un evento di sicurezza delle informazioni è un evento che può indicare che si è verificato o è in corso un incidente. In effetti, gli eventi sono indizi che devono essere valutati per effettuare ulteriori indagini; questo perché non tutti gli eventi danno necessariamente luogo alla segnalazione di un incidente.
un incidente di sicurezza è definito come qualsiasi evento che potrebbe avere un impatto negativo sulle informazioni aziendali gestite ossia impattarne la riservatezza, l’integrità e la disponibilità nonché sulla protezione dei dati personali e i diritti e libertà degli interessati (Data Breach).

Per Data Breach si intende “una violazione di sicurezza che comporta - accidentalmente o in modo illecito - la distruzione, la perdita, la modifica, la divulgazione non autorizzata o l’accesso ai dati personali trasmessi, conservati o comunque trattati”[1]. Una violazione dei dati personali può compromettere la riservatezza, l’integrità o la disponibilità di dati personali.

La definizione di regole comportamentali e di procedure specifiche da compiere per segnalare e valutare gli eventi di sicurezza delle informazioni e classificare e gestire gli incidenti di sicurezza è essenziale ai fini della loro risoluzione in maniera efficiente, nonché per evitare che si ripetano in futuro.

Essere in grado di mappare le minacce e le vulnerabilità e tenere attivo un sistema di monitoraggio è un passo importante per il controllo della sicurezza, incoraggiando lo sviluppo di un approccio proattivo e per ridurre la probabilità di un incidente. Una corretta mappatura delle minacce consente, inoltre, di fornire tempestivamente le contromisure da implementare per minimizzare il possibile impatto.

Avere strumenti adeguati a gestire il processo e definire ruoli e responsabilità del personale coinvolto ai vari livelli, nella gestione e risoluzione dell'incidente, permette di creare uno sforzo organizzato e coordinato di contenimento e risoluzione con l'obiettivo di ripristinare il più rapidamente possibile il normale funzionamento del sistema, evitando interruzioni prolungate nell'erogazione dei servizi e limitando i danni all'intero sistema informativo.

Il personale è informato e preparato a reagire correttamente agli incidenti di sicurezza e allo strumento di gestione da utilizzare.

Categorizzazione degli eventi di sicurezza

L'individuazione di un evento potenzialmente dannoso comporta la necessità di saperlo identificare e classificare; tutti gli eventi devono essere inseriti in un gruppo di categorie predefinite, valutate in base al loro impatto, sia per l’Organizzazione sia per eventuali interessati di dati personali coinvolti, e in base all’urgenza di risoluzione.

Alcuni degli esempi più comuni di categorie di eventi che potenzialmente possono scaturire in incidenti di sicurezza e, quindi, per i quali è importante prestare maggiore attenzione, sono:

cyber-attacchi, intenzionali o meno, alla disponibilità della rete o del sistema;
malware: virus, worm, trojan, trojan, backdoor, spyware, rootkit o qualsiasi altro codice dannoso che può infettare il sistema;
modifica non autorizzata delle configurazioni di sistema;
modifica della password di amministratore;
violazione dell'accesso: discrepanze nell'uso dell'account, errore di accesso multiplo;
accesso sia logico che fisico a reti, sistemi, applicazioni e dati da parte di personale non autorizzato;
scarse prestazioni di un sito web;
danni alle informazioni;
malfunzionamento dell'hardware;
un dispositivo rilevato come inattivo mentre dovrebbe essere attivo;
uso irregolare del sistema;
uso improprio delle risorse IT a causa di una violazione delle politiche e delle procedure di sicurezza;
violazioni delle infrastrutture fisiche;
una soglia che viene superata (o che sta per essere superata), ad esempio la capacità dello spazio su disco;
indisponibilità delle strutture principali;
catastrofi naturali (terremoti, inondazioni, ecc.);
prolungata assenza di energia elettrica;
impossibilità di accesso alla sede di lavoro a causa della mancanza di credenziali o chiavi di accesso;
perdita, smarrimento o furto di asset contenenti informazioni aziendali o dati personali;
mancato rispetto degli SLA contrattuali dei clienti e dei fornitori.

Un elenco esteso degli eventi di sicurezza mappati può essere trovato nella ISO/IEC 27035 di cui si riporta una sintesi nell’Allegato A al presente documento.

Rilevamento e analisi degli incidenti di sicurezza

La segnalazione di un evento potrà avvenire secondo le modalità di seguito riportate:

Reattiva: identificazione di eventi di sicurezza mediante “rilevazione” e “segnalazione” automatica, in cui le informazioni provengono da sistemi di monitoraggio (anche mediante soluzioni automatizzate), in relazione a malfunzionamenti:
- delle infrastrutture di elaborazione (ad esempio in relazione ad eventi quali la saturazione di processori, buffer overflow della memoria, ecc.);
- di ulteriori infrastrutture (ad esempio in relazione ad eventuali interruzioni di energia elettrica);
Proattiva: rilevazione di eventi di sicurezza mediante “notifica” da parte di fonti interne o esterne non automatizzate. In questi casi i soggetti provvedono a segnalare l’evento mediate gli appositi canali di comunicazione individuati e, ove ritenuto necessario, informando tempestivamente il proprio responsabile.

Gli eventi andranno segnalati al CISO e verranno gestiti seguendo quanto descritto nella procedura “PR27.1 - Gestione Incidenti e Data Breach”. Tale documento indirizza i seguenti punti:

categorizzazione dell’evento;
classificazione in base al livello di impatto e urgenza;
coinvolgimento del trattamento dei dati personali in modo da poter definire se in presenza di un Data Breach;
valutazione al fine di individuare e pianificare le contromisure per prevenire ulteriori conseguenze;
azioni da attuare per il ripristino delle normali condizioni;
analisi periodica degli incidenti accaduti.
1. Risposta agli incidenti di sicurezza

Le contromisure possono essere classificate nelle seguenti categorie:

misure di contenimento, che consistono nell'isolare la minaccia in modo da ridurre il perimetro dell'incidente;

Ad esempio: chiusura dell'accesso a Internet, segregazione delle reti.

Misure correttive, volte a sradicare la minaccia;

Ad esempio: disinfestazione o, nei casi più gravi, rottamazione della macchina colpita;

Misure di riparazione, che consentono il ripristino delle normali operazioni, riparando tutti i componenti danneggiati.

Ad esempio: riapertura degli accessi, reinstallazione dei sistemi;

Misure preventive, che mirano, in caso di danno potenziale, a prevenire la diffusione di minacce quali, ad esempio, quelle poste da una vulnerabilità nota o da un giorno zero.

Le contromisure sono destinate a rispondere agli incidenti di sicurezza, con l'obiettivo di:

ridurre il più possibile gli interventi “di rottura” sui sistemi sospetti;
ridurre il più possibile l'utilizzo di risorse potenzialmente compromesse;
valutare il rischio a cui l'azienda può essere esposta, se l'asset potenzialmente compromesso viene mantenuto attivo;
ripristinare o sospendere le credenziali dei sistemi potenzialmente compromessi;
gestire i dati dei servizi coinvolti nell'incidente e, se necessario, procedere al ripristino.

Tutte le operazioni effettuate per rispondere agli incidenti di sicurezza dovranno essere tracciate e documentate. Inoltre, tutte le evidenze dovranno essere registrate e archiviate per facilitare qualsiasi indagine che possa portare alla definizione di nuovi piani di continuità operativa.

La conservazione in sicurezza delle informazioni relative ad eventi e incidenti di sicurezza può essere di aiuto alla Società di fronte alle significative conseguenze legali che possono derivare da un incidente di sicurezza; inoltre può essere di aiuto nella risoluzione di eventuali incidenti simili che potrebbero verificarsi in futuro. Mantenere la cronologia degli incidenti aiuta a prevenirne di nuovi e a rendere consapevoli di quanto in precedenza trascurato e sfruttato per attaccare il sistema, consentendo un'adeguata ricerca statistica e reportistica.

Se le autorità sono coinvolte nella gestione dell'incidente, devono riceverne tutte le informazioni ed essere rese consapevoli delle modalità di memorizzazione, conservazione e manutenzione, di come non compromettere l'integrità dei dati parte dell'analisi e di come accedere a una copia in tempo reale dei sistemi e delle registrazioni interessate. Se è richiesto l'accesso ad un sistema, deve essere fornita alle Autorità una copia consistente temporalmente prima che vengano intraprese azioni correttive sul sistema, e deve essere fornito alle autorità competenti un adeguato account utente privilegiato per accedere al Sistema.

Le contromisure devono essere monitorate per verificarne l'efficacia e l'efficienza.

Tutti gli incidenti di sicurezza rilevati dovranno essere valutati durante riunioni dedicate e dovranno essere registrati nel sistema di ticketing aziendale.

Risoluzione degli incidenti di sicurezza

La risoluzione di un incidente di sicurezza avviene a seguito del monitoraggio delle soluzioni implementate; se i risultati non evidenziano anomalie dopo il ripristino in esercizio dei sistemi coinvolti, la Direzione che ha assunto la titolarità dell'incidente e il monitoraggio delle azioni di rimedio implementate, procede alla chiusura dell'incidente richiedendo la chiusura del ticket.

Gestione di Data Breach

Vectorlab può trattare dati personali in veste di Titolare o Responsabile degli stessi. In entrambi i casi è necessario essere in grado di identificare eventuali violazioni di dati personali e valutarne l’impatto sui diritti degli interessati.

Se la violazione può comportare un elevato rischio di ledere i diritti e le libertà delle persone, è obbligatorio:

informare l’Autorità Garante per la Protezione dei Dati Personali entro 72 ore dal momento in cui si è venuti a conoscenza della violazione;
informare senza indebito ritardo anche gli interessati valutando, in base alla numerosità e tipologia degli interessati, il contenuto della comunicazione e le modalità di invio.

Il Considerando 85 del GDPR spiega questo punto:

"Una violazione dei dati personali può, se non affrontata in modo appropriato e tempestivo, provocare un danno fisico, materiale o morale alle persone fisiche, come la perdita di controllo sui loro dati personali o la limitazione dei loro diritti, la discriminazione, il furto di identità o la frode, la perdita finanziaria, l'inversione non autorizzata dello pseudonimo, il danno alla reputazione, la perdita di riservatezza dei dati personali protetti dal segreto professionale o qualsiasi altro svantaggio economico o sociale significativo per la persona fisica interessata”.

Quando si procede con la segnalazione di una violazione, la stessa dovrà tramite apposito modulo di segnalazione che includa nello specifico:

una descrizione della natura della violazione dei dati personali, compresa, ove possibile:
- le categorie e il numero approssimativo di persone interessate; e
- le categorie e il numero approssimativo dei dati personali in questione;
- il nome e le coordinate del responsabile della protezione dei dati (se la vostra organizzazione ne ha uno) o un altro punto di contatto presso il quale è possibile ottenere ulteriori informazioni;
una descrizione delle probabili conseguenze della violazione dei dati personali; e
una descrizione delle misure adottate o proposte per far fronte alla violazione dei dati personali, comprese, se del caso, le misure adottate per attenuare eventuali effetti negativi.

Il diagramma seguente mostra gli obblighi di notifica da attuare quando una violazione dei dati diventa evidente, ed è tradotto dal “Guidelines on Personal Data Breach notification under Regulation 2016/679”, rev. 06/02/2018 dal Gruppo di Lavoro “Articolo 29”.

Figura 1 - Diagramma di flusso che indica obblighi di notifica

La procedura dettagliata di gestione di un Data Breach e relative notifiche è descritta in “PR27.1 - Gestione Incidenti e Data Breach”.

Comunicazione e reportistica degli incidenti di sicurezza

Gli incidenti di sicurezza devono sempre essere tempestivamente comunicati a tutti i soggetti coinvolti, alla Direzione e ai Terzi interessati dall'evento.

Per le comunicazioni interne al personale e alle parti correlate, nonché le comunicazioni esterne verso Terzi interessati o Autorità, verrà seguito quanto previsto dalla politica “PO07 - Gestione delle Comunicazioni” che aiuta a trovare il modo giusto per comunicare un evento avverso e identificare il mittente e i destinatari della comunicazione.

Tracciamento

Vectorlab dovrà assicurare il corretto tracciamento ed archiviazione di tutte le informazioni relativa alla gestione e chiusura dell’incidente.

Le registrazioni raccolte e archiviate dopo la risoluzione dell’incidente, potranno servire anche per indagini ex-post svolte dalle autorità competenti. Le evidenze raccolte e adeguatamente conservate potranno inoltre essere utili a fini statistici per la valutazione dei livelli di efficacia delle misure di protezione in atto e delle procedure operative di sicurezza.

Lezione appresa

Vectorlab coglierà ogni opportunità di effettuare un'analisi post-incidente mirata a:

identificare le cause iniziali che hanno innescato l'incidente eseguendo un'analisi delle cause alla radice;
analizzare le contromisure e misurarne l'efficacia, al fine di individuare i modi migliori per reagire in futuro ad eventi simili;
valutare la necessità di contromisure più specifiche per prevenire il ripetersi dell'evento;
aggiornare la base di conoscenze con procedure appropriate per affrontare eventi simili.

In quanto parte essenziale e utile di qualsiasi risposta ad un incidente per la sicurezza dell'informazione è importante l'individuazione di insegnamenti per migliorare la posizione di sicurezza e ridurre il rischio che lo stesso tipo di incidente si ripeta. Gli incidenti devono inoltre essere analizzati per determinare se vi sono tendenze o modelli che si ripropongono.

Il CISO, in accordo con la Direzione, riesamina periodicamente ogni incidente di sicurezza segnalato per individuare le aree di miglioramento del sistema. Durante questa revisione saranno analizzate le metriche disponibili per valutare le prestazioni e sarà organizzata una formazione specifica per migliorare la consapevolezza e l’adattamento del personale all'evoluzione dei rischi e delle minacce alla sicurezza.

ALLEGATO A

(ISO/IEC 27035-1:2016 – Annex B)

Esempi di incidenti di sicurezza delle informazioni e loro cause.

B.1 Attacchi

B.1.1 Denial of Service

Denial of Service (DoS) e Distributed Denial of Service (DDoS) sono un'ampia categoria di incidenti con un filo comune. Tali incidenti impediscono a un sistema, servizio o rete di continuare a funzionare seconda la capacità prevista, molto spesso con la completa negazione dell'accesso agli utenti legittimi. Esistono due tipi principali di file Incidenti DoS / DDoS causati da mezzi tecnici: eliminazione delle risorse e carenza di risorse.

Alcuni esempi tipici di incidenti tecnici DoS / DDoS intenzionali includono:

eseguire il ping degli indirizzi di trasmissione di rete per riempire la larghezza di banda della rete con il traffico di risposta;
invio di dati in un formato imprevisto a un sistema, servizio o rete nel tentativo di bloccarlo o interromperlo il suo normale funzionamento;
apertura di più sessioni autorizzate con un particolare sistema, servizio o rete nel tentativo di esaurire le sue risorse (cioè, per rallentarlo, bloccarlo o bloccarlo).

Tali attacchi vengono spesso eseguiti tramite Botnet, una raccolta di robot software (codice dannoso) in esecuzione in modo autonomo e automatico. Le botnet possono riguardare da alcune centinaia a milioni di computer interessati.

Alcuni incidenti tecnici DoS possono essere causati accidentalmente, ad esempio causati da un'errata configurazione da parte dell'operatore o per incompatibilità del software applicativo, ma il più delle volte sono intenzionali. Alcuni incidenti tecnici DoS vengono lanciati intenzionalmente al fine di mandare in crash un sistema o un servizio, o interrompere una rete, nel frattempo altri sono semplicemente i sottoprodotti di altre attività dannose. Ad esempio, alcune delle più comuni invisibili tecniche di scansione e identificazione possono causare l'arresto anomalo di sistemi o servizi meno recenti o mal configurati quando scansiti. Va notato che molti incidenti DoS tecnici deliberati vengono spesso eseguiti in modo anonimo (ad es. la fonte dell'attacco è "falsificata"), poiché in genere non si basano sul fatto che l'aggressore riceva alcuna informazione indietro dalla rete o dal sistema attaccato.

Incidenti DoS causati da mezzi non tecnici, con conseguente perdita di informazioni, servizi e/o strutture potrebbero essere causati, ad esempio, da:

violazioni delle disposizioni di sicurezza fisica che comportano furto o danno intenzionale e distruzione di attrezzatura;
danni accidentali all'hardware (e/o alla sua posizione) causati da fuoco o danni causati dall'acqua / inondazioni;
condizioni ambientali estreme, ad esempio temperature di esercizio elevate (ad esempio dovute all'aria condizionata fallimento);
malfunzionamenti del sistema o sovraccarico;
modifiche al sistema incontrollate;
malfunzionamenti del software o dell'hardware.

B.1.2 Accesso non autorizzato

In generale, questa categoria di incidenti consiste in tentativi effettivi non autorizzati di accesso o uso improprio di un sistema, servizio o rete. Alcuni esempi di incidenti di accesso non autorizzato stimolati tecnicamente includono:

tentativi di recuperare i file delle password;
attacchi al buffer overflow per tentare di ottenere l'accesso privilegiato (ad es. Amministratore di sistema) per un obiettivo;
sfruttamento delle vulnerabilità del protocollo per dirottare o indirizzare in modo errato connessioni di rete legittime;
tentativi di elevare i privilegi a risorse o informazioni oltre a quanto già un utente o un amministratore legittimamente possiede.

Incidenti di accesso non autorizzato causati da mezzi non tecnici, con conseguente divulgazione diretta o indiretta o la modifica delle informazioni, violazioni di responsabilità o uso improprio dei sistemi di informazione, potrebbe essere causato, per esempio, da:

violazioni delle disposizioni di sicurezza fisica che comportano un accesso non autorizzato alle informazioni;
sistemi operativi mal configurati e / o mal configurati a causa di modifiche incontrollate del sistema o malfunzionamenti di software o hardware.

B.1.3 Codice dannoso

Il codice dannoso identifica un programma o parte di un programma inserito in un altro programma con l'intento di modificare il suo comportamento originale, di solito per eseguire attività dannose come informazioni e identificare il furto, distruzione di informazioni e risorse, Denial of Service, Spam, ecc. Gli attacchi di codice dannoso potrebbero essere suddivisi in cinque categorie: virus, worm, cavalli di Troia, codice mobile e blended. Mentre alcuni anni fa i virus sono stati creati per colpire qualsiasi sistema infetto vulnerabile, oggi i codici dannosi vengono utilizzati per eseguire mirati attacchi. Questo a volte viene eseguito modificando un codice dannoso esistente, creando una variante che spesso non è riconosciuta da tecnologie di rilevamento di codici dannosi.

B.1.4 Uso inappropriato

Questo tipo di incidente si verifica quando un utente viola i criteri di sicurezza del sistema informativo di un'organizzazione. Come gli incidenti non sono attacchi nel senso stretto del termine, ma sono spesso segnalati come incidenti e dovrebbero esserlo gestito da un ISIRT (team composto da membri dell'organizzazione adeguatamente qualificati e affidabili che gestisce la sicurezza delle informazioni durante gli incidenti e il loro ciclo di vita). Un utilizzo inappropriato potrebbe essere:

scaricare e installare strumenti di hacking;
utilizzo della posta elettronica aziendale per spam o promozione di affari personali;
utilizzare le risorse aziendali per creare un sito Web non autorizzato;
utilizzo di attività peer-to-peer per acquisire o distribuire file piratati (musica video, software).

B.2 Raccolta di informazioni

In termini generali, la categoria di raccolta delle informazioni degli incidenti include le attività associate all’identificazione di potenziali obiettivi e comprendere i servizi in esecuzione su tali obiettivi. Questo tipo di incidente coinvolge la ricognizione, con l'obiettivo di identificare:

esistenza di un obiettivo e comprensione della topologia di rete che lo circonda e con chi l’obiettivo comunica regolarmente, e
potenziali vulnerabilità nell’obiettivo o nel suo ambiente di rete immediato che potrebbero essere sfruttate.

Esempi tipici di attacchi di raccolta di informazioni con mezzi tecnici includono:

scaricare i record DNS (Domain Name System) per il dominio Internet di destinazione (trasferimento di zona DNS);
eseguire il ping degli indirizzi di rete per trovare sistemi "vivi";
sondare il sistema per identificare (ad es. Impronta digitale) il sistema operativo host;
eseguire la scansione delle porte di rete disponibili su un sistema per identificare i servizi correlati (ad es. E-mail, FTP, web, ecc.) e la versione software di tali servizi;
ricerca di uno o più servizi vulnerabili noti in un intervallo di indirizzi di rete (orizzontale scansione).

In alcuni casi, la raccolta di informazioni tecniche si estende all'accesso non autorizzato se, ad esempio, come parte della ricerca delle vulnerabilità, l'aggressore tenta anche di ottenere un accesso non autorizzato. Ciò si verifica comunemente con strumenti di hacking automatizzati che non solo cercano le vulnerabilità ma tentano anche di sfruttarle automaticamente i sistemi, i servizi e / o le reti vulnerabili rilevati.

Incidenti di raccolta di informazioni causati da mezzi non tecnici, con conseguenti:

divulgazione diretta o indiretta o informazioni di modifica;
furto di proprietà intellettuale archiviata elettronicamente;
violazioni della responsabilità, ad es. nella registrazione dell'account;
uso improprio dei sistemi di informazione (ad esempio contrario alla legge o alla politica dell'organizzazione);

potrebbe essere causato, ad esempio, da:

violazioni delle disposizioni in materia di sicurezza fisica che comportano un accesso non autorizzato alle informazioni e il furto di apparecchiature di archiviazione dati che contengono dati importanti, ad esempio chiavi di crittografia;
sistemi operativi mal configurati e/o mal configurati a causa di modifiche incontrollate del sistema o malfunzionamenti software o hardware, con conseguente accesso alle informazioni da parte del personale interno o esterno per il quale non hanno autorità.

WP250 - Linee guida sulla notifica delle violazioni dei dati personali ai sensi del regolamento (UE) 2016/679