Vai al contenuto

IDMEFv2: formato di scambio di messaggi di rilevamento incidenti V2

Da Wikipedia, l'enciclopedia libera.

IDMEFV2 ( Incident Detection Message Exchange Format ) è un'iniziativa per standardizzare un formato di allerta per il rilevamento degli incidenti presso l'IETF. Due prime bozze del formato e del trasporto sono in fase di sviluppo presso l'IETF da maggio 2023[1],[2]. È un'evoluzione dello standard IETF IDMEFv1 (Intrusion Detection Message Exchange Format RFC 4765 ) definito nel 2007. Da questo si riprende il principio (definizione di un formato di allerta standard) estendendolo però a tutte le tipologie di allerta, siano esse informatiche o fisiche, aggiornandone il formato e la relativa tecnologia[3]. Il “Rilevamento delle intrusioni” viene dunque sostituito dal “Rilevamento degli incidenti” che copre un ambito molto più ampio.

La prima versione del formato IDMEFv2 è stata creata nel 2021 nell'ambito di una partnership tra un progetto di ricerca francese (FUI 25 SECEF : Security Exchange Format) finanziato da BPI e IDF finalizzato a migliorare il formato IDMEFv1 e un progetto europeo H2020 7SHIELD che lavora sulla protezione delle infrastrutture fisiche e informatiche contro attacchi complessi e ibridi[4]. Il formato IDMEFv1 (Intrusion Detection), inizialmente riservato al rilevamento delle intrusioni informatiche, in questa occasione è stato allargato a tutti gli incidenti (Incident Detection).

Nell'ambito del progetto 7Shield, il formato è stato utilizzato in 5 segmenti terrestri pilota in Europa (Belgio, Finlandia, Grecia, Italia e Spagna), collegando così più di trenta componenti tecnici sviluppati dai diversi partner.

La prima bozza del formato è stata pubblicata all'IETF nell'aprile 2023 da Télécom SudParis[5].

Dal primo gennaio 2024, Télécom SudParis guida un nuovo progetto di ricerca afferente al programma Digital Europe (SAFE4SOC : Security Alert Exchange Format for SOC) volto ad ampliare l'utilizzo del formato allo scambio di informazioni di rilevamento tra SOC ( Security Operation Center ) all'interno della Comunità Europea[6]. Il progetto mira ad adattare il formato IDMEFv2 a questo tipo di scambio nonché a finalizzare le sue specifiche e ottenere la standardizzazione IETF.

La comunità IDMEFv2

[modifica | modifica wikitesto]

La definizione e il miglioramento del formato sono oggi aperti all'intera comunità tecnico-scientifica attraverso un sito web e una mailing list in cui vengono discussi sviluppi e scelte del formato[7].

La comunità sta attualmente lavorando alla standardizzazione del formato presso IETF.

Le ragioni della convergenza fisica e informatica

[modifica | modifica wikitesto]

Storicamente, il rilevamento degli incidenti è stato suddiviso in tre principali aree d'impiego. Gestione delle prestazioni e della disponibilità attorno a NMS (sistemi di gestione della rete) e altri strumenti di osservabilità, che concentrano, analizzano e notificano gli incidenti relativi alle prestazioni ed alle disponibilità. Gestione della sicurezza IT attorno ai SIEM (Security Information & Event Management) che concentrano, analizzano e notificano gli incidenti di sicurezza informatica. Gestione della sicurezza fisica attorno al PSIM (Physical Security Information Management) che concentra, analizza e notifica gli incidenti di sicurezza fisica. Ciascuno di questi domini offre i suoi strumenti e formati.

Questa compartimentazione, giustificata storicamente, presenta oggi numerosi svantaggi tra cui la moltiplicazione degli strumenti, delle competenze e dei team di lavoro specializzati. È, dunque, anche difficile o impossibile rilevare incidenti complessi, a cascata o attacchi combinati. Ed è, inoltre, impossibile eseguire la correlazione incrociata o l’elaborazione dell’intelligenza artificiale multidominio.

Infine, in un momento di esplosione dell’Internet of Things, la separazione tra mondo cibernetico e mondo fisico diventa sempre più difficile da definire ed è urgente riuscire a unire la supervisione dei due mondi digitale e fisico .

IDMEFv2 offre quindi un formato di avviso universale che consente la convergenza di questi molteplici domini in un sistema unificato di rilevamento degli incidenti.

L'obiettivo del formato IDMEFv2

[modifica | modifica wikitesto]

IDMEFv2 offre la possibilità di descrivere incidenti (o eventi sospetti) di tipo cyber (mancata autenticazione, tentativo di intrusione, rilevamento di un virus, scansione illegittima di una porta, ecc.), fisico (rilevazione di movimento, allarme incendio, intrusione fisica, avvicinamento di un drone...), relativi alla disponibilità (mancata risposta da un server o una telecamera, temperatura o velocità della CPU che superano una soglia...) e infine i rischi. Inoltre, il formato permette di descrivere i potenziali rischi umani o naturali in particolare legati al clima (e ai suoi sconvolgimenti).

Classi IDMEFv2

[modifica | modifica wikitesto]

La versione V03 del Draft IDMEFV2 offre sette classi.

Classe Descrizione
Fonte un indirizzo IP, un individuo...
Bersaglio un server informatico o fisico, un edificio, un'area, una persona...
Vettore il vettore d'attacco, la modalità operativa, un virus, un drone...
Sensore una sonda, una telecamera, un sensore di movimento/temperatura...
Analizzatore lo strumento che analizza i dati catturati dal rilevatore (analizzatore e rilevatore possono essere la stessa istanza),
Avviso L'avviso stesso generato dall'analizzatore
Allegato Per allegare un elemento ad una classe: un file, un'immagine, un suono...

Le specifiche del formato

[modifica | modifica wikitesto]

La definizione del formato IDMEFv2 si basa su quattro principi principali. Universalità con lo stesso formato per tutti gli incidenti con 5 "dimensioni" per ogni avviso: la tripla dimensione spaziale, la dimensione cyber (indirizzo IP) e la dimensione temporale. Una classificazione molto ampia basata sul lavoro del gruppo di lavoro RIST (Reference Security Incident Taxonomy) dell'ENISA[8] e del “Centro di ricerca sull'epidemiologia dei disastri” (CRED)[9] per i pericoli. Concetti semplici con un numero limitato di classi e attributi di alto livello (con semplici possibilità di estensione), un formato limitato al solo rilevamento degli incidenti (prima della fase di analisi) e l'uso di tecnologie popolari con JSON su HTTP . E un formato di rilevamento “end-to-end”: IDMEFv2 porta attributi tecnici per la catena di rilevamento (rilevamento, correlazione, aggregazione, AI, ecc.) nonché attributi più significativi per la visualizzazione degli avvisi in una dashboard "supervisione per gli operatori.

Esempi JSON di avvisi IDMEFv2

[modifica | modifica wikitesto]

Incidente informatico

[modifica | modifica wikitesto]

Un SIEM ha rilevato un potenziale attacco a forza bruta sull'account root sui server 192.0.2.2 e 2001:db8::/32:

{
  "Version": "2.D.V0X",
  "ID": "819df7bc-35ef-40d8-bbee-1901117370b2",
  "Description": "Potential bruteforce attack on root user account",
  "Priority": "Medium",
  "CreateTime": "2021-05-10T16:55:29.196408+00:00",
  "StartTime": "2021-05-10T16:55:29+00:00",
  "Category": [
    "Attempt.Login"
  ],
  "Analyzer": {
    "Name": "SIEM",
    "Hostname": "siem.acme.com",
    "Type": "Cyber",
    "Model": "Concerto SIEM 5.2",
    "Category": [
      "SIEM",
      "LOG"
    ],
    "Data": [
      "Log"
    ],
    "Method": [
      "Monitor",
      "Signature"
    ],
    "IP": "192.0.2.1"
  },
  "Sensor": [
    {
      "IP": "192.0.2.5",
      "Name": "syslog",
      "Hostname": "www.acme.com",
      "Model": "rsyslog 8.2110",
      "Location": "Server room A1, rack 10"
    }
  ],
  "Target": [
    {
      "IP": "192.0.2.2",
      "Hostname": "www.acme.com",
      "Location": "Server room A1, rack 10",
      "User": "root"
    },
    {
      "IP": "2001:db8::/32",
      "Hostname": "www.acme.com",
      "Location": "Server room A1, rack 10",
      "User": "root"
    }
  ]
}

Incidente fisico

[modifica | modifica wikitesto]

Nell'edificio vicino alle sale server è stato identificato un uomo ricercato dall'FBI. All'avviso sono allegati il file dell'FBI e una foto scattata dalla telecamera.

{
  "Version": "2.D.V0X",
  "ID": "819df7bc-35ef-40d8-bbee-1901117370b1",
  "Description": "Potential intruder detected",
  "Priority": "Low",
  "Status": "Incident",
  "Cause": "Malicious",
  "CreateTime": "2021-05-10T16:52:13.075994+00:00",
  "StartTime": "2021-05-10T16:52:13+00:00",
  "Category": [
    "Intrusion.Burglary"
  ],
  "Analyzer": {
    "Name": "BigBrother",
    "Hostname": "bb.acme.com",
    "Type": "Physical",
    "Model": "Big Brother v42",
    "Category": [
      "HAR",
      "FRC"
    ],
    "Data": [
      "Images"
    ],
    "Method": [
      "Movement",
      "Biometric",
      "AI"
    ],
    "IP": "192.0.2.1"
  },
  "Sensor": [
    {
      "IP": "192.0.2.2",
      "Name": "Camera #23",
      "Model": "SuperDuper Camera v1",
      "Location": "Hallway to server room A1"
    }
  ],
  "Source": [
    {
      "Note": "Black Organization, aka. APT 4869"
    }
  ],
  "Vector": [
    {
      "Category": ["Man"],
      "TI": ["Name:FBI-Wanted"],
      "Name": "John Doe",
      "Note": "Codename Vodka, known henchman for APT 4869",
      "Location": "Hallway to server room A1",
      "Attachment": ["pic01", "wanted"]
    }
  ],
  "Attachment": [
    {
      "Name": "wanted",
      "FileName": "fbi-wanted-poster.jpg",
      "Size": 1234567,
      "Ref": ["https://www.fbi.gov/wanted/topten"],
      "ContentType": "image/jpg",
      "ContentEncoding": "base64",
      "Content": "..."
    },
    {
      "Name": "pic01",
      "Note": "Hi-res picture showing John Doe near server room A1",
      "ExternalURI": ["ftps://192.0.2.1/cam23/20210510165211.jpg"],
      "ContentType": "image/jpg"
    }
  ]
}

Incidente di disponibilità

[modifica | modifica wikitesto]

Il server www.acme.com non risponde alle richieste ping

{
  "Version": "2.D.V0X",
  "ID": "819df7bc-35ef-40d8-bbee-1901117370b3",
  "Description": "A server did not reply to an ICMP ping request",
  "Priority": "Medium",
  "Status": "Incident",
  "Cause": "Unknown",
  "CreateTime": "2021-05-10T16:59:11.875209+00:00",
  "StartTime": "2021-05-10T16:59:11.875209+00:00",
  "Category": [
    "Availability.Outage"
  ],
  "Analyzer": {
    "Name": "NMS",
    "Hostname": "nms.example.com",
    "Type": "Availability",
    "Model": "Concerto NMS 5.2",
    "Category": [
      "NMS"
    ],
    "Data": [
      "Network"
    ],
    "Method": [
      "Monitor"
    ],
    "IP": "192.0.2.1"
  },
  "Target": [
    {
      "IP": "192.168.1.2",
      "Hostname": "www.acme.com",
      "Service": "website",
      "Location": "Server room A1, rack 10"
    }
  ]
}

Implementazioni

[modifica | modifica wikitesto]

Il GitHub IDMEFv2[10] ospita librerie Java e Python per la manipolazione degli alert IDMEFv2 (formato e trasporto), un prototipo di CP-SIEM (Cyber & Physical Security Information & Event Management) e uno strumento per la validazione degli alert in formato JSON.

Casi d'uso di IDMEFv2

[modifica | modifica wikitesto]

Tra i principali casi d’uso possiamo citare il rilevamento cyber e/o fisico; IDMEFv2 può infatti essere utilizzato solo in un sistema cyber o fisico. IDMEFv2 è adatto anche a proteggere le infrastrutture critiche che potrebbero essere soggette ad attacchi o incidenti ibridi. Lo stesso vale per i sistemi intelligenti che combinano cyber e fisica (città, case, ecc.), uno dei migliori esempi è l’auto connessa che oggi include tanto la fisica quanto la cyber.

IDMEFv2 e l'ecosistema esistente

[modifica | modifica wikitesto]

Limitandosi al rilevamento degli incidenti, IDMEFv2 si presenta chiaramente come complementare ai formati e agli standard esistenti come SNMP per la sola disponibilità, l'iniziativa OCSF[11] per la definizione di eventi di sicurezza, IODEF per la descrizione di un incidente (dopo il rilevamento) o STIX per l'intelligence sulle minacce informatiche.

Collegamenti esterni

[modifica | modifica wikitesto]