Chiudere le porte d’ingresso: vulnerabilità, phishing, applicazioni web

Perché queste tre porte dominano

Scomodo ma vero: gli attaccanti non hanno bisogno di exploit esotici. In una percentuale superiore alla media dei casi bastano vulnerabilità aperte, una consapevolezza poco realistica e applicazioni web con una validazione degli input debole. Il resto è velocità. I difensori non perdono “intelligenza”, ma disciplina: SLO mancanti per il patching, rollout MFA a metà, assenza di uno standard vincolante di secure coding. Quando la sicurezza IT viene concepita come un progetto invece che come un’operazione continua, le falle restano aperte — talvolta per anni.

Chiudere le vulnerabilità: dal “patching” all’igiene guidata da SLO

“Patching regolare” non è un indicatore di qualità. Ciò che conta è quanto velocemente vengono chiuse le vulnerabilità critiche sul perimetro Internet — e in modo dimostrabile.
Controlli obbligatori:

• Inventario & esposizione: Inventario completo degli asset incl. esposizione a Internet (sistema, versione, responsabile, rilevanza per il business).
• SLO basati sul rischio: Vulnerabilità Internet critiche risolte in giorni, quelle interne in settimane definite. Violazione SLO ⇒ escalation automatica (slot di change, ping al management, obbligo di approvazione).
• Canary & rollout graduale: Prima anello di test, poi distribuzione scaglionata. Piano di rollback documentato e testato.
• Governance delle eccezioni: Ogni deviazione ha un owner, una scadenza e misure compensative (es. hardening/monitoraggio aggiuntivo).

KPI: Conformità agli SLO di patching (Internet vs. interno), MTTD/MTTR per criticità, percentuale di sistemi con agent/scanner aggiornati, Mean Exposure Time (MET) per CVE critiche.

Neutralizzare il phishing: tecnologia + comportamento, ancorati alla realtà

L’e-mail è lo strumento preferito degli attaccanti — non perché i difensori siano “stupidi”, ma perché pressione quotidiana, deleghe e approvazioni mobili favoriscono gli errori.
Controlli obbligatori:

• MFA resistente al phishing (passkey/FIDO2) per tutti i ruoli critici; disattivazione dei flussi legacy.
• Autenticazione e-mail (SPF/DKIM/DMARC) più rilevamento delle anomalie e policy su link/allegati.
• Protezione delle sessioni contro AitM (es. re-challenge in presenza di segnali di rischio, token binding).
• Esercitazioni realistiche: Scenari con pressione temporale, contesto dirigenziale, fornitori. Niente teatro del “non cliccare”, ma addestramento dei processi (es. verifica tramite richiamata, principio dei quattro occhi, approvazioni out-of-band).

KPI: Copertura MFA (resistente al phishing), percentuale di e-mail ad alto rischio bloccate, tempo fino alla conferma dell’allarme (SecOps), quota di verifiche positive per modifiche di pagamenti/identità.

Mettere in sicurezza le applicazioni web: dallo SDLC alla porta d’ingresso

Le applicazioni web insicure non sono un “problema degli sviluppatori”, ma un rischio di business. Portare in produzione funzionalità senza un gate di sicurezza significa risparmiare nel posto sbagliato.
Controlli obbligatori:

• Secure SDLC: Standard di coding vincolante, code review con controlli di sicurezza, secret scanning, gestione delle dipendenze (SBOM, equivalente Renovate/Dependabot).
• Test pre-produzione: DAST/SAST sui flussi critici (auth, upload, pagamento), casi di abuso (rate limit, enumeration, CSRF).
• Intorno all’applicazione: WAF/reverse proxy con regole chiare, hardening di TLS/header, bot management per gli endpoint di login.
• Esercizio operativo: Configurazioni versionate, deployment riproducibili, interruttori di emergenza (feature flag), telemetria fino all’evento di business.

KPI: “Time-to-fix” dei finding, percentuale di endpoint critici con policy WAF, finding aperti vs. risolti per sprint, hit di rate-limit vs. utilizzo legittimo.

Piano a 90 giorni: dalle buone intenzioni al controllo reale

Giorni 0–15 – trasparenza & baseline

• Inventario completo di asset e vulnerabilità con esposizione a Internet.
• Stato MFA: quali ruoli critici utilizzano metodi resistenti al phishing?
• Catalogazione delle applicazioni web: flussi critici, dipendenze, copertura dei test.
• Baseline KPI: conformità SLO di patching, copertura MFA, MTTD/MTTR, finding applicativi aperti.

Giorni 16–45 – hardening & applicazione degli SLO

• Rafforzare la policy SLO (Internet critico in giorni). Applicare la logica di escalation tecnicamente.
• Rollout di MFA resistente al phishing; disattivazione dei protocolli legacy; re-challenge di sessione in caso di rischio.
• Percorso SDLC obbligatorio: security review e test prima di ogni go-live. Baseline WAF per login/pagamenti/upload.

Giorni 46–75 – automatizzare & provare

• Ticketing automatico per CVE critiche; pipeline di deployment canary.
• Drill di phishing realistici (narrative dirigenti/fornitori) con policy di richiamata chiara.
• Drill applicativi: scenari di abuso (credential stuffing, download massivo, enumeration) incl. fine-tuning dei rate-limit.

Giorni 76–90 – consolidare l’impatto

• Review dei KPI vs. baseline; affinare le misure.
• Principio “never go alone”: nessun change in produzione senza checkpoint di sicurezza.
• Steering trimestrale: il budget segue la riduzione del rischio dimostrabile (rispetto SLO, tempo al containment, tasso di fix per sprint).

Architettura minima: meno attrito, più efficacia

• Backlog centrale dei finding: risultati di sicurezza da scanner, review, WAF in un unico sistema — prioritizzati per impatto sul business.
• Obbligo di telemetria: endpoint, identità, applicazioni web — un percorso dati coerente.
• Automazioni standard: isolamento, blocco account, creazione ticket, notifica stakeholder — senza orgie di clic manuali.
• Piano di uscita: Percorso di migrazione documentato per ogni componente core, così un problema del fornitore non blocca il programma.

Conclusione: la disciplina batte la speranza

Gli attaccanti vincono con velocità e semplicità. I difensori vincono con igiene guidata da SLO, autenticazione resistente al phishing e uno SDLC che impone la sicurezza come gate. Se chiudete queste tre porte in modo coerente, superficie d’attacco, tempi di reazione e costi diminuiscono — in modo misurabile, non “a sensazione”.

FAQ sul post del blog