Cap 09 - Implementing Controls to Protect Assets

Comparing Physical Security Controls

#

mindmap
  root((Physical
Security Controls))
    Access Badges
      smart card
      proximity card
      MAC bypass risk
    Personnel
      guards
      two-person integrity
    Video Surveillance
      IP cameras
      motion recognition
      retention policies
    Sensors
      noise motion infrared
      microwave
      ultrasonic
    Fencing Lighting Alarms
      deterrent preventive
      CCTV + lighting combo
    Barricades
      bollards
      vehicle barriers
    Access Control Vestibules
      mantrap
      piggybacking tailgating

La sicurezza fisica è il primo layer di difesa: senza di essa, qualsiasi controllo logico (firewall, crittografia, MFA) può essere aggirato fisicamente rubando un laptop, un server o un disco. Il principio è lo stesso della defense in depth: nessun singolo controllo basta, si stratificano.

Access Badges

#

Un access badge (badge di accesso) è un dispositivo fisico che autentica l'identità di una persona e le consente di entrare in aree riservate. Esistono due tecnologie principali:

MAC bypass (MAB - MAC Authentication Bypass): in alcuni sistemi di controllo accessi fisici collegati alla rete, un device non autenticato può essere autorizzato basandosi solo sul suo MAC address. E' una modalità di fallback rischiosa: i MAC address si falsificano facilmente (MAC spoofing, vedi Wireless Attacks). Da usare solo quando l'alternativa è bloccare device legacy che non supportano 802.1X.

Increasing Security with Personnel

#

Il personale fisicamente presente è uno dei controlli di sicurezza più efficaci: una guardia può riconoscere situazioni anomale, rispondere a incidenti e deterrere attaccanti con la sola presenza.

Guards (guardie): pattuglie fisiche che monitorano aree, controllano i badge all'ingresso, verificano le identità e rispondono agli allarmi. Possono essere guardie interne o fornite da un vendor esterno di sicurezza.

Two-person integrity (o two-person control): richiede che due persone autorizzate siano presenti per eseguire operazioni critiche. Elimina il rischio di un singolo punto di compromissione umano (insider threat) su operazioni ad alto rischio come l'accesso a vault fisici, l'accesso a sistemi nucleari o la manipolazione di backup crittografati.

Dev parallel: il two-person integrity è l'equivalente fisico del peer review obbligatorio prima del merge su main: nessuno può fare push direttamente al branch di produzione da solo. Stessa logica, layer diverso.

Monitoring Areas with Video Surveillance

#

Le telecamere di sorveglianza (CCTV - Closed-Circuit Television o IP cameras) registrano le aree fisiche per deterrenza e investigazione post-incidente.

Le telecamere coprono sia il ruolo deterrente (chi sa di essere osservato si comporta diversamente) sia il ruolo detective (forniscono evidenze dopo un incidente, vedi Detective Controls).

Sensors

#

I sensori rilevano condizioni ambientali o movimenti e triggertano allarmi o sistemi di risposta automatica:

I sensori si combinano con telecamere e guardie: il sensore triggera un alert, la telecamera inquadra l'area, la guardia verifica. E' un esempio di controllo automatico + umano in sequenza.

Fencing, Lighting, and Alarms

#

Fencing (recinzione): barriera fisica perimetrale. Tipicamente alta abbastanza da rendere difficile la scalata (minimum 2,4 m, spesso con filo spinato o anti-arrampicata in cima). E' un controllo preventive e deterrent combinato (vedi Control Types).

Lighting (illuminazione): un'area ben illuminata riduce i nascondigli, aumenta la visibilità delle telecamere e deterisce gli attaccanti. L'illuminazione notturna combinata con CCTV è lo standard per perimetri di data center e edifici corporate.

Alarms (allarmi): rilevano intrusioni (sensori perimetrali, sensori sulle porte) e notificano personale di sicurezza o forze dell'ordine. Gli allarmi si classificano come detective controls: non prevengono l'intrusione, ma la rilevano e triggertano una risposta.

