IT CHRONICLE
Home Home Il Progetto The Project Il Team The Team Strumenti di Rete Tool Kit Chiave PGP PGP Key Chi sono About Servizi Services EN
[ DOTT. FRANCESCO_RUSSO ]

ICT JOB DIARIESICT JOB DIARIES

List topics List topics
[ DOTT. FRANCESCO_RUSSO ]

Consulente ICT ICT Consultant

> Bridging Technology, Risk Management & Business

Il Profilo
Con oltre 25 anni di esperienza in reti, sistemi e IT risk management, mi occupo di amministrazione On-Premise e Cloud. Aiuto organizzazioni e imprese a garantire la conformità normativa (GDPR, ISO 27001, NIS 1 e 2) e offro servizi avanzati di Digital Forensics. Il mio obiettivo acquittal è consolidare il mio ruolo di esperto in Cybersecurity e Intelligenza Artificiale Generativa, operando a livello internazionale in modalità remote-first.

Esperienza sul Campo
Dal 2005 sono Programmatore Sistemista e Privacy Manager per il Consorzio per la Bonifica della Capitanata, ruolo a cui affianco una continua attività di consulenza per realtà sanitarie e studi legali (Gruppo Salatto, Studio Torlontano, ecc.). Gestisco operativamente attività di DFIR (Digital Forensics and Incident Response), Business Continuity, Disaster Recovery e mitigazione dell'impatto dei rischi IT. In passato, ho coordinato team internazionali come IT Project Manager tra Amsterdam e Tallinn.

Visione Strategica e Competenze
Comprendere l'infrastruttura richiede anche una solida visione aziendale. Per questo ho integrato il mio background tecnico (Windows/Linux Server, reti TCP/IP, Firewall) con una Laurea Magistrale in Scienze Economiche conseguita con lode. Unisco l'approccio ingegneristico alle metodologie manageriali e Agile (ITIL v.3, Scrum, Six Sigma). Attualmente sto espandendo le mie competenze attraverso i percorsi ufficiali Google come Cybersecurity Expert e Generative AI Leader.

Oltre il codice
Lavoro correntemente in inglese (certificazione C2 Cambridge) e conosco altre tre lingue. Quando non sono alle prese con server o incident response, ricarico le energie a contatto con la natura, pilotando droni (UAS Open A1/A3), dedicandomi alla fotografia o sperimentando nuove tecniche ai fornelli.

Formazione in corso

  • Professional Cloud Architect (Google Cloud)

Formazione Accademica

  • Master in Gestione delle imprese e delle società MA659 (30/30)
  • Laurea Magistrale in Scienze Economiche LM-56 (110/110 e Lode)
  • Laurea Triennale in Scienze dell'Economia e della Gestione Aziendale L-18 (94/110)

Certificazioni
Di seguito l'elenco completo delle certificazioni conseguite, dei corsi di specializzazione e dei badge ottenuti, a testimonianza del continuo aggiornamento tecnico e professionale:

  • Cybersecurity Foundations Professional Certificate (ID: 51934206)
  • Microsoft Certified: Azure Fundamentals
  • Foundations of Operationalizing MITRE ATT&CK
  • Foundations of Purple Teaming
  • Autopsy Basics and Hands On – Digital Forensics (ID: YRXYSTQBK8)
  • GrassHopper Javascript – Coding Fundamentals, Coding Fundamentals II, Array Methods, Animations
  • Project Management Essentials Certified (ID: 55005870)
  • Scrum Foundation Certificate (SFPC) (ID: 43043593)
  • Six Sigma White Belt (ID: 55005099)
  • Six Sigma Yellow Belt (ID: 729673)
  • ITIL v.3 Foundation (ID: GR750562993FR)
  • Cybersecurity Essentials – Cisco Netacad
  • Introduction to Cybersecurity – Cisco Netacad
  • Introduction to Cisco Packet Tracer – Cisco Netacad
  • Introduction to Internet of Everything – Cisco Netacad
  • Google Analytics for Beginners
  • Google Digital Training (ID: R7ZXBVRRR)
  • The EU GDPR - An Introduction (ID: UC-0HROEMGN)
  • Eipass Progressive (ID: 8B77A028CB)

