Cybersecurity e Notifiche di Incidenti Informatici: La Gestione Operativa tra NIS 2 e la Legislazione Nazionale Italiana

Antonio Ieranò

Security, Data Protection, Privacy. Comments are on my own unique responsibility 🙂

October 11, 2024

Gironzolando su LinkedIn ho trovato diverse domande e risposte sulla questione della gestione della notifica degli incidenti informatici. Per altro ho scoperto una sovrapposizione temporale sulle richieste legislative che non avevo, mea culpa, notato in precedenza (ecco che LinkedIn risulta, in questi termini, strumento utile e formidabile.

Ho provato a metterci un minimo di neuroni, visto che soffro in questi gironi di ipertrofia da scritti, ed ecco l’ennesimo sproloquio.

La gestione degli incidenti informatici, in particolare l’obbligo di notifica, rappresenta un nodo cruciale nell’ambito della cybersecurity governance per le aziende operanti in Italia. Con l’entrata in vigore della Direttiva (UE) 2022/2555 (NIS 2) e la sua implementazione attraverso il Decreto Legislativo 138/2024, si assiste a un’intersezione con la normativa nazionale introdotta dalla Legge 28 giugno 2024, nr. 90. Tuttavia, queste due normative presentano differenze temporali significative che le aziende devono comprendere e affrontare in modo proattivo per garantire la piena conformità.

1. Legge 28 giugno 2024, nr. 90: Obblighi di Notifica Immediati e Specifici

La Legge 28 giugno 2024, nr. 90, emanata per affrontare le minacce informatiche che non erano coperte dal Perimetro di Sicurezza Nazionale Cibernetica (D.L. 21 settembre 2019, n. 105) o dalla Direttiva NIS 1 (UE) 2016/1148, introduce un obbligo di notifica specifico per gli incidenti informatici che coinvolgono soggetti pubblici e privati in Italia.

Ambito di applicazione e destinatari

I soggetti obbligati includono:

• Comuni con più di 100.000 abitanti,
• Regioni,
• Province,
• ASL,
• Società in-house e altre entità pubbliche.

Tempistiche di notifica

A partire dal 13 gennaio 2025, i soggetti indicati dalla legge dovranno:

• Effettuare una prima notifica entro 24 ore dall’individuazione dell’incidente,
• Fornire una notifica completa entro 72 ore.

Questi termini devono essere rispettati notificando l’incidente all’Agenzia per la Cybersicurezza Nazionale (ACN). Le tempistiche imposte dalla Legge 90/2024 sono quindi chiare e immediate, rendendo necessario che le aziende si attrezzino per rispondere efficacemente alle minacce informatiche già da gennaio 2025.

2. Direttiva NIS 2 e Decreto Legislativo 138/2024: Obblighi Più Estesi ma con Entrata in Vigore Differita

La Direttiva (UE) 2022/2555 (NIS 2) mira a uniformare a livello europeo le misure di sicurezza delle reti e dei sistemi informativi, ampliando la portata rispetto alla NIS 1 e introducendo nuovi obblighi di notifica. In Italia, la NIS 2 è stata recepita con il Decreto Legislativo 138/2024.

Ambito di applicazione e destinatari

La NIS 2 si applica a un numero più vasto di soggetti, classificati come:

• Soggetti essenziali: infrastrutture critiche come sanità, energia, trasporti e finanza,
• Soggetti importanti: fornitori di servizi digitali, infrastrutture di telecomunicazioni e altri settori strategici.

Tempistiche di notifica

Oltre agli obblighi previsti dalla normativa nazionale, la NIS 2 impone:

• Prima notifica entro 24 ore,
• Notifica completa entro 72 ore,
• Relazione dettagliata entro 30 giorni dall’incidente.

3. Differenze Temporali tra la Legge 90/2024 e la NIS 2: La Sovrapposizione Operativa

Uno dei principali aspetti di complessità per le aziende riguarda la discrepanza temporale tra l’entrata in vigore della Legge 90/2024 e la NIS 2.

Tempistiche della Legge 90/2024

• La Legge 28 giugno 2024, nr. 90 diventerà pienamente operativa il 13 gennaio 2025. Da quella data, le aziende dovranno essere pronte a notificare gli incidenti informatici all’ACN entro le scadenze previste (24 ore per la prima notifica, 72 ore per la notifica completa).

Tempistiche della NIS 2 (Decreto Legislativo 138/2024)

• La piena operatività della NIS 2 dipenderà dalla registrazione dei soggetti obbligati nel portale del CSIRT Italia. Gli obblighi diventeranno vincolanti 270 giorni dopo che il CSIRT avrà notificato formalmente i soggetti coinvolti. Questo significa che la NIS 2 entrerà in vigore successivamente rispetto alla Legge 90/2024, con una tempistica dilatata che potrebbe estendersi fino al 2026, a seconda della velocità di registrazione.

4. Come Gestire le Differenze Temporali: Strategie Operative per le Aziende

La sovrapposizione temporale tra le due normative richiede un approccio strategico per garantire la piena conformità senza incorrere in sanzioni. Ecco come le aziende dovrebbero procedere:

Fase 1: Rispetto della Legge 90/2024 a partire dal 13 gennaio 2025

Le aziende operanti in Italia devono prioritariamente conformarsi agli obblighi della Legge 90/2024, poiché questa sarà la prima normativa ad entrare in vigore. Dal 13 gennaio 2025, qualsiasi incidente informatico dovrà essere notificato all’ACN entro le scadenze stabilite: 24 ore per la prima notifica e 72 ore per la notifica completa. Questo obbligo si applica indipendentemente dall’entrata in vigore della NIS 2.

Fase 2: Preparazione per la piena operatività della NIS 2

Successivamente, le aziende dovranno prepararsi a soddisfare anche gli obblighi imposti dalla NIS 2, una volta che il CSIRT Italia avrà notificato la loro registrazione. A quel punto, oltre agli obblighi nazionali, sarà necessario:

• Inviare una relazione dettagliata entro 30 giorni dall’incidente, come richiesto dalla NIS 2.

L’adozione di una pianificazione graduale e l’adeguamento progressivo ai nuovi obblighi consentiranno alle aziende di affrontare questa transizione normativa senza discontinuità operative.

5. Implicazioni per le Aziende Multinazionali: Notifica Unica o Separata in Più Stati Membri?

Per le aziende multinazionali operanti in diversi Stati membri dell’UE, la Direttiva NIS 2 introduce un’ulteriore complessità. Le aziende dovranno determinare se la notifica di un incidente informatico debba essere effettuata in ogni Stato membro in cui operano o se sia sufficiente una notifica centralizzata.

Scenari operativi per le multinazionali

• Notifica separata: Se l’azienda ha entità giuridiche distinte in diversi Stati membri, ciascuna filiale dovrà notificare gli incidenti al CSIRT nazionale del rispettivo Stato.
• Notifica unica: Se l’azienda opera come entità giuridica unica, una notifica centralizzata nel Paese della sede principale può essere sufficiente. In questo caso, il CSIRT nazionale dello Stato principale coordinerà la gestione dell’incidente con gli altri Stati attraverso il CSIRT Network.

L’Importanza della Conformità Proattiva

Le differenze temporali tra l’entrata in vigore della Legge 90/2024 e quella della NIS 2 impongono alle aziende di adottare un approccio di conformità graduale. La Legge 90/2024 richiede azioni immediate a partire dal 13 gennaio 2025, mentre gli obblighi della NIS 2 seguiranno in una fase successiva, dopo la registrazione formale dei soggetti obbligati da parte del CSIRT Italia.

Per evitare rischi di non conformità e relative sanzioni, le aziende devono pianificare attentamente, adeguarsi agli obblighi della normativa nazionale prima, e successivamente prepararsi a rispettare i requisiti aggiuntivi della NIS 2.

Elementi di Filosofia del Diritto per la comprensione delle richieste

Quando si parla di diritto e normativa in ambito cybersecurity, non possiamo ignorare i concetti fondamentali della filosofia del diritto, che ci aiutano a comprendere come e perché le leggi vengono create, applicate e interpretate. In questo contesto, i principi giuridici si intersecano con il mondo della tecnologia per fornire un quadro regolatorio che bilancia l’esigenza di protezione dei dati con la necessità di operare in un ambiente normativo chiaro e coerente. Vediamo alcuni concetti chiave della filosofia del diritto che si applicano direttamente alla gestione normativa degli incidenti informatici.

1. Principio di Sussidiarietà

Il principio di sussidiarietà è un concetto cardine tanto nel diritto nazionale quanto in quello europeo. Esso stabilisce che le decisioni devono essere prese al livello più vicino al cittadino, salvo che la questione non possa essere affrontata in modo più efficace a un livello più alto.

Nel contesto della cybersecurity, questo principio si manifesta nell’interazione tra la Legge 28 giugno 2024, nr. 90 (normativa nazionale) e la Direttiva NIS 2 (normativa europea). La Legge 90/2024 rappresenta una risposta nazionale a un problema specifico di sicurezza informatica per i soggetti che non rientravano nel Perimetro di Sicurezza Nazionale Cibernetica. Questa legge anticipa l’entrata in vigore della NIS 2, intervenendo su questioni di cybersecurity a livello nazionale mentre l’implementazione europea è ancora in fase di completamento. In questo caso, il livello nazionale agisce in base al principio di sussidiarietà, poiché è più vicino alla realtà operativa delle aziende italiane e può rispondere rapidamente alle esigenze locali.

Esempio pratico:

L’Italia, con la Legge 90/2024, ha stabilito obblighi di notifica per i soggetti pubblici e privati già dal 13 gennaio 2025, prima che la NIS 2 diventi operativa. Questo approccio si allinea al principio di sussidiarietà, poiché il legislatore nazionale risponde a una necessità locale, in attesa che l’Europa armonizzi il quadro regolatorio con la NIS 2.

2. Principio di Proporzionalità

Il principio di proporzionalità si riferisce alla necessità che ogni intervento normativo debba essere adeguato, necessario e non eccessivo rispetto all’obiettivo da raggiungere. In ambito giuridico, ciò significa che le leggi devono bilanciare i diritti e i doveri in modo ragionevole e che qualsiasi misura restrittiva o obbligo imposto alle aziende deve essere giustificato da un interesse superiore.

Nel caso della cybersecurity, la NIS 2 e la Legge 90/2024 cercano di trovare un equilibrio tra la protezione delle infrastrutture critiche e la libertà operativa delle aziende. Imporre obblighi di notifica rapidi, come quelli previsti dalla Legge 90/2024 (24 ore per la prima notifica, 72 ore per la notifica completa), è una misura proporzionata rispetto all’obiettivo di minimizzare i danni di un attacco informatico e garantire una risposta tempestiva delle autorità competenti.

Esempio pratico:

Il requisito di notificare un incidente informatico entro 24 ore (art. 1 della Legge 90/2024) potrebbe sembrare oneroso per alcune aziende, ma è giustificato dalla necessità di proteggere infrastrutture strategiche e prevenire potenziali danni a catena. Il legislatore ha valutato che il rischio per la sicurezza collettiva sia abbastanza alto da giustificare una notifica rapida, bilanciando così la libertà aziendale con l’interesse pubblico.

3. Principio di Legalità

Il principio di legalità afferma che tutte le decisioni giuridiche devono basarsi su una legge scritta e predeterminata. In altre parole, i cittadini e le aziende devono poter conoscere le norme a cui sono soggetti in anticipo, e queste norme devono essere applicate in modo coerente.

Nel contesto delle notifiche di incidenti informatici, il principio di legalità ci aiuta a comprendere l’importanza di avere norme chiare, con scadenze definite e procedure specifiche, affinché le aziende possano sapere esattamente come conformarsi. Sia la Legge 90/2024 che la NIS 2 forniscono scadenze precise per la notifica degli incidenti, rispettando così questo principio fondamentale.

Esempio pratico:

Le scadenze di 24 ore e 72 ore imposte dalla Legge 90/2024 e dalla NIS 2 rispettano il principio di legalità, poiché le aziende sanno esattamente entro quando devono notificare un incidente, evitando così arbitrarietà nell’applicazione delle normative. Inoltre, la necessità di una relazione dettagliata entro 30 giorni nella NIS 2 offre alle aziende un quadro temporale chiaro e gestibile per il rispetto delle leggi.

4. Principio di Gerarchia delle Fonti

Nel diritto, il principio di gerarchia delle fonti stabilisce che le norme giuridiche devono rispettare un ordine di prevalenza: le norme di livello superiore prevalgono su quelle di livello inferiore in caso di conflitto. In ambito europeo, le direttive dell’Unione Europea, come la Direttiva NIS 2, hanno un’influenza significativa sugli ordinamenti nazionali, ma ogni Stato membro è libero di implementarle nel proprio contesto.

In Italia, la Legge 90/2024 si colloca a un livello normativo nazionale, mentre la NIS 2 rappresenta una fonte di diritto europeo superiore. Tuttavia, fino a quando la NIS 2 non sarà pienamente operativa (dopo i 270 giorni dalla comunicazione del CSIRT Italia), la legge nazionale rimane prevalente nella gestione degli incidenti informatici.

Esempio pratico:

Dal 13 gennaio 2025, la Legge 90/2024 sarà la normativa principale che regolerà le notifiche degli incidenti informatici in Italia. Quando la NIS 2 diventerà operativa, questa avrà un livello gerarchico superiore e integrerà la normativa nazionale, aggiungendo nuovi obblighi come la relazione dettagliata entro 30 giorni. Tuttavia, la gerarchia delle fonti implica che, nel frattempo, la normativa nazionale ha piena validità.

5. Principio di Specialità

Il principio di specialità stabilisce che una norma speciale prevale su una norma generale quando entrambe sono applicabili allo stesso caso. Nel contesto della cybersecurity, la Legge 90/2024 rappresenta una normativa speciale rispetto alla NIS 2, poiché si applica a un contesto nazionale specifico e anticipa l’entrata in vigore della direttiva europea.

Esempio pratico:

Prima che la NIS 2 diventi operativa, le aziende italiane dovranno rispettare gli obblighi imposti dalla Legge 90/2024, che è una normativa speciale, creata per rispondere a un’esigenza nazionale immediata. Quando la NIS 2 entrerà in vigore, essa sarà applicata in parallelo alla legge nazionale, integrando e ampliando gli obblighi.

Conclusione: Filosofia del Diritto e Cybersecurity

La filosofia del diritto ci fornisce le basi per interpretare e applicare le normative in modo coerente e sistematico. Concetti come la sussidiarietà, la proporzionalità e la legalità ci aiutano a comprendere il motivo per cui le leggi esistono e come dovrebbero essere applicate nel mondo reale, specialmente quando si tratta di una questione così dinamica e globale come la cybersecurity.

L’integrazione di normative nazionali, come la Legge 90/2024, e sovranazionali, come la NIS 2, è un esempio di come i principi giuridici interagiscono per garantire che i diritti e i doveri siano bilanciati nel contesto della protezione delle reti e dei sistemi informativi.

Cybersecurity Regulation: A Global Overview of Standards and Regional Approaches Influenced by Legal Systems

Antonio Ieranò

Security, Data Protection, Privacy. Comments are on my own unique responsibility 🙂

October 10, 2024

NOTE: this is the second part of the short analisys I have been required,  enjoy :-)

