Alessandria – Penetration Test (PT): come si esegue, metodologia e Compliance

Cyber Advising si occupa di Sicurezza Informatica offrendo servizi per prevenire attacchi informatici, Cyber Security, Consulenza di Sicurezza Informatica.

  • Home   /  
  • Alessandria – Penetration Test (PT): come si esegue, metodologia e Compliance

Vulnerability Assessment e Penetration Test (VAPT): Analisi delle Vulnerabilità per Web, API, WordPress, Server e Cloud

Se un attaccante provasse oggi a colpire il tuo sito, la tua API o la tua infrastruttura, da dove entrerebbe? E soprattutto, cosa riuscirebbe a ottenere? Un Vulnerability Assessment professionale serve esattamente a rispondere a questa domanda in modo concreto, con priorità chiare, evidenze tecniche e un piano di remediation pratico.

Molte aziende hanno già fatto “una scansione”, ma una scansione automatica da sola non basta per prendere decisioni serie. Un servizio di Vulnerability Assessment e Penetration Test (VAPT) fatto bene unisce visibilità, prioritizzazione del rischio e validazione tecnica, così il team non perde tempo dietro falsi positivi o report pieni di rumore.

In questa guida completa trovi una panoramica dettagliata su analisi delle vulnerabilità, Penetration Test e approccio VAPT, con focus su Web Application Security, API Security, WordPress Security, server e cloud security. L’obiettivo è semplice: aiutarti a capire cosa fare, quando farlo e come ottenere un report che serva davvero a ridurre il rischio, migliorare la postura di sicurezza e superare audit e compliance (GDPR, PCI-DSS, ISO 27001).

Avvia scansione gratuita
Richiedi assessment completo
  • VAPT per Web, API, WordPress, Server e Cloud con scope definito e regole d’ingaggio chiare
  • Riduzione falsi positivi con validazione mirata e contesto applicativo
  • Report operativo con priorità, evidenze, remediation plan e raccomandazioni di hardening
  • Re-test opzionale per confermare la chiusura tecnica dei finding
  • Approccio Black Box, Grey Box o White Box in base a obiettivi, vincoli e criticità
  • Conformità a standard internazionali (OWASP Top 10, PTES, NIST SP 800-115)

Indice della guida

Cos’è un Vulnerability Assessment

Il Vulnerability Assessment (VA) è un’attività tecnica di analisi delle vulnerabilità che serve a identificare debolezze di sicurezza, misconfigurazioni, esposizioni e posture deboli su sistemi, applicazioni e infrastrutture. In pratica, significa capire cosa è esposto, dove sono i rischi e quali correzioni hanno la priorità più alta.

Un assessment professionale non si limita a dire “c’è un problema”, ma trasforma i finding in decisioni operative. Per questo, oltre al rilevamento, include classificazione del rischio, validazione dei finding più importanti, contesto applicativo e remediation plan con passi pratici. Il tutto basato su framework riconosciuti come OWASP Top 10, NIST SP 800-115 e linee guida ENISA.

I 3 obiettivi reali di un VA professionale

  • Visibilità: inventario e mappatura della superficie d’attacco reale, inclusi asset dimenticati o shadow IT.
  • Priorità: ordine di correzione basato su rischio reale, non solo su punteggio CVSS, ma considerando exploitabilità, esposizione e impatto sul business.
  • Azione: indicazioni chiare su come correggere e come verificare la chiusura, con esempi di codice o configurazioni sicure.

Se manca uno di questi tre elementi, spesso non stai ricevendo un vero Vulnerability Assessment, ma solo una scansione con output poco utilizzabile.

Perché serve davvero e cosa evita

Molti incidenti nascono da problemi molto comuni: componenti non aggiornati, plugin vulnerabili, pannelli admin esposti, endpoint dimenticati, configurazioni errate, access control debole, file di backup accessibili, token o chiavi pubblicate, ruoli troppo permissivi in cloud o API senza rate limiting.

Un Vulnerability Assessment serve a intercettare questi problemi prima che vengano sfruttati, quando il costo della correzione è più basso e l’impatto sul business è ancora controllabile. Questo è il punto chiave: non è solo “fare sicurezza”, è ridurre costi futuri, tempi di fermo e danni reputazionali.