The Profile
With over 25 years of experience in networks, systems, and IT risk management, I specialize in On-Premise and Cloud administration. I help organizations ensure regulatory compliance (GDPR, ISO 27001, NIS 1 and 2) and provide advanced Digital Forensics services. My current goal is to consolidate my expertise in Cybersecurity and Generative AI, collaborating internationally in a remote-first work environment.

Field Experience
Since 2005, I have served as the System Programmer and Privacy Manager for the Consorzio per la Bonifica della Capitanata, alongside continuous consulting work for healthcare facilities and law firms. I operationally manage DFIR (Digital Forensics and Incident Response), Business Continuity, Disaster Recovery, and IT risk mitigation. Previously, I coordinated international teams as an IT Project Manager between Amsterdam and Tallinn.

Strategic Vision & Skills
Understanding IT infrastructure also requires a solid business vision. That is why I integrated my technical background (Windows/Linux Servers, TCP/IP networks, Firewalls) with a Master's Degree in Economics (Summa Cum Laude). I combine an engineering approach with managerial and Agile methodologies (ITIL v.3, Scrum, Six Sigma). I am currently expanding my skill set through the official Google Cybersecurity Expert and Generative AI Leader paths.

Beyond the code
I am fluent in English (Cambridge C2 certification) and have knowledge of three other languages. When I am not dealing with servers or incident response, I recharge my energy by immersing myself in nature, flying drones (UAS Open A1/A3), practicing photography, or experimenting with new cooking techniques.

Formazione in corso

  • Professional Cloud Architect (Google Cloud)

Academic Background

  • Postgraduate Master in Corporate and Business Management (MA659)
  • Master's Degree in Economics LM-56 (Summa Cum Laude)
  • Bachelor's Degree in Economics and Business Management L-18 (94/110)

Certifications
Below is the complete list of certifications, specialization courses, and badges achieved, demonstrating a continuous commitment to technical and professional development:

  • Cybersecurity Foundations Professional Certificate (ID: 51934206)
  • Microsoft Certified: Azure Fundamentals
  • Foundations of Operationalizing MITRE ATT&CK
  • Foundations of Purple Teaming
  • Autopsy Basics and Hands On – Digital Forensics (ID: YRXYSTQBK8)
  • GrassHopper Javascript – Coding Fundamentals, Coding Fundamentals II, Array Methods, Animations
  • Project Management Essentials Certified (ID: 55005870)
  • Scrum Foundation Certificate (SFPC) (ID: 43043593)
  • Six Sigma White Belt (ID: 55005099)
  • Six Sigma Yellow Belt (ID: 729673)
  • ITIL v.3 Foundation (ID: GR750562993FR)
  • Cybersecurity Essentials – Cisco Netacad
  • Introduction to Cybersecurity – Cisco Netacad
  • Introduction to Cisco Packet Tracer – Cisco Netacad
  • Introduction to Internet of Everything – Cisco Netacad
  • Google Analytics for Beginners
  • Google Digital Training (ID: R7ZXBVRRR)
  • The EU GDPR - An Introduction (ID: UC-0HROEMGN)
  • Eipass Progressive (ID: 8B77A028CB)
> author identified
Foto Francesco Russo

IT Risk Assessment Ep. 3: Choosing the Framework (NIST SP 800-30 vs FAIR)

We have our assets and we know the threats. Now it's time to connect the dots and calculate the Risk. As an IT Manager, the temptation is to invent a custom spreadsheet, but in the corporate world (and to pass compliance audits), you must rely on recognized standards. Let's explore the two most authoritative frameworks.


1. The Qualitative Approach: NIST SP 800-30

NIST's Special Publication 800-30 is the de facto standard of the US government. It offers a rigorous and tested approach. It relies predominantly on qualitative or semi-quantitative assessments: probability and impact are classified on scales such as Very High, High, Medium, Low.

The Pro: It is relatively simple to implement and provides a solid, unassailable baseline for compliance (e.g., ISO 27001).
The Con: It is subjective. One sysadmin's "High Risk" might be another's "Medium Risk", and most importantly, it doesn't tell the CFO how much money the company is risking.


2. The Quantitative Approach: FAIR

