Godiamoci il panorama. Insieme.
Ma prima costruiamo insieme la postura della cybersecurity. Non è un ombrello sotto cui sentirsi protetti una volta aperto. Per arrivare a godersi il panorama tocca rimboccarsi le maniche e fortificare. Insieme.
La consulenza cybersecurity di M4SS:

Adeguamento normativo CRA e NIS2.
M4SS è soggetto importante NIS2 registrato in ACN (Agenzia per la Cybersicurezza Nazionale) e produttrice di hardware soggetto al CRA (Cyber Resilience Act). Significa che la conformità la tariamo prima su noi stessi. Dall'esperienza che ne deriva creiamo valore per i clienti.
ProblemaIl Cyber Resilience Act (Regolamento UE 2024/2847) è in vigore: gli obblighi pieni scattano l'11 dicembre 2027, quelli di vulnerability reporting già dall'11 settembre 2026. La Direttiva NIS2 è operativa, e i soggetti importanti devono mettere a punto governance, supply chain, gestione degli incidenti, documentazione difendibile davanti agli organismi di controllo. Per chi inizia ora, la documentazione richiesta è molta. Per chi ci ha provato con consulenti generalisti, spesso il risultato è un Technical File che non regge alla prima domanda dell'organismo notificato.
SoluzioneM4SS sta facendo questo percorso su sé stessa. Il progetto CDM-CRA sta portando il nostro Communication Data Module alla piena conformità CRA prima della commercializzazione: gap analysis, OTA pentest, SBOM, security policy, Technical File, Declaration of Conformity, PSIRT operativo. Vendiamo l'esperienza, non la teoria. Per le entità NIS2 portiamo lo stesso approccio: registrazione e adempimenti con ACN, governance del rischio, supply chain, incident handling, documentazione che regge l'audit. La prova vivente è il CDM-CRA stesso, che produce in tempo reale i deliverable che riapplichiamo ai clienti.
- Technical File CRA completo: valutazione del rischio, security plan, gestione delle vulnerabilità lungo il ciclo di vita.
- Declaration of Conformity e gestione marcatura CE.
- PSIRT operativo: policy, canali di disclosure, processi di patch management.
- NIS2 end-to-end: registrazione ACN, governance, supply chain, business continuity, incident reporting, SBOM (CycloneDX/SPDX).
Vulnerability Assessment e Penetration Testing.
ProblemaLe entità NIS2 devono attestare periodicamente la sicurezza dei propri sistemi. I distributori e produttori di hardware soggetti al Cyber Resilience Act (CRA) devono dimostrare un processo continuo di vulnerability handling. Un report tecnico crudo, fatto solo di CVE e CVSS, non basta più: l'auditor chiede a quale obbligo NIS2 risponde ogni rilievo, quale articolo del CRA è in gioco, quanto rischio normativo resta dopo la remediation.
SoluzioneM4SS conduce Vulnerability Assessment e Penetration Testing su applicazioni web, API, infrastrutture cloud, dispositivi IIoT ed embedded, ambienti OT/SCADA e supply chain del software. Usiamo gli strumenti standard del settore (Burp Suite, ZAP, Metasploit, Nmap; strumentazione specifica per OT/SCADA dove serve), con tassonomia coerente con CWE e MITRE ATT&CK. Quello che differenzia il nostro report è uno strumento proprietario di mappatura: ogni vulnerabilità trovata è connessa all'obbligo NIS2 e all'articolo CRA che impatta, con un punteggio di rischio normativo (Regulatory Risk Score) per la prioritizzazione. Quando finisce il pentest, il cliente non riceve un report tecnico da tradurre: riceve un dossier già pronto per l'audit.
- Scope esteso: web, API, cloud, IIoT/embedded, OT/SCADA, supply chain software.
- Tassonomia: CWE e MITRE ATT&CK.
- Mappa CVE → controllo NIS2 → articolo CRA, con Regulatory Risk Score per voce.
- Reportistica a tre livelli: executive summary, dettaglio tecnico, replicabilità.
Software supply chain security Rust.
ProblemaIl software moderno è una catena di dipendenze: una vulnerabilità in una libreria transitiva diventa una vulnerabilità nel tuo prodotto. Il Cyber Resilience Act lo richiama all'Art. 13, la NIS2 nell'allegato sui controlli. Un audit di supply chain superficiale, fatto solo con un cargo audit e un PDF, non basta. Serve sapere quali crate non sono manutenute, quali hanno supply chain non verificabile, quali hanno codice unsafe non revisionato, quali stanno andando in deprecation.
SoluzioneM4SS audita la supply chain Rust dall'interno della comunità che la produce. Sei advisory RustSec pubblicate, responsible disclosure con fix mergiate a monte, contributi diretti al cuore dell'ecosistema. M4SS è maintainer di lettre (libreria SMTP Rust di riferimento) e co-maintainer di rust-postgres (client PostgreSQL® di riferimento). Quando facciamo audit di un codebase Rust per un cliente, lo facciamo con gli stessi strumenti e standard con cui contribuiamo all'ecosistema. (Il dettaglio del lavoro a monte, con numeri e progetti, è in Attività › Open Source.)
- Audit dipendenze con cargo-deny, integrato con il database RustSec a cui contribuiamo direttamente.
- Riproducibilità dei crate con cargo-goggles, strumento open source M4SS.
- Code audit puntuali su moduli unsafe, codice crittografico, parser di rete.
- Adozione di Rust per nuovi sviluppi memory-safe: strategia, training, review continua.
Red Team.
ProblemaVuoi sapere se reggi un attacco reale? Simuliamo l'attaccante reale. Non il bug-hunter sul perimetro. Le entità NIS2 e i distributori e produttori di hardware soggetti al Cyber Resilience Act (CRA) devono dimostrare di reggere a uno scenario di attacco reale, non solo di non avere bug noti. Un Vulnerability Assessment risponde a una domanda: quali bug ci sono. Un Red Team risponde a una domanda diversa: se qualcuno volesse davvero entrare, ci riuscirebbe?
SoluzioneM4SS conduce campagne di Red Teaming complete, in tutte le fasi: ricognizione (OSINT), costruzione del vettore di accesso iniziale, lateral movement, persistenza, esfiltrazione, evasione dei controlli difensivi. Su scope concordato, con regole d'ingaggio scritte e catena di custodia chiara per ogni evidenza raccolta. Quando ha senso e il cliente lo autorizza, includiamo anche social engineering controllato (phishing, pretexting). Operiamo coordinati con il vostro Blue Team se presente, in modalità black-box se non c'è. Metodologia ispirata a TIBER-EU come riferimento di processo; tassonomia e reportistica su MITRE ATT&CK.
- Tutte le fasi della kill chain: OSINT, accesso iniziale, lateral movement, persistenza, esfiltrazione, evasione.
- Metodologia ispirata a TIBER-EU + reportistica MITRE ATT&CK.
- Regole d'ingaggio esplicite: autorizzazioni scritte, ambito chiuso, esfiltrazione solo simulata.
- Mapping degli esiti ai controlli NIS2 e CRA dove applicabile.
Inquadra il tuo bisogno di cybersecurity con noi.
CONTATTACI