Secure Configuration Management (SCM): fondamenti, sfide e strategie di implementazione per la cybersecurity aziendale
Il secure configuration management (gestione sicura della configurazione) rappresenta uno dei pilastri fondamentali della moderna cybersecurity aziendale. In un panorama digitale caratterizzato da minacce sempre più sofisticate e da infrastrutture IT in rapida evoluzione, la capacità di mantenere configurazioni sicure e consistenti costituisce un fattore critico per la protezione degli asset informativi organizzativi.
La configurazione non sicura dei sistemi rappresenta una delle principali cause di violazioni della sicurezza informatica. Secondo le statistiche più recenti, le misconfigurazione rappresentano oltre il 30% degli incidenti di sicurezza nelle aziende, evidenziando la criticità di implementare strategie di gestione della configurazione basate su principi di sicurezza by design.
Definizione e ambito del Secure Configuration Management (SCM)
Il secure configuration management può essere definito come “la gestione e il controllo delle configurazioni per un sistema informativo per abilitare la sicurezza e facilitare la gestione del rischio”. Questa disciplina si estende oltre la tradizionale gestione della configurazione, integrando considerazioni di sicurezza in ogni fase del ciclo di vita dei sistemi IT.
L’ambito del secure configuration management include:
La definizione di configurazioni di base sicure (secure baseline configurations)
L’implementazione di controlli per le modifiche della configurazione
Il monitoraggio continuo delle deviazioni dalle configurazioni approvate
La documentazione e la tracciabilità delle modifiche
L’integrazione con i processi di gestione del rischio organizzativo
Framework di Riferimento: NIST SP 800-128
Il NIST Special Publication 800-128 fornisce linee guida per le organizzazioni responsabili della gestione e dell’amministrazione della sicurezza dei sistemi informativi federali. Il framework proposto dal NIST identifica quattro fasi principali del secure configuration management:
Pianificazione (Planning): Sviluppo di politiche e procedure organizzative
Identificazione e implementazione delle configurazioni (Identifying and Implementing Configurations): Stabilimento di configurazioni di base sicure
Controllo delle modifiche (Controlling Configuration Changes): Gestione strutturata delle modifiche
Monitoraggio (Monitoring): Verifica continua dell’aderenza alle configurazioni approvate
L’Evoluzione del Cybersecurity Framework NIST 2.0
Il NIST ha aggiornato il Cybersecurity Framework (CSF) nella versione 2.0, rilasciata nel febbraio 2024, per aiutare tutte le organizzazioni a gestire e ridurre i rischi. La versione 2.0 si concentra su sei funzioni principali: Govern, Identify, Protect, Detect, Respond e Recover.
L’introduzione della funzione “Govern” rappresenta un’evoluzione significativa, enfatizzando l’allineamento strategico tra cybersecurity e gestione del rischio. Questa nuova funzione sottolinea l’importanza di integrare la gestione della configurazione sicura nei processi decisionali strategici dell’organizzazione.
Controlli CIS: una prospettiva operativa
I CIS Controls v8.1, rilasciati nel giugno 2024, hanno introdotto una nuova funzione di sicurezza “Governance” per allinearsi con il NIST Cybersecurity Framework 2.0. La versione 8.1 si focalizza sull’importanza della gestione della sicurezza in ambienti cloud o ibridi.
I CIS Controls forniscono un approccio pratico al secure configuration management attraverso:
Controllo 1: Inventario e controllo degli asset hardware
Controllo 2: Inventario e controllo degli asset software
Controllo 4: Configurazione sicura degli asset aziendali
I CIS Controls offrono tre gruppi di implementazione (IG) che forniscono raccomandazioni per dare priorità all’implementazione e un metodo semplificato per assistere le aziende di tutte le dimensioni nel dirigere le proprie risorse di sicurezza.
ISO/IEC 27001:2022 e la Gestione della Configurazione
La norma ISO 27001:2022 Annex A Control 8.9 sulla gestione della configurazione enfatizza la necessità di politiche strutturate, configurazioni standardizzate e controlli di sicurezza per garantire operazioni IT sicure ed efficienti.
Il controllo A.8.9 è critico per garantire l’integrità e la sicurezza dei sistemi informativi attraverso la gestione sistematica delle configurazioni, includendo aspetti hardware e software con l’obiettivo di stabilire configurazioni di base sicure.
Elementi chiave del controllo ISO 27001 A.8.9
La norma richiede alle organizzazioni di:
Stabilire e mantenere configurazioni di base sicure per tutti i sistemi
Implementare processi strutturati per la gestione delle modifiche
Condurre revisioni periodiche delle configurazioni
Mantenere documentazione completa e controllo delle versioni
Sfide tecniche e operative
Complessità e scala
La gestione delle configurazioni sicure in un ambiente IT vasto e diversificato può essere incredibilmente complessa. Le organizzazioni spesso hanno vari sistemi, applicazioni e dispositivi con requisiti di configurazione.
Configuration Drift
Il configuration drift si verifica quando i sistemi si discostano dalle loro configurazioni di base sicure nel tempo. Questo può accadere a causa di modifiche non autorizzate, aggiornamenti del sistema o nuove implementazioni che non aderiscono agli standard stabiliti.
Vincoli di risorse
Un SCM efficace richiede risorse significative, incluso personale qualificato, tempo e investimenti finanziari. Budget limitati possono limitare la capacità di investire in strumenti automatizzati, audit regolari e monitoraggio continuo.
Strategie di automazione e strumenti
Infrastructure as Code (IaC)
L’adozione di approcci Infrastructure as Code rappresenta una strategia fondamentale per il secure configuration management. L’utilizzo di strumenti di configuration as code (CaC) per documentare gli stati desiderati in modo dichiarativo riduce le discrepanze e semplifica i processi di ripristino.
Strumenti di gestione della configurazione
Chef, Puppet, Ansible e Microsoft System Center Configuration Manager (SCCM) automatizzano la distribuzione, il monitoraggio e la riparazione della configurazione. Questi strumenti migliorano l’efficienza e la precisione, garantendo l’applicazione coerente delle impostazioni di sicurezza su tutti i sistemi.
Security Content Automation Protocol (SCAP)
Il Security Content Automation Protocol (SCAP) è una suite di specifiche che standardizza il formato e la nomenclatura con cui le informazioni sui difetti del software e le configurazioni sicure possono essere comunicate. L’utilizzo di strumenti SCAP-validati facilita l’automazione delle valutazioni di sicurezza e la gestione delle configurazioni.
Implementazione delle best practices
Stabilimento di configurazioni di base
La ricerca indica che fino all’80% degli attacchi riusciti sfrutta misconfigurazione, rendendo necessario stabilire una configurazione di sicurezza di base su tutti i sistemi.
Le best practices includono:
Utilizzo di configurazioni comuni sicure basate su standard riconosciuti
Personalizzazione delle configurazioni in base alla funzione del sistema
Implementazione del principio di funzionalità minima
Gestione rigorosa delle password e dell’autenticazione
Gestione delle modifiche
Il controllo delle modifiche della configurazione è il processo documentato per gestire e controllare le modifiche alla configurazione di un sistema o dei suoi CI costituenti.
Un processo efficace di gestione delle modifiche deve includere:
Valutazione dell’impatto sulla sicurezza
Approvazione attraverso un Configuration Control Board (CCB)
Testing in ambiente controllato
Implementazione monitorata
Verifica post-implementazione
Monitoraggio continuo
Le attività di monitoraggio sono utilizzate come meccanismo all’interno del SecCM per validare che il sistema aderisca alle politiche, procedure e configurazione di base sicura approvata dall’organizzazione.
Il monitoraggio continuo comprende:
Scansioni automatizzate per rilevare deviazioni
Analisi dei log di audit
Verifica dell’integrità del sistema
Reporting degli stati di compliance
Integrazione con la gestione del rischio
Risk Assessment e Configuration Management
Il SecCM supporta la gestione del rischio organizzativo fornendo maggiore controllo e assicurando l’integrità delle risorse IT. L’integrazione tra gestione del rischio e configuration management richiede:
Identificazione degli asset critici
Classificazione dei rischi associati alle configurazioni
Implementazione di controlli proporzionati al rischio
Monitoraggio continuo dell’efficacia dei controlli
Compliance e conformità normativa
Il secure configuration management supporta la conformità a diverse normative e standard:
SOX (Sarbanes-Oxley): Per controlli finanziari e IT
HIPAA: Per la protezione dei dati sanitari
PCI DSS: Per la sicurezza dei dati di pagamento
GDPR: Per la protezione dei dati personali
Tecnologie emergenti e sfide future
Cloud e Hybrid Environments
La versione 8.1 dei CIS Controls affronta la sicurezza dei sistemi man mano che le aziende si spostano sempre più verso ambienti cloud e ibridi e utilizzano tecnologie mobili.
Le sfide specifiche per gli ambienti cloud includono:
Gestione delle configurazioni multi-tenant
Sicurezza dei container e dell’orchestrazione
Configurazione di servizi cloud nativi
Gestione delle identità e degli accessi in ambienti distribuiti
Artificial Intelligence e Machine Learning
L’integrazione di tecnologie AI/ML nel secure configuration management presenta opportunità e sfide:
Opportunità: Rilevamento automatico di anomalie, predizione di vulnerabilità, ottimizzazione delle configurazioni
Sfide: Sicurezza dei modelli AI, gestione dei bias, interpretabilità delle decisioni automatizzate
Metriche e KPI per il Secure Configuration Management
Indicatori di efficacia
Le organizzazioni dovrebbero implementare metriche specifiche per valutare l’efficacia del proprio programma di secure configuration management:
Percentuale di sistemi conformi: Rapporto tra sistemi configurati secondo standard sicuri e totale dei sistemi
Tempo medio di rilevamento delle deviazioni: Efficacia del monitoraggio continuo
Tempo medio di correzione: Capacità di risposta alle non conformità
Numero di incidenti legati a misconfigurazione: Efficacia complessiva del programma
ROI e benefici economici
Le organizzazioni che utilizzano il controllo delle versioni sperimentano un aumento del 50% nella collaborazione del team e nella risoluzione degli errori. Altri benefici misurabili includono:
Riduzione dei tempi di ripristino
Diminuzione dei costi di audit
Miglioramento della disponibilità dei servizi
Riduzione dei rischi operativi
Raccomandazioni per l’implementazione dell’SCM
Approccio graduale
Fase 1: Assessment dello stato attuale e identificazione dei gap
Fase 2: Definizione di politiche e procedure
Fase 3: Implementazione di configurazioni di base per sistemi critici
Fase 4: Estensione graduale a tutti i sistemi
Fase 5: Ottimizzazione e automazione completa
Fattori di successo critici
Supporto del management: Commitment della direzione aziendale
Competenze tecniche: Formazione del personale IT e di sicurezza
Integrazione con processi esistenti: Allineamento con ITIL e altri framework
Cultura della sicurezza: Sensibilizzazione di tutto il personale
Conclusioni
Il secure configuration management rappresenta un elemento strategico per la sicurezza informatica aziendale moderna. Stabilire una configurazione di sicurezza di base su tutti i sistemi è cruciale, dato che la ricerca indica che fino all’80% degli attacchi riusciti sfrutta misconfigurazione.
L’evoluzione verso architetture cloud-native, l’adozione di tecnologie DevOps e l’integrazione di soluzioni AI/ML richiedono un approccio sempre più sofisticato alla gestione della configurazione sicura. Le organizzazioni che investono in programmi strutturati di secure configuration management non solo migliorano la propria postura di sicurezza, ma ottengono anche benefici operativi significativi in termini di efficienza, compliance e riduzione dei rischi.
La chiave del successo risiede nell’adozione di un approccio olistico che integri persone, processi e tecnologie, supportato da framework consolidati come NIST, CIS Controls e ISO 27001, e implementato attraverso strumenti di automazione appropriati per il contesto organizzativo specifico.
The escalating and constant digital threats from state-sponsored adversaries like China, Iran, North Korea, and Russia coincide with a fractured global governance and a shifting domestic policy landscape. This moment presents a unique opportunity for the administration to continue to set the tone as a global leader in cyber threat deterrence. Public and private collaboration can help with this effort.
By collaborating, we can address the fragmented approaches to cybersecurity within the U.S. government, help defenders navigating the maze of competing regulation, and clarify among industry stakeholders about jurisdictional responsibilities as well as regulatory priorities which currently dilute efforts to combat malicious actors effectively.
The private sector’s adaptability to change is beneficial for national security agencies in quickly responding to new threats. Criminals have rapidly embraced the digital world, often outpacing authorities who may struggle with limited funding and resources. Their ability to work across jurisdictions and quickly turn challenges to their advantage, as seen in recent geopolitical crises, highlights the need for a strategic shift in focus toward criminal behavior rather than specific types of crime. By taking advantage of private-sector capabilities, national security agencies can access the data and tools to monitor patterns, become more adaptable, and be better equipped to address these evolving threats. We can do this with privacy top-of-mind.
Risks remain high for infrastructure attacks and financial stability threats, and even organizations with robust security measures are not immune to the domino effect of supply chain vulnerabilities. More than ever, partnering with the private sector is key. Sharing methodologies such as cybersecurity risk scores and analytics as well as frontline offensive tactics can help government maneuver threatening environments and detect potential issues in their supply chains.
The Trump administration is driving progress by streamlining governance and harmonizing efforts across federal agencies. DHS Secretary Kristi Noem affirmed that “the Trump team would continue to push companies to develop more secure technology while reducing regulatory and information-sharing burdens on the private sector.”
In this hyper-connected era, our agencies are keenly aware that protecting and securing the homeland and cyberspace also means being vigilant of our cyber infrastructure.”
Complementing this approach would be a more cohesive framework for sector risk management agencies — such as those overseeing energy, water, transportation and health care — which will provide clarity and reduce redundancy. By simplifying regulations, organizations will be empowered to focus resources on meaningful security measures rather than bureaucratic compliance.
At the international level, a unified U.S. approach to global cybersecurity regulation will be critical. Inconsistent standards among allies and partners create exploitable gaps in defenses. Gaps such as defense capabilities, cyber vulnerabilities and supply chain weaknesses remind us that in the digital age — cybersecurity is a shared concern.
Yet, by championing global harmonization, the Trump administration has a unique opportunity to redefine America’s role as the world’s global cybersecurity leader while strengthening our collective security and advancing U.S. leadership in cybersecurity policymaking. By sharpening the Cybersecurity and Infrastructure Security Agency’s (CISA’s) focus, harmonizing governance efforts, and addressing digital supply chain vulnerabilities, the administration can lay the groundwork for a more resilient and secure future.
In this hyper-connected era, our agencies are keenly aware that protecting and securing the homeland and cyberspace also means being vigilant of our cyber infrastructure. The threat environment to our homeland through cyberspace now changes by the nanosecond, and we must keep up. Every day, the Department of Homeland Security works with government, industry, and international partners to prevent, detect, and respond to cyber intrusions. CISA proactively addresses a rapidly evolving cyber threat environment and helps thwart cyber-attacks from foreign adversaries and cyber criminals.
Their factsheets, advisories and alerts reflect how attacks continue to grow in frequency, scope, and severity, as demonstrated by the recent cyber espionage campaign by the People’s Republic of China (PRCs) advanced persistent threat (APT) group known as Salt Typhoon, which resulted in the compromise of numerous IT environments in various critical sectors, including communications, energy, transportation systems, and water and wastewater systems. These attacks are intended to pre-position capabilities to disrupt critical functions during future geopolitical tensions. Salt Typhoon demonstrates how China has the capability and intent to infiltrate and potentially disrupt critical systems within the United States incessantly.
This moment demands more than defense — it calls for comprehensive focus. To combat malicious cyber-attacks on American sovereignty and increasingly aggressive intrusions into our homeland and our interests, a reimagined cybersecurity strategy has the potential to protect critical infrastructure while reinforcing America’s position as the global standard-bearer in the face of mounting digital threats.
The number of mis-issued 1.1.1.1 certificates grows. Here’s the latest.
Cloudflare on Thursday acknowledged this failure, writing:
We failed three times. The first time because 1.1.1.1 is an IP certificate and our system failed to alert on these. The second time because even if we were to receive certificate issuance alerts, as any of our customers can, we did not implement sufficient filtering. With the sheer number of names and issuances we manage it has not been possible for us to keep up with manual reviews. Finally, because of this noisy monitoring, we did not enable alerting for all of our domains. We are addressing all three shortcomings.
Ultimately, the fault lies with Fina; however, given the fragility of the TLS PKI, it’s incumbent on all stakeholders to ensure system requirements are being met.
And what about Microsoft? Is it at fault, too?
There’s some controversy on this point, as I quickly learned on Wednesday from social media and Ars reader comments. Critics of Microsoft’s handling of this case say that, among other things, its responsibility for ensuring the security of its Root Certificate Program includes checking the transparency logs. Had it done so, critics said, the company would have found that Fina had never issued certificates for 1.1.1.1 and looked further into the matter.
Additionally, at least some of the certificates had non-compliant encoding and listed domain names with non-existent top-level domains. This certificate, for example, lists ssltest5 as its common name.
Instead, like the rest of the world, Microsoft learned of the certificates from an online discussion forum.
Some TLS experts I spoke to said it’s not within the scope of a root program to do continuous monitoring for these types of problems.
In any event, Microsoft said it’s in the process of making all certificates part of a disallow list.
Microsoft has also faced long-standing criticism that it’s too lenient in the requirements it imposes on CAs included in its Root Certificate Program. In fact, Microsoft and one other entity, the EU Trust Service, are the only ones that, by default, trust Fina. Google, Apple, and Mozilla don’t.
“The story here is less the 1.1.1.1 certificate and more why Microsoft trusts this carelessly operated CA,” Filippo Valsorda, a Web/PKI expert, said in an interview.
I asked Microsoft about all of this and have yet to receive a response.
Sextortion with a twist: Spyware takes webcam pics of users watching porn
“How you use this program is your responsibility,” the page reads. “I will not be held accountable for any illegal activities. Nor do i give a shit how u use it.”
In the hacking campaigns Proofpoint analyzed, cybercriminals attempted to trick users into downloading and installing Stealerium as an attachment or a web link, luring victims with typical bait like a fake payment or invoice. The emails targeted victims inside companies in the hospitality industry, as well as in education and finance, though Proofpoint notes that users outside of companies were also likely targeted but wouldn’t be seen by its monitoring tools.
Once it’s installed, Stealerium is designed to steal a wide variety of data and send it to the hacker via services like Telegram, Discord, or the SMTP protocol in some variants of the spyware, all of which is relatively standard in infostealers. The researchers were more surprised to see the automated sextortion feature, which monitors browser URLs for a list of pornography-related terms such as “sex” and “porn,” which can be customized by the hacker and trigger simultaneous image captures from the user’s webcam and browser. Proofpoint notes that it hasn’t identified any specific victims of that sextortion function, but suggests that the existence of the feature means it has likely been used.
More hands-on sextortion methods are a common blackmail tactic among cybercriminals, and scam campaigns in which hackers claim to have obtained webcam pics of victims looking at pornography have also plagued inboxes in recent years—including some that even try to bolster their credibility with pictures of the victim’s home pulled from Google Maps. But actual, automated webcam pics of users browsing porn is “pretty much unheard of,” says Proofpoint researcher Kyle Cucci. The only similar known example, he says, was a malware campaign that targeted French-speaking users in 2019, discovered by the Slovakian cybersecurity firm ESET.
The pivot to targeting individual users with automated sextortion features may be part of a larger trend of some cybercriminals—particularly lower-tier groups—turning away from high-visibility, large-scale ransomware campaigns and botnets that tend to attract the attention of law enforcement, says Proofpoint’s Larson.
“For a hacker, it’s not like you’re taking down a multimillion-dollar company that is going to make waves and have a lot of follow-on impacts,” Larson says, contrasting the sextortion tactics to ransomware operations that attempt to extort seven-figure sums from companies. “They’re trying to monetize people one at a time. And maybe people who might be ashamed about reporting something like this.”
Ransomware Attack Targets PA Attorney General’s Office
The Pennsylvania Office of Attorney General was the victim of a ransomware attack. The attack has reportedly impeded several agency functions, including access to archived emails, files, and systems that are essential for pursuing cases. However, the office has stated that it does not anticipate criminal prosecutions, investigations or civil proceedings to be hindered solely due to this cyber incident.
At this time, it is not immediately apparent how the attack is or is not affecting other county courts or the state appellate courts.
A statement from the office reveals that the “interruption was caused by an outsider encrypting files in an effort to force the office to make a payment to restore operations.” That same statement asserts that no ransom payment has been issued. Furthermore, an active investigation has begun with other agencies.
The office has not yet revealed how this attack occurred or if any sensitive data has been compromised.
Cyberattack on Jaguar Land Rover Disrupts Business Operations
Jaguar Land Rover (JLR) experienced a cyber incident, as stated on September 2, 2025. According to the company’s statement, immediate action was taken upon discovering the cyberattack (shutting down systems proactively). At this time, there is no evidence that customer data was compromised. However, the organization has said that retail and production has been “severely disrupted.”
Security Leaders Weigh In
Mr. Agnidipta Sarkar, Chief Evangelist at ColorTokens:
JLR was attacked earlier, too. In March 2025, JLR was targeted by the HELLCAT ransomware group, which compromised Atlassian Jira credentials to steal hundreds of gigabytes of sensitive data. This new attack, leading to the systematic shutdown of production facilities and retail systems, suggests either a ransomware attack or a significant system compromise. Clearly, JLR needs to immediately implement capabilities to prevent lateral movement that attackers resort to after an initial breach, among other cybersecurity controls.
The attack poses a systemic cyber risk to the automotive supply chain, occurring at the confluence of IT and OT. This shutdown would eventually affect the entire supply chain. As a zero-trust ambassador, I can only state that it is time for organizations to implement a zero-trust foundation across IT, OT, and cloud.
Ms. Nivedita Murthy, Senior Staff Consultant at Black Duck:
The first step after detecting a security incident is containment. JLR did the right thing by shutting down its IT system before the attack spread further and caused damage. As part of post incident activity, they would be able to identify how the attackers were able to access the systems and take advantage of it. This incident is another reminder to retailers that emphasizes the need to work on securing business operations as well as customer data to ensure smooth production and uncompromised trust in software, as attackers are increasingly targeting retail operators to access customer base information.
People within an organization tend to be the weakest links and any information gained on customers could be used for future phishing attacks or scams. The fraud industry is thriving, and more and more people are falling victim due to the fact a lot of information on customer activity is available online.
Mr. Piyush Pandey, CEO at Pathlock:
With widespread cyberattacks targeting retailers in recent months — and now expanding to manufacturers with the JLR incident — security teams across both sectors should strengthen security controls to reduce exposure. Ensuring the principle of least privilege is implemented on a continuous basis is a fundamental step in addressing this risk. That includes automating access reviews to revoke excessive permissions, promptly locking down emergency access, and continuously monitoring critical applications to detect and terminate unauthorized activity quickly.
Trey Ford, Chief Strategy and Trust Officer at Bugcrowd:
Not a lot is known publicly about the actual scope of impact, however, in operational technology environments, taking an environment fully offline to troubleshoot issues on the line is the expected practice. OT environments rely heavily on air gap protections — specifically isolating the network used for production from all other system (office, guest, and internet) networks. This is due to the lack of resilience and age-old system designs and architectures used by OT systems providers.
The time to see OT providers step into the modern, internet resilient age is upon us. These fragile systems will continue to be impacted until they’re built to stand up in the face of adversarial pressure — like all modern technology and services are today.
Ethical hacking e CTF: formazione della prossima generazione di professionisti della cybersecurity
L’evoluzione del panorama della cybersecurity ha portato all’emergere di metodologie di formazione innovative che combinano competenze tecniche avanzate con principi etici rigorosi. Le competizioni Capture the Flag (CTF) rappresentano oggi un paradigma formativo fondamentale per la preparazione di professionisti qualificati nell’ambito dell’ethical hacking e della sicurezza informatica. Questo articolo analizza l’impatto delle competizioni CTF sulla formazione professionale, con particolare focus sul contributo dell’eccellenza italiana rappresentata dai mHackeroni, e delinea le implicazioni strategiche per lo sviluppo delle competenze nel settore della cybersecurity.
Introduzione all’ethical hacking: paradigmi e metodologie
L’ethical hacking, definito dal NIST come “testing that verifies the extent to which a system, device or process resists active attempts to compromise its security”, costituisce una disciplina fondamentale nell’ecosistema della cybersecurity moderna. La metodologia penetration testing del NIST specifica che gli assessment devono “attempt to circumvent or defeat the security features of an information system”, stabilendo parametri rigorosi per la conduzione di test di sicurezza autorizzati.
Le certificazioni professionali nell’ethical hacking hanno registrato una crescita esponenziale, con la certificazione CEH (Certified Ethical Hacker) che conta oltre 22.000 posizioni lavorative disponibili a livello globale secondo un’analisi LinkedIn del settembre 2024. Il framework curriculare delle competenze di ethical hacking si articola attraverso domini tecnici specializzati che includono:
Reconnaissance e information gathering: Metodologie sistematiche per la raccolta di intelligence sui target
Vulnerability assessment: Identificazione e classificazione delle vulnerabilità secondo standard CVSS
Exploitation techniques: Implementazione controllata di tecniche di attacco per la validazione delle vulnerabilità
Post-exploitation e privilege escalation: Analisi degli impatti potenziali e delle catene di compromissione
Reporting e risk assessment: Documentazione professionale e valutazione del rischio secondo framework standardizzati
La crescente domanda di ethical hacker è supportata da statistiche che indicano salari medi di $83,000 negli Stati Uniti, con possibilità di incrementi significativi in contesti metropolitani e aziendali Fortune 500.
Competizioni CTF: architettura formativa e metodologie di assessment
Le competizioni Capture the Flag rappresentano un ecosistema formativo strutturato che simula scenari di sicurezza reali attraverso challenge multi-disciplinari. Il formato CTF fu sviluppato inizialmente nel 1996 durante DEF CON, la più grande conferenza di cybersecurity negli Stati Uniti, evolvendo successivamente in due principali tipologie:
Jeopardy-style CTF
Le competizioni in formato jeopardy presentano challenge categorizzate per domini tecnici specifici:
Cryptography: Implementazione e analisi di algoritmi crittografici, protocolli di sicurezza e tecniche di cryptanalysis
Web exploitation: Identificazione e sfruttamento di vulnerabilità in applicazioni web secondo la OWASP Top 10
Reverse engineering: Analisi statica e dinamica di binari, malware analysis e techniques di code obfuscation
Forensics: Digital forensics, network traffic analysis e incident response procedures
Binary exploitation: Buffer overflow, ROP chains, format string attacks e moderne tecniche di exploit development
OSINT: Open Source Intelligence gathering e social engineering techniques
Attack-defense CTF
Nel formato attack-defense, i team competitori devono difendere i propri sistemi vulnerabili mentre attaccano quelli degli avversari, simulando scenari di red team vs blue team operations tipici degli ambienti enterprise.
Il caso studio mHackeroni: eccellenza italiana nel panorama internazionale
I mHackeroni rappresentano un paradigma di eccellenza nel panorama italiano della cybersecurity competitiva. Il team, fondato nel 2018 dalla fusione di cinque team CTF italiani (@towerofhanoi, @c00kiesATvenice, @n0pwnintended, @TheRomanXpl0it, @aboutblankets), ha conseguito risultati di livello mondiale.
Achievements internazionali
Nel maggio 2018, i mHackeroni hanno ottenuto il secondo posto nelle qualificazioni DEF CON CTF su oltre 600 team globali, qualificandosi per le finali di Las Vegas dove hanno conseguito il settimo posto. Più recentemente, durante DEF CON 31, il team ha conquistato la vittoria nella competizione Hack-a-Sat 4 Finals, diventando i primi “Certified Satellite Hackers” al mondo.
Composizione e background accademico
Il team comprende circa 40 membri provenienti da istituzioni accademiche di prestigio (Politecnico di Milano, La Sapienza Roma, Università di Padova, Ca’ Foscari Venezia, Vienna University of Technology, ETH Zurich) e realtà industriali affermate.
Impatto delle CTF sulla formazione professionale
Skill-based hiring e evoluzione del mercato del lavoro
Le tendenze per il 2025 indicano che il 45% delle aziende statunitensi intende sostituire i requisiti di laurea con competenze skill-based, posizionando le CTF come strumento privilegiato per la dimostrazione pratica delle competenze.
Secondo il Cyber Attack Readiness Report (CARR) 2024 di Hack the Box, oltre il 67% dei team di cybersecurity utilizza certificazioni o laboratori hands-on per il benchmarking delle competenze, evidenziando la preferenza per approcci formativi pratici rispetto alla formazione teorica tradizionale.
Competenze emergenti e specializzazioni
Le CTF moderne integrano challenge che riflettono le evolute minacce del panorama cyber:
Cloud security: Challenge focalizzate su AWS, Azure, GCP security misconfigurations
IoT e Industrial Control Systems (ICS): HTB ha sviluppato partnership con Dragos per l’Alchemy Lab specializzato in sicurezza ICS
Active Directory security: Lancio della certificazione HTB Certified Active Directory Pentesting Expert (CAPE) nel dicembre 2024
AI/ML security: Challenge emergenti su adversarial machine learning e model poisoning.
Framework normativi e standard di riferimento
NIST cybersecurity framework integration
Il NIST Penetration Testing Framework (SP 800-115) fornisce una metodologia strutturata per la conduzione di test di penetrazione, articolata nelle fasi di Planning, Discovery, Attack e Reporting. L’integrazione delle competenze CTF con i framework NIST permette:
Identify function: Sviluppo di competenze per l’asset inventory e risk assessment
Protect function: Implementazione di controlli di sicurezza basati su threat intelligence
Detect function: Capacità di identificazione di indicators of compromise (IoC)
Respond function: Incident response e threat hunting capabilities
Recover function: Business continuity e disaster recovery planning
Certificazioni professionali e career pathway
Il percorso formativo nell’ethical hacking si articola attraverso certificazioni progressive:
Entry-level certifications:
CompTIA Security+: Fondamenti di cybersecurity con focus su network security e threat detection
CompTIA PenTest+: Specializzazione in penetration testing con componenti performance-based
Intermediate certifications:
CEH v13 AI: Certified Ethical Hacker con capabilities AI-enhanced, 20 moduli formativi e 550+ tecniche di attacco
GIAC Penetration Tester (GPEN): Certificazione avanzata per security tester con minimo due anni di esperienza
Advanced certifications:
OSCP (Offensive Security Certified Professional): Metodologia hands-on con simulazione di live network environment
CISSP: Comprehensive management-level certification per security practitioners senior.
Tendenze future e skill gap analysis
Panorama del deficit di competenze
L’ISC2 Cybersecurity Workforce Study 2024 riporta un gap globale di 4.763.963 professionisti, con un incremento del 19,1% rispetto al 2023. CompTIA stima una crescita dell’employment cybersecurity del 267% sopra il tasso nazionale negli Stati Uniti.
Impatto dell’intelligenza artificiale
Il 68% dei professionisti ritiene che entro due anni sarà in grado di utilizzare efficacemente GenAI nel proprio ruolo, con aspettative di miglioramento nel threat detection e riduzione dei costi organizzativi. Le competizioni CTF stanno integrando challenge AI-focused per preparare i professionisti alle nuove frontiere della cybersecurity.
Specialized domains e emerging technologies
Industrial Control Systems (ICS) security: L’espansione delle tecnologie IoT e automation nel settore manifatturiero ha creato nuove superficie di attacco, evidenziando la necessità di specialisti ICS.
Cloud-native security: La migrazione verso architetture cloud-first richiede competenze specializzate in container security, Kubernetes hardening e cloud security posture management (CSPM).
Metodologie di training e practical application
Hands-on learning approaches
Le competizioni business-focused come Global Cyber Skills Benchmark 2025 offrono esperienze immersive con storyline interattive e contenuti basati su latest attack techniques. Queste piattaforme implementano:
Red team simulations: Scenari avanzati di persistent threat simulation
Purple team exercises: Integrazione tra offensive e defensive operations
Threat intelligence integration: Challenge basati su real-world threat actor TTPs
Assessment e benchmarking
L’approccio skill-based hiring richiede metodologie di assessment oggettive, con le CTF che forniscono metrics quantitativi per la valutazione delle competenze tecniche. I parametri di assessment includono:
Technical proficiency: Velocità di risoluzione e accuratezza nelle soluzioni
Methodology adherence: Aderenza a standard e best practices consolidate
Innovation capability: Capacità di sviluppare soluzioni creative per challenge complessi
Collaboration skills: Efficacia nel team working e knowledge sharing.
Implicazioni strategiche per l’industria
Corporate training programs
Con cybercrime costs stimati a $10.5 trilioni USD entro il 2025, le organizzazioni stanno investendo massivamente in corporate training programs basati su CTF methodologies. Piattaforme come Hack the Box Business CTF permettono team benchmarking e skill assessment su scala enterprise.
Government e critical infrastructure
Competizioni governative come DARPA Cyber Grand Challenge e ENISA European Cybersecurity Challenge evidenziano l’importanza strategica delle CTF per la national cybersecurity preparedness.
Conclusioni e raccomandazioni
Le competizioni Capture the Flag rappresentano un ecosistema formativo maturo e consolidato per lo sviluppo di competenze avanzate nell’ethical hacking. L’eccellenza italiana rappresentata dai mHackeroni dimostra la capacità di competere ai massimi livelli internazionali, contribuendo significativamente alla reputation nazionale nel settore cybersecurity.
Raccomandazioni strategiche:
Institutional investment: Potenziamento degli investimenti istituzionali in programmi CTF universitari e corporate training
Industry-academia collaboration: Sviluppo di partnership strutturate tra università e industria per practical skill development
Certification integration: Integrazione delle competenze CTF nei pathway di certificazione professionale
Emerging technologies focus: Adattamento dei curriculum CTF per includere AI/ML security, quantum cryptography e post-quantum security
L’evoluzione del panorama delle minacce cyber richiede un approccio formativo dinamico e pratico. Le CTF, combinate con framework standardizzati e certificazioni professionali, offrono una metodologia comprovata per la formazione della prossima generazione di ethical hacker e cybersecurity professionals.
Mis-issued certificates for 1.1.1.1 DNS service pose a threat to the Internet
The certificates are a key part of the Transport Layer Protocol. They bind a specific domain to a public key. The certificate authority posesses the private key certifying that the certificate is valid. Anyone in possession of a TLS certificate can cryptographically impersonate the domain for which it was issued.
The holder of the 1.1.1.1 certificates could potentially use them in active adversary-in-the-middle attacks that intercept communications passing between end users and the Cloudflare DNS service, Ryan Hurst, CEO of Peculiar Ventures and a TLS and public key infrastructure expert, told Ars.
“Doing so would require a BGP hijack to trick your host to think your [rogue] 1.1.1.1 was the one I should connect to,” he explained. BGP is short for Border Gateway Protocol, a specification used to link regional networks scattered around the world, known as Autonomous Systems, to each other. By manipulating the system through false notices, attackers regularly take control of legitimate IP addresses, including those belonging to telecoms, banks, and Internet services.
As several Ars commenters have noted, there are likely many other ways an attacker could exploit the certificates to mount an adversary-in-the-middle attack.
From there, attackers with possession of the 1.1.1.1 certificates could decrypt, view, and tamper with traffic from the Cloudflare DNS service, Hurst said. He added that Cloudflare’s WARP VPN service may also be similarly affected.
Wednesday’s discovery exposes key failures of the public key infrastructure that’s responsible for ensuring trust of the entire Internet. They are the only thing ensuring that gmail.com, bankofamerica.com, irs.gov, and any other sensitive website is controlled by the entity claiming ownership.
Given the pivotal role of certificates, CAs are required to provide the IP addresses they used to verify that a party applying for a certificate controls the address they want covered. None of thethreecertificates provides that information. The incident also reflects poorly on Microsoft for failing to catch the mis-issued certificate and allowing Windows to trust it for such a long period of time.
Also at partial fault are Cloudflare and the PKI stakeholders at large, since all issued certificates are published to a publicly available transparency log. The purpose of the log is to quickly identify mis-issued certificates before they can be actively used. The public discovery of the certificates four months after they were issued suggests the transparency logs didn’t receive the attention they were intended to get.
Post updated to correct explanation of TLS certificates.
Appena rilasciato e già preso di mira dagli attaccanti: Hexstrike AI, un nuovo tool di offensive security (OffSec), è già entrato nelle mani dei cybercriminali che lo stanno usando per cercare di sfruttare diverse vulnerabilità.
Come si legge sul sito ufficiale dello strumento, Hexstrike AI è stato pensato per essere “un framework rivoluzionario di sicurezza offensiva basato sull’intelligenza artificiale che combina strumenti di sicurezza professionali con agenti autonomi di intelligenza artificiale per fornire funzionalità complete di test di sicurezza“.
Come riporta un recente report di CheckPoint, però, poche ore dopo il rilascio del tool i cybercriminali hanno cominciato a valutare come usare il framework per sfruttare le vulnerabilità zero-day di Citrix NetScaler ADC e Gateway, rese note lo scorso 26 agosto. Insomma, un tool che dovrebbe proteggere dagli attacchi può diventare potenzialmente una minaccia a sua volta, un potente strumento al servizio del cybercrimine.
Sui forum del dark web si discute su come usare Hexstrike AI a proprio vantaggio. Credits: CheckPoint
E in effetti Hexstrike AI promette di essere un tool molto potente: lo strumento infatti introduce un livello di astrazione e orchestrazione per far eseguire autonomamente tool di sicurezza a modelli di IA quali Claude, GPT e Copilot. Grazie agli MCP Agent, Hexstrike AI consente di eseguire in contemporanea e senza intervento umano oltre 150 tool di sicurezza.
Come sottolinea CheckPoint, il tempismo tra la scoperta delle vulnerabilità Citrix e il rilascio del tool di IA è preoccupante: gli attaccanti potrebbero agire molto più in fretta del normale e sfruttare i bug prima che le organizzazioni possano agire. “Sfruttare queste vulnerabilità non è banale. Gli attaccanti devono comprendere le operazioni di memoria, i bypass di autenticazione e le peculiarità dell’architettura di NetScaler. Storicamente, questo tipo di lavoro ha richiesto tecnici altamente qualificati e settimane di sviluppo. Con Hexstrike AI, questa barriera sembra essere crollata” evidenzia CheckPoint.
Tutte le implicazioni positive del tool, come gli aenti intelligenti che scansionano migliaia di IP simultaneamente e le attività che possono essere inizializzate ed eseguite in pochi minuti invece che in ore o giorni, hanno anche la controparte negativa quando vengono sfruttate dai cybercriminali.
La soluzione, in questo momento, è applicare immediatamente le patch risolutive e investire su strumenti di protezione all’avanguardia, in grado di contrastare la capacità di adattamento degli attaccanti.
Business Impact Analysis BIA: Calcolo RTO RPO e analisi Impatto per la continuità operativa
Questo articolo prosegue la serie di approfondimenti dedicati alla Business Continuity ISO 22301, concentrandosi sulla fase operativa cruciale: l’implementazione del template di Business Impact Analysis (BIA). Dopo aver analizzato contesto organizzativo e leadership, entriamo nel vivo del processo di identificazione dei processi critici, calcolo di RTO e RPO, e definizione delle soluzioni di continuità operativa per garantire la resilienza aziendale.
Implementazione Template BIA: dalla teoria alla pratica
Una volta identificato il contesto organizzativo e ottenuto il supporto del Top Management, è possibile avviare il processo di realizzazione e implementazione di un programma di Business Continuity.
Il programma inizia con l’identificazione delle linee di business critiche e vitali per l’organizzazione e il Risk Assessment propedeutico a determinare il Risk Appetite e la Risk Tolerance dell’organizzazione.
L’identificazione delle linee di business critiche e vitali può avvenire in tre modi differenti:
viene comunicata dal Top Management;
viene identificata grazie alle Business Impact Analysis;
viene identificata tramite analisi di mercato e dei competitor.
Riprendendo l’esempio dell’istituto finanziario, il Top Management, dopo aver effettuato il Risk Assesment, fornisce il Risk Appetite, la Risk Tolerance e la Risk Capacity, che rispettivamente indicano:
Risk Appetite – l’ammontare e tipo di rischio che un’organizzazione è disposta a perseguire o ritenere (ISO Guide 73:2009 – Risk Management Vocabulary);
Risk Tolerance – la disponibilità dell’organizzazione o delle parti interessate a sostenere il rischio, dopo il suo trattamento, al fine di raggiungere i propri obiettivi (ISO Guide 73:2009 – Risk Management Vocabulary);
Risk Capacity – l’ammontare di rischio massimo sopportabile per l’azienda.
È doveroso ricordare che l’attività di Risk Assessment è un processo volto a individuare e analizzare i rischi identificati all’interno dell’organizzazione ed è un’attività, come già riportato nella Parte I, strettamente collegata alla gestione della Business Continuity.
Non esistono tecniche o metodologie universali per identificare tali valori, in quanto essi variano in base alle esigenze aziendali.
Un buon punto di partenza potrebbe comunque essere il Margine di Contribuzione aziendale[1]
A titolo esemplificativo, le metriche economiche si potrebbero dunque così suddividere:
MARGINE DI CONTRIBUZIONE: € 1.000.000,00
RISK APPETITE: € 250.000,00
RISK TOLERANCE: € 500.000,00
RISK CAPACITY: € 750.000,00
La figura 2 rappresenta, a titolo esemplificativo, come tali metriche economiche possano essere suddivise in base ai livelli di gravità (in questo caso 5) al fine di creare delle scale di impatto da utilizzare durante lo svolgimento della Business Impact Analysis (BIA). Tali scale possono essere variate e personalizzate anche in base al grado di precisione delle analisi che si intende perseguire.
Prendiamo ad esempio il processo bancario “Gestione Assegni Bancari”, che è stato (in questa casistica ipotetica) definito come vitale.
Al fine di analizzare tale processo, è possibile condurre l’analisi BIA in due modalità:
intervista 1 to 1 con il process owner (alternativa sempre altamente consigliabile)
sottoporre al process owner il template BIA, che dovrà compilare in autonomia e restituire al Business Continuity Managero chi per lui.
Al fine di redigere un’analisi BIA il più corretta possibile, è necessario che il process owner recuperi o rediga anticipatamente un report o estratto dei movimenti e transazioni registrate, a cadenza giornaliera, almeno nell’ultimo trimestre, includendo anche particolari periodi di picco noti.
Inoltre, è sempre consigliabile (ove possibile) analizzare il processo nel modo più quantitativo possibile.
Di fatto, un’analisi troppo qualitativa potrebbe portare a un risultato finale troppo basato sulla soggettività del process owner.
Una BIA correttamente impostata, invece, deve permettere di raccogliere almeno le seguenti informazioni:
informazioni circa il compilatore, il ruolo e l’ufficio di appartenenza;
il processo oggetto di analisi;
una tabella, o elenco, in cui valorizzare i potenziali impatti economici, reputazionali e normativi (almeno) che il processo porterebbe all’organizzazione in caso di fermo (si veda figura 2);
i razionali di impatto che hanno portato alla valorizzazione degli impatti;
il sito (o siti) in cui viene erogato il processo;
il processo in input (ossia da quale processo il processo oggetto di analisi riceve informazioni);
il processo in output (ossia il processo che riceve i dati dal processo oggetto di analisi);
i potenziali periodi di picco del processo (ad esempio, il processo “buste paga” potrebbe avere come periodo di picco i giorni precedenti l’addebito degli stipendi) ed eventuali scadenze giornaliere;
gli applicativi / sistemi / software utilizzati, indicandone le criticità;
i fornitori a supporto di tale processo, indicandone la criticità;
le attività svolte dal processo;
le risorse ordinarie coinvolte (se il processo viene erogato per più sedi, è opportuno suddividere questo elenco per sedi);
il numero di risorse necessarie in caso di emergenza (solitamente inferiore al numero ordinario) e dopo quanto tempo è necessaria la loro attivazione (ad esempio durante la prima ora potrebbe essere sufficiente l’operatività di una sola risorsa, dopo 2 ore tre risorse e così via);
le risorse di backup, identificate in risorse in grado di svolgere il minimo dell’attività nel caso in cui quelle ordinarie non siano disponibili. Per tale motivo è sconsigliabile identificare risorse di backup che rientrino nello stesso Team/Ufficio delle risorse ordinarie. È possibile identificare risorse di backup primarie e secondarie per garantire una maggiore resilienza in caso di evento;
gli apparati e strumenti utilizzati dalle risorse;
i documenti critici (indicare se sono cartacei o digitali);
dove sono salvati i documenti digitali (specialmente le cartelle di rete).
IMPATTI
FERMO OPERATIVO IN ORE
0 – 4 ore
4 – 8 ore
8 – 24 ore (1 giorno)
24 – 48 ore (2 giorni)
48 – 72 ore (3 giorni)
72 ore – 1 settimana
1 – 2 settimane
2 settimane – 1 mese
Mancati ricavi
Costi aggiuntivi
Sanzioni normative
Danno reputazionale
Fermo operativo altri processi
RTO
BASSO
MEDIO BASSO
MEDIO
ALTO
MOLTO ALTO
Da € 100.000,00 a € 230.000,00
Da € 230.000,01 a € 360.000,00
Da € 360.000,01 a € 490.000,00
Da € 490.000,01 a € 700.000,00
Da € 700.000,01 a € 750.000,00
Figura 2. Tabella quantificazione impatti creata da Chiara Cavicchioli
Al fine di agevolare il process owner nella corretta identificazione e classificazione degli impatti in caso di fermo del processo, alcune domande da porre potrebbero essere:
A quanto ammontano i mancati ricavi a seguito di fermo del processo nelle varie fasce temporali?
In caso di fermo, l’istituto dovrebbe sostenere spese per far ripartire il processo, come l’ingaggio di fornitori terzi, il pagamento di straordinari dei dipendenti etc?
Se sì, a quanto ammontano queste spese per ogni fascia temporale?
Sono presenti delle scadenze ricorrenti che, se non rispettate, potrebbero dar seguito a sanzioni normative? A quanto ammontano?
Un fermo comporterebbe risonanza mediatica o impatti diretti sulla clientela, con conseguente danno reputazionale?
Un fermo del presente processo porterebbe, a catena, al fermo operativo di altri processi? Se sì, con quali impatti?
Tali analisi e la conseguente compilazione del template BIA vengono ripetute a cadenza annuale od ogni qualvolta vi siano particolari modifiche al processo, alla struttura organizzativa e/o a seguito di incidenti.
Al termine dell’analisi, si avrà dunque un quadro preciso relativo ai processi più o meno critici e da cosa sono supportati e composti.
Informazioni aggiuntive BIA
Se volessimo creare un’analisi di impatto ancora più dettagliata e granulare, andrebbero tenuti in considerazione i seguenti fattori.
Siti di Erogazione: andrebbe assegnata una criticità che non tenga solo conto delle attività e un numero di risorse che vi lavora, ma anche la criticità del sito da un punto di vista geopolitico.
Applicativi: potrebbe essere aggiunto il valore “RTO” e “RPO” del singolo applicativo, che può essere fornito dalle funzioni che gestiscono gli applicativi utilizzati dall’organizzazione. Così facendo, nella BIA si avrebbero non solo l’RTO e RPO del processo ma anche dei singoli applicativi, che potrebbero non essere identici (i desiderata sarebbero inferiori o uguale agli RTO e RPO del processo).
CIA Triad: un ulteriore fattore di vitale importanza è analizzare il rischio di perdita di Confidenzialità, Integrità e Disponibilità del dato (CIA Triad), le cui definizioni sono così distinte:
Confidenzialità (Confidentiality) – indica la protezione dei dati durante tutto il ciclo di vita e ha lo scopo di proteggere e preservare la riservatezza dei dati degli utenti;
Integrità (Integrity): indica il mantenimento dell’incolumità e la salvaguardia dei dati, ossia la protezione da qualsiasi tentativo di compromissione non autorizzato;
Disponibilità (Availability): intende garantire il diritto di accesso ai dati per gli utenti dotati dei permessi necessari.
Al fine di analizzare e quantificare tale rischio, è necessario individuare e classificare i dati ritenuti sensibili (tale attività generalmente può essere svolta prima delle analisi di impatto, creando una sorta di registro delle classificazioni con il supporto del DPO ed eventualmente delle funzioni IT). Ai sensi della normativa GDPR, tra i dati sensibili troviamo:
origine razziale ed etnica;
convinzioni religiose o filosofiche;
opinioni politiche;
orientamento sessuale;
situazione giudiziaria;
informazioni relative alle comunicazioni elettroniche (indirizzo IP, social network etc);
dati di geolocalizzazione;
dati genetici e biometrici;
Inoltre, ulteriori tipologie di dati/assets da tenere in considerazione e da analizzare possono essere:
proprietà intellettuali;
software o sistemi tecnologici operativi;
licenze;
etc.
Durante le BIA, è importante valutare se le informazioni trattate dal processo oggetto di analisi o dal fornitore a supporto di tale processo (in quanto l’istituto continuerebbe ad essere Titolare del trattamento dei dati, mentre il fornitore risulterebbe come Responsabile) siano critiche, in quanto dati sensibili; e se, a seguito di un incidente, vi possano essere perdite di confidenzialità, integrità e disponibilità del dato.
A differenza della valutazione degli impatti suddivisa su fasce orarie riportata alla figura 2 – che non si focalizza sullo scenario ma sul fermo del processo, indipendentemente dalla causa – durante l’analisi dei dati è opportuno considerare anche le minacce e le possibili conseguenze.
Ad esempio, un attacco ransomware che comprometta un processo dove le attività vengono svolte in modalità manuale e cartacea non avrà alcun impatto sulla CIA Triad; mentre un’alluvione che distrugga tale documentazione avrà un impatto almeno sull’integrità e sulla disponibilità del dato. Inoltre, è importante considerare anche la quantità dei dati trattati.
Ipotizzando di riprendere l’analisi precedentemente effettuata per il processo “Gestione Assegni Bancari”, un esempio su come svolgere la valutazione sul rischio legato ai dati può essere il seguente.
DATO
EVENTO
RISCHIO
Perdita di Confidenzialità
Perdita di Integrità
Perdita di Disponibilità
ALTO
MEDIO
BASSO
ALTO
MEDIO
BASSO
ALTO
MEDIO
BASSO
Licenza Applicativo XX
Ransomware
x
x
x
Licenza Applicativo XX
Violazione sicurezza fisica
x
x
x
Informazioni anagrafiche emittente assegno
Ransomware
x
x
X
Informazioni anagrafiche mittente
Phishing
x
x
X
Informazioni anagrafiche destinatario
Ransomware
x
x
X
Informazioni anagrafiche destinatario cartacee
Phishing
x
x
x
Figura 4. Tabella valutazione del dato creata da Chiara Cavicchioli
L’analisi sopra riportata (a scopo esemplificativo) può essere personalizzata sulla base delle necessità aziendali. I valori “alto-medio-basso” potrebbero, per esempio, riferirsi al numero degli utenti impattati, oppure al danno economico o reputazionale che potrebbe derivare dalla perdita di tali informazioni.
La valutazione e la mappatura del rischio legato ai dati può essere svolta all’interno della BIA, oppure con analisi separata che andrà comunque a concorrere alla valutazione finale della definizione del perimetro dei processi critici. Tale analisi potrà inoltre essere utilizzata e migliorata dalle funzioni IT che dovranno identificare e implementare soluzioni di sicurezza atte a preservare la confidenzialità, l’integrità e la disponibilità dei dati considerati particolarmente critici.
Risorse: sia per le risorse di emergenza che di backup, si possono individuare le risorse “primarie” e “secondarie” secondo il seguente criterio:
nel caso in cui le primarie risorse di emergenza non siano disponibili, ingaggio quelle secondarie;
nel caso in cui le primarie risorse di backup non siano disponibili, ingaggio quelle secondarie.
Così facendo avremo:
risorse di emergenza primarie e secondarie;
risorse di backup primarie e secondarie.
È utile, specialmente per i processi critici, definire quale sia il numero minimo di risorse umane necessarie per svolgere i processi in ordinario e, tra quelle attualmente presenti, quali siano quelle con il maggiore know-how.
In questo modo, in caso di pensionamenti e/o dimissioni, si saprà immediatamente quante risorse umane sia necessario assumere e con quale livello di seniority.
Arco temporale di svolgimento – cut off: l’arco temporale di svolgimento di un processo/attività può essere più o meno critico a seconda delle tempistiche necessarie per lo svolgimento, appunto, dell’attività.
Un ufficio che si occupa della gestione della compravendita di titoli avrà un arco di svolgimento quantificato in minuti e ore; mentre l’ufficio che si occupa di preparare e pubblicare l’informativa finanziaria ogni qualvolta venga rilasciato un nuovo prodotto (ipotizzando ne venga lanciato uno ogni 4 mesi) avrà un arco temporale di svolgimento di 4 mesi, quindi con una criticità bassa.
Quando si valuta questo driver è importante non confondere la disorganizzazione con un’emergenza. Pertanto, ipotizzando che il lancio del prodotto avvenga il giorno 16 del mese di riferimento e che la relativa documentazione debba quindi essere pubblicata in tale giornata, un’obiezione che potrebbe essere posta in fase di analisi BIA è che un incidente che avviene il giorno 15 avrebbe un impatto alto.
Se si valutassero i processi sotto questa prospettiva, avrebbero tutti una criticità medio-alta/alta.
Inoltre, la presa in considerazione del worst-case scenario è utile nei casi in cui sia difficile stimare un impatto su attività/processi che sappiamo essere critici, ma non “quanto” critici, specialmente per quelli con arco temporale di svolgimento basso (ad esempio, un incidente informatico che impatti un processo alle ore 14.00, quando alle 16.00 di ogni giorno vi è una scadenza per la rendicontazione della compravendita dei titoli).
Per i processi con arco temporale di svolgimento ampio, riprendendo l’esempio della documentazione informativa, è difficile che le risorse inizino a scriverla in concomitanza della data della pubblicazione.
Se l’ufficio è ben organizzato, le risorse addette avranno quindi 4 mesi per predisporre il documento ed essere pronte al lancio del prodotto; anche nel caso di incidenti che avvengano qualche giorno prima di tale data, l’azienda avrà predisposto backup e soluzioni di continuità propedeutiche alla ripresa dell’attività da dove è stata interrotta, senza quindi dover affrontare una perdita totale dei dati e garantendo così il rispetto della scadenza.
Nel caso in cui tali soluzioni non siano adeguate, dovranno essere modificate e migliorate queste ultime e non la criticità dell’arco temporale di svolgimento.
Una sintesi di tale valutazione del presente driver può essere riassunta dal seguente schema.
ARCO TEMPORALE DI SVOLGIMENTO IN ORE
ARCO TEMPORALE DI SVOLGIMENTO
CRITICITÀ ARCO TEMPORALE
1 – 8 ORE
BASSO
MOLTO ALTO
8 – 24 ORE
MEDIO – BASSO
ALTO
24 – 48 ORE
MEDIO
MEDIO – ALTO
48 – 72 ORE
MEDIO
MEDIO
72 ORE – 1 SETTIMANA
BASSO
BASSO
> 1 SETTIMANA
MOLTO BASSO
MOLTO BASSO
Figura 5. Arco temporale di svolgimento creato da Chiara Cavicchioli
Calcolo RTO
A ciascun driver precedentemente indicato (sito di erogazione, applicativi, etc.) può essere associato un valore che concorrerà alla definizione dell’RTO.
Nella BIA in questione, è stato creato un modello di calcolo che assegna un valore aggiuntivo pari ad un 0,5% qualora vengano selezionate le criticità “alto” e “molto alto”; questo perché in alcuni casi è consigliabile ragionare in ottica di worst-case scenario e mantenere un approccio prudenziale.
Di fronte a processi la cui criticità potrebbe oscillare tra “Medio” e “Alto / Medio Alto”, sarà dunque possibile applicare la fascia più alta, garantendo un presidio maggiormente accurato.
La scala dei valori è quindi così definita:
Basso = 1
Medio Basso = 2
Medio = 3
Alto = 4 (+ 0,5%)
Molto Alto = 5 (+ 0,5%)
La media aritmetica definisce la criticità del processo come di seguito esemplificato.
Figura 6. Valorizzazione tabella quantificazione impatti creato da Chiara Cavicchioli
Riprendendo le soglie di Risk Appetite, Tolerancee Capacity riportate al paragrafo 4.1 (rispettivamente € 250.000,00, € 500.000,000 e € 750.000,00), nel caso analizzato la prima fascia temporale in cui viene raggiunta la soglia risk tolerance – risk capacity è quella delle 24-48 ore (è possibile arrotondare per difetto e per eccesso, quindi in questo caso il 3,56 può diventare un 4[3]) e la media aritmetica ci suggerisce che, in caso di fermo, il processo arrecherebbe impatti economici che superano il risk appetite e la risk tolerance.
Sappiamo quindi che l’RTO oltre il quale il danno economico risulterebbe inaccettabile è di 48 ore, in quanto si avvicina alla risk capacity che non deve mai essere oltrepassata.
L’organizzazione potrebbe stabilire che tutti i processi con RTO inferiore e/o uguale a 72h sono considerati critici (tale valore può ovviamente essere cambiato sulla base delle esigenze aziendali) e che quindi richiedono maggiori test annuali, soluzioni di Business Continuity specifiche e maggiori controlli.
Ogni driver tramite cui elaborare la BIA e calcolare l’RTO può essere variato sulla base delle esigenze aziendali.
Un ulteriore strumento di vitale importanza, che può essere utilizzato durante le analisi BIA al fine di quantificare gli impatti nella maniera più accurata possibile, è relativo agli incidenti pregressi e “near missed”.
Le aziende dovrebbero predisporre e mantenere un elenco degli incidenti, dei relativi impatti e delle azioni implementate al fine di mitigarli. Tale elenco dovrebbe essere accessibile durante le analisi BIA, in quanto permette di quantificare un danno effettivo che la società potrebbe subire a seguito di fermo, sulla base di quanto già avvenuto in passato.
Tale strumento è utile anche poiché potrebbe rivelare che, per i processi rispetto ai quali è difficile stabilire gli impatti e la relativa criticità, negli anni precedenti si sono verificati fermi operativi superiori alle 48 ore a seguito dei quali non sono stati riscontrati danni ingenti.
In questo caso sapremo quindi se, da quando è avvenuto l’incidente, non ci sono state variazioni in termini di criticità e numero delle attività svolte; e, se tale attività non è diventata parte del core business, tale processo non andrà ritenuto critico.
Calcolo dell’RPO
L’RPO (Recovery Point Object) può essere fornito dal process owner che sta compilando l’analisi di impatto, oppure da funzioni esterne che hanno preventivamente calcolato la criticità dei dati, stabilendo entro quanto debbano essere resi nuovamente disponibili, oltre a quantificare il margine di informazioni che è accettabile perdere (i.e. maximum data loss).
Solitamente – come già spiegato nella Parte I – l’RPO coincide con la periodicità del backup.
Probabilità di accadimento
Nell’esempio specifico di BIA finora analizzata, si è data enfasi al potenziale impatto derivante da un fermo operativo (indipendentemente dalla sua natura), suddiviso per un determinato numero di fasce orarie.
Tuttavia, alcune organizzazioni potrebbero avere la necessità di considerare anche la probabilità di accadimento di un determinato evento e di analizzare gli impatti rispetto ad ogni singolo scenario[4].
Tale necessità spesso deriva dal fatto che le soluzioni di mitigazione da implementare hanno sia costi iniziali, sia costi di manutenzione molto onerosi; quindi, se la probabilità di accadimento di un evento è particolarmente bassa, la soluzione più economica risulta essere quella di assumersi il rischio.
Un esempio di definizione delle percentuali da attribuire alle probabilità di accadimento di un evento, finalizzate a classificare un rischio, può essere il seguente:
Estremamente probabile (si verifica almeno 1 volta all’anno) – 1 punto
Probabile (si verifica almeno 1 volta ogni 2 anni) – 0,7 punti
Probabilità media (si verifica 1 volta ogni 5/6 anni) – 0,5 punti
Poco probabile (si verifica 1 volta ogni 10/20 anni) – 0,3 punti
Raro (si verifica 1 volta ogni 50/70 anni) – 0,1 punti
Riprendendo l’analisi precedente, in cui abbiamo determinato che un fermo operativo di 48 ore può arrecare un danno dai € 490.000 agli € 700.000, possiamo applicare le probabilità sulla base degli scenari di rischio, come nell’esempio seguente.
Alluvione – dai dati storici dell’istituto, i siti da cui viene erogato il processo non sono situati in zone soggette ad alluvioni; inoltre il rischio che tutti gli stabili da cui vengono erogati i processi siano colpiti contemporaneamente da alluvione è estremamente raro, quindi:
€ 595.000,00 (la metà tra € 490.000,00 e € 700.000,00) * 0,1 = € 59.500,00 (nuovo impatto economico) – rientra nel risk appetite.
Blackout – in base ai dati storici dell’istituto e ai precedenti eventi, ogni anno a Milano e a Verona si registrano due blackout, quindi:
€ 595.000,00 * 0,5 (dividiamo a metà il punto attribuito alla classificazione del “estremamente probabile” in quanto il processo viene svolto su 4 siti differenti e solo due sono coinvolti dai blackout) = € 297.000,00 – è nella soglia risk appetite/risk tolerance.
Indisponibilità applicativo – dai dati storici dell’istituto, almeno una volta ogni 2 anni sono state riscontrate anomalie negli applicativi con una durata superiore alle 24h, quindi:
€ 595.000,00 * 0,7 = €416.000,00 – è nella soglia risk appetite/risk tolerance.
Tali valutazioni fanno riferimento alla “Risk Matrix”, dove un rischio è calcolato secondo l’equazione
RISCHIO = PROBABILITÀ X MAGNITUDO
Figura 8. Risk Matrix
Perimetro dei processi oggetto di analisi
Le BIA possono essere svolte secondo diverse modalità:
Analisi di tutti i processi;
Analisi dei macro-processi e dei processi sottostanti solo per i macro-processi che risultano essere critici.
L’analisi di tutti i processi è consigliabile in quanto permette di avere una fotografia e una mappatura completa di tutte le attività svolte, indipendentemente dalla criticità delle terze parti – interne ed esterne – a supporto di tali processi.
Nel caso in cui tale modalità, a causa dello scarso numero di risorse operanti in ambito Business Continuity o per il poco tempo a disposizione, non sia perseguibile, può essere svolta l’analisi del macro-processo utilizzando il template BIA precedentemente riportato, compilando solo la parte iniziale relativa agli impatti (con un’analisi che sarà, ovviamente, ad alto livello) e, successivamente, procedere ad analizzare i processi sottostanti, compilando anche le restanti sezioni.
Nel caso in cui l’informazione relativa ai macro-processi e alle aree di business critiche sia fornita dal Top Management o dalla Funzione Rischi, è a discrezione delle risorse coinvolte nella Business Continuity scegliere se analizzare comunque il macro-processo ad alto livello o se intraprendere direttamente le BIA per tutti i processi sottostanti.
Qualora non sia presente una mappatura dei processi, o non vi siano chiare indicazioni su dove partire con le BIA – si pensi ad un’azienda appena costituita, oppure a una società che ha la necessità di costruire e avviare un sito secondario – è consigliabile intraprendere una delle seguenti strade.
Identificare, con il supporto del Top Management, le aree lavorative che garantiscono un introito consistente e hanno rilevanza sul bilancio annuale, andando poi ad analizzare tutti i processi sottostanti; successivamente si procederà all’analisi di tutti gli altri processi.
Identificare i processi con output aventi impatti diretti sulla clientela (es. tutti i processi che gestiscono e sono a supporto dell’home banking o degli applicativi e sistemi per le operazioni di pagamento fisico o virtuale) e procedere a ritroso, analizzando successivamente i processi di supporto a questi ultimi; successivamente, si procederà all’analisi di tutti gli altri processi.
La BIA è estremamente importante in quanto non solo consente di avere una mappa di tutti i processi, interdipendenze e risorse dell’organizzazione, ma permette altresì, in caso di incidente, di assegnare priorità ai processi che devono ripartire prima di altri, al fine di limitare l’impatto economico, reputazionale e legale sull’organizzazione.
Soluzioni di Continuità Operativa
È doveroso evidenziare che, al termine della raccolta delle informazioni, andranno individuate delle soluzioni di Business Continuity da applicare ai vari processi, distinguendo tra processi critici e non.
Esempi di soluzioni a protezione dei processi critici potrebbe essere:
Indisponibilità del sistema informativo: al fine di garantire la continua disponibilità del sistema informativo, ogni suo componente viene costantemente sottoposto a “hot backup”. Le copie dei backup sono salvate in modalità virtuale e cloud (modalità di backup ibrida).
Indisponibilità di dati e documenti critici: ogni documento critico viene digitalizzato e salvato in modalità ibrida su server fisici e in cloud. I backup sono automatici e le copie sono conservate tramite storage immutabile (ad esempio) per 5 anni.
Indisponibilità del personale critico: in caso di indisponibilità del personale critico possono essere ingaggiate le risorse di backup che vengono formate ogni anno sulle principali attività che saranno chiamate a svolgere attività in caso di emergenza. Tali risorse possono essere variate durante il corso dell’anno e dovranno in ogni caso essere sottoposte a sessioni formative.
Indisponibilità dei siti: in caso di indisponibilità dei siti, le risorse in possesso di accordi vigenti per il lavoro da remoto possono riprendere l’operatività da sito alternativo (es. la propria abitazione), purché vengano rispettati tutti i criteri relativi alla privacy. Qualora questa soluzione non sia percorribile, è possibile ingaggiare le risorse di backup.
Indisponibilità di fornitori critici: in caso di indisponibilità di fornitori critici è previsto l’ingaggio di fornitori alternativi con i quali sono stati precedentemente presi accordi al fine di farli subentrare al fornitore principale e, dove possibile, rispettando gli RTO del processo. Nel caso in cui non siano presenti accordi contrattuali con fornitori di backup, è possibile valutare di re-internalizzare le attività finché non verrà identificato un nuovo fornitore.
Indisponibilità di applicativi critici: in caso di indisponibilità di applicativi critici è previsto l’utilizzo di applicativi secondari per i quali sono già state predisposte funzionalità aggiuntive propedeutiche allo svolgimento di attività non ordinarie. Nel caso in cui questa soluzione non sia percorribile, è possibile valutare il ripristino delle attività per mezzo di documenti cartacei.
Indisponibilità dell’infrastruttura critica: in caso di indisponibilità delle reti di telecomunicazione ed energia elettrica, è prevista l’attivazione di reti secondarie di backup già contrattualizzate; nel caso non siano presenti, gli stabili sono dotati di UPS e/o gruppi elettrogeni che sono sottoposti a test e manutenzione continua e formalizzata.
Indisponibilità dei servizi ICT: in caso di indisponibilità di sistemi ICT a supporto dei processi critici, è prevista l’attivazione di sistemi di backup secondari e/o il ricorso a funzioni/fornitori terzi precedentemente testati e verificati.
Una soluzione applicabile alla maggior parte dei processi – non solo a quelli critici – potrebbe essere l’adozione del lavoro da remoto.
Tale soluzione, ovviamente, non si applica a tutte le attività che devono essere svolte in loco.
Per approfondire ulteriormente questi concetti metodologici e scoprire le tecniche avanzate di implementazione, ti invitiamo a scaricare il white paper completo elaborato da Chiara Cavicchioli e Federica Maria Rita Livelli dal titolo “Business Continuity: mito o realtà? La continuità nella discontinuità”.
Nel prossimo approfondimento della serie esploreremo la fase successiva fondamentale: il testing delle soluzioni identificate. Scoprirai come una volta identificate le soluzioni è indispensabile testarle al fine di verificare se, attivandole, vengano rispettati gli RTO, nonché di identificare la Recovery Time Capability (RTC) per garantire l’efficacia operativa del programma di Business Continuity.
Note
[1]Intesa come la differenza tra il fatturato e i costi variabili.
[2]La decisione di arrotondare per eccesso o per difetto può variare in base alla propensione al rischio dell’azienda; il presente esempio ha solo scopo illustrativo.
[3]La decisione di arrotondare per eccesso o per difetto può variare in base alla propensione al rischio dell’azienda; il presente esempio ha solo scopo illustrativo.
[4] È opportuno precisare che la mappatura del rischio e delle relative probabilità di accadimento è generalmente a carico di chi si occupa di risk management all’interno dell’organizzazione. Dal punto di vista della continuità operativa, è consigliabile analizzare un processo sulla base del fermo operativo suddiviso in diverse fasce orarie e considerare, con il supporto della funzione rischi, anche la probabilità di accadimento durante l’analisi BIA in situazioni eccezionali in cui sia difficile quantificare gli impatti, o a fronte di spese particolarmente ingenti.
Profilo Autore
Digital and Operational Resilience and Crisis Management Specialist. Certificata FERMA Rimap & AMBCI.
Ha maturato esperienza nell’ambito della Continuità Operativa, Crisis Management e Resilienza Digitale in ambito finanziario, anche grazie alle esperienze lavorative svolte presso primari istituti bancari.
Autrice di alcuni articoli pubblicati dal Business Continuity Institute (BCI).