FAIR (Factor Analysis of Information Risk) flips the paradigm. Instead of using colors and adjectives, it uses statistics and financial modeling (like Monte Carlo simulations). It breaks risk down into its fundamental mathematical factors: Event Frequency and Financial Loss Magnitude (very reminiscent of the ARO and ALE concepts we discussed previously).

The Pro: It speaks the Board's language. Instead of saying "There is a critical risk of ransomware", FAIR allows you to say: "There is a 15% probability of experiencing ransomware this year, with an expected loss between €50,000 and €250,000".
The Con: It requires historical data, precise measurements, and a very high level of corporate maturity to be implemented correctly.


3. Which to choose?

The strategic advice is a hybrid approach: use NIST SP 800-30 for the initial screening and to quickly discard minor risks, and apply FAIR's quantitative analysis only to risks considered "High" or "Critical" to justify security investments (ROI) to management.

Index: IT Risk Assessment Playbook

IT Risk Assessment Ep. 3: Scegliere il Framework (NIST SP 800-30 vs FAIR)

Abbiamo gli asset e conosciamo le minacce. Ora è il momento di unire i puntini e calcolare il Rischio. Da IT Manager, la tentazione è quella di inventarsi un foglio di calcolo personalizzato, ma nel mondo aziendale (e per superare gli audit di compliance) devi affidarti a standard riconosciuti. Esploriamo i due framework più autorevoli.


1. L'approccio Qualitativo: NIST SP 800-30

La Special Publication 800-30 del NIST è lo standard de facto del governo USA. Offre un approccio rigoroso e testato. Si basa prevalentemente su valutazioni qualitative o semi-quantitative: la probabilità e l'impatto vengono classificati su scale come Molto Alto, Alto, Medio, Basso.

Il pro: È relativamente semplice da implementare e fornisce una base solida e inattaccabile per la compliance (es. ISO 27001).
Il contro: È soggettivo. Il "Rischio Alto" di un sistemista potrebbe essere un "Rischio Medio" per un altro, e soprattutto non dice al CFO quanti soldi rischia l'azienda.


2. L'approccio Quantitativo: FAIR

FAIR (Factor Analysis of Information Risk) capovolge il paradigma. Invece di usare colori e aggettivi, usa la statistica e i modelli finanziari (come le simulazioni Monte Carlo). Scompone il rischio nei suoi fattori matematici fondamentali: Frequenza dell'evento e Magnitudo della perdita finanziaria (ricorda molto i concetti di ARO e ALE che abbiamo visto in passato).

Il pro: Parla la lingua del Board. Invece di dire "C'è un rischio critico di ransomware", FAIR ti permette di dire: "C'è il 15% di probabilità di subire un ransomware quest'anno, con una perdita attesa tra i 50.000€ e i 250.000€".
Il contro: Richiede dati storici, misurazioni precise e un livello di maturità aziendale molto alto per essere implementato correttamente.


3. Quale scegliere?

Il consiglio strategico è un approccio ibrido: usa il NIST SP 800-30 per lo screening iniziale e per scartare rapidamente i rischi minori, e applica l'analisi quantitativa di FAIR solo ai rischi considerati "Alti" o "Critici" per giustificare gli investimenti di sicurezza (ROI) al management.

Indice: IT Risk Assessment Playbook

The Risk Matrix Series - Vulnerability vs. Risk: Why a CVSS 9.8 isn't always a Business Emergency

There is a recurring moment of panic in many IT departments: the release of a new security bulletin with a vulnerability rated CVSS 9.8 (Critical). Immediately, everything stops, and the rush to patch begins. But as an IT Security Manager, the question I ask is different: does that vulnerability truly represent a business risk?


1. The CVSS score is not the Risk

The Common Vulnerability Scoring System (CVSS) measures the technical severity of a flaw. It tells us how easy it is to exploit and what technical impact it has on the isolated system. It tells us nothing about the business context. Risk, by definition, is the intersection between the Probability of a threat exploiting a vulnerability and the Impact (which we calculated in the BIA) that this event would have on the asset.


2. The Power of Context

Let's look at a practical example. We have the same CVSS 9.8 vulnerability (Remote Code Execution) on two different machines:

  • Server A: An isolated test machine in a VLAN with no internet access and no real data.
  • Server B: The internet-facing web server that handles the company's e-commerce.