Securing Access with Barricades

#

Le barricades (barriere fisiche) proteggono strutture da attacchi con veicoli e accessi non autorizzati. Il tipo più comune sono i bollards: pali di acciaio o cemento interrati che bloccano fisicamente i veicoli ma consentono il passaggio pedonale. Li trovi davanti ai data center, ai parlamenti, agli aeroporti. Funzione: impedire che un veicolo (accidentale o intenzionale) possa sfondare l'ingresso di una struttura.

Access Control Vestibules

#

Un access control vestibule (o mantrap) è un'area di transizione tra due zone a diverso livello di sicurezza: una persona entra in una piccola anticamera, la porta esterna si chiude, e solo dopo aver verificato l'identità si apre la porta interna. Impedisce il tailgating e il piggybacking:

Da ricordare: il mantrap/vestibule previene il tailgating impedendo l'accesso fisico di più persone con una sola autenticazione. Un bollard è una barriera fisica contro i veicoli. L'illuminazione è sia deterrent che supporto alle telecamere. Il two-person integrity richiede due persone autorizzate per operazioni critiche.

Asset Management

#

mindmap
  root((Asset
Management))
    Hardware Asset Management
      inventory
      lifecycle tracking
        procurement to disposal
    Software Asset Management
      license compliance
      EOL tracking
    Data Asset Management
      classification
        public confidential
      DLP
    Platform Diversity
      reduces single vendor risk
        monoculture risk

L'asset management (gestione degli asset) è il processo di identificare, tracciare e gestire gli asset di un'organizzazione per tutta la loro vita utile (lifecycle), dalla fase di acquisizione fino alla dismissione. Senza asset management, un'organizzazione non sa esattamente cosa possiede, dove si trova, e quindi non può proteggerlo.

Hardware Asset Management

#

Il hardware asset management tiene traccia di tutto l'hardware fisico: server, workstation, laptop, stampanti, switch, router, access point, telefoni. Un inventario hardware aggiornato è il presupposto di qualsiasi altra attività di sicurezza: non puoi patchare quello che non sai di avere, e non puoi proteggere un sistema che non sai dove si trova.

L'inventario traccia informazioni come:

• Identificatore univoco dell'asset (numero seriale, asset tag)
• Posizione fisica
• Utente assegnato
• Data di acquisizione e data di dismissione prevista

Il lifecycle tracking copre l'intero ciclo: acquisizione, configurazione, deployment, manutenzione, e infine dismissione sicura (disposal), che include la sanitizzazione dei dati prima che l'hardware esca dall'organizzazione (vedi Decommissioning and Disposal).

Software Asset Management

#

Il software asset management tiene traccia del software installato, delle licenze acquistate e delle date di End of Life (EOL). Gli obiettivi principali sono:

• License compliance: verificare che ogni installazione del software sia coperta da licenza valida (vedi Software Compliance/Licensing).
• EOL tracking: identificare software che il vendor non supporta più e che quindi non riceve patch di sicurezza (vedi Legacy Systems).
• Unauthorized software detection: identificare software installato senza approvazione (shadow IT) che potrebbe introdurre vulnerabilità.

Dev parallel: nel contesto dev, il software asset management ha il suo equivalente in un file package.json o composer.json come registro di dipendenze: sai esattamente quali librerie usi, in quale versione, e strumenti come Dependabot o Renovate ti avvisano quando una versione è EOL o ha CVE aperte.

Data Asset Management

#

Il data asset management identifica, classifica e protegge i dati dell'organizzazione. La prima domanda è: dove sono i dati? Poi: quanto sono sensibili? La classificazione dei dati (vedi Data Classification) determina i controlli applicati.

Categorie tipiche di classificazione:

• Public: dati che possono essere condivisi liberamente (comunicati stampa, contenuto del sito web pubblico)
• Internal: dati per uso interno, non pubblici ma non critici
• Confidential: dati sensibili (informazioni clienti, contratti)
• Secret/Top Secret (in contesti governativi/militari): massima protezione

