Con il termine Memory Forensics si intende lo studio dei dati catturati dalla memoria di un sistema target. Si tratta di un settore relativamente nuovo della Digital Forensics, la branca della scienza forense che si occupa della preservazione, dell’identificazione e dell’investigazione delle informazioni trovate all’interno dei dispositivi digitali, al fine di produrre evidenze che riguardano crimini informatici.
L’acquisizione della memoria dei dispositivi e la sua analisi viene effettuata nell’ambito della Digital Forensics già da diversi anni, sicuramente da quando l’approccio “pull the plug” è stato abbandonato a favore della ricerca anche delle evidenze volatili. Inizialmente l’analisi della memoria era limitata alla ricerca di stringhe di interesse, ma nel frattempo le strutture presenti all’interno della memoria sono diventate più chiare ed è ora possibile estrarre dalle immagini della memoria una quantità notevole di informazioni.
Qualsiasi cosa che avviene all’interno dei sistemi passa, infatti, dalla RAM e può essere mantenuta in memoria anche molto tempo dopo che è avvenuta. Possiamo quindi trovare all’interno della RAM una quantità immensa di informazioni: su processi e thread in esecuzione, su socket di rete, indirizzi IP, chiavi di cifratura, password, clipboard e malware (rootkit incluso).
La memoria è quindi il posto migliore dove cercare attività di software malevolo: il malware cerca infatti di nascondersi, ma deve essere eseguito. È possibile analizzare le attività recenti svolte sul sistema e collezionare evidenze che non possono essere trovate altrove, come malware residenti solo in memoria (malware fileless), attività che non lasciano traccia sul sistema (ad esempio, la navigazione in incognito) e chat history. Anche le chiavi di registro di Windows possono essere modificate soltanto in memoria.
Il focus di questo articolo sarà quindi l’utilizzo della Memory Forensics nell’ambito della risposta agli incidenti, piuttosto che alla raccolta di informazioni relative a crimini informatici da utilizzare in tribunale. Le tecniche utilizzate sono le stesse, semplicemente non insisteremo tanto sulla modalità di raccolta e di preservazione delle evidenze.
Le evidenze trovate all’interno della RAM possono essere correlate con le evidenze trovate mediante l’ispezione degli hard disk o dall’analisi dei pacchetti di rete catturati, al fine di avere un quadro completo di quanto successo.
Indice degli argomenti
Le fasi di un processo di Memory Forensics
Possiamo dividere il processo di Memory Forensics in diverse fasi, in maniera analoga a quanto avviene per l’analisi di hard disk o altri dispositivi non volatili:
- acquisizione della memoria: se siamo in presenza di un sistema live, l’acquisizione riguarda la memoria fisica (dalla RAM) e il contenuto di file di paging o swap. Tuttavia, può essere possibile acquisire la memoria anche di sistemi che non sono in esecuzione, per esempio attraverso l’acquisizione del file d’ibernazione creato quando il sistema è stato sospeso o ibernato (%SystemDrive%\hiberfil.sys in Windows). È inoltre possibile trovare file di paging (%SystemDrive%\pagefile.sys) e di swap (%SystemDrive%\swapfile.sys). Infine, è possibile trovare all’interno del sistema i file di dump (%WinDir%\MEMORY.DMP) generati in caso di crash del sistema;
- collocare quanto acquisito in un contesto: dobbiamo avere un’idea chiara dell’obiettivo dell’indagine, di quale versione di sistema operativo sta girando sul sistema, di dove sono posizionati i vari oggetti di interesse;
- analisi dei risultati: l’ultima fase del processo ha lo scopo di comprendere il significato dei dati raccolti e di recuperare le evidenze.
Rispetto all’analisi di dispositivi non volatili, l’analisi della memoria è più complicata. I dati non sono infatti in un formato progettato per essere estratto e compreso, ma per essere eseguito efficacemente. Inoltre, la struttura dei dati all’interno della memoria è dipendente dal sistema operativo utilizzato, e anche dalla versione (ad esempio, service pack di Windows o major release del kernel di Linux).
Per tale motivo prima di procedere all’analisi occorre verificare che il tool di analisi che si intende utilizzare supporti la versione del sistema operativo del sistema target.
I tool per l’acquisizione della memoria
L’acquisizione della memoria dovrebbe essere effettuata nella maniera più pulita possibile, ma questo è molto più difficile rispetto all’acquisizione dell’immagine di un hard disk, in quanto il tool utilizzato per l’acquisizione della memoria deve essere eseguito all’interno del sistema di cui si vuole acquisire la memoria, cambiando i dati raccolti mentre li colleziona.
Sui sistemi Windows ci sono diversi tool che permettono l’acquisizione della memoria, ma tutti necessitano di un driver che acceda alla memoria attraverso il kernel del sistema operativo. Il tool di acquisizione carica tale driver e, attraverso di esso, accede alla memoria e scarica il contenuto in un file RAW. Indipendentemente dal tool utilizzato per effettuare l’acquisizione della memoria, ognuno dei principali tool di analisi sarà in grado di analizzarlo.
Di seguito si forniscono alcuni tool che permettono l’estrazione della memoria su sistemi Windows live:
- Winpmem: tool opensource parte del tool di analisi Rekall;
- Mandiant Redline: tool freeware che permette l’acquisizione a partire da un dispositivo removibile. Contiene anche un tool basato su GUI per l’analisi della RAM;
- F-Response: tool commerciale che permette l’acquisizione della memoria da sistemi live da remoto;
- Bekasoft Live RAM Capturer: tool freeware che per mette l’acquisizione della memoria anche in presenza di meccanismi di anti-debuggin e anti-dumping.
Volatility: il tool più usato per l’analisi della memoria
Volatility è probabilmente il tool più utilizzato e potente per l’analisi della memoria. Si tratta di un tool open source (rilasciato con licenza GPL-2) a riga di comando, scritto in Python; quest’ultima caratteristica ha come conseguenza il fatto che Volatility può essere utilizzato su macchine di analisi basate su Windows, Linux o Mac.
La potenza di Volatility deriva dal fatto di essere un framework estensibile e basato su plugin: per questo motivo vengono continuamente introdotte nuove funzionalità da parte di sviluppatori di tutto il mondo. L’ultima versione disponibile al momento è la 2.6, mediante la quale è possibile effettuare su immagini di memoria provenienti dai seguenti sistemi operativi:
- 64-bit Windows Server 2016
- 64-bit Windows Server 2012 and 2012 R2
- 32- and 64-bit Windows 10
- 32- and 64-bit Windows 8, 8.1, and 8.1 Update 1
- 32- and 64-bit Windows 7 (all service packs)
- 32- and 64-bit Windows Server 2008 (all service packs)
- 64-bit Windows Server 2008 R2 (all service packs)
- 32- and 64-bit Windows Vista (all service packs)
- 32- and 64-bit Windows Server 2003 (all service packs)
- 32- and 64-bit Windows XP (SP2 and SP3)
- 32- and 64-bit Linux kernels from 2.6.11 to 4.2.3
- 32-bit 10.5.x Leopard (the only 64-bit 10.5 is Server, which isn’t supported)
- 32- and 64-bit 10.6.x Snow Leopard
- 32- and 64-bit 10.7.x Lion
- 64-bit 10.8.x Mountain Lion (there is no 32-bit version)
- 64-bit 10.9.x Mavericks (there is no 32-bit version)
- 64-bit 10.10.x Yosemite (there is no 32-bit version)
- 64-bit 10.11.x El Capitan (there is no 32-bit version)
- 64-bit 10.12.x Sierra (there is no 32-bit version)
Volatility non permette di acquisire la memoria da un sistema target: con uno dei tool elencati al paragrafo precedente è possibile estrarre un’immagine della memoria del sistema target, che può essere poi analizzata attraverso l’uso di Volatility.
La maggior parte dei comandi base di Volatility avrà un formato di questo tipo:
python vol.py -f [image] [plugin] –profile=[PROFILE]
Volatility si aspetta quindi in input:
- l’immagine della memoria del dispositivo (opzione -f);
- la versione di sistema operativo in uso sul sistema target, ovvero il profilo da utilizzare (opzione -profile);
- che tipo di informazione estrarre dalla memoria, ovvero il plugin da utilizzare.
L’esecuzione di Volatility con l’opzione -info permette di ottenere l’elenco dei profili e dei plugin supportati dalla versione di Volatility che stiamo utilizzando:
$ python vol.py –info
Volatility Foundation Volatility Framework 2.6
Profiles
——–
VistaSP0x64 – A Profile for Windows Vista SP0 x64
VistaSP0x86 – A Profile for Windows Vista SP0 x86
VistaSP1x64 – A Profile for Windows Vista SP1 x64
VistaSP1x86 – A Profile for Windows Vista SP1 x86
VistaSP2x64 – A Profile for Windows Vista SP2 x64
VistaSP2x86 – A Profile for Windows Vista SP2 x86
Win10x64 – A Profile for Windows 10 x64
Win10x64_10586 – A Profile for Windows 10 x64 (10.0.10586.306 / 2016-04-23)
Win10x64_14393 – A Profile for Windows 10 x64 (10.0.14393.0 / 2016-07-16)
Win10x86 – A Profile for Windows 10 x86
Win10x86_10586 – A Profile for Windows 10 x86 (10.0.10586.420 / 2016-05-28)
Win10x86_14393 – A Profile for Windows 10 x86 (10.0.14393.0 / 2016-07-16)
Win2003SP0x86 – A Profile for Windows 2003 SP0 x86
Win2003SP1x64 – A Profile for Windows 2003 SP1 x64
Plugins
——-
amcache – Print AmCache information
apihooks – Detect API hooks in process and kernel memory
atoms – Print session and window station atom tables
atomscan – Pool scanner for atom tables
auditpol – Prints out the Audit Policies from HKLM\SECURITY\Policy\PolAdtEv
bigpools – Dump the big page pools using BigPagePoolScanner
bioskbd – Reads the keyboard buffer from Real Mode memory
cachedump – Dumps cached domain hashes from memory
callbacks – Print system-wide notification routines
clipboard – Extract the contents of the windows clipboard
cmdline – Display process command-line arguments
cmdscan – Extract command history by scanning for _COMMAND_HISTORY
connections – Print list of open connections [Windows XP and 2003 Only]
connscan – Pool scanner for tcp connections
L’opzione -h, infine, può essere utilizzata per conoscere i dettagli sull’uso di uno specifico plugin:
$ vol.py pslist -h
———————————
Module PSList
———————————
Print all running processes by following the EPROCESS lists
Memory Forensics: come avviene l’analisi della memoria
Riferendoci a sistemi Windows, la struttura dati da cui partire per dare un senso ai dati presenti in un’immagine della memoria è il Kernel Debugger Datablock (KDBG), che contiene un puntatore alla lista dei processi. Fino a Windows XP il KDBG poteva essere individuato facilmente attraverso il Kernel Processor Control Region (KPCR), che contiene un puntatore al KDBG e che era conservato in un offset fisso all’interno della memoria. Nelle versioni di Windows successive il KDBG può essere individuato attraverso signature.
Una volta individuato il KDBG, attraverso il puntatore PsActiveProcessHead possiamo arrivare all’EPROCESS , una doppia lista dei processi in esecuzione sul sistema, ognuno dei quali ha il suo Process Environment Block (PEB), che contiene molte informazioni relative al processo. Ogni PEB punta a sua volta al Virtual Address Descriptor (VAD), un albero che tiene traccia di tutte le sezioni di memoria assegnate al processo. Attraverso il VAD possiamo individuare eventuali discrepanze fra il contenuto nelle varie sezioni di memoria di un processo e quanto appare dalle varie liste: un’eventuale discrepanza potrebbe essere sintomo della presenza di un software malevolo.
L’immagine seguente visualizza graficamente quanto illustrato.
$ vol.py -f mem.img imageinfo
Volatility Foundation Volatility Framework 2.6
INFO : volatility.debug : Determining profile based on KDBG search…
Suggested Profile(s) : Win7SP1x86_23418, Win7SP0x86, Win7SP1x86
AS Layer1 : IA32PagedMemoryPae (Kernel AS)
AS Layer2 : FileAddressSpace (/mem.img)
PAE type : PAE
DTB : 0x185000L
KDBG : 0x82d29c28L
Number of Processors : 1
Image Type (Service Pack) : 1
KPCR for CPU 0 : 0x82d2ac00L
KUSER_SHARED_DATA : 0xffdf0000L
Image date and time : 2012-04-06 20:52:46 UTC+0000
Image local date and time : 2012-04-06 16:52:46 -0400
Il profilo da utilizzare, basato sulla ricerca del KDBG, è Win7SP1x86: utilizzeremo tale informazione con i prossimi plugin.
Un buon punto da cui cominciare è l’analisi dei processi in esecuzione sul sistema target, al fine di evidenziare eventuali processi che presentano eventuali anomalie.
A tal fine utilizziamo il plugin pslist, il quale restituisce l’elenco dei processi in esecuzione e, per ognuno di essi, le seguenti informazioni:
- Virtual offset dell’EPROCESS block
- Process name
- Processe Identifier (PID)
- Parent PID
- Numero di threads
- Numero di handles
- Start time
- Exit time
Di seguito un esempio di utilizzo del plugin pslist:
$ vol.py -f mem.img –profile=Win7SP1x86 pslist
Volatility Foundation Volatility Framework 2.6
Offset(V) Name PID PPID Thds Hnds Sess Wow64 Start Exit
—————————————————————————-
0x85c50958 System 4 0 105 532 —— 0 2012-04-04 11:47:29
0x86ecaa70 smss.exe 280 4 3 32 —— 0 2012-04-04 11:47:29
0x86cfa540 csrss.exe 412 404 9 756 0 0 2012-04-04 11:47:41
0x87d85d40 wininit.exe 464 404 3 74 0 0 2012-04-04 11:47:44
0x86e7f030 csrss.exe 472 456 9 75 1 0 2012-04-04 11:47:44
0x87d8fd40 winlogon.exe 520 456 3 91 1 0 2012-04-04 11:47:44
0x87f68030 services.exe 564 464 7 243 0 0 2012-04-04 11:47:45
0x87f79600 lsass.exe 592 464 8 888 0 0 2012-04-04 11:47:46
0x87f8c030 lsm.exe 600 464 10 248 0 0 2012-04-04 11:47:46
0x87fc5590 svchost.exe 704 564 11 358 0 0 2012-04-04 11:47:48
0x87fee6d0 svchost.exe 780 564 6 277 0 0 2012-04-04 11:47:51
0x88000d40 svchost.exe 820 564 18 469 0 0 2012-04-04 11:47:51
0x8800e178 LogonUI.exe 880 520 7 197 1 0 2012-04-04 11:47:51
0x880308e8 svchost.exe 920 564 18 495 0 0 2012-04-04 11:47:51
0x88047a58 svchost.exe 944 564 31 1213 0 0 2012-04-04 11:47:52
0x880462b8 svchost.exe 1032 564 17 394 0 0 2012-04-04 11:47:52
0x880a0758 svchost.exe 1184 564 20 634 0 0 2012-04-04 11:48:00
0x88070d40 spoolsv.exe 1308 564 13 328 0 0 2012-04-04 11:48:03
0x880e7030 svchost.exe 1344 564 17 295 0 0 2012-04-04 11:48:03
0x88120658 armsvc.exe 1456 564 4 61 0 0 2012-04-04 11:48:04
0x88145b38 FireSvc.exe 1516 564 22 355 0 0 2012-04-04 11:48:05
0x881b8030 McSACore.exe 1604 564 11 199 0 0 2012-04-04 11:48:08
0x881b4900 FireTray.exe 1624 1516 0 — 0 0 2012-04-04 11:48:09 2012-04-04 11:48:10
0x881dd770 FrameworkServi 1740 564 31 426 0 0 2012-04-04 11:48:10
0x8820bd40 VsTskMgr.exe 1796 564 21 365 0 0 2012-04-04 11:48:11
0x88227358 mfevtps.exe 1824 564 5 171 0 0 2012-04-04 11:48:12
0x8821a660 mfeann.exe 1872 1796 14 181 0 0 2012-04-04 11:48:12
0x88220d40 conhost.exe 1880 412 2 30 0 0 2012-04-04 11:48:12
0x88235cf8 VMwareService. 1964 564 7 192 0 0 2012-04-04 11:48:14
0x8824cd40 naPrdMgr.exe 200 704 8 252 0 0 2012-04-04 11:48:15
0x88263648 mcshield.exe 332 564 28 459 0 0 2012-04-04 11:48:15
0x8827d9f0 mfefire.exe 456 564 7 108 0 0 2012-04-04 11:48:23
0x88295900 VMUpgradeHelpe 888 564 4 87 0 0 2012-04-04 11:48:24
0x8842a4b8 svchost.exe 2980 564 12 198 0 0 2012-04-04 11:50:42
0x885561f8 SearchIndexer. 3092 564 14 992 0 0 2012-04-04 11:50:46
0x862709a0 csrss.exe 2132 3112 9 271 2 0 2012-04-04 14:45:30
0x8617bd40 winlogon.exe 3836 3112 3 112 2 0 2012-04-04 14:45:30
0x85dbcb48 taskhost.exe 1108 564 9 290 2 0 2012-04-04 14:45:43
0x861bb8f0 rdpclip.exe 2408 1184 4 88 2 0 2012-04-04 14:45:43
0x8625b030 dwm.exe 3924 920 3 67 2 0 2012-04-04 14:45:44
0x8622b4b8 explorer.exe 296 2392 22 853 2 0 2012-04-04 14:45:45
0x861d4520 VMwareTray.exe 3780 296 5 65 2 0 2012-04-04 14:45:46
0x861b6518 VMwareUser.exe 3804 296 3 77 2 0 2012-04-04 14:45:46
0x86272d40 UdaterUI.exe 2944 1740 6 109 2 0 2012-04-04 14:49:35
0x863c8030 McTray.exe 2864 2944 23 341 2 0 2012-04-04 14:49:35
0x85f98728 a.exe 3264 3440 0 — 2 0 2012-04-04 14:57:52 2012-04-04 18:40:58
0x85e24030 OSPPSVC.EXE 4040 564 3 134 0 0 2012-04-04 15:42:01
0x861d93a0 cmd.exe 3472 3264 0 — 2 0 2012-04-04 15:47:47 2012-04-04 15:49:07
0x862bfa40 spinlock.exe 3796 3472 0 — 2 0 2012-04-04 15:48:18 2012-04-04 18:43:25
0x8654c4a8 spinlock.exe 1208 3796 0 — 2 0 2012-04-04 15:48:18 2012-04-04 18:43:25
0x860f2578 cmd.exe 208 1208 1 31 2 0 2012-04-04 18:43:24
0x86136a60 conhost.exe 2840 2132 2 28 2 0 2012-04-04 18:43:25
0x864e57c8 PSEXESVC.EXE 2100 564 6 104 0 0 2012-04-04 18:52:11
0x862a4d40 svchost.exe 3612 2100 0 — 0 0 2012-04-04 18:52:11 2012-04-05 13:25:07
0x862bb290 spinlock.exe 2956 2100 1 26 0 0 2012-04-04 18:54:51
0x86383c18 spinlock.exe 1328 2956 2 128 0 0 2012-04-04 18:54:51
0x86d2b578 a.exe 5008 4212 0 — 0 0 2012-04-06 13:19:34 2012-04-06 16:58:26
0x862f9a58 cmd.exe 5192 5008 1 28 0 0 2012-04-06 14:03:11
0x86a1c8b8 conhost.exe 3408 412 2 31 0 0 2012-04-06 14:03:11
0x8649d880 svchost.exe 6404 2100 8 256 0 0 2012-04-06 19:22:20
0x86eeb430 f-response-ent 7776 564 8 75 0 0 2012-04-06 20:34:42
0x85dde298 svchost.exe 5176 564 5 90 0 0 2012-04-06 20:34:44
Osservando l’output dell’esempio mostrato, possiamo constatare la presenza di diversi processi svchost.exe, cosa assolutamente normale. Due di questi hanno però un’anomalia rispetto a tutti gli altri; mentre normalmente il PPID è il processo 564 (services.exe), per i processi 6404 e 3612 il PPID è il processo 2100 (PSEXESVC.EXE). Inoltre, il processo 3612 è terminato.
Altra possibile anomalia è costituita dai processi a.exe, anch’essi terminati, che hanno generato altri processi.
Per visualizzare in maniera più chiara le dipendenze fra i processi, è possibile utilizzare il plugin pstree. Nel nostro caso, limitando l’output ai processi evidenziati sopra, otterremo:
$ vol.py -f mem.img –profile=Win7SP1x86 pstree
Volatility Foundation Volatility Framework 2.6
Name Pid PPid Thds Hnds Time
————————————————– —— —— —— —— —-
0x864e57c8:PSEXESVC.EXE 2100 564 6 104 2012-04-04 18:52:11 UTC+0000
0x862a4d40:svchost.exe 3612 2100 0 — 2012-04-04 18:52:11 UTC+0000
0x8649d880:svchost.exe 6404 2100 8 256 2012-04-06 19:22:20 UTC+0000
0x862bb290:spinlock.exe 2956 2100 1 26 2012-04-04 18:54:51 UTC+0000
0x86383c18:spinlock.exe 1328 2956 2 128 2012-04-04 18:54:51 UTC+0000
0x85f98728:a.exe 3264 3440 0 — 2012-04-04 14:57:52 UTC+0000
0x861d93a0:cmd.exe 3472 3264 0 — 2012-04-04 15:47:47 UTC+0000
0x862bfa40:spinlock.exe 3796 3472 0 — 2012-04-04 15:48:18 UTC+0000
0x8654c4a8:spinlock.exe 1208 3796 0 — 2012-04-04 15:48:18 UTC+0000
0x860f2578:cmd.exe 208 1208 1 31 2012-04-04 18:43:24 UTC+0000
Entrambi i processi anomali che avevamo evidenziato hanno generato processi denominati spinlock.exe, due dei quali ancora in esecuzione al momento dell’acquisizione della memoria.
Altra prova dell’anomalia del processo 6404 la possiamo derivare attraverso l’uso del plugin cmdline, il quale mostra il path di esecuzione da cui è stato avviato il processo.
$ vol.py -f mem.img –profile=Win7SP1x86 cmdline -p 6404
Volatility Foundation Volatility Framework 2.6
************************************************************************
svchost.exe pid: 6404
Command line : “c:\windows\system32\dllhost\svchost.exe”
Normalmente svchost.exe è situato in C:\windows\system32\, come si può vedere dall’output dello stesso plugin utilizzato per uno degli svchost regolari.
$ vol.py -f mem.img –profile=Win7SP1x86 cmdline -p 920
Volatility Foundation Volatility Framework 2.6
************************************************************************
svchost.exe pid: 920
Command line : C:\Windows\System32\svchost.exe -k LocalSystemNetworkRestricted
La nostra piccola analisi ha quindi mostrato la presenza di alcuni processi anomali, il cui comportamento dovrà essere approfondito nel proseguimento dell’analisi della memoria:
- a.exe
- PSEXESVC.exe
- c:\windows\system32\dllhost\svchost.exe
- spinlock.exe
Dopo aver mostrato qualche esempio di identificazione di processi anomali, con l’utilizzo dei plugin pslist e psview e cmdline l’analisi della memoria può continuare attraverso i seguenti step:
- analisi dei process object;
- analisi delle connessioni di rete;
- ricerca di code injection;
- ricerca di rootkit;
- estrazione di eseguibili e driver dalla memoria da analizzare con altri strumenti.
Per ognuna di queste fasi esistono plugin di Volatility dedicati, per i quali si rimanda alla documentazione specifica.
Introduzione a Rekall
Rekall è un altro tool utilizzabile per l’analisi della memoria. Nato da un fork di Volatility, negli ultimi anni è diventato molto popolare.
Le principali differenze rispetto a Volatility sono le seguenti:
- riconosce automaticamente (a runtime) il profilo;
- è maggiormente orientato alle performance;
- comprende tool per l’acquisizione della memoria di diversi sistemi operativi;
- può essere utilizzato come libreria e quindi inserito all’interno di un altro progetto;
- comprende una shell attraverso la quale è possibile interagire direttamente con il tool.
Può tuttavia essere utilizzato con la stessa modalità di Volatility, fornendo sulla linea di comando l’immagine della memoria (opzione -f) e il plugin da utilizzare, ma non il profilo:
rekall -f <memory_image> <volatility_plugin>
Conclusioni
Nonostante questo articolo abbia per forza di cose solo scalfito l’argomento, spero sia riuscito nell’intento di fare intuire le grandi potenzialità delle tecniche di Memory Forensics, non solo nell’ambito forense, ma anche nel processo di gestione degli incidenti.
La Memory Forensics, come più in generale la Digital Forensics, è un tema ancora poco conosciuto dalle aziende, in quanto spesso considerato appannaggio delle forze dell’ordine, anche se negli ultimi anni le cose stanno cambiando. Le tecniche utilizzate richiedono una certa competenza che non è detto che le aziende debbano avere in casa; l’invito è quello di prepararsi per tempo, sviluppando competenze all’interno dell’azienda o individuandole all’esterno, definendo policy e procedure, dotandosi di strumenti che permettano all’azienda di essere pronta in caso di incidente, fosse anche un incidente minore.
Infine, per chi volesse approfondire l’uso delle tecniche illustrate, è possibile scaricare una lista contenente diversi campioni di memoria scaricabili liberamente e utilizzabili a scopo di test.