The vulnerability is identical, but the Risk is vastly different. Stopping production to urgently patch Server A is a managerial mistake. The risk on Server A is low, almost nil. The risk on Server B is extreme and requires immediate action (Risk Mitigation).


3. The Risk Matrix for Prioritization

Mature security management does not aim to resolve all vulnerabilities (it's impossible and costly). It aims to prioritize. Using data from the Business Impact Assessment, we can map discovered vulnerabilities onto a Risk Matrix, focusing budget and sysadmin time only on the flaws that threaten critical processes or sensitive data. The rest can wait for the normal maintenance window or, in extreme cases, be handled via Risk Acceptance.

The Risk Matrix Series - Vulnerability vs. Risk: Perché un CVSS 9.8 non è sempre un'emergenza

C'è un momento di panico ricorrente in molti reparti IT: l'uscita di un nuovo bollettino di sicurezza con una vulnerabilità classificata come CVSS 9.8 (Critical). Immediatamente, si fermano i lavori e si corre a patchare. Ma da IT Security Manager, la domanda che mi pongo è un'altra: quella vulnerabilità rappresenta davvero un rischio per il nostro business?


1. Il punteggio CVSS non è il rischio

Il Common Vulnerability Scoring System (CVSS) misura la severità tecnica di una falla. Ci dice quanto è facile sfruttarla e che tipo di impatto tecnico ha sul sistema isolato. Non ci dice nulla sul contesto aziendale. Il rischio, per definizione, è l'intersezione tra la Probabilità che una minaccia sfrutti una vulnerabilità e l'Impatto (che abbiamo calcolato nel BIA) che questo evento avrebbe sull'asset.


2. Il Potere del Contesto

Facciamo un esempio pratico. Abbiamo la stessa vulnerabilità CVSS 9.8 (Remote Code Execution) su due macchine diverse:

  • Server A: Una macchina di test isolata in una VLAN senza accesso a Internet e senza dati reali.
  • Server B: Il web server esposto su Internet che gestisce l'e-commerce aziendale.

La vulnerabilità è identica, ma il Rischio è abissalmente diverso. Fermare la produzione per patchare urgentemente il Server A è un errore manageriale. Il rischio sul Server A è basso, quasi nullo. Il rischio sul Server B è estremo e richiede un'azione immediata (Risk Mitigation).


3. La Matrice del Rischio per prioritizzare

Una gestione matura della sicurezza non punta a risolvere tutte le vulnerabilità (è impossibile e costoso). Punta a prioritizzare. Utilizzando i dati del Business Impact Assessment, possiamo mappare le vulnerabilità scoperte su una Matrice del Rischio, concentrando il budget e il tempo dei sistemisti solo sulle falle che minacciano i processi critici o i dati sensibili. Il resto può attendere la normale finestra di manutenzione o, in casi estremi, essere gestito tramite Risk Acceptance.

The Risk Matrix Series - From BIA to the Mathematics of Risk (EV, ARO, ALE)

Today I will finally try to put into practice the true purpose for which this site was born: addressing the issue of IT risk management not from the technician's point of view, but from the Board of Directors' perspective. The goal? To justify the choice of security countermeasures (or, alternatively, risk acceptance) based on precise economic data.

To do this, the only logically valid starting point is the BIA (Business Impact Assessment). Why the BIA? Because before we can decide how to manage a risk, we must first quantify how much it would cost us to suffer it. The BIA is the tool that translates the downtime of an IT system or data loss into a tangible economic, operational, or legal impact. Only by holding this "price tag" can we make a rational choice among four different strategies:

  • Risk Acceptance: consciously deciding to do nothing. This choice is opted for when the probability of the risk is very low, its effects are negligible, or when the costs to implement a countermeasure far exceed the estimated potential economic damage.
  • Risk Mitigation: the adoption of countermeasures to reduce the probability of the incident occurring or to limit the extent of the damage itself.
  • Risk Transfer: shifting the economic impact to third parties (e.g., Cyber insurance or SLA clauses with suppliers).
  • Risk Avoidance: eliminating the root cause of the risk, deciding not to start or to halt a project entirely.

The Mathematics of Risk: EV, ARO, and ALE

In quantitative Risk Management, we rely on three fundamental acronyms to justify the budget:

  • EV (Expected Value / Single Loss Expectancy): The financial estimate of a single loss in the event of an incident.
  • ARO (Annualized Rate of Occurrence): The estimated frequency with which the threat is expected to occur in a year.
  • ALE (Annualized Loss Expectancy): The "annual cost of the risk" (EV multiplied by ARO). This number is your maximum justifiable budget to mitigate that specific risk.

A Practical Case Study: The ERP Server

// 1. Calculation of the value exposed per single incident
Asset Value (Server + DB + Production Downtime) = € 100,000
Exposure Factor (Ransomware, total loss) = 100%
EV = € 100,000

// 2. Frequency of the event
Estimated successful ransomware attack (1 time every 5 years)
ARO = 0.2

// 3. Annualized Expected Loss
ALE = EV * ARO
ALE = 100,000 * 0.2
ALE = € 20,000 / year

If, as an IT Manager, I propose an immutable backup solution for €8,000 a year, management will immediately understand the ROI: we are spending €8,000 to zero out a €20,000 risk. Deal done.

The Risk Matrix Series - Dal BIA alla matematica del rischio (EV, ARO, ALE)

Buongiorno. Oggi cercherò finalmente di mettere in pratica il vero proposito per cui è nato questo sito: affrontare la tematica della gestione del rischio IT non dal punto di vista del tecnico, ma dal punto di vista del Board of Directors. L'obiettivo? Motivare la scelta delle contromisure di sicurezza (o, in alternativa, l'accettazione del rischio) basandoci su precisi dati economici.

Per fare questo, l'unico punto di partenza logicamente valido è la BIA (Business Impact Assessment). Perché proprio la BIA? Perché prima di poter decidere come gestire un rischio, dobbiamo prima quantificare quanto ci costerebbe subirlo. La BIA è lo strumento che traduce il blocco di un sistema informatico o la perdita di un dato in un impatto economico, operativo o legale tangibile. Solo avendo in mano questo "cartellino del prezzo" possiamo compiere una scelta razionale tra quattro diverse strategie:

  • Risk Acceptance (Accettazione): decidere consapevolmente di non fare nulla. Si opta per questa scelta quando la probabilità del rischio è molto bassa, i suoi effetti sono trascurabili, oppure quando i costi per implementare una contromisura superano di gran lunga il potenziale danno economico stimato.
  • Risk Mitigation (Mitigazione): l'adozione di contromisure per ridurre la probabilità che l'incidente accada o per limitare l'entità del danno stesso.
  • Risk Transfer (Trasferimento): spostare l'impatto economico su terzi (es. assicurazione Cyber o clausole SLA con i fornitori).
  • Risk Avoidance (Evitamento): eliminare la causa del rischio alla radice, decidendo di non avviare o di interrompere un progetto.

La matematica del rischio: EV, ARO e ALE

Nel Risk Management quantitativo, ci affidiamo a tre acronimi fondamentali per giustificare il budget:

  • EV (Expected Value / Single Loss Expectancy): La stima finanziaria della singola perdita in caso di incidente.
  • ARO (Annualized Rate of Occurrence): La frequenza stimata con cui ci si aspetta che la minaccia si verifichi in un anno.
  • ALE (Annualized Loss Expectancy): Il "costo annuale del rischio" (EV moltiplicato per ARO). Questo numero è il tuo budget massimo giustificabile per mitigare quel rischio.

Un caso di studio pratico: Il server gestionale

// 1. Calcolo del valore esposto per singolo incidente
Valore Asset (Server + DB + Fermo Produzione) = € 100.000
Fattore di Esposizione (Ransomware, perdita totale) = 100%
EV = € 100.000

// 2. Frequenza dell'evento
Stima attacco ransomware a buon fine (1 volta ogni 5 anni)
ARO = 0.2

// 3. Perdita attesa annualizzata
ALE = EV * ARO
ALE = 100.000 * 0.2
ALE = € 20.000 / anno

Se come IT Manager propongo una soluzione di immutabilità dei backup da 8.000€ all'anno, la direzione capirà immediatamente il ROI: stiamo spendendo 8.000€ per azzerare un rischio da 20.000€. Affare fatto.