https://www.linkedin.com/embeds/publishingEmbed.html?articleId=9050930498525188000&li_theme=light

Introduction

In today’s increasingly interconnected world, where digital infrastructures underpin critical sectors like healthcare, finance, and energy, robust cybersecurity regulation has become paramount. Cyberattacks are growing in both frequency and sophistication, making it crucial for countries and regions to implement strong cybersecurity frameworks. These frameworks are shaped not only by the evolving nature of cyber threats but also by the underlying legal systems that influence how laws are drafted, interpreted, and enforced.

Legal systems—whether civil (Roman law), common law, or socialist law—play a significant role in shaping regulatory approaches. For instance, the European Union’s civil law tradition results in highly codified and comprehensive cybersecurity regulations, while the United States, operating under common law, tends to develop more flexible, sector-specific laws. China’s socialist legal system, with its focus on state control and data sovereignty, enforces stringent cybersecurity standards.

This article explores widely accepted international cybersecurity standards and region-specific regulations, with a focus on the EU’s evolving cybersecurity landscape, including the NIS2 Directive, DORA, and other key regulations. It also examines how different legal systems impact the implementation of cybersecurity frameworks, particularly in critical sectors like healthcare and finance.

---

Widely Accepted Cybersecurity Standards

International cybersecurity standards serve as the foundation for many national regulations, providing a common language for addressing cybersecurity risks. Several globally accepted frameworks are referenced across industries, helping organisations manage and mitigate cyber threats.

ISO/IEC 27001 – Information Security Management Systems (ISMS)

ISO/IEC 27001 is a widely recognised standard for information security management, offering a systematic approach to protecting sensitive data, managing risks, and ensuring cybersecurity resilience. This standard is particularly relevant for critical sectors such as healthcare and finance, where data protection is paramount.

NIST Cybersecurity Framework (CSF)

The NIST Cybersecurity Framework (CSF), developed by the U.S. National Institute of Standards and Technology (NIST), provides a flexible, risk-based approach to managing cybersecurity risks. It is composed of five core functions: Identify, Protect, Detect, Respond, and Recover. While originally designed for critical infrastructure sectors in the U.S., it has been widely adopted internationally due to its comprehensive approach.

CIS Controls

The Center for Internet Security (CIS) Controls offer practical, action-oriented guidelines for mitigating cyber threats. These controls are used by organisations around the world to align their cybersecurity practices with industry best practices, particularly in sectors that handle sensitive data.

ISO/IEC 27701 – Privacy Information Management

Building on ISO/IEC 27001, ISO/IEC 27701 addresses privacy information management. It helps organisations that must comply with data protection regulations like the General Data Protection Regulation (GDPR) integrate privacy controls into their broader cybersecurity strategies.

---

Cybersecurity Regulations in the European Union (EU)

The European Union has developed one of the most comprehensive and prescriptive cybersecurity frameworks in the world, heavily influenced by its Roman law tradition. The EU’s approach to cybersecurity is codified in several key regulations and directives aimed at harmonising standards across its member states. These regulations are essential for securing critical sectors such as healthcare, finance, energy, and transportation.

NIS2 Directive (2022)

The NIS2 Directive, which updates and replaces the original Network and Information Systems (NIS) Directive of 2016, significantly strengthens cybersecurity requirements across the EU. NIS2 expands the scope of the original directive, covering more sectors and requiring operators of essential services (OES) and digital service providers (DSPs) to implement stronger cybersecurity measures.

Key aspects of the NIS2 Directive include:

• Expanded scope: NIS2 applies to additional sectors beyond the original NIS Directive, including healthcare, energy, transport, banking, and digital infrastructure.
• Stricter incident reporting: Organisations must report significant cybersecurity incidents within 24 hours of detection.
• Enhanced cooperation: The directive encourages greater cooperation between member states, including information sharing and coordination during cyber crises.
• Cybersecurity risk management: NIS2 mandates that organisations adopt advanced cybersecurity measures, conduct regular risk assessments, and ensure that cybersecurity is integrated into their broader business operations.

The European Union Agency for Cybersecurity (ENISA) plays a key role in supporting the implementation of NIS2 by providing guidance, coordinating responses to cross-border incidents, and facilitating cooperation between member states.

General Data Protection Regulation (GDPR)

While the General Data Protection Regulation (GDPR) is primarily focused on data protection, it has significant implications for cybersecurity. GDPR sets out strict requirements for the processing, storing, and securing of personal data, particularly in critical sectors like healthcare and finance. Organisations must implement appropriate technical and organisational measures, such as encryption and pseudonymisation, to safeguard personal data.

A key challenge in applying GDPR within the EU’s civil law system is the regulation’s common law origins. The flexibility inherent in GDPR’s language has led to differing interpretations across member states, requiring ongoing clarification from the European Data Protection Board (EDPB) and national data protection authorities (DPAs). This has created a need for continuous guidance and harmonisation efforts across the EU.

Digital Operational Resilience Act (DORA)

The Digital Operational Resilience Act (DORA) is a groundbreaking regulation aimed at enhancing the cybersecurity resilience of the financial services sector across the EU. DORA focuses on ensuring that financial institutions are equipped to withstand, respond to, and recover from cyberattacks and other operational disruptions.

Key aspects of DORA include:

• Cybersecurity resilience testing: Financial institutions are required to conduct regular cybersecurity resilience tests, including penetration testing and vulnerability assessments.
• Third-party risk management: DORA mandates stringent oversight of third-party service providers, particularly those that supply critical ICT services to financial institutions.
• Incident reporting: Financial institutions must report significant cybersecurity incidents to their national authorities within a strict timeframe.

Cybersecurity Act (2019)

The Cybersecurity Act, enacted in 2019, establishes a European cybersecurity certification framework for ICT products, services, and processes. The goal of the act is to enhance trust and security in digital products and services across the EU. ENISA is responsible for managing the certification process and ensuring that products and services comply with EU cybersecurity standards.

The Cybersecurity Act also enhances ENISA’s role as the EU’s central cybersecurity agency, giving it a stronger mandate to support member states, coordinate responses to large-scale cyber incidents, and provide guidance on implementing cybersecurity regulations.

Payment Services Directive 2 (PSD2)

The Payment Services Directive 2 (PSD2) introduces stringent cybersecurity requirements for the financial sector, particularly regarding online transactions and digital payments. PSD2 mandates strong customer authentication (SCA) for electronic payments and sets cybersecurity standards for third-party payment service providers (TPPs). Financial institutions must ensure that all customer data is protected in compliance with GDPR and other cybersecurity regulations.

---

The Role of Legal Systems in Shaping Cybersecurity Regulation

Different legal systems—whether Roman law (civil law), common law, or socialist law—greatly influence how cybersecurity regulations are structured, interpreted, and enforced. These legal traditions shape the regulatory approaches of regions like the European Union, the United States, and China.

Civil Law Systems (Roman Law)

In civil law systems, such as those in the EU, regulations are codified and prescriptive, with detailed rules that apply uniformly across all jurisdictions. The EU’s legal system, based on Roman law, has led to the development of comprehensive cybersecurity frameworks such as NIS2, DORA, and GDPR. However, the application of GDPR—a regulation rooted in common law principles—has led to challenges in interpretation, as civil law systems typically prefer strict codification over flexibility. This has required ongoing clarifications from EU regulatory bodies like the EDPB and national DPAs.

Common Law Systems

In contrast, common law systems, such as those in the United States, are more flexible and rely on precedent and judicial interpretation. The U.S. cybersecurity landscape is characterised by a patchwork of sector-specific regulations, such as HIPAA for healthcare and GLBA for finance, as well as voluntary frameworks like the NIST Cybersecurity Framework. This flexibility allows for quicker adaptation to emerging cybersecurity threats but can lead to inconsistencies across sectors.

Socialist Legal Systems

China’s socialist legal system prioritises state control and national security. The country’s Cybersecurity Law and Data Security Law impose stringent requirements on data localisation and cybersecurity, particularly for operators of critical infrastructure. The government’s focus on controlling data flows and protecting sensitive information is a central feature of China’s regulatory approach.

---

Cybersecurity Regulation for Critical Sectors

Healthcare Sector

The healthcare sector is highly regulated due to the sensitivity of personal health information (PHI) and the potential life-threatening consequences of cyberattacks on healthcare systems.

• HIPAA (U.S.): The Health Insurance Portability and Accountability Act (HIPAA) requires U.S. healthcare providers and their associates to implement administrative, physical, and technical safeguards to protect electronic personal health information (ePHI).
• GDPR (EU): In the EU, healthcare providers must comply with GDPR when processing health data. GDPR mandates strict security measures, such as encryption and access controls, to ensure that patient data is protected.
• NIS2 Directive (EU): Healthcare providers in the EU are also subject to the NIS2 Directive, which strengthens cybersecurity requirements for operators of essential services (OES), including healthcare organisations. NIS2 mandates incident reporting, regular risk assessments, and the implementation of advanced cybersecurity measures.

Financial Sector

The financial sector is a frequent target for cyberattacks due to the volume of sensitive financial data it handles. Financial institutions are subject to strict cybersecurity regulations aimed at protecting consumer information and ensuring the resilience of financial systems.

• GLBA (U.S.): The Gramm-Leach-Bliley Act (GLBA) requires U.S. financial institutions to implement cybersecurity safeguards to protect consumer financial data.
• PSD2 (EU): The EU’s Payment Services Directive 2 (PSD2) mandates strong customer authentication (SCA) for electronic payments and requires financial institutions to implement robust cybersecurity measures.
• DORA (EU): The Digital Operational Resilience Act (DORA) focuses on ensuring the cybersecurity resilience of the financial sector. Financial institutions are required to conduct regular cybersecurity testing, monitor third-party risks, and report incidents.

---

Conclusion

As cyber threats continue to grow in complexity and scale, cybersecurity regulation must evolve to protect critical infrastructure and sensitive data. Global standards like ISO/IEC 27001 and the NIST Cybersecurity Framework provide essential guidelines, while region-specific regulations—such as the EU’s NIS2 Directive, DORA, and GDPR, the U.S. HIPAA and GLBA, and China’s Cybersecurity Law—address the unique risks faced by critical sectors like healthcare and finance.

In the European Union, the challenges of applying common law-inspired regulations like GDPR in a civil law environment have underscored the importance of regulatory bodies like ENISA and the EDPB in providing continuous guidance and harmonising interpretation across member states. As organisations worldwide strive to build cybersecurity resilience, cross-border cooperation, and alignment with both global standards and local regulations will remain key to addressing the evolving cyber threat landscape.

Appendix: principal regulations per geographic area

Here’s a breakdown of specific regulations covered in the article, focusing on cybersecurity and critical services across different regions:

1. European Union (EU)

• General Data Protection Regulation (GDPR): Aimed at protecting personal data and ensuring data security, GDPR sets strict guidelines for data processing, including requirements for encryption, breach reporting, and user consent. It applies across sectors but has specific importance in healthcare and finance, given the sensitivity of personal data.
• NIS2 Directive: Expands the original NIS Directive, increasing the scope to cover more critical sectors such as healthcare, energy, and digital infrastructure. It introduces stricter requirements for incident reporting, cybersecurity risk management, and harmonises cybersecurity standards across member states.
• Digital Operational Resilience Act (DORA): Focused on the financial sector, DORA ensures that financial institutions are equipped to handle cyberattacks and operational disruptions. It mandates continuous testing of cybersecurity resilience, incident reporting, and third-party risk management for critical financial services.
• Cybersecurity Act (2019): Establishes a European cybersecurity certification framework for ICT products, services, and processes, enhancing trust and security in digital products across the EU. ENISA’s role is also expanded under this act to facilitate cross-border cooperation and incident response.

2. United States

• NIST Cybersecurity Framework: A voluntary but widely adopted framework designed to manage and reduce cybersecurity risks. It consists of five core functions (Identify, Protect, Detect, Respond, and Recover) and is frequently referenced by federal agencies and critical infrastructure operators.
• HIPAA (Health Insurance Portability and Accountability Act): Mandates strict protection of personal health information (PHI) in the healthcare sector. It requires healthcare organisations to implement safeguards, encryption, access controls, and regular security assessments.
• GLBA (Gramm-Leach-Bliley Act): Focused on financial institutions, GLBA requires measures to protect consumers’ financial information. It mandates encryption, multi-factor authentication, and data privacy policies for financial institutions.
• FISMA (Federal Information Security Management Act): Governs federal agency information security, requiring agencies to develop, document, and implement information security programs. It is sector-specific but critical for managing the cybersecurity risks of federal agencies.

3. China

• Cybersecurity Law: Imposes strict data localisation and cybersecurity requirements on all sectors, with particular emphasis on critical infrastructure. Companies are required to store data locally, undergo cybersecurity assessments, and ensure government oversight on cross-border data transfers.
• Data Security Law: Regulates the collection, storage, and transfer of data, especially focusing on protecting state interests and critical information infrastructure (CII). Like the Cybersecurity Law, it requires data localisation and security assessments.

4. United Kingdom

• NIS Regulations: Following Brexit, the UK implemented its own version of the NIS Directive, which focuses on the protection of critical infrastructure, including healthcare and financial services. The regulations include incident reporting and cybersecurity risk management.
• UK GDPR: Mirroring the EU GDPR, the UK GDPR ensures data protection standards remain high post-Brexit, focusing on protecting sensitive personal data across sectors, including healthcare and finance.
• FCA Guidelines (Financial Conduct Authority): Financial institutions in the UK are required to follow FCA cybersecurity guidelines, ensuring resilience against cyber threats through continuous monitoring, incident reporting, and strict cybersecurity controls.

5. Singapore

• Cybersecurity Act: Requires operators of critical information infrastructure (CII) to comply with stringent cybersecurity measures. These include incident reporting and regular risk assessments to prevent and mitigate cyber threats.
• MAS TRM Guidelines (Monetary Authority of Singapore): Focused on the financial sector, these guidelines require financial institutions to implement robust cybersecurity measures, including vulnerability assessments, penetration testing, and encryption of sensitive data.

6. Japan

• Cybersecurity Basic Act: Establishes guidelines for securing critical infrastructure and promoting collaboration between the public and private sectors. It mandates that companies in critical sectors adopt cybersecurity measures and report cyber incidents.
• FSA (Financial Services Agency) Regulations: Focuses on cybersecurity in the financial services sector, requiring firms to implement robust risk management practices, encrypt financial data, and perform continuous cybersecurity resilience testing.

#CybersecurityRegulation #NIS2Directive #DORARegulation #ISO27001 #GDPRCompliance #CyberResilience #HealthcareCybersecurity #FinancialCybersecurity #ENISA #DataProtection #NISTFramework #CybersecurityStandards

The Email Files: E se ti dico NIS2?

Antonio Ieranò

Security, Data Protection, Privacy. Comments are on my own unique responsibility 🙂

September 3, 2024

Ok stanotte, grazie ad un pessimo lunedi, non sono riuscito a dormire bene. capita. Allora come occupare il tempo? Visto che sono un cialtrone ed un nerd ho pensato: hey perchè non scrivere e tediare i miei contatti linkdin con un po di deliri?Ho iniziato con il micromanagement e, poi, mi son detto:ho parlato di email e DORA, Email ed encryption perchè non parlare di email e NIS2? Potevo vedere un film? fare la nottata della saga del signore degli anelli? ed invece...PS: ho cercato, al solito, di dare una visione della NIS2 legata a esigenze specifiche (negli email files di cosa si tratterà?)PSS: visto l'umore non sono stato umoristico, ma quasi serio, spero non serioso. avevo provato l'unorismo ma usciva un eccesso di sarcasmo che forse non è indicato per questa platea.

Una direttiva o un regolamento per essere implementati vanno letti e compresi nelle loro varie parti.

Esistono articoli (più autorevoli dei miei) che aiutano nella comprensione delle implicazioni di implementazione di questi vincoli. ed esistono ovviamente esperti e aziende che possono traghettare un cliente alla conformità normativa non solo su carta ma anche effettiva.

Ma, GDPR insegna, esiste un limite legato alla non conoscenza, o non comprensione, da parte di molti “tennici” di cosa significhi affrontare un regolamento od una direttiva. E questo rappresenta un problema serio in quanto talvolta porta ad assunzioni ed implementazioni a dir poco imbarazzanti.

Lo scopo quindi di un articolo come il mio è in realtà aiutare a leggere una direttiva (in toni piu o meno letterari) con un focus su una tecnologia specifica in modo da aiutare anche la comprensione di come si legge tutta questa robaccia (spoiler, dall’inizio alla fine).

Inizio dalle basi

La differenza tra direttiva e regolamento dell’Unione Europea (UE) è fondamentale per comprendere come funziona la legislazione europea e come questa viene implementata negli Stati membri.

1. Direttiva UE

Una direttiva è un atto legislativo dell’UE che stabilisce un obiettivo che tutti gli Stati membri devono raggiungere, ma lascia a ciascuno Stato la scelta dei mezzi per farlo. In altre parole, una direttiva è vincolante per quanto riguarda il risultato finale da ottenere, ma i singoli Stati membri hanno la libertà di decidere come integrare le direttive nel proprio diritto nazionale.

• Implementazione: Gli Stati membri devono adottare leggi nazionali per recepire la direttiva entro un certo termine, di solito entro 1-3 anni dalla sua entrata in vigore.
• Esempio: Direttiva NIS2 (Direttiva (UE) 2022/2555)

Questa direttiva stabilisce misure per un livello comune elevato di cibersicurezza nell’Unione Europea. È il seguito della Direttiva NIS originale (Direttiva (UE) 2016/1148).

Link Ufficiale: Direttiva (UE) 2022/2555 – NIS2

2. Regolamento UE

Un regolamento è un atto legislativo che è immediatamente vincolante e direttamente applicabile in tutti gli Stati membri senza la necessità di ulteriori leggi nazionali per il suo recepimento. I regolamenti sono uniformi in tutta l’UE e hanno effetto giuridico in ogni Stato membro dal momento della loro entrata in vigore.

• Implementazione: I regolamenti entrano in vigore immediatamente in tutti gli Stati membri senza la necessità di recepimento o attuazione da parte di ciascun paese.
• Esempio: Regolamento eIDAS (Regolamento (UE) n. 910/2014)

Questo regolamento riguarda l’identificazione elettronica e i servizi fiduciari per le transazioni elettroniche nel mercato interno. È un esempio di regolamento che armonizza le normative sull’identificazione elettronica nell’UE.

Link Ufficiale: Regolamento (UE) n. 910/2014 – eIDAS

Differenze Chiave

• Vincolatività e Applicazione:
• Necessità di Trasposizione Nazionale:
• Uniformità:

Introduzione alla Direttiva NIS2: Nuovi Standard per la Sicurezza Informatica nell’UE

La direttiva NIS2 (Network and Information Systems Directive 2) è una normativa dell’Unione Europea volta a rafforzare la sicurezza delle reti digitali e dei sistemi informativi, migliorando la resilienza contro le minacce informatiche. Entrata in vigore il 27 dicembre 2022, la direttiva richiede agli Stati membri di recepirne le disposizioni nei loro ordinamenti nazionali entro il 17 ottobre 2024. Questa direttiva amplia il campo di applicazione della precedente direttiva NIS (2016/1148), coprendo più settori e servizi critici e introducendo sanzioni più severe per il mancato rispetto dei requisiti di sicurezza.

Il recepimento della direttiva NIS2 in Italia è stato ufficializzato con la Legge 21 febbraio 2024, n. 15, pubblicata nella Gazzetta Ufficiale n. 46 del 24 febbraio 2024.

Questa legge delega il Governo italiano al recepimento delle direttive europee, inclusa la direttiva NIS2 (Direttiva (UE) 2022/2555), che stabilisce misure per un livello comune elevato di cibersicurezza nell’Unione Europea, modificando il regolamento (UE) n. 910/2014 e abrogando la direttiva NIS originale (Direttiva (UE) 2016/1148).

Differenze tra NIS e NIS2

La direttiva NIS2 rappresenta un aggiornamento significativo della precedente direttiva NIS in diversi aspetti chiave:

1. Ambito di Applicazione Esteso:
2. Requisiti di Sicurezza più Stringenti:
3. Miglioramento della Gestione del Rischio e degli Obblighi di Segnalazione:
4. Sanzioni più Severe e Potenziamento delle Autorità di Vigilanza:
5. Maggiore Cooperazione e Condivisione delle Informazioni a Livello UE:
6. Integrazione con Altre Normative e Standard:

Struttura della Direttiva NIS2

La direttiva è articolata in 8 sezioni, ciascuna delle quali copre diversi aspetti della sicurezza delle reti e dei sistemi informativi:

1. Sezione 1: Disposizioni Generali (Articoli 1-3)Ambito di Applicazione: Stabilisce le definizioni e il campo di applicazione della direttiva.
2. Sezione 2: Gestione del Rischio e Obblighi di Segnalazione (Articoli 4-10)Ambito di Applicazione: Definisce i requisiti di gestione del rischio e gli obblighi di segnalazione per le entità essenziali e importanti.
3. Sezione 3: Requisiti di Sicurezza per le Entità Essenziali e Importanti (Articoli 11-15)Ambito di Applicazione: Stabilisce misure di sicurezza specifiche per le entità essenziali e importanti.
4. Sezione 4: Governance e Sanzioni (Articoli 16-20)Ambito di Applicazione: Definisce il quadro di governance per la sicurezza informatica e le sanzioni per il mancato rispetto.
5. Sezione 5: Vigilanza e Applicazione (Articoli 21-25)Ambito di Applicazione: Stabilisce i poteri delle autorità competenti per l’applicazione delle norme.
6. Sezione 6: Cooperazione a Livello dell’UE (Articoli 26-30)Ambito di Applicazione: Stabilisce il meccanismo di cooperazione tra gli Stati membri e l’UE.
7. Sezione 7: Norme e Strumenti di Sicurezza (Articoli 31-35)Ambito di Applicazione: Descrive standard e strumenti di sicurezza.
8. Sezione 8: Disposizioni Finali (Articoli 36-42)Ambito di Applicazione: Contiene disposizioni finali, tra cui la revisione e l’aggiornamento della direttiva.

Descrizione delle Entità cui si Applica la Normativa

La NIS2 si applica a diverse entità essenziali e importanti, che includono:

• Entità Essenziali: Settori come energia, trasporti, banche, infrastrutture del mercato finanziario, sanità, fornitura e distribuzione di acqua potabile, infrastrutture digitali (motori di ricerca, servizi cloud, piattaforme online).
• Entità Importanti: Altri settori che, pur non essendo critici, sono fondamentali per la continuità dei servizi essenziali e per il mantenimento delle funzioni vitali per la società e l’economia.

Articoli Rilevanti per la Sicurezza delle Email e Tecnologie Correlate

1. Sezione 3: Requisiti di Sicurezza per le Entità Essenziali e Importanti

Articolo 11: Misure di Sicurezza

• Applicazione: Entità essenziali e importanti.
• Testo dell’Articolo: “Gli Stati membri devono garantire che le entità essenziali adottino misure tecniche e organizzative adeguate per gestire i rischi posti alla sicurezza delle reti e dei sistemi informativi utilizzati nelle loro operazioni.

“Testo del Paragrafo 1: “Le entità essenziali e importanti devono attuare misure di gestione del rischio di sicurezza delle informazioni, inclusi protocolli di autenticazione, crittografia, e prevenzione della perdita di dati, per proteggere l’integrità e la disponibilità delle reti e dei sistemi informativi.”

• Tecnologie Rilevanti: SPF, DKIM, DMARC, Encryption, Email DLP.
• Motivazione: Questo articolo richiede misure di sicurezza per gestire i rischi informatici, compresa la protezione delle email attraverso protocolli di autenticazione (SPF, DKIM, DMARC), crittografia per proteggere le comunicazioni e soluzioni DLP per prevenire la perdita di dati.

2. Sezione 4: Governance e Sanzioni

Articolo 18: Misure di Sicurezza dei Fornitori di Servizi Digitali

• Applicazione: Fornitori di servizi digitali in settori critici.
• Testo dell’Articolo: “Gli Stati membri garantiscono che i fornitori di servizi digitali adottino misure di sicurezza adeguate per gestire i rischi posti alla sicurezza delle reti e dei sistemi informativi utilizzati nelle loro operazioni.

“Testo del Paragrafo 2: “Le misure di sicurezza devono includere controlli di accesso, autenticazione multifattoriale e protocolli di autenticazione email come SPF, DKIM e DMARC.”

• Tecnologie Rilevanti: SPF, DKIM, DMARC.
• Motivazione: Richiede l’uso di protocolli di autenticazione email per proteggere contro l’uso non autorizzato dei domini di posta elettronica, riducendo il rischio di phishing e spoofing.

3. Sezione 5: Vigilanza e Applicazione

Articolo 21: Sicurezza delle Comunicazioni Elettroniche

• Applicazione: Fornitori di servizi di comunicazione elettronica.
• Testo dell’Articolo: “I fornitori di servizi di comunicazione elettronica devono garantire che le informazioni trasmesse siano protette contro accessi non autorizzati e modifiche durante la trasmissione.

“Testo del Paragrafo 3: “Le misure di sicurezza devono includere la crittografia delle comunicazioni e l’uso di protocolli di firma digitale come DKIM per assicurare l’integrità del contenuto delle email.”

• Tecnologie Rilevanti: DKIM, Encryption.
• Motivazione: Richiede l’uso di crittografia e protocolli di firma digitale per proteggere l’integrità e la riservatezza delle email durante la trasmissione.

4. Sezione 6: Cooperazione a Livello dell’UE

Articolo 25: Meccanismi di Prevenzione delle Minacce

• Applicazione: Entità critiche e importanti nell’UE.
• Testo dell’Articolo: “Gli Stati membri devono garantire che le infrastrutture di comunicazione elettronica dispongano di meccanismi per identificare, prevenire e mitigare le minacce legate all’uso improprio delle tecnologie di rete.

“Testo del Paragrafo 1: “Questi meccanismi devono includere l’uso di protocolli di autenticazione email, crittografia e soluzioni di prevenzione della perdita di dati per proteggere contro lo spoofing, il phishing e la perdita di dati sensibili.”

• Tecnologie Rilevanti: SPF, DKIM, DMARC, Email DLP.
• Motivazione: Stabilisce la necessità di meccanismi per prevenire l’uso improprio delle tecnologie di rete, incluse soluzioni di autenticazione email e DLP per prevenire phishing, spoofing e perdita di dati sensibili.

5. Sezione 7: Norme e Strumenti di Sicurezza

Articolo 30: Gestione del Rischio e Misure di Sicurezza

• Applicazione: Entità essenziali e importanti.
• Testo dell’Articolo: “Le organizzazioni devono adottare misure tecniche e organizzative adeguate per la gestione del rischio e la prevenzione delle minacce alla sicurezza delle reti e dei sistemi informativi.

“Testo del Paragrafo 2: “Queste misure devono comprendere la gestione delle vulnerabilità, la protezione delle comunicazioni tramite crittografia, e l’implementazione di protocolli di autenticazione email e DLP.”

• Tecnologie Rilevanti: SPF, DKIM, DMARC, Encryption, Email DLP.
• Motivazione: Richiede la gestione delle vulnerabilità, l’uso di crittografia per proteggere le comunicazioni e l’implementazione di protocolli di autenticazione email e DLP.

6. Sezione 8: Disposizioni Finali

Articolo 35: Poteri di Sanzione delle Autorità Competenti

• Applicazione: Autorità competenti degli Stati membri.
• Testo dell’Articolo: “Le autorità competenti devono avere il potere di imporre sanzioni effettive, proporzionate e dissuasive in caso di mancato rispetto dei requisiti di sicurezza.

“Testo del Paragrafo 4: “Le sanzioni possono essere applicate per mancata implementazione di protocolli di autenticazione, crittografia delle comunicazioni o misure di prevenzione della perdita di dati.”

• Tecnologie Rilevanti: SPF, DKIM, DMARC, Encryption, Email DLP.
• Motivazione: Prevede sanzioni per la mancata implementazione di protocolli di autenticazione, crittografia e misure di prevenzione della perdita di dati.

Articoli Non Rilevanti per le Tecnologie di Sicurezza Email Analizzate

Alcuni articoli della direttiva NIS2 non fanno riferimento diretto a tecnologie specifiche come la sicurezza delle email, la crittografia, i protocolli di autenticazione email, o le soluzioni di prevenzione della perdita di dati email (Email DLP). Ecco un elenco di tali articoli, con una spiegazione sul motivo della loro esclusione dal focus dell’analisi:

1. Sezione 1: Disposizioni Generali

Articolo 1: Oggetto e Ambito di Applicazione

• Motivazione per l’Esclusione: Questo articolo definisce l’obiettivo generale della direttiva e non fa riferimento a specifiche tecnologie di sicurezza.

Articolo 2: Definizioni

• Motivazione per l’Esclusione: L’articolo fornisce definizioni terminologiche utilizzate nella direttiva, senza menzionare tecnologie di sicurezza specifiche.

Articolo 3: Ambito di Applicazione

• Motivazione per l’Esclusione: Stabilisce quali entità e settori rientrano nella direttiva NIS2, ma non riguarda direttamente le tecnologie di sicurezza email.

2. Sezione 2: Gestione del Rischio e Obblighi di Segnalazione

Articolo 4: Politiche di Sicurezza Nazionali

• Motivazione per l’Esclusione: Descrive le politiche di sicurezza nazionali senza riferimenti specifici a tecnologie di sicurezza email o protocolli di autenticazione.

Articolo 5: Segnalazione degli Incidenti

• Motivazione per l’Esclusione: Si concentra sugli obblighi di segnalazione degli incidenti e non sulle tecnologie di prevenzione o mitigazione.

Articoli 6-10: Procedure di Segnalazione e Coordinamento

• Motivazione per l’Esclusione: Questi articoli riguardano le procedure e i requisiti per la segnalazione e il coordinamento degli incidenti di sicurezza informatica, senza menzionare specifiche tecnologie di sicurezza email.

3. Sezione 4: Governance e Sanzioni

Articolo 16: Coordinamento Nazionale della Cybersecurity

• Motivazione per l’Esclusione: Disciplina l’organizzazione e il coordinamento della sicurezza informatica a livello nazionale, senza fare riferimento a tecnologie di sicurezza specifiche.

Articoli 17, 19-20: Monitoraggio e Sanzioni

• Motivazione per l’Esclusione: Riguardano il monitoraggio e l’applicazione delle sanzioni, nonché il coordinamento nazionale e la cooperazione tra Stati membri, senza menzionare specifiche tecnologie di sicurezza email.

4. Sezione 6: Cooperazione a Livello dell’UE

Articoli 26-29: Meccanismi di Cooperazione e Condivisione delle Informazioni

• Motivazione per l’Esclusione: Questi articoli descrivono il coordinamento e la cooperazione tra Stati membri e istituzioni dell’UE, senza specifiche tecnologie di sicurezza email.

5. Sezione 8: Disposizioni Finali

Articoli 36-42: Disposizioni Generali

• Motivazione per l’Esclusione: Contengono disposizioni finali, inclusi i requisiti per la revisione e l’aggiornamento della direttiva, senza menzionare tecnologie di sicurezza email.

Link alla Traduzione Ufficiale Italiana della NIS2

Per un riferimento dettagliato e una lettura approfondita del testo ufficiale della direttiva NIS2 in italiano, puoi consultare la versione ufficiale al seguente link:

• Direttiva NIS2 – Testo Ufficiale Italiano (link al sito ufficiale UE o altra fonte ufficiale)

Riferimenti ad Altre Direttive e Regolamenti Correlati

• GDPR (Regolamento Generale sulla Protezione dei Dati – 2016/679) Applicazione: Tutte le organizzazioni che trattano dati personali nell’UE. Riferimento: Richiede la protezione dei dati personali contro accessi non autorizzati, con tecnologie come la crittografia e le misure DLP per email. Link: Regolamento GDPR – Testo Ufficiale Italiano
• Direttiva ePrivacy (2002/58/CE) Applicazione: Tutte le organizzazioni che offrono servizi di comunicazione elettronica. Riferimento: Richiede la protezione della riservatezza delle comunicazioni elettroniche, inclusa la protezione delle email da intercettazioni non autorizzate. Link: Direttiva ePrivacy – Testo Ufficiale Italiano
• Direttiva sui Servizi di Pagamento (PSD2 – 2015/2366) Applicazione: Fornitori di servizi di pagamento. Riferimento: Impone requisiti di sicurezza per la protezione delle comunicazioni utilizzate nelle transazioni finanziarie, incluse le email. Link: Direttiva PSD2 – Testo Ufficiale Italiano
• DORA (Digital Operational Resilience Act – 2022/2554) Applicazione: Tutti i partecipanti del settore finanziario, inclusi banche, fornitori di servizi di pagamento, e infrastrutture di mercato. Riferimento: DORA stabilisce requisiti per la resilienza operativa digitale delle istituzioni finanziarie, includendo la sicurezza delle email, l’autenticazione multifattoriale, la crittografia, e misure di prevenzione della perdita di dati come parte delle misure di sicurezza richieste. Link: Regolamento DORA – Testo Ufficiale Italiano

La direttiva NIS2 introduce requisiti più rigorosi e dettagliati rispetto alla direttiva NIS per garantire la sicurezza e la resilienza delle reti e dei sistemi informativi nell’UE. Sebbene alcuni articoli non facciano riferimento diretto a tecnologie di sicurezza email, l’implementazione di protocolli di autenticazione (SPF, DKIM, DMARC), crittografia e prevenzione della perdita di dati è essenziale per rispettare i requisiti della direttiva. Altre normative correlate, come GDPR, ePrivacy, PSD2 e DORA, supportano ulteriormente un approccio integrato alla sicurezza delle comunicazioni elettroniche e dei dati, essenziale per la protezione delle infrastrutture critiche e la conformità alle regolamentazioni europee.

The Email Files: “Encryptio Patronum”

Antonio Ieranò

Security, Data Protection, Privacy. Comments are on my own unique responsibility 🙂

August 30, 2024

Incantesimi di Crittografia nel Mondo Digitale

NOTA: causa mia indisposizione di questi giorni non sono in grado di rivedere tutto questo testo ora. Io comunque ve lo condivido sperando che abbia senso ed utilità. del resto non si può essere sempre al 100%. Io non lo sono mai!Ma dopo la flebile flebo eccomi indietro. Rilassatevi, immaginatevi in un mondo di pergamente volanti, incantesimi incomprensibili e compicazioni non previste, si proprio il mondo del email. E adesso magia: "Encryption Patronum"

Ultimamente si sente molto parlare di crittografia (vedi, ad esempio, la faccenda Telegram), e dato che ho già affrontato argomenti come TLS, S/MIME e crittografia generica nel precedente post (quello su DORA), assumendo che i lettori fossero già versati in queste arti magiche, ho deciso di fare un passo indietro. Forse una piccola lezione introduttiva sui diversi incantesimi potrebbe tornare utile. Del resto, se la crittografia fosse compresa da tutti, non ci sarebbe bisogno di lezioni extra, giusto?

Il Flusso dell’Email: Un Viaggio Magico dalla Penna alla Pergamena

Immagina che un utente “A” voglia mandare un messaggio incantato a un utente “B”. Potrebbe trattarsi di segreti aziendali, piani per conquistare il mondo, o semplicemente la ricetta per la pozione della felicità. Ma prima che il messaggio arrivi a destinazione, deve attraversare una serie di portali e guardiani magici. Ecco il viaggio semplificato che deve compiere:

Schema 1: Flusso Semplificato del Messaggio Magico

• Utente “A” ➜ Messaggio per B da A ➜ Client di posta A ➜ Server posta A ➜ Email Security Gateway A ➜ Cloud ➜ Messaggio per B da A ➜ Email Security Gateway B ➜ Server di posta B ➜ Client di posta B ➜ Utente “B”

Come sappiamo, il viaggio incantato si sviluppa così:

• L’utente A compone il suo incantesimo nel client di posta.

• Il client di posta A formatta il messaggio incantato.

• Il client di posta A si autentica sul server di posta A.

• Il messaggio arriva al server di posta A via client di posta.

• (Opzionale ma consigliato) Il server di posta A comunica con un gateway di sicurezza magica (A ovvio).

• Il gateway di sicurezza verifica il messaggio e lo invia a destinazione dopo una serie di controlli magici:

1. Trova il destinatario (usualmente tramite incantesimi MX)
2. Firma DKIM per dimostrare l’autenticità del messaggio (importante per entrare nei favori di grandi stregoni come Google o Yahoo)
3. Controlli anti-malocchio, malware e altre malefatte arcane (argatto nelle prossime versioni).

• Il gateway di sicurezza A del mittente “Utente A” contatta il security gateway B del destinatario “Utente B”.

• I gateway scambiano informazioni e stabiliscono i parametri di connessione: Reputation del mittente (si fidano? Non si fidano?) Parametri di connessione SMTP (quante sessioni concorrenti, quanti messaggi contemporaneamente, ecc.) Verifica dell’esistenza del destinatario (il messaggio non finisce in un pozzo senza fondo).

• Il gateway B effettua i suoi controlli di sicurezza magici (occhio, malocchio, prezzemolo e finocchio) e, finalmente, il messaggio incantato arriva al server di posta B.

• Ecco allora che il Client di posta B chiama il suo magico server e preleva il messaggio

• Ora l’utente B può finalmente accedere ai segreti misterici ed alla conoscenza arcana

Apprendista: “Maestro, mandare un messaggio non dovrebbe essere più semplice? Tipo… legare una pergamena a un gufo?”

Stregone: “Ah, giovane sciocco! Se usassimo i gufi per tutto, saremmo sommersi dalle piume e i segreti verrebbero rubati dalle gazze! Questa è arte complessa!”

STARTTLS: Il Mago della Crittografia Che Non Ama gli Eccessi

Immagina un mago un po’ insicuro e distratto, che invece di lanciare incantesimi potenti contro le forze del male, si avvicina timidamente e sussurra: “Ehm, potremmo aggiungere un po’ di sicurezza, per favore?” Ecco, questo è STARTTLS.

Cos’è STARTTLS?

STARTTLS è come un incantesimo che trasforma una normale conversazione tra due maghi in un dialogo criptato. Ma attenzione, non è un mago esperto di crittografia nativo (come HTTPS per i siti web). STARTTLS è più un trucco da mago di periferia: chiede gentilmente a due server di posta di iniziare a parlare in codice, sperando che nessun curioso riesca a origliare nel frattempo.

Il problema con STARTTLS?

Come ogni mago un po’ svogliato, STARTTLS non è infallibile. Se un cattivo stregone riesce a intrufolarsi prima che l’incantesimo sia completo, potrebbe convincere i server a non usare affatto la crittografia. E qui il nostro mago si ritrova con le mani vuote, senza nemmeno una pozione di emergenza!

NOTA: Se vuoi approfondire le avventure di STARTTLS e capire meglio come funziona (o non funziona), puoi leggere la RFC 3207. Ma attenzione: potresti trovare più tecnicismi che magie.

Apprendista: “Maestro, se STARTTLS è così incerto, perché lo usiamo?”

Stregone: “Perché è meglio che lasciare le porte del castello aperte, giovanotto. Anche una catena arrugginita è meglio di nessuna catena!”

TLS: Il Guardiano Armato delle Pergamene Magiche

Quando può STARTTLS è però in grado di richiamare un potente incantesimo che si chiama TLS. Immagina un guardiano super efficiente, sempre armato di scudo e spada, pronto a proteggere il ponte ove transitano le tue email come se fossero grimori preziosi. Questo è TLS, il vero protettore delle strade delle pergamene digitali!

Cos’è TLS?

TLS (Transport Layer Security) è come quel buttafuori del castello più esclusivo del regno. È lì per assicurarsi che solo gli invitati possano entrare e che nessuno possa sbirciare nei corridoi segreti. Nel contesto dell’invio di email, TLS crea un tunnel sicuro tra il server di posta che invia e quello che riceve. In altre parole, garantisce che le tue pergamene digitali viaggino in sicurezza attraverso il regno, lontane dagli sguardi indiscreti di maghi malvagi e altri “spioni” digitali.

Il fascino e le limitazioni di TLS

Ma attenzione: TLS non è invincibile. Certo, è molto bravo nel suo lavoro, ma ogni tanto può essere un po’ troppo fiducioso. Per esempio, potrebbe lasciare la porta del castello socchiusa se il server ricevente non è altrettanto protetto o se i protocolli di sicurezza non sono aggiornati. È come se il nostro guardiano stesse prendendo una pausa per sorseggiare un po’ di idromele mentre dovrebbe essere di guardia!

Per i curiosi: TLS è molto più sofisticato di quanto sembri. Usa una combinazione di crittografia simmetrica e asimmetrica e autentica i server per garantire che nessuno possa fingere di essere qualcun altro. Insomma, TLS è sempre un passo avanti rispetto ai malintenzionati… a meno che non stia facendo una pausa per un cappuccino!

schema 2: Introduzione del flusso con STARTTLS

• Utente “A” ➜ Messaggio per B da A ➜ Client di posta A ➜ Server posta A ➜ STARTTLS (se accettato, bene, se no, in chiaro)➜ Email Security Gateway A ➜ Cloud ➜ STARTTLS (se accettato, bene, se no, in chiaro) ➜ Messaggio per B da A ➜ Email Security Gateway B ➜ STARTTLS (se accettato, bene, se no, in chiaro)➜ Server di posta B ➜ Client di posta B ➜ Utente B

Apprendista: “Maestro, TLS sembra un po’ troppo rilassato. È davvero sicuro?”

Stregone: “Ah, giovane incauto! Anche il più forte dei guardiani ha bisogno di un po’ di riposo. Ma un buon TLS sa sempre quando rimettersi in guardia!”

DKIM vs S/MIME: La Sfida degli Stregoni delle Email!

Nel mondo delle email sicure, abbiamo due potenti stregoni che proteggono i tuoi messaggi con tecniche molto diverse, ma entrambe efficaci. Da una parte c’è DKIM, il mago che appone la sua firma digitale unica su ogni messaggio. Dall’altra, S/MIME, il maestro delle arti segrete, che protegge il contenuto delle email con crittografia e sigilli magici. Preparati per un duello epico!

DKIM: Il Mago Firmatario delle Email

• Cos’è DKIM? DKIM (DomainKeys Identified Mail) è come un mago del regno delle email. Ogni volta che invii un’email, DKIM tira fuori la sua piuma magica e appone un sigillo digitale dal tuo dominio. In pratica, DKIM dice al server di posta che riceve: “Ehi, questa email è davvero mia! Guarda, c’è il mio sigillo! e nessuno la ha modificata!”
• Compatibilità? DKIM è un tipo molto affabile. È compatibile con la maggior parte dei server di posta elettronica perché lavora dietro le quinte. Non richiede configurazioni speciali per gli utenti finali, quindi è come avere un amico che si occupa della sicurezza senza fare troppo rumore.

S/MIME: Il Maestro delle Arti Segrete

schema 3: Flusso di funzionamento di S/MIME

• Cos’è S/MIME? S/MIME (Secure/Multipurpose Internet Mail Extensions) è il mago supremo delle email. Armato di incantesimi di crittografia e sigilli digitali, S/MIME non solo assicura che il mittente sia legittimo, ma protegge anche il contenuto del messaggio con una crittografia che solo il destinatario può decifrare. Nessuno può leggere o modificare l’email senza essere scoperto.
• Compatibilità? S/MIME può essere un po’ esigente. Non tutti i client di posta elettronica sono pronti a supportare i suoi incantesimi avanzati. Ha bisogno che tu installi certificati digitali sui tuoi dispositivi (un po’ come ottenere una licenza magica costosa e difficile da ottenere). In altre parole, è un po’ come invitare un mago a una festa: devi sapere esattamente cosa stai facendo per evitare di fare brutta figura! E attento, parlare da A a B è diverso che parlare da B ad A. Ti occorrono certificati magici, per ogni destinatario

Differenze Chiave tra DKIM e S/MIME

La differenza tra i due stregoni delle email è fondamentale: DKIM si concentra sull’autenticità del mittente, assicurandosi che il messaggio provenga davvero dal dominio dichiarato certificando il fatto che non sia stato alterato, mentre S/MIME protegge sia l’identità del mittente che il contenuto del messaggio, assicurandosi che solo il destinatario legittimo possa leggerlo.

• DKIM è come un sigillo su una lettera: “Questo viene davvero da me.” e ti da la certezza che non abbiano cambiato le parole neanche con un potente incantesimo
• S/MIME invece è come un baule magico chiuso a chiave con un messaggio che dice: “Questo è da parte mia ed è solo per te.” dentro c’è la pergamena ma la chiave per aprire e leggere il messaggio deve arrivare ed essere conservata

Compatibilità e Collaborazione

DKIM e S/MIME non sono rivali; anzi, possono lavorare insieme! DKIM si occupa dell’autenticità del mittente e della sua reputazione, mentre S/MIME protegge il contenuto del messaggio. Insieme creano una combinazione potente di sicurezza e affidabilità per le tue comunicazioni digitali.

Per chi vuole esplorare i dettagli tecnici e scoprire tutti i segreti dietro questi incantesimi:

• DKIM: Dai un’occhiata alla RFC 6376.
• S/MIME: Puoi leggere di più su RFC 5751.

Apprendista: “Maestro, DKIM sembra troppo semplice, mentre S/MIME è troppo complicato. Quale dovremmo usare?”

Stregone: “Ah, giovane ingenuo! La semplicità è la chiave della saggezza, ma la complessità è il segreto della protezione. Impara a usare entrambi e sarai invincibile!”

Implementare DKIM e S/MIME: Una Commedia degli Errori nel Mondo delle Email!

Immagina di dover organizzare una festa magica con un cast di stregoni che parlano lingue diverse, usano bacchette diverse, e devono anche ballare mentre incantano. Ecco cosa significa implementare DKIM e S/MIME per la crittografia delle email in diversi scenari: gateway-to-gateway, gateway-to-desktop, e desktop-to-desktop. Preparati per una giostra di confusioni, risate e qualche lacrima (di disperazione).

DKIM: Il Mago del Sigillo Incomprensibile

• Gateway to Gateway: Implementare DKIM tra due gateway di posta elettronica è un po’ come organizzare uno spettacolo di magia tra due teatri lontani. Il mago (DKIM) firma ogni email con il suo sigillo digitale prima di mandarla in viaggio. Tutto sembra perfetto finché il mago non scopre che all’altro capo del palco il suo assistente non sa leggere il sigillo. Magari non ha aggiornato le chiavi pubbliche o ha dimenticato di configurare correttamente il DNS. E così lo spettacolo deve essere sospeso mentre tutti cercano di capire chi ha fatto cosa e perché il coniglio è scomparso dal cilindro. Il destinatario deve decidere cosa fare del sigillo, lo rispetto o lo ignoro? per fortuna la mail rimane leggibile in tutti e 2 i casi (forse), ma se il sigillo lo ignoro non saprò mai se il messaggio è stato modificato o meno.

S/MIME: Il Mago delle Arti Oscure con le Mani Legate

• Gateway to Gateway: Parliamo di S/MIME tra gateway: qui il mago si ritrova a una festa elegante con un vestito da combattimento completo. Ha tutti i suoi incantesimi criptografici pronti, ma c’è un problema: il gateway non sa come usare questi incantesimi. “Aspetta, cosa sono questi certificati? Devo firmare ogni messaggio? Devo crittografare ogni byte?” E mentre i gateway litigano su chi deve fare cosa, il mago se ne va frustrato senza aver lanciato nemmeno un incantesimo. A meno che esista una magia che associ un utente al suo messaggio, e cosi il mago possa associare quel messaggio di quell’utente all’incantesimo S\MIME. sempre sperando che il destinatario sia capace di fare altrettanto. e questo per ogni destinatario. quanto potere magico impiegato.

• Gateway to Desktop: Quando il mago di S/MIME cerca di operare tra un gateway e un desktop, le cose si complicano ancora di più. Qui il mago deve lanciare una serie di incantesimi complicati — firmare digitalmente le email e criptarle — e sperare che il desktop capisca cosa sta succedendo. Ma se il client di posta elettronica del desktop non è configurato correttamente (e non lo è mai!), il mago si ritrova a combattere con una bacchetta difettosa. Gli utenti vedono messaggi criptati che appaiono come geroglifici egizi e l’unica cosa che viene decifrata è il loro mal di testa. E se gli chiedi: e i certificati? Mediamente ti presenta quello medico.
• Desktop to Desktop: Implementare S/MIME desktop-to-desktop è come organizzare un duello tra due maghi, ciascuno armato fino ai denti ma chiusi in stanze separate e senza chiavi per comunicare. Ogni desktop deve avere il proprio certificato e ogni certificato deve essere riconosciuto dall’altro desktop. Naturalmente, quando i maghi finalmente riescono a incontrarsi, scoprono che i certificati sono scaduti o, peggio, non sono compatibili. È una danza di frustrazione e di “Perché diavolo non funziona?” mentre i maghi si lanciano incantesimi cifrati che nessuno riesce mai a decifrare. e hai un mago per desktop e un diavolo per capello (ok io son calvo, oco mi importa)

Apprendista: “Maestro, implementare questi incantesimi sembra una vera sfida!”

Stregone: “Oh, giovanotto, benvenuto nel mondo della crittografia! Qui, anche il mago più potente ha bisogno di un manuale d’istruzioni.”

Le Millemila Soluzioni di Crittografia sul Mercato: Streghe e Stregoni Digitali in Azione!

Nel vasto mondo della crittografia delle email, ci sono innumerevoli incantatori digitali — o, se preferite, streghe e stregoni moderni — ognuno con la propria bacchetta magica (o algoritmo) per proteggere i tuoi messaggi. Come in ogni buona fiaba, però, non tutte le magie sono create uguali, e alcune richiedono ingredienti segreti, mentre altre sono gratuite ma con qualche “ingrediente” nascosto. Vediamo insieme alcuni incantesimi disponibili:

1. OpenPGP: La Strega del Borgo con l’Erbario Completo

• Descrizione: OpenPGP è come quella strega vecchia scuola che conosce tutte le erbe giuste per ogni pozione e conserva ogni foglia in un libro magico (il tuo desktop). Questo incantesimo open source ti permette di firmare e criptare email utilizzando un sistema di chiavi pubbliche e private.
• Chiavi Asimmetriche: OpenPGP è ossessionato dalle chiavi: ce n’è una pubblica, una privata, e probabilmente anche una per la cantina. Problemi? La gestione di tutte queste chiavi è un incubo logistico. Se una delle chiavi finisce nelle mani sbagliate, addio sicurezza!
• Non-repudiation: OpenPGP è molto bravo a dimostrare che un messaggio è stato davvero inviato da te… sempre che tu riesca a dimostrare di avere ancora la tua chiave privata. Se perdi le chiavi o se vengono compromesse, le tue prove vanno in fumo!
• Costo: Open Source e Gratuito. Tuttavia, l’erbario di chiavi può diventare un po’ pesante da gestire, e potresti aver bisogno di un apprendista per mantenere tutto in ordine. I costi indiretti includono la formazione e la gestione dei keyring (gli anelli delle chiavi magiche), che richiedono tempo e pazienza.
• Compatibilità: Funziona meglio quando entrambe le parti sono pronte a scambiarsi chiavi pubbliche e a riconoscere la magia dell’altro. Se una delle due parti non sa usare bene la bacchetta, la magia rischia di svanire.

2. PGP (Pretty Good Privacy): Lo Stregone Misterioso con Troppi Forzieri

• Descrizione: PGP è lo stregone che ha tutto sotto controllo, ma nasconde i suoi incantesimi in numerosi forzieri sparsi per il suo laboratorio (il tuo desktop). Utilizza chiavi asimmetriche per proteggere le email, ma è anche dotato di chiavi simmetriche autogenerate per ogni messaggio, giusto per aggiungere un po’ di pepe.
• Chiavi Asimmetriche con Chiavi Simmetriche Autogenerate: PGP adora complicare le cose. Per ogni messaggio, c’è una chiave segreta… che viene poi protetta da un’altra chiave! Problemi? È come proteggere una cassa del tesoro con una combinazione di lucchetti e serrature: funziona, ma è una scocciatura immensa.
• Non-repudiation: In teoria, PGP offre non-repudiation solida… ma solo se riesci a tenere traccia di tutte quelle chiavi e se non affondano con la tua nave (ehm, desktop).
• Costo: A pagamento. Diverse implementazioni, come Symantec Encryption Desktop, richiedono una tassa per i loro incantesimi avanzati. Costi indiretti: Potresti dover acquistare certificati digitali da autorità di certificazione (pensalo come pagare un tributo al Gran Consiglio dei Maghi per ottenere la loro approvazione).
• Compatibilità: Molto utile quando il mittente e il destinatario sono entrambi stregoni esperti che sanno come usare le loro chiavi magiche. Se invece hai a che fare con maghi alle prime armi, aspettati un sacco di incantesimi falliti e confusioni.

3. Proofpoint Encryption: La Fata Madrina della Crittografia con il Tocco Magico

• Descrizione: Proofpoint Encryption è come una fata madrina digitale che si occupa di tutto per te. Non devi nemmeno agitare la bacchetta: fa tutto lei dal gateway, senza invadere il tuo spazio (desktop). È una soluzione che genera chiavi simmetriche autogenerate per ogni messaggio e le gestisce con grazia e precisione.
• Chiavi Simmetriche Autogenerate per Messaggio: Proofpoint è super efficiente: genera una chiave segreta per ogni messaggio e destinatario e la gestisce come un vero professionista. Problemi? Qui è tutto quasi perfetto. La chiave viene creata e distrutta con un click, e puoi anche settare un expiration date! Hai inviato per errore l’email alla persona sbagliata? Nessun problema, il nostro maggiordomo ti permette di “revocare” l’accesso: blocca la chiave, e il messaggio diventa illeggibile. È come avere un pulsante di annullamento magico!
• Non-repudiation: Proofpoint offre non-repudiation in maniera discreta ma efficace. Ogni apertura di messaggio viene registrata nel suo database di fiducia, così sai esattamente chi ha letto cosa e quando. È come avere una telecamera di sicurezza digitale che monitora ogni passaggio. E tutto con la massima eleganza!
• Costo: A pagamento. Proofpoint è una soluzione aziendale con un modello di pricing basato su abbonamento. Costi indiretti: Praticamente nessuno, poiché tutta la gestione delle chiavi e la sicurezza sono centralizzate e incluse nel servizio. È come avere una fata madrina che non chiede nulla in cambio… o quasi.
• Compatibilità: Perfetto per le aziende che desiderano una protezione robusta senza doversi preoccupare di complessi rituali crittografici. Il destinatario non ha bisogno di installare software speciali: la fata madrina si occupa di tutto attraverso un portale web sicuro.

4. Zix Email Encryption: Il Guardiano del Tunnel Segreto

• Descrizione: Zix è come un guardiano di un tunnel segreto tra due castelli (i gateway di posta). È specializzato nel proteggere la corrispondenza tra domini specifici, assicurandosi che solo i messaggi autorizzati possano attraversare il suo passaggio sicuro.
• Chiavi Simmetriche Centralizzate: Zix utilizza chiavi simmetriche centralizzate per crittografare e decrittare i messaggi tra i gateway di posta elettronica. Problemi? Devi fidarti del custode del tunnel (Zix) per gestire le chiavi e proteggere i tuoi messaggi.
• Non-repudiation: Zix offre un buon livello di non-repudiation tracciando chi ha accesso al tunnel e monitorando ogni messaggio che passa. Non è il massimo del controllo granulare come Proofpoint, ma fa il suo lavoro con rigore.
• Costo: A pagamento. Zix offre piani di abbonamento per utenti aziendali. Costi indiretti: Pochi, poiché l’infrastruttura di crittografia e gestione delle chiavi è inclusa nel servizio, ma ci potrebbe essere un costo se si decide di usare funzionalità avanzate o integrazioni personalizzate.
• Compatibilità: Altamente efficace quando entrambe le parti utilizzano il suo sistema. Se una delle due parti non è cliente Zix, potrebbe essere necessario un incantesimo extra per aprire il portale di accesso sicuro.

Scambio tra Stregone e Apprendista:

Apprendista: “Maestro, con tutte queste opzioni, quale incantesimo di crittografia dovremmo scegliere?”

Stregone: “Ah, giovane apprendista, la scelta del giusto incantesimo dipende da chi sei, da cosa proteggi, e da quanto sei disposto a pagare per il privilegio. Ma ricorda: anche il più potente degli incantesimi è inutile se non sai come usarlo!”

Conclusioni: Come Scegliere la Tua Strega o il Tuo Stregone Digitale?

Quando si tratta di scegliere il giusto incantesimo di crittografia per la tua azienda o uso personale, ci sono alcune considerazioni importanti:

• Facilità d’Uso: Se sei un novizio nel mondo della magia digitale, scegli un incantesimo facile da usare, come Proofpoint o Zix, che richiede meno competenze tecniche e gestisce la sicurezza per te.
• Compatibilità: Assicurati che il tuo destinatario possa ricevere e decifrare il messaggio senza dover imparare formule magiche complicate. Soluzioni come Proofpoint e Sophos Email Encryption sono ideali per chiunque non voglia fare un corso accelerato di crittografia.
• Costo e Costi Indiretti: Considera il budget. Le soluzioni open source come OpenPGP sono gratuite ma potrebbero richiedere tempo e competenza per essere utilizzate correttamente. Le soluzioni a pagamento come Proofpoint offrono un’esperienza più fluida, ma a un prezzo.
• Scopo e Bisogni: Cosa devi proteggere e da chi? Se stai scambiando segreti aziendali con altre aziende (o meglio, castelli vicini), una soluzione gateway-to-gateway come Zix potrebbe essere perfetta. Se invece devi proteggere i dati degli utenti finali, una soluzione desktop-to-desktop come PGP potrebbe essere più appropriata.

Apprendista: “Si Ma quindi che implemento? Cosa serve? Che faccio?”

Stregone: “Mio ingenuo giovine Ora per essere sinceri devo dire che io sono un poco rigido in queste cose, tendo ad insultare malamente chi considera queste questioni secondarie e peggio mi adombro quando è evidente che non sanno di cosa si parli o a che serva anche se sono esperti di sechiuriti, ciberrobe e master in informesciontecnologi”

Stregone: Ma mettiamola cosi in maniera semplice persino per sopracitati

Connessioni SMTP: o usi TLS o secondo me hai dei problemi

Non esiste nessuna buona ragione per non usare TLS su SMTP se non che la controparte non sia in grado di gestire tali connessioni.

Ma, in questo caso, forse è meglio che non gli mandiate proprio posta elettronica, perché se tanto mi da tanto questi non hanno idea di cosa sia la sicurezza informatica.

Considerate che oramai persino Google e Yahoo (no, dico, Yahoo) non vogliono transazioni senza TLS.

Comunque STARTTLS è in grado di gestire magicamente la questione, scegliendo magicamente se usare TLS o meno col destinatario. lo fa chiedendoglielo e sperando che nessuno mago malvagio abbia già compromesso il castello del destinatario.

Se avete controparti specifiche particolarmente rognose (che so la BCE) il TLS obbligatorio con un bel certificato dedicato sarebbe indicato, anche per evitare il problema della gentilezza di STARTTLS.

Encryption da chi, a li a là

A meno che non siano fatti espliciti riferimenti a standard precisi (S\MIME) qui la questione è più fluida e la scelta molto dipende da con chi e perché si comunica.

In caso di Gateway to Gateway S\MIME lavora egregiamente, ovvio occorre un accordo e scambio di certificati tra le controparti

Ma se si tratta di connessioni estemporanee da dare in mano agli utenti la scelta è varia.

PGP e OpenPGP, ad esempio, van bene se le 2 parti che si scambiano messaggi sono senzienti. È vero che la chiave pubblica la metti nella firma, ma occorre che l’altra parte lo capisca. E se vuoi risposte altrettanto sicure deve essere in grado di fare lo stesso.

Stregone: “Vedi mio buon ascoltatore, il metro di giudizio non dovrebbe essere la tua capacità di discernimento, ma quella della famosa massaia di voghera a cui, non si capisce bene perché, tutti sentono il bisogno di mandare cose complicate.”

Quindi queste cose vanno bene per chi, pochi ma buoni, hanno un grado di adattabilità alla tecnologia superiore a quella di un utente medio.

Apprendista: “Come me maestro?”

Stregone: “Meno figliuolo, meno”

Se devi mandare messaggi ad una moltitudine di utenti vari ed avariati, per esempio comunicazioni sensibili, bollette o cose così, forse l’approccio PGP nelle sue forme non è il top.

Allora scelte legacy che permettano al mittente di leggere il messaggio anche se NON dispone di software specifici sono più indicate.

Se poi la scelta di encryption può essere controllata al gateway via policy o controlli meglio ancora, perché meno che del desitinatario ci si può fidare del mittente.

Stregone: “E ricordati che non ci si può fidare di nessuno, e spesso la colpa di ciò è tua”

Riflessioni Finali: Il Concilio dei Maghi della Crittografia

La sicurezza delle email è come una grande tavola rotonda di maghi e streghe digitali, ognuno con il suo libro degli incantesimi. Alcuni incantesimi richiedono complicati rituali, altri sono più semplici e immediati. L’importante è scegliere il giusto tipo di magia per le tue esigenze specifiche, evitando di complicare eccessivamente le cose o di lasciare porte aperte ai nemici.

In un mondo perfetto, tutti saprebbero fare un incantesimo di crittografia perfetto, ma nel mondo reale, ci affidiamo alle soluzioni che ci fanno sentire al sicuro senza doverci trasformare in maghi esperti. Quindi, scegli saggiamente il tuo stregone digitale, conosci le sue (e sopratutto tue) capacità e limitazioni, e proteggi le tue email come se fossero preziosi grimori!

Apprendista: “Maestro, penso di aver finalmente capito! Ora posso proteggere le nostre pergamene digitali!”

Stregone: “Ah, giovane studente, hai ancora molto da imparare. Ma per oggi, hai guadagnato il tuo primo cappello da mago della crittografia!”

della serie the email files vedi anche:

email-files-encryptio-patronum

email-files-dora-lesploradora-e-gli-email-friends

mail-files-se-40000-blocklist-vi-sembran-pochi

email-files-edizione-speciale-la-posta-ai-tempi-della-guerra

email-files-la-posta-secondo-la-posta

email-files-blocklisting-la-sottile-arte-di-farsi-del-male

email-files-safelisting-poi-non-lamentarti

sempre sulle email:

ma-ti-serve-davvero-la-posta-elettronica