Il DLP (Data Loss Prevention) è il controllo tecnico che monitora e blocca la trasmissione non autorizzata di dati classificati (vedi DLP).

Platform Diversity

#

La platform diversity (diversità di piattaforma) è la strategia di usare sistemi operativi, hardware e vendor diversi invece di una singola piattaforma omogenea. L'obiettivo è ridurre il rischio di monoculture: se tutta l'organizzazione usa lo stesso OS, una singola vulnerabilità può compromettere l'intera infrastruttura.

Esempio: un'organizzazione che usa sia Windows che Linux sui server riduce la superficie d'attacco di una singola vulnerabilità critica su Windows: i server Linux non sarebbero impattati. Stessa logica per hardware (non solo un vendor) e browser (non solo Chrome).

Il lato negativo: la complessità operativa aumenta (competenze diverse, strumenti diversi, patch management più complesso).

Da ricordare: l'asset management copre hardware (lifecycle), software (licenze, EOL), e dati (classificazione, DLP). La platform diversity riduce il rischio di monoculture ma aumenta la complessità.

Physical Attacks

#

mindmap
  root((Physical
Attacks))
    Card Skimming
      reads card data
        ATM POS terminal
    Card Cloning
      duplicates the card
        RFID proximity card
    Brute Force
      physical force
        locks doors
    Environmental
      HVAC manipulation
        temperature humidity
      power attacks

Gli attacchi fisici mirano direttamente all'hardware, ai sistemi fisici o all'ambiente in cui operano. Spesso precedono o accompagnano attacchi logici.

Card Skimming and Card Cloning

#

Card skimming: lettura non autorizzata dei dati da una card (carta di credito, badge RFID). L'attaccante installa un dispositivo reader nascosto su un ATM, un terminale POS o un lettore di badge legittimo: quando la vittima usa la card, il dispositivo legge e registra i dati della banda magnetica o del chip RFID.

Card cloning: duplicazione di una card a partire dai dati rubati con lo skimming. Con i dati della banda magnetica, l'attaccante scrive una card clone che funziona come l'originale. Per le proximity card RFID, dispositivi economici (es. ACR122U) possono clonare badge di building access in pochi secondi a distanza ravvicinata (vedi RFID Attacks).

Il contromisure: smart card con crittografia (più difficili da clonare della sola banda magnetica), MFA fisico (badge + PIN), ispezioni periodiche dei reader per rilevare skimmer nascosti.

Brute Force Attacks

#

Nel contesto fisico, un brute force attack (attacco a forza bruta) è l'uso della forza fisica per superare misure di sicurezza: forzare una serratura, sfondare una porta, rompere un lucchetto. Non è una tecnica sofisticata, ma è efficace contro controlli fisici deboli.

Contromisure: serrature di qualità (high-security locks), porte rinforzate, rilevatori di intrusione (sensori di vibrazione/impatto), guardie.

Environmental Attacks

#

Gli environmental attacks (attacchi ambientali) mirano a compromettere i sistemi manipolando le condizioni fisiche dell'ambiente in cui operano:

Contromisure: controllo degli accessi fisici all'HVAC, ridondanza energetica (UPS, generatori), monitoraggio della temperatura (alert automatici), separazione delle infrastrutture critiche.

Da ricordare: card skimming = lettura non autorizzata dei dati della card. Card cloning = duplicazione della card con i dati rubati. Brute force fisico = forza fisica su serrature/porte. Environmental attacks = compromissione tramite ambiente (temperatura, alimentazione, HVAC).

Adding Redundancy and Fault Tolerance

#

mindmap
  root((Redundancy
and Fault Tolerance))
    Single Point of Failure
      SPOF elimination goal
    Disk Redundancy
      RAID 0 no redundancy
      RAID 1 mirror
      RAID 5 parity
      RAID 6 double parity
      RAID 10 mirror plus stripe
    Server HA
      Active Active
      Active Passive
      Load Balancers
    NIC Teaming
      multiple NICs
        bandwidth + failover
    Power
      UPS
      Generators
      PDU

La redundancy (ridondanza) e la fault tolerance (tolleranza ai guasti) sono strategie che garantiscono la continuità operativa eliminando o minimizzando i single point of failure (SPOF): punti in cui un singolo guasto causa l'interruzione dell'intero servizio.

Single Point of Failure

#

Un SPOF (Single Point of Failure) è un componente il cui guasto causa il fallimento dell'intero sistema. Eliminare i SPOF è l'obiettivo primario della ridondanza.

Esempi di SPOF comuni:

• Un singolo disco su cui girano tutti i dati (senza RAID)
• Un singolo switch che connette tutti i server
• Un singolo ISP per la connettività internet
• Un singolo alimentatore in un server critico
• Un singolo datacenter in una sola città

La ridondanza aggiunge componenti di backup che entrano in funzione quando il componente primario fallisce, eliminando (o riducendo) il downtime.

Disk Redundancies

#

Il RAID (Redundant Array of Independent Disks) combina più dischi fisici per migliorare performance, ridondanza o entrambe. I livelli principali testati all'esame:

Da ricordare: RAID non sostituisce i backup. RAID protegge da guasti hardware del disco, non da cancellazione accidentale, ransomware, o corruzione logica dei dati. Un ransomware cifra tutti i file accessibili: se il RAID è montato, viene cifrato anche lui.

Server Redundancy and High Availability

#

La high availability (HA) garantisce che i servizi siano disponibili continuamente, eliminando il downtime causato da guasti hardware o software. Si ottiene con cluster di server in configurazione attiva.

Active/Active Load Balancers

#

In una configurazione active/active, tutti i server nel cluster sono operativi e gestiscono traffico contemporaneamente. Il load balancer distribuisce le richieste tra tutti i server attivi:

Client → Load Balancer → Server A (attivo, 33% del traffico)
                       → Server B (attivo, 33% del traffico)
                       → Server C (attivo, 33% del traffico)

Se un server fallisce, il load balancer reindirizza automaticamente il suo traffico agli altri. Vantaggio: massimo utilizzo delle risorse e migliore performance. Svantaggio: quando un nodo fallisce, il traffico si distribuisce su meno nodi (potenziale sovraccarico se non dimensionato correttamente).

Active/Passive Load Balancers

#

In una configurazione active/passive, solo alcuni server gestiscono il traffico (active); gli altri sono in standby (passive) e non ricevono traffico finché il primario non fallisce:

Client → Load Balancer → Server A (attivo, gestisce tutto)
                       → Server B (passivo, standby)

Se il server A fallisce, il load balancer promuove il server B ad active. Vantaggio: il server passivo è sempre pronto e integro. Svantaggio: le risorse del server passivo sono sprecate in condizioni normali.

Dev parallel: nelle architetture cloud è la stessa logica dei multi-region deployment: active/active = due region che gestiscono entrambe il traffico (es. eu-west-1 + us-east-1 con Route53 latency-based routing); active/passive = una region primaria, una in standby che prende il traffico solo se la primaria è down (failover routing).

NIC Teaming

#

Il NIC teaming (chiamato anche link aggregation o bonding) combina più NIC (Network Interface Card) su un singolo server in un'unica interfaccia logica. Offre due benefici:

• Fault tolerance: se una NIC o il cavo collegato fallisce, le altre continuano a funzionare senza interruzione del servizio.
• Increased bandwidth: il traffico viene distribuito su tutte le NIC attive, sommando la loro banda (es. 4x 1Gbps NIC = fino a 4Gbps effettivi).

Lo standard IEEE è il 802.3ad (LACP - Link Aggregation Control Protocol): richiede il supporto anche sullo switch a cui il server è connesso.

Power Redundancies

#

I sistemi critici richiedono ridondanza anche nell'alimentazione elettrica:

Da ricordare: RAID 1 = mirror (2 dischi identici). RAID 5 = parità distribuita (min 3 dischi, tollera 1 guasto). RAID 6 = doppia parità (min 4 dischi, tollera 2 guasti). RAID 10 = mirror+stripe (min 4 dischi, alta performance E ridondanza). Active/active: tutti i nodi gestiscono traffico. Active/passive: un nodo in standby. UPS = bridging immediato, generatore = continuità prolungata.

Protecting Data with Backups

#

mindmap
  root((Protecting Data
with Backups))
    Backup Media
      tape disk cloud
    Backup Types
      Full
        everything
      Differential
        since last full
      Incremental
        since last backup
    Offline Immutable
      air-gapped
      WORM
    Geographic
      offsite 3-2-1 rule
    Testing
      restoration drills

I backup sono il controllo di sicurezza fondamentale per garantire la recovery dei dati dopo un incidente (ransomware, guasto hardware, cancellazione accidentale, disastro naturale). Un backup non testato non è un backup: è solo una speranza.

Backup Media

#

I backup possono essere salvati su supporti diversi:

La regola 3-2-1 è la best practice per i backup: 3 copie dei dati, su 2 media diversi, con 1 copia offsite (geograficamente separata).

Online Versus Offline Backups

#

Prima di approfondire i tipi di backup, è importante distinguere:

• Online backup: il backup è accessibile dalla rete (NAS, storage condiviso, cloud). Vantaggio: restore rapido. Svantaggio: se un ransomware compromette il sistema, può raggiungere anche i backup online.
• Offline backup: il backup è fisicamente disconnesso (nastro in cassaforte, disco staccato). Non raggiungibile dalla rete. Vantaggio: immune a ransomware e attacchi logici. Svantaggio: restore più lento.

Full Backups

#

Un full backup (backup completo) copia TUTTI i dati selezionati, indipendentemente da quando sono stati modificati. E' il tipo più semplice da capire e da ripristinare: per un restore completo serve solo l'ultimo full backup.

Svantaggi: richiede il tempo e lo spazio maggiore tra tutti i tipi. Per grandi dataset, un full backup giornaliero potrebbe essere impraticabile.

Recovering a Full Backup: il restore richiede solo un singolo set di backup (l'ultimo full). Processo più semplice possibile.

Differential Backups

#

Un differential backup (backup differenziale) copia tutti i dati che sono stati modificati o creati dall'ultimo full backup, indipendentemente da quanti differential backup siano stati eseguiti nel frattempo.

Esempio: full backup domenica. Differential lunedi = tutto ciò che è cambiato da domenica. Differential martedi = tutto ciò che è cambiato da domenica (non solo da lunedi). Ogni differential include sempre tutti i cambiamenti dall'ultimo full.

Order of Recovery for a Full/Differential Backup Set: per il restore completo servono 2 elementi: (1) l'ultimo full backup + (2) l'ultimo differential backup. Il differential martedi contiene già tutto quello che conteneva il differential lunedi, quindi non serve ripristinare il lunedi.

Per restore completo a mercoledi: Full Dom + Differential Mer (2 set). Semplice da ripristinare. Ogni differential cresce nel tempo finche' non si esegue un nuovo full.

Incremental Backups

#

Un incremental backup (backup incrementale) copia solo i dati modificati dall'ultimo backup (full O incrementale). A differenza del differential che guarda sempre all'ultimo full, l'incremental guarda sempre all'ultimo backup di qualsiasi tipo.

Esempio: full domenica. Incrementale lunedi = cambiamenti da domenica. Incrementale martedi = cambiamenti da LUNEDI (non da domenica). Ogni incrementale e' piu' piccolo e veloce del differential corrispondente.

Order of Recovery for a Full/Incremental Backup Set: per il restore completo servono il full + TUTTI gli incrementali in sequenza: (1) full domenica + (2) incrementale lunedi + (3) incrementale martedi + ... Il restore e' piu' complesso e lento: bisogna ripristinare piu' set in sequenza.

Per restore completo a mercoledi: Full Dom + Inc Lun + Inc Mar + Inc Mer (4 set). Piu' complesso, ma ogni backup giornaliero e' piu' veloce e piccolo.

Choosing Full, Incremental or Full/Differential

#

La scelta dipende dal trade-off tra quanto spazio si ha e quanto deve essere veloce il restore. In produzione si combinano spesso: full settimanale + incrementali giornalieri, con un differential a meta' settimana come compromesso.

Offline and Immutable Backups

#

Offline backup (air-gapped): il backup e' fisicamente disconnesso dalla rete. Immune ad attacchi ransomware che tentano di cifrare i backup online. Critico per la recovery da ransomware: senza backup offline, l'unica alternativa e' pagare il riscatto o perdere i dati.

Immutable backup: i dati sono scritti una volta sola e non possono essere modificati o eliminati per un periodo definito. Tecnologia WORM (Write Once, Read Many): originariamente nastri fisici, oggi implementata anche nel cloud (es. AWS S3 Object Lock, Azure Immutable Blob Storage). Un ransomware non puo' cifrare o eliminare backup immutabili.

Replication and Journaling

#

Replication (replica): copia continua dei dati in tempo reale su un secondo sistema (locale o geograficamente separato). A differenza del backup, la replica e' sincrona o quasi-sincrona: ogni scrittura viene immediatamente duplicata. Garantisce un RPO (Recovery Point Objective) vicino a zero, ma se un ransomware cifra i dati primari, la replica li cifra immediatamente anche sul secondario.

Journaling: tecnica usata dai filesystem per registrare le modifiche prima di applicarle (write-ahead log). Garantisce l'integrita' del filesystem in caso di crash improvviso (es. blackout durante una scrittura). Non e' un backup: e' una misura di integrita' del filesystem.

Backup Frequency

#

La frequenza dei backup determina il RPO (Recovery Point Objective): quanti dati al massimo si possono perdere in caso di disastro (vedi #Recovery Point Objective). Se si fa un backup ogni 24 ore, l'RPO e' di 24 ore: in caso di disastro si perdono al massimo le ultime 24 ore di dati.

La frequenza dipende da quanto frequentemente cambiano i dati e da quanto perdita di dati e' accettabile per il business.

Testing Backups

#

Errori comuni che si scoprono solo al restore: backup corrotti, procedura di restore non documentata, permessi sbagliati sui file ripristinati, dipendenze non incluse nel backup (configurazioni, certificati, credenziali).

Backups and Geographic Considerations

#

Un backup nello stesso edificio del sistema primario non protegge da disastri fisici (incendio, allagamento, terremoto). Le best practice prevedono:

• Offsite backup: copia dei backup in una location geograficamente separata.
• Distanza minima: sufficiente da non essere colpiti dallo stesso disastro naturale (es. non nella stessa citta' in zona sismica).
• Cloud backup: il cloud e' nativamente offsite, ma richiede verifica della geolocalizzazione dei datacenter del provider e rispetto delle normative sulla residenza dei dati (es. GDPR: dati UE devono rimanere in UE).

Da ricordare: full backup = tutto. Differential = dall'ultimo full, restore con 2 set. Incremental = dall'ultimo backup, restore con N set. Immutable backup = WORM, immune a ransomware. Regola 3-2-1 = 3 copie, 2 media, 1 offsite. Testare i backup periodicamente.

Comparing Business Continuity Elements

#

mindmap
  root((Business
Continuity))
    BIA
      identifies critical processes
        RTO RPO
        MTBF MTTR
    COOP
      site redundancy
        hot warm cold
      restoration order
    Disaster Recovery
      DR plan
      exercises
        tabletop
        simulation
        parallel
        full cutover
    Capacity Planning
      people technology infrastructure

Il Business Continuity Planning (BCP) e' il processo di garantire che le operazioni critiche di un'organizzazione possano continuare durante e dopo un'interruzione. Include la prevenzione delle interruzioni, la risposta alle interruzioni e il recupero.

Business Impact Analysis Concepts

#

Una Business Impact Analysis (BIA) identifica e prioritizza le funzioni e i processi aziendali critici, determinando l'impatto di un'interruzione su di essi. E' il prerequisito di qualsiasi piano di business continuity: senza sapere quale processo e' piu' critico, non si possono allocare le risorse di recovery in modo efficace.

Site Risk Assessment

#

Prima di pianificare la continuita', un'organizzazione valuta i rischi specifici della propria location fisica:

• Rischi naturali (terremoti, alluvioni, uragani, incendi boschivi) tipici della regione geografica.
• Rischi industriali (impianti chimici vicini, aeroporti).
• Rischi infrastrutturali (affidabilita' della rete elettrica locale, connettivita' internet).

Questa valutazione informa le scelte su dove collocare i siti di backup e quali scenari di disaster recovery pianificare.

Impact

#

L'impact (impatto) di un'interruzione misura le conseguenze negative per l'organizzazione: perdita di ricavi, danni alla reputazione, sanzioni normative, perdita di clienti. La BIA quantifica l'impatto per ogni processo critico, spesso in termini monetari per ora di downtime.

Recovery Time Objective

#

Il RTO (Recovery Time Objective) e' il tempo massimo accettabile per ripristinare un sistema o un processo dopo un'interruzione. E' una soglia definita dal business, non un valore tecnico:

• RTO = 4 ore: il business accetta al massimo 4 ore di downtime. I sistemi di recovery devono essere dimensionati per rispettare questa soglia.
• RTO = 0 (zero downtime): richiede ridondanza attiva (active/active), molto costosa.

Dev parallel: l'RTO e' il SLA interno sulla recovery. Come un SLA su un'API (99.9% uptime = max 8,7 ore/anno di downtime), il RTO e' il "quanto possiamo stare giu' prima che diventi un problema serio per il business".

Recovery Point Objective

#

Il RPO (Recovery Point Objective) e' la quantita' massima di dati che l'organizzazione puo' permettersi di perdere, misurata nel tempo. Determina la frequenza dei backup:

• RPO = 1 ora: backup ogni ora. In caso di disastro si perdono al massimo 1 ora di dati.
• RPO = 0: replica sincrona in tempo reale. Nessuna perdita di dati accettabile.

Comparing MTBF and MTTR

#

Esempio: un disco ha MTBF di 100.000 ore. Ci si aspetta un guasto ogni 100.000 ore operative (~11 anni). Una volta guasto, l'MTTR indica quanto ci vuole per sostituirlo e ripristinare i dati dal backup.

MTBF alto + MTTR basso = alta disponibilita'. Un MTBF basso (componenti inaffidabili) o un MTTR alto (recovery lenta) si traducono entrambi in bassa disponibilita'.

Dev parallel: MTBF e MTTR sono le stesse metriche che usi su un servizio cloud: l'MTBF e' il tempo tra gli outage, l'MTTR e' il tempo per ripristinare il servizio dopo un outage. AWS/GCP/Azure pubblicamente tracciano entrambe nelle post-mortem degli incident report.

Continuity of Operations Planning

#

Il COOP (Continuity of Operations Planning) definisce come l'organizzazione mantiene le funzioni critiche durante e dopo un'interruzione. Include la selezione di siti alternativi e l'ordine di ripristino.

Site Redundancy

#

Quando un sito primario diventa inaccessibile (disastro, guasto, attacco), l'organizzazione ha bisogno di un sito alternativo. Esistono tre livelli di sito di backup, in ordine decrescente di costo e crescente di RTO:

La scelta del tipo di sito dipende dall'RTO definito nella BIA: un RTO di 4 ore esclude un cold site, un RTO di ore esclude un hot site se il budget non lo permette.

Restoration Order

#

Il restoration order (ordine di ripristino) definisce la sequenza con cui i sistemi vengono riportati online dopo un'interruzione. Non tutto si ripristina contemporaneamente: i sistemi critici hanno la precedenza.

Criterio tipico:

1. Infrastruttura di rete (firewall, switch, router) - senza rete niente altro funziona
2. Active Directory / servizi di autenticazione - senza autenticazione gli utenti non possono lavorare
3. Servizi critici di business (ERP, sistemi di pagamento, email)
4. Applicazioni secondarie

L'ordine e' definito nella BIA in base alla criticita' di ogni sistema per il business.

Disaster Recovery

#

Il Disaster Recovery (DR) e' il sottoinsieme del BCP che si occupa specificamente del ripristino dei sistemi IT dopo un disastro. Un DR plan (piano di disaster recovery) documenta le procedure per rispondere a scenari specifici di interruzione.

Testing Plans with Exercises

#

Un DR plan non testato e' inutile: non si sa se funziona finche' non si ha un vero disastro. Esistono quattro tipi di esercitazioni per testare i piani, in ordine crescente di invasivita' e realismo:

Tabletop Exercises

#

Un tabletop exercise (esercitazione da tavolo) e' una discussione facilitata in cui i partecipanti chiave parlano di cosa farebbero in risposta a un determinato scenario di disastro. Non si eseguono azioni reali: si discutono le procedure, si identificano gap, si verificano le responsabilita'.

Analogia: e' come fare un code review di un runbook prima di eseguirlo: si leggono le procedure, si identificano ambiguita', si verifica che tutti sappiano cosa fare, senza toccare nessun sistema.

Simulations

#

Le simulations (simulazioni) vanno un passo oltre il tabletop: i partecipanti eseguono le procedure del DR plan in un ambiente simulato o su sistemi non critici, senza impattare la produzione. Testano se le procedure funzionano davvero, non solo se sembrano ragionevoli sulla carta.

Parallel Processing

#

Il parallel processing (elaborazione parallela, anche chiamato parallel test) attiva il sito di disaster recovery mentre il sito primario continua a operare. I due sistemi girano in parallelo per verificare che il sito DR sia funzionale e che i dati siano consistenti, senza interrompere il servizio.

E' il test piu' realistico senza rischio: se il sito DR ha problemi, il sito primario e' ancora operativo. Il costo e' elevato (due infrastrutture in funzione contemporaneamente).

Full Cutover Tests

#

Un full cutover test (o failover test completo) sposta effettivamente tutto il traffico e le operazioni dal sito primario al sito di DR. E' il test piu' realistico: simula esattamente cosa succederebbe in un disastro reale.

E' anche il piu' rischioso: se il sito DR ha problemi, l'organizzazione non ha fallback immediato. Per questo si esegue raramente, tipicamente una volta all'anno, e con molta pianificazione.

Da ricordare: tabletop = discussione, nessuna azione reale. Simulation = procedure eseguite in ambiente simulato. Parallel = DR attivato mentre il primario gira. Full cutover = tutto il traffico sul DR.

Capacity Planning

#

Il capacity planning (pianificazione della capacita') garantisce che l'organizzazione abbia risorse sufficienti per operare in condizioni normali e durante una crisi. Riguarda tre dimensioni:

• People: il personale sufficiente e con le competenze giuste per operare i sistemi critici, anche durante un'emergenza. Evitare dipendenza da singole persone con conoscenza esclusiva (key person risk, l'equivalente umano di un SPOF).
• Technology: sistemi e software scalabili che possono gestire picchi di carico imprevisti senza degradare le performance.
• Infrastructure: banda di rete, storage, potenza di elaborazione adeguati sia per la normale operativita' sia per scenari di recovery.

Dev parallel: il capacity planning e' la pianificazione che fai prima di un lancio di prodotto o di uno scaling orizzontale su cloud: quantifica quante risorse servono (vCPU, RAM, banda, storage), e verifica che l'infrastruttura tenga in scenari di picco. In un contesto DR, significa verificare che il sito hot/warm abbia abbastanza risorse da gestire il carico del sito primario, non solo esistere.

Da ricordare: BIA identifica i processi critici e il loro impatto. RTO = tempo massimo per il recovery. RPO = massima perdita di dati accettabile. MTBF = affidabilita' del componente. MTTR = velocita' di recovery. Hot site = operativo subito. Warm site = ore. Cold site = giorni. Tabletop = discussione. Full cutover = test reale completo.