Cosa puoi prevenire con un VAPT fatto bene

  • Data exposure di dati clienti, ordini, documenti, email, fatture, credenziali
  • Account takeover su utenti, operatori o amministratori
  • Compromissione del sito con malware, redirect malevoli, defacement
  • Abuso API con enumeration, scraping, accessi non autorizzati
  • Fermo servizio, degrado prestazioni, blocchi da provider o blacklist
  • Costi emergenziali di incident response, ripristino e comunicazione
  • Sanzioni normative per violazione di GDPR, PCI-DSS o altre compliance

Inoltre, se devi rispondere a richieste di clienti enterprise, vendor assessment, audit o procurement, un report strutturato fa una differenza enorme tra “non sappiamo” e “abbiamo visibilità e piano d’azione”.

Vulnerability Assessment vs scansione automatica

Una scansione automatica (ad esempio con strumenti open source come Nikto, OpenVAS o commerciali come Nessus) è utile per ottenere segnali rapidi e una prima fotografia del rischio. Ma una scansione da sola non capisce bene logiche di business, ruoli, flussi, condizioni reali di sfruttamento e impatto sui processi aziendali. Per questo non sostituisce un Vulnerability Assessment o un Penetration Test.

Attività Cosa fa bene Limiti principali
Scansione automatica Rileva velocemente header, esposizioni note, misconfig evidenti, segnali di componenti obsoleti Falsi positivi, poca profondità, poco contesto, logiche e ruoli spesso non compresi
Vulnerability Assessment Copertura ampia, priorità reali, remediation plan, contesto applicativo, riduzione dei falsi positivi Richiede scope chiaro e attività strutturata, tempi più lunghi
Penetration Test Verifica sfruttabilità e impatto con evidenze tecniche controllate, catene d’attacco Non nasce per “inventariare tutto” ma per approfondire i punti critici

Approccio consigliato nella pratica: scansione gratuita per partire, Vulnerability Assessment per priorità e remediation, Penetration Test per validare i rischi più gravi o più dubbi.

Vulnerability Assessment vs Penetration Test vs VAPT

Questi servizi rispondono a domande diverse. Capire bene la differenza aiuta a scegliere il percorso giusto e a non spendere budget nel modo sbagliato.

Servizio Domanda a cui risponde Output tipico
Vulnerability Assessment (VA) Dove sono le vulnerabilità e quali sono prioritarie? Finding ordinati per rischio + remediation plan
Penetration Test (PT) Questa vulnerabilità è davvero sfruttabile e con quale impatto? Evidenze di sfruttabilità, catene d’attacco, impatto dimostrato
VAPT (VA + PT) Come ottengo copertura e validazione sui punti critici? Report completo, utile a tecnici, management e audit

Nella maggior parte dei casi, l’approccio più efficace è VAPT: prima si mappa e si classifica, poi si valida in profondità dove il rischio è davvero alto. Questo è in linea con le migliori pratiche PTES (Penetration Testing Execution Standard).

Per chi è consigliato

Un servizio di analisi vulnerabilità e Penetration Test è utile a qualsiasi realtà che esponga asset online. Diventa particolarmente importante in questi casi:

  • E-commerce con account utenti, ordini, pagamenti, coupon e pannelli admin
  • Portali clienti con documenti, aree riservate, ticket, fatture
  • SaaS e piattaforme web con ruoli, permessi, tenant multipli e API
  • WordPress aziendali con plugin, temi, integrazioni e script di terze parti
  • API REST / GraphQL usate da app mobile o partner
  • Infrastrutture cloud con storage, IAM, CI/CD, container e segreti
  • Aziende con audit, vendor questionnaire, procurement o richieste enterprise
  • Realtà soggette a normative come GDPR, PCI-DSS, HIPAA, che richiedono valutazioni periodiche

È molto utile anche prima di un go-live, dopo una migrazione, dopo una release importante o quando vuoi ridurre il rischio in modo misurabile senza rallentare il business.

Quando farlo e con quale frequenza

Regola pratica: quando cambia il rischio, va aggiornata la misura. Fare un assessment una volta sola e poi dimenticarlo non è sufficiente se l’ambiente evolve.

  • Dopo rilasci importanti o nuove feature
  • Dopo migrazioni di hosting, cloud, CDN, WAF, reverse proxy, database
  • Dopo installazione di plugin, moduli o integrazioni di terze parti
  • Dopo modifiche a ruoli, autorizzazioni o flussi applicativi
  • Dopo incidenti, anomalie o segnali di compromissione
  • In modo periodico sugli asset critici (almeno annuale, o semestrale per ambienti ad alto rischio)
  • In ottica di continuous security integrata con DevSecOps

Per ambienti con rilasci frequenti, il modello più efficace è combinare scansioni regolari con assessment mirati e re-test post-fix, così la sicurezza diventa un processo e non un evento isolato.

Metodo di lavoro: come si svolge

Un Vulnerability Assessment professionale non è un click. È un processo strutturato che combina discovery, analisi, validazione, prioritizzazione e reporting. Il flusso può variare in base allo scope, ma in generale segue questi passaggi.

  1. Scoping e pre-engagement: asset inclusi, obiettivi, vincoli, contatti, finestre orarie, regole d’ingaggio, definizione del tipo di test (Black/Grey/White Box).
  2. Asset discovery: domini, sottodomini, endpoint, servizi, pannelli, tecnologie, componenti, versioni.
  3. Attack surface mapping: individuazione dei punti di ingresso reali (login, form, upload, API, callback, admin).
  4. Analisi vulnerabilità e misconfigurazioni: rilevamento, correlazione e classificazione dei finding sulla base di CVE, CWE e best practice.
  5. Validazione mirata: conferma tecnica dei finding più rilevanti e definizione del contesto (es. un SQL injection è realmente sfruttabile? un IDOR permette accesso a dati altrui?).
  6. Prioritizzazione: ordine di remediation per rischio reale e urgenza, utilizzando CVSS e metriche contestuali.
  7. Report tecnico + executive: evidenze, priorità, remediation plan, raccomandazioni.
  8. Re-test (opzionale): verifica della chiusura tecnica dei finding corretti, con report di chiusura.

Approcci possibili: Black Box, Grey Box, White Box

  • Black Box: nessuna informazione iniziale, simulazione esterna realistica (attaccante non autenticato).
  • Grey Box: credenziali o contesto limitato (es. account utente normale), ottimo compromesso tra copertura e profondità.
  • White Box: massimo dettaglio, accesso al codice sorgente, architettura, credenziali admin; utile per applicazioni complesse e logiche di business avanzate.

In molti progetti reali, il Grey Box è la scelta migliore perché aumenta la qualità dei finding su aree riservate, API e flussi autenticati, mantenendo tempi sostenibili.

Scope e regole d’ingaggio

Uno dei motivi principali per cui un assessment produce risultati mediocri è uno scope confuso. Definire bene lo scope serve a migliorare copertura, qualità del report, tempi e costo.

Cosa definiamo nello scope

  • Asset inclusi (domini, sottodomini, ambienti, API, IP, pannelli)
  • Asset esclusi (sistemi fragili, ambienti non autorizzati, servizi non target)
  • Ambiente (production, staging, pre-produzione)
  • Finestre orarie e limiti di carico
  • Contatti tecnici ed escalation
  • Approccio (Black Box, Grey Box, White Box)
  • Credenziali di test e ruoli (se previsti)
  • Limitazioni su test ad alto impatto (es. DoS, phishing)
  • Re-test incluso o opzionale

Uno scope chiaro riduce i rischi operativi, evita incomprensioni e rende il report finale più credibile e più utile per la remediation.

Cosa analizziamo: Web, API, WordPress, Server, Cloud

In base al tuo caso, il servizio può coprire uno o più ambiti. Di seguito una panoramica concreta di cosa viene verificato in un percorso di Vulnerability Assessment e Penetration Test, con riferimenti agli standard OWASP.

Web Application Security

  • Attack surface: pagine esposte, endpoint sensibili, aree admin, endpoint legacy
  • Autenticazione: brute force, enumeration, reset password, recovery flow, MFA bypass
  • Session management: cookie (HttpOnly, Secure, SameSite), timeout, logout, fixation
  • Autorizzazione: IDOR, Broken Access Control (OWASP #1), escalation di privilegi
  • Injection: SQLi, NoSQLi, command injection, path traversal, template injection (OWASP #3)
  • XSS: riflessa, persistente, DOM-based (OWASP #7), impatto su sessione e azioni utente
  • Upload security: validazione file, MIME, storage, permessi, esecuzione di script
  • Security headers: CSP, HSTS, X-Frame-Options, policy client-side
  • Misconfigurazioni: debug attivo, errori verbosi, directory listing, componenti obsoleti

API Security (REST e GraphQL)

  • Auth e token: JWT/OAuth, scadenza, revoca, rotazione, scope, audience, algoritmi deboli
  • Access control: BOLA/IDOR, BFLA, permessi multi-tenant, escalation (OWASP API Top 10 #1)
  • Data exposure: campi sensibili in response, errori verbosi, leakage di informazioni
  • Rate limiting: brute force, enumeration, abuso endpoint critici (OWASP API #4)
  • CORS: policy permissive, wildcard, credenziali e rischi correlati
  • Input validation: injection su payload JSON, filtri, parametri, mass assignment
  • GraphQL: introspection, query depth/complexity, leakage e misconfig, batch attacks
  • Business logic: bypass workflow e controlli mancanti lato server (OWASP API #6)

WordPress Security e CMS

  • Plugin e temi: vulnerabilità note (WPScan), versioni obsolete, moduli non mantenuti
  • Hardening admin: brute force, enumeration utenti, protezioni login, MFA dove possibile
  • Endpoint sensibili: admin, wp-json, xmlrpc, aree legacy
  • File esposti: backup, log, dump, file temporanei, configurazioni (wp-config.php backup)
  • Ruoli e permessi: capability troppo ampie, ruoli custom errati
  • Terze parti: tag, pixel, script esterni e rischio supply chain lato client
  • Misconfig cache/CDN/WAF: bypass o esposizione involontaria di risorse
  • Database: tabelle con prefisso predefinito, utenti con password deboli

Server, Rete e Cloud Security

  • Servizi esposti: porte, pannelli, default config, servizi non necessari (FTP, Telnet, ecc.)
  • TLS/SSL: protocolli, cipher, certificati, configurazione del trasporto, vulnerabilità (Heartbleed, ecc.)
  • Credenziali e segreti: esposizione, gestione, rotazione, variabili d’ambiente, hardcoded secrets
  • IAM: policy troppo ampie, least privilege, ruoli e chiavi a lungo termine (cloud)
  • Storage: bucket pubblici (AWS S3, Azure Blob), policy errate, listing e accessi non previsti
  • Container e CI/CD: permessi, immagini vulnerabili, pipeline, gestione dei segreti, Kubernetes misconfig
  • Logging e monitoraggio: visibilità, audit trail, segnali di compromissione, retention
  • Hardening: baseline CIS, riduzione attack surface, configurazioni raccomandate

Se il perimetro è ampio, il lavoro viene organizzato per priorità: prima gli asset più esposti e critici, poi hardening e approfondimenti progressivi. Questo approccio permette di ridurre il rischio più velocemente senza bloccare l’operatività.

Cosa ottieni: deliverable e risultati concreti

Un buon servizio di Vulnerability Assessment / Penetration Test deve produrre output utilizzabili da tecnici e management. Non solo alert, ma decisioni, priorità e azioni.

Deliverable tipici

  • Mappa della superficie d’attacco con asset e aree sensibili rilevate
  • Elenco finding prioritizzato per rischio reale (critico, alto, medio, basso, info)
  • Evidenze tecniche su endpoint, parametri, comportamento osservato (request/response, screenshot)
  • Remediation plan operativo con quick win e fix strutturali, esempi di codice o comandi
  • Executive summary per decision maker, procurement e audit (grafici, trend, sintesi)
  • Re-test opzionale con stato dei finding dopo correzione (chiuso, aperto, parzialmente risolto)
  • Attestato di esecuzione test (utile per compliance)

Risultati pratici che dovresti vedere

  • Riduzione del rumore e dei falsi positivi
  • Backlog di sicurezza più chiaro e prioritizzato
  • Tempi di remediation più rapidi
  • Migliore allineamento tra Dev, IT, DevOps e management
  • Maggiore controllo del rischio su asset critici
  • Documentazione spendibile in audit o richieste enterprise
  • Diminuzione della superficie d’attacco nel tempo

Come riduciamo falsi positivi e rumore

Il problema numero uno delle scansioni veloci è il rumore. Un assessment serio deve fare il contrario: filtrare, validare e dare contesto.

  • Validazione tecnica dei finding critici: ripetibilità, condizioni, coerenza del comportamento, test manuali
  • Contesto applicativo: endpoint pubblico o autenticato, ruolo richiesto, impatto su dati e funzioni
  • Deduplicazione: raggruppiamo segnali simili per facilitare remediation (es. stesso problema su più pagine)
  • Priorità orientata al rischio: focus su compromissione, data exposure, takeover, abuso API
  • Evidenze utili: request/response, endpoint, screenshot o passaggi di verifica dove servono
  • Analisi di exploitabilità: verifichiamo se una vulnerabilità è realmente sfruttabile in quel contesto

Risultato: meno tempo perso dietro segnalazioni inutili, più tempo speso a chiudere i finding che contano davvero.

Severità e priorità: come decidere cosa viene prima

La priorità non dipende solo da un punteggio numerico (es. CVSS base). Per decidere bene cosa correggere prima bisogna valutare esposizione, sfruttabilità, impatto, probabilità e blast radius. Una vulnerabilità “media” su un endpoint admin pubblico può essere più urgente di un “alto” difficilmente raggiungibile.

Fattore Cosa valutiamo Esempio
Esposizione Internet-facing, autenticato, interno, dietro VPN Endpoint admin pubblico aumenta urgenza
Sfruttabilità Prerequisiti, ruolo richiesto, complessità dell’exploit, esistenza di exploit pubblici Exploit in una richiesta è più urgente di uno che richiede interazione utente
Impatto Dati, account, pagamenti, continuità del servizio, reputazione IDOR su documenti clienti ha impatto alto
Probabilità Quanto è comune e facile da trovare/sfruttare Plugin WP noto e pubblicamente exploitato
Blast radius Quanti utenti/sistemi coinvolge se sfruttato API multi-tenant con permessi deboli
Livello Significato operativo Azione consigliata
Critico Compromissione o esposizione dati plausibile e immediata, senza prerequisiti complessi Mitigazione rapida (ore/giorni), fix definitivo e verifica
Alto Impatto significativo con sfruttamento realistico, richiede condizioni moderate Fix prioritario nel prossimo ciclo di rilascio (giorni/settimana)
Medio Serve condizione specifica o impatto più limitato, o difficile da sfruttare Pianificare remediation e hardening (entro 1-3 mesi)
Basso Best practice o impatto ridotto, o richiede accesso già privilegiato Gestire in manutenzione programmata (backlog)
Info Osservazioni utili su postura e inventario, non vulnerabilità Documentare e usare per miglioramento continuo

Questo approccio aiuta il team a lavorare con un ordine chiaro e aiuta il management a capire perché una correzione viene trattata prima di un’altra.

Esempi di vulnerabilità comuni con impatto reale

Non servono scenari “da film”. Gli incidenti nascono spesso da errori comuni e ripetuti. Ecco esempi frequenti su siti, portali, e-commerce e API.

  • IDOR / BOLA: cambiando un ID, un utente accede a dati o documenti di altri utenti (es. fatture, messaggi).
  • Broken Access Control: funzioni admin raggiungibili con ruoli minori o controlli solo lato client (es. pulsante nascosto ma URL accessibile).
  • Account takeover: brute force, reset password debole (token prevedibile), sessioni non invalidate, MFA assente.
  • XSS persistente: furto sessione, azioni a nome utente, alterazione contenuti, phishing.
  • SQL Injection: lettura dati, bypass login, estrazione di informazioni sensibili (es. dati clienti, credenziali).
  • File upload pericoloso: webshell, malware o esecuzione di file non previsti, defacement.
  • SSRF: accesso a risorse interne o metadata cloud tramite richieste server-side (es. rubare chiavi AWS).
  • Misconfigurazioni cloud/IAM: bucket pubblici, policy troppo ampie, ruoli eccessivi, chiavi esposte.
  • Backup e file sensibili esposti: dump SQL, ZIP, log, .env, file temporanei (es. .bak, .swp).
  • Rate limiting assente: enumeration, brute force, abuso API, scraping aggressivo, DoS applicativo.
  • Error handling verboso: stack trace, versioni, path interni, leakage utile agli attaccanti per pianificare attacchi.
  • Headers e cookie deboli: clickjacking (X-Frame-Options mancante), session hijacking (cookie senza Secure/HttpOnly), riduzione delle difese client-side.
  • Dipendenza con vulnerabilità note: uso di librerie o framework con CVE pubbliche (es. Log4j, Spring4Shell).

Queste vulnerabilità non sono solo “tecniche”. Hanno impatto su business, reputazione, assistenza clienti, compliance e tempi del team. Per questo la priorità va ragionata sul rischio reale.

Remediation: quick win e interventi strutturali

Il valore di un report si vede nella capacità di accelerare la correzione. Per questo è utile distinguere tra interventi rapidi e interventi strutturali.

Quick win (alto impatto, tempi rapidi)

  • Patch di componenti e plugin critici (aggiornare WordPress, plugin, librerie)
  • Chiusura endpoint/servizi esposti non necessari (es. phpMyAdmin, FTP, porta 21)
  • Hardening login, pannelli admin e reset password (blocco account, CAPTCHA, MFA)
  • Rate limit su endpoint sensibili e API critiche (login, registrazione, recovery)
  • Configurazione di security headers (CSP, HSTS, X-Frame-Options, X-Content-Type-Options)
  • Rimozione di backup, log e file temporanei esposti (scansione e cancellazione)
  • Disabilitazione di directory listing su server web

Fix applicativi (server-side e logica)

  • Controlli di autorizzazione lato server (non fidarsi del client)
  • Validazione input e output encoding (prevenire injection e XSS)
  • Gestione sessione e token (revoca, timeout, rotazione, HttpOnly)
  • Gestione errori e logging sicuro (non esporre dettagli interni)
  • Protezione upload, parsing e workflow sensibili (controllo tipo file, dimensione, scansione antivirus)
  • Implementare parametrizzazione query (prepared statements) per SQL

Interventi strutturali (riduzione rischio nel tempo)

  • Riduzione della superficie d’attacco (principio del minimo privilegio, servizi superflui rimossi)
  • Least privilege su IAM, ruoli e accessi (revisione policy cloud, utenti)
  • Rotazione e gestione corretta dei segreti (vault, variabili d’ambiente, non hardcoded)
  • Miglioramento di logging, monitoraggio e alerting (SIEM, detection rule)
  • Baseline di hardening su server, cloud e CMS (CIS benchmark)
  • Processo di re-test e verifica post-remediation (cultura della sicurezza continua)
  • Formazione degli sviluppatori su secure coding (OWASP Top 10)

Obiettivo pratico: abbassare subito il rischio sui punti più critici e migliorare progressivamente la resilienza complessiva del sistema.

Use case: dove il VAPT fa più differenza

E-commerce con pagamenti e account utenti

In un e-commerce la priorità è alta su aree admin, checkout, gestione ordini, coupon, autenticazione, API collegate, plugin e moduli di terze parti. Un problema di access control o un plugin vulnerabile può portare a danni economici e reputazionali immediati. Inoltre, per la conformità PCI-DSS, sono obbligatori test regolari.

SaaS e portali multi-tenant

Qui il focus è spesso su autorizzazioni, isolamento dei tenant, BOLA/IDOR, escalation di privilegi e leakage tra account. Il rischio non è solo tecnico, ma anche contrattuale verso i clienti. Un VAPT aiuta a dimostrare dovuta diligenza e a prevenire violazioni massive.

WordPress aziendali con molti plugin

In WordPress i problemi più frequenti sono plugin e temi non aggiornati, file di backup esposti, hardening admin debole, endpoint sensibili (xmlrpc.php), misconfig di cache/CDN/WAF e integrazioni terze parti non controllate. Un assessment mirato riduce il rischio di compromissione e defacement.

API per app mobile o integrazione partner

Le API richiedono controlli solidi su token, ruoli, rate limiting, BOLA/BFLA, CORS, data exposure e validazione dei payload. Anche una debolezza apparentemente “media” può diventare grave se sfruttabile in modo automatizzato (scraping, furto dati).

Migrazione cloud e cambi infrastrutturali

Quando cambiano hosting, cloud o architettura, aumentano i rischi di misconfigurazione: IAM troppo permissivo, storage esposto, segreti gestiti male, servizi pubblicati inutilmente, logging insufficiente. Un assessment in questa fase riduce il rischio di errori costosi e fughe di dati.

Rilevanza per compliance e normative (GDPR, PCI-DSS, ISO 27001)

Un Vulnerability Assessment non è solo buona pratica, ma spesso un requisito normativo. Ecco come si collega ai principali framework:

  • GDPR: richiede misure tecniche adeguate a proteggere i dati personali (art. 32). Un VAPT documenta l’adozione di tali misure e aiuta a prevenire data breach che comportano sanzioni.
  • PCI-DSS: requisito 11 richiede scansioni delle vulnerabilità trimestrali e test di penetrazione annuali sulle applicazioni e sulla rete.
  • ISO 27001: controllo A.12.6.1 richiede la gestione delle vulnerabilità tecniche; i report VAPT forniscono evidenze per gli audit.
  • NIST Cybersecurity Framework: la categoria “Identify” e “Protect” include la valutazione delle vulnerabilità.

I nostri report sono strutturati per soddisfare le esigenze di audit e fornire la documentazione necessaria per dimostrare la conformità.

Cosa contiene il report (con demo PDF)

Il report non deve essere solo “bello”. Deve essere utile. Per questo è importante che sia strutturato in modo da servire sia chi decide, sia chi implementa la correzione.

Executive Summary (management, audit, procurement)

  • Scope e asset analizzati
  • Sintesi del rischio complessivo (es. “rischio alto su 3 asset critici”)
  • Top criticità e impatto sul business (es. “possibile furto dati clienti”)
  • Ordine di priorità per remediation (cosa fare subito, cosa programmare)
  • Stato del re-test, se incluso
  • Grafici e statistiche (vulnerabilità per gravità, per tipologia)

Sezione tecnica (IT, Dev, DevOps, Security)

  • Finding dettagliati con classificazione e contesto (CVE, CWE, CVSS)
  • Evidenze tecniche (endpoint, parametri, comportamento osservato, screenshot, request/response)
  • Condizioni di verifica/riproduzione dove utile (es. “per riprodurre, inviare POST a /api/user con ID=123”)
  • Remediation plan pratico (es. “aggiornare il plugin X alla versione Y”, “aggiungere controllo lato server in file Z.php”)
  • Raccomandazioni di hardening e miglioramento postura

Apri un esempio di report

Vuoi vedere come appare un report completo con executive summary e dettagli tecnici? Apri il PDF demo:

Apri Report Demo (PDF)

Se vuoi, puoi incorporare il PDF direttamente nella pagina:

Scansione gratuita: cosa ottieni e limiti

La scansione gratuita è un ottimo punto di partenza per capire se esistono esposizioni evidenti e per ottenere una prima fotografia del rischio.

  • Avvio rapido: inserisci il dominio e avvii l’analisi in pochi secondi
  • Primi segnali di rischio: configurazioni deboli, esposizioni note, superfici comuni
  • Priorità iniziali: capisci dove conviene approfondire per primo
  • Report base con elenco di potenziali problemi

Cosa può fare bene una scansione automatica: rilevare rapidamente header, misconfig evidenti, alcuni endpoint esposti, errori verbosi, segnali di componenti obsoleti. Cosa non sostituisce: contesto applicativo, logiche di business, ruoli, autorizzazioni complesse, chaining e impatto reale. La scansione gratuita può generare falsi positivi e non include validazione manuale.

Avvia Free Scan su ExploitFinder

Nota: la scansione gratuita è un inizio. Per priorità serie, remediation strutturata e decisioni tecniche affidabili serve un Vulnerability Assessment completo e, quando opportuno, un Penetration Test.

Quando serve anche un Penetration Test

Il Penetration Test è particolarmente utile quando vuoi trasformare un finding in una prova tecnica controllata e capire l’impatto reale. Non sempre va fatto su tutto il perimetro, ma su aree ad alto rischio è spesso decisivo.

  • Login, ruoli, autorizzazioni e aree riservate
  • Pagamenti, ordini, documenti e dati sensibili
  • API esposte a mobile app o partner
  • Piattaforme multi-tenant e SaaS
  • Go-live o migrazioni recenti
  • Richieste enterprise, audit, procurement, assicurazioni cyber
  • Dopo aver corretto vulnerabilità critiche, per verificare che non ci siano regressioni

Una strategia molto efficace è: scansione gratuita (per una baseline), poi Vulnerability Assessment completo (per copertura e priorità), infine Penetration Test mirato sui punti a maggiore impatto (per validare lo sfruttamento).

Checklist di preparazione

Per ottenere risultati migliori e ridurre tempi morti, è utile preparare queste informazioni (se disponibili). Se non le hai, si può comunque partire in Black Box.

  • Lista di domini, sottodomini e ambienti (prod, staging, pre-prod)
  • Elenco API o documentazione base (OpenAPI/Swagger), se presente
  • Credenziali di test e ruoli (per Grey Box), se previsti (es. utente normale, admin)
  • Vincoli orari e limiti di carico (es. non testare in ore di punta)
  • Contatto tecnico per chiarimenti e validazioni rapide (es. Slack, telefono)
  • Informazioni su stack (CMS, framework, cloud provider, WAF, CDN)
  • Eventuali allowlist IP o regole da coordinare (per non bloccare i test)
  • Sistemi fragili o esclusioni esplicite (es. server legacy che non devono essere stressati)
  • Scopo del test: conformità, go-live, verifica post-fix, etc.

Una preparazione minima fatta bene migliora copertura, qualità del report e velocità della remediation.

Tempi e costi: da cosa dipendono

I tempi e i costi di un Vulnerability Assessment / Penetration Test dipendono soprattutto dallo scope e dalla complessità reale, non solo dal numero di pagine del sito.

Fattore Impatto su tempi/costi Esempio pratico
Numero di asset Aumenta discovery, analisi e reporting Più domini, API, ambienti, pannelli, sottodomini
Profondità del test Aumenta validazione e attività manuale Grey Box e White Box più approfonditi di Black Box
Funzioni critiche Richiedono più attenzione e verifica Pagamenti, upload, area admin, ruoli, flussi complessi
Complessità applicativa Aumenta effort di comprensione e test SaaS, multi-tenant, workflow con stati, integrazioni esterne
Cloud / infra Amplia la superficie e la posture review IAM, storage, servizi esposti, CI/CD, container, orchestrazione
Re-test Aggiunge ciclo di verifica post-fix Conferma chiusura finding corretti, di solito con uno sconto se incluso nel pacchetto
Tipo di report Executive summary e dettaglio tecnico richiedono tempo di scrittura Report personalizzati con raccomandazioni specifiche

Il modo più rapido per spendere bene il budget è definire uno scope chiaro e una priorità iniziale sugli asset più esposti e più critici. Offriamo preventivi personalizzati dopo un colloquio di scoping.

FAQ: Vulnerability Assessment e Penetration Test (VAPT)

Il Vulnerability Assessment elimina le vulnerabilità?
No. Le identifica, le classifica e fornisce un remediation plan. Su richiesta si può supportare anche la remediation e il re-test, ma l’implementazione è a carico del tuo team.

Qual è la differenza tra scansione automatica e VAPT?
La scansione automatica è una prima fotografia. Il VAPT aggiunge contesto, validazione, priorità reali, evidenze e un piano di azione più utile, riducendo i falsi positivi.

È adatto a WordPress?
Sì. WordPress è uno dei contesti in cui plugin, temi, hardening admin, file esposti e misconfigurazioni possono generare rischi concreti. Un assessment ben fatto aiuta a ridurli rapidamente, con raccomandazioni specifiche per il CMS.

Serve sempre anche un Penetration Test?
Non sempre. È consigliato quando hai login, ruoli, dati sensibili, pagamenti, API o scenari ad alto impatto e vuoi verificare la sfruttabilità reale in modo controllato. Per molti siti informativi un Vulnerability Assessment può essere sufficiente.

Quanto spesso va fatto?
Dopo release importanti, migrazioni, nuove integrazioni, nuovi plugin/moduli e periodicamente sugli asset critici (almeno annuale). Per ambienti in evoluzione rapida, consigliamo un approccio continuo o semestrale.

C’è rischio di impattare la produzione durante i test?
Il rischio si riduce con scope chiaro, regole d’ingaggio, finestre orarie, limiti di carico e validazione controllata. Eventuali sistemi fragili vengono gestiti nello scoping. In ogni caso, eseguiamo test non distruttivi e monitoriamo costantemente.

Fate re-test dopo la correzione?
Sì, il re-test è opzionale e serve a confermare tecnicamente la chiusura dei finding, evitando false sicurezze. Di solito viene offerto a un costo ridotto se incluso nel preventivo iniziale.

Il report è utile anche per management o audit?
Sì. Un buon report include sia sezione tecnica, sia executive summary con priorità, impatto e ordine di intervento, oltre a grafici e sintesi. È adatto a essere mostrato a revisori e clienti.

La scansione gratuita basta per audit o clienti enterprise?
In genere no. È utile come primo step, ma per decisioni serie e documentazione strutturata serve un assessment completo, spesso con validazione mirata e firma di un professionista.

Quanto dura un test tipico?
Da 2-3 giorni per un sito piccolo a 2-3 settimane per applicazioni complesse con molti servizi. Il tempo dipende dalla profondità e dal numero di asset.

Che strumenti utilizzate?
Combiniamo strumenti automatici (Burp Suite, Nessus, OWASP ZAP, Nmap, WPScan, ecc.) con tecniche manuali per garantire copertura e ridurre falsi positivi. Tutti i test sono eseguiti da consulenti certificati (OSCP, CEH, ecc.).

Richiedi un Vulnerability Assessment completo

Vuoi un report completo con evidenze, priorità reali e remediation plan, senza rumore inutile? Contattaci e definiamo lo scope ideale per il tuo caso, con focus sugli asset più critici per il business. Ti supporteremo anche nella scelta tra Black, Grey o White Box in base alle tue esigenze.

Se preferisci partire subito, usa la scansione gratuita per ottenere una prima fotografia del rischio e poi valutare un Vulnerability Assessment o un VAPT mirato.

Contattaci
Avvia free scan

Articoli correlati

Generate via Browser