Skip to content

Risposta agli incidenti e recupero da una violazione della sicurezza con vettore di attacco sconosciuto

Ti do il benvenuto nella nostra community, in questo luogo troverai la risoluzione che stavi cercando.

Soluzione:

State osservando la situazione dal punto di vista della sicurezza e (presumo) dal punto di vista di un professionista della sicurezza. Supponendo che l'azienda abbia l'obiettivo di fare soldi, chiuderà per il tempo minimo necessario perché ciò influirà sui profitti. Raramente l'IT avrà un ruolo importante nel decidere se rimanere offline o meno durante l'analisi delle cause. Diamine, nella maggior parte delle indagini sulle violazioni in cui sono stato coinvolto, i sistemi vengono semplicemente ripristinati dai backup, non viene svolta alcuna indagine sull'accaduto fino a quando non vengono colpiti per l'ennesima volta in pochi mesi e non ci viene dato quasi nulla su cui lavorare per trovare la causa principale. La direzione si preoccupa dei dollari e, sebbene i processi possano cambiare con cose come il GDPR, dubito che questo cambierà molto, a parte il fatto che più personale IT verrà licenziato dopo una violazione. Per quanto riguarda la domanda sulle "eccellenti capacità di rilevamento delle intrusioni", anche queste sono generalmente carenti. Se leggete il Verizon Threat Report: http://www.verizonenterprise.com/industry/public_sector/docs/2018_dbir_public_sector.pdf a pagina 10 fornisce una panoramica sulla "scoperta", e in genere i mesi necessari per rilevare una compromissione sono pochi.

Nella sua domanda c'è un'idea sbagliata riguardo alle tecniche di attacco e agli exploit utilizzati in questi incidenti di sicurezza spettacolari e ampiamente conosciuti.

Gli exploit sono generalmente classificati con metriche (oltre ad altre) come gravità e complessità. Di solito(!) più un attacco è complesso, più è difficile per la scientifica capire cosa sia successo esattamente. Gli attacchi da lei citati sono effettivamente difficili da eseguire e quindi difficili da indagare. Ma il punto più importante è che, secondo le aziende colpite, non sono quelli utilizzati dagli aggressori in questi incidenti popolari.

Prendiamo ad esempio la violazione di Equifax. Citazione da Wikipedia:

Equifax ha dichiarato che la violazione è stata facilitata da una falla in Apache Struts (CVE-2017-5638). Una patch per la vulnerabilità è stata rilasciata il 7 marzo, ma l'azienda non ha applicato gli aggiornamenti di sicurezza prima dell'attacco avvenuto due mesi dopo. Tuttavia, questo non è stato l'unico punto di fallimento: i fattori che hanno contribuito sono stati la progettazione di una rete insicura, priva di una sufficiente segmentazione, la crittografia potenzialmente inadeguata delle informazioni di identificazione personale (PII) e l'inefficacia dei meccanismi di rilevamento delle violazioni.

Questi non descrivono affatto vettori di attacco fantasiosi. La falla di Apache Struts era già abbastanza nota all'epoca e Struts stesso era (per quanto ne so) un framework ampiamente utilizzato. Ogni volta che un CVE come questo viene pubblicato, viene testato dagli attaccanti di tutto il mondo. immediatamente. L'IT di Equifax avrebbe dovuto patchare i propri sistemi il prima possibile, ma non l'ha fatto. D'altra parte, la patch dei server richiede un po' di tempo, ma non per sempre. È quindi possibile limitare la disponibilità del servizio per un po' e poi ripristinarla lentamente, una volta che i server sono stati aggiornati.

Inoltre: Se Equifax avesse avuto una segmentazione, una crittografia o un rilevamento adeguati - tutte e tre tecniche di miglioramento della sicurezza estremamente note e indispensabili - la violazione sarebbe stata meno grave. Ma non è stato così.

Il punto è che gli aggressori non hanno bisogno di exploit complessi concatenati per creare un nuovo Stuxnet per violare grandi aziende come Equifax o Quora. Un exploit RCE vecchio di due mesi è sufficiente.

Per aggiungere un po' di speculazione da parte mia, per rispondere alla tua domanda "Perché possono reagire così velocemente" da un'altra angolazione.
Credo che la maggior parte di queste aziende fosse a conoscenza di queste falle di sicurezza. E conoscere le vulnerabilità della propria rete rende molto più semplice l'attività forense.

Sì, l'Intrusion Detection e la Digital Forensics hanno componenti che possono essere automatizzati per un rapido triage su installazioni su larga scala in infrastrutture tecnologiche molto diverse e organizzazioni globali complesse.

La risposta agli incidenti e la gestione delle crisi sono più difficili e spesso includono l'obbligo di staccare la spina o di andare offline, soprattutto durante un'intrusione di livello root (ovvero a livello di amministratore, spesso descritta come acquisizione del dominio o compromissione dell'amministratore del dominio). In passato la messa offline era più comune, ma le piattaforme di Digital Forensics and Incident Response (DFIR) hanno iniziato a cambiare intorno al 2012.

Ciò che queste nuove piattaforme DFIR hanno aggiunto, in termini di tecnologia dirompente, è stata la capacità di eseguire il Live Response. Prima del supporto delle piattaforme commerciali per il Live Response (ad esempio FireEye HX, originariamente chiamato MIR o Mandiant Incident Response, CbER, Crowdstrike Falcon, ecc.), la maggior parte delle piattaforme DFIR si concentrava sulla Digital Forensics (ad esempio EnCase, utilizzato dalle aziende, o FTK, utilizzato dai governi, in particolare dall'FBI) o sull'Incident Response (ad esempio Belkasoft RAM Capturer o Sysinternals Autoruns), non su entrambe. Un'eccezione è stata la piattaforma F-Response, che ha iniziato a essere distribuita intorno al 2009 (un'adozione precoce di queste tecniche). Il termine DFIR non è stato utilizzato o diffuso almeno fino al 2013, quindi si tratta di un concetto ancora molto nuovo per la maggior parte dei negozi di cybersecurity/Infosec e IT.

Più di recente, sono nate nuove soluzioni commerciali (ad esempio, Velocidex) intorno alle piattaforme DFIR Live Response (spesso basate su soluzioni open-source gratuite, come quella che in passato era nota come Google Rekall, un fork del Volatility Framework, anch'esso gratuito/open-source). Tuttavia, ci sono anche molte soluzioni che cercano di indicare che condividono somiglianze con queste piattaforme, anche se sono più vicine alle classiche piattaforme Anti-Virus (AV). La terminologia ufficiale è Endpoint Protection Platform (EPP), con soluzioni di SOPHOS, Symantec e Mcafee. Tuttavia, alcune piattaforme che sono chiaramente EPP (ad esempio, Cylance, SentinelOne) cercano di utilizzare la terminologia NG-AV (per gli antivirus di nuova generazione) o, peggio, Endpoint Detection and Response (EDR), che rovina ciò che le piattaforme DFIR Live Response hanno originariamente cercato di interrompere.

Le piattaforme EDR commerciali sono spesso focalizzate più sul rilevamento che sulla risposta, il che significa che sono più vicine all'AV classico. Una vera piattaforma di risposta in tempo reale consentirà almeno due funzionalità primarie:

  1. Eseguire l'isolamento dell'host, ossia la capacità di un sistema di andare offline consentendo ai soccorritori di accedere all'host in remoto.
  2. Fornire un dump della memoria dell'intero sistema da un host isolato su una varietà di sistemi operativi senza degrado delle prestazioni e mantenendo una stabilità superiore. Se un kernel va in panico (cioè l'intero sistema operativo si blocca), spesso la capacità di conservare un'acquisizione di memoria viene completamente annullata. Il dump della memoria deve includere i bit di ordine superiore che contengono l'MBR o il GPT del sistema, al fine di rilevare e rispondere a potenziali rootkit nel firmware, come BIOS o UEFI. Spesso questo significa che la piattaforma installa un driver, e i driver devono essere codificati con cura per evitare crash del sistema.

Pochissimi fornitori di servizi DFIR mantengono il talento e la pipeline di automazione necessari per eseguire un triage rapido in installazioni su larga scala, anche quando hanno implementato con successo una piattaforma EDR o DFIR Live Response per i loro clienti, migliorandola e integrandola, durante l'incidente o la crisi (post-breach), o prima (pre-breach). Tra questi, The Cowen Group, Mandiant di FireEye, Crowdstrike, Verizon Business e Stroz Friedberg. Ci sono alcuni nuovi operatori, come Endgame, e alcuni legati a settori specifici, come Trustwave nel settore delle carte di pagamento. I loro nomi compaiono nelle ultime notizie sulle principali violazioni di dati.

In molti casi, l'organizzazione che ha subito la violazione dei dati più grave aveva già in carico uno di questi fornitori di servizi DFIR (o un concorrente), il che significa che li pagava mensilmente o annualmente solo per tenere la porta aperta nel caso in cui si verificasse una crisi. A volte si sente parlare di questa offerta specifica come Compromise Assessment. Si tratta sicuramente della crema del raccolto in termini di rilevamento delle intrusioni e analisi forense digitale rapida e di alta qualità!

Gli strumenti (o parti di essi) e le tecniche di questi fornitori di servizi DFIR sono disponibili in libri, risorse e persino soluzioni open-source. Ad esempio, The Cowen Group è legato a TriForce (una tecnica di digital forensics brevettata), FireEye ha FLARE VM, Crowdstrike ha Falcon Orchestrator e VxStream Sandbox, Verizon Business ha rilasciato VERIS e Stroz Friedberg ha il proprio Github con lightgrep e ha acquisito fsrip. Alcune di queste aziende sono state acquisite e altre sono state scorporate.

Non è solo l'industria privata ad aver innovato: è chiaro che gran parte del lavoro di MITRE, CIRCL, CERT-BDF, CERT-Tools, ANSSI-FR e CSE-CST è stato preveggente rispetto a quanto sopra.

Altri sono semplicemente fantastici, come Gransk, PUNCH-Cyber e SkadiVM.



Utilizzate il nostro motore di ricerca

Ricerca
Generic filters

Lascia un commento

Il tuo indirizzo email non sarà pubblicato.