Vai al contenuto
GlabIT
GlabIT

Sicurezza offensiva · puntuale

Penetration testing

Penetration test manuali di applicazioni web, API, reti, cloud e mobile secondo OWASP WSTG e PTES — report esecutivo e tecnico, retest incluso.

In una frase

Un test manuale, perimetrato e autorizzato delle vostre applicazioni web, reti, cloud o app mobili, eseguito secondo OWASP WSTG e PTES, che si conclude con un report su cui i vostri ingegneri possono agire e con il retest dei risultati rimediati specificati entro il perimetro e la finestra concordati.

A chi serve

  • Aziende di prodotto che devono mostrare un pentest recente a clienti enterprise, revisori o partner
  • Organizzazioni che preparano evidenze per NIS2, DORA, ISO/IEC 27001 o PCI DSS
  • Team che lanciano o modificano in modo sostanziale un'applicazione web, un'API o un ambiente cloud
  • Chiunque abbia avuto come ultimo "pentest" una scansione automatica con un logo in copertina

Cosa testiamo

  • Applicazioni web e API. Autenticazione e gestione delle sessioni, controllo degli accessi, injection, abuso della logica di business, gestione dei file, integrazioni di terze parti; API REST e GraphQL; single-page application. Metodologia: OWASP Web Security Testing Guide (WSTG v4.2), con OWASP ASVS come checklist di copertura.
  • Rete esterna. La vostra superficie esposta a internet: servizi esposti, VPN, posta, DNS, igiene dei certificati, host dimenticati. Metodologia: PTES.
  • Rete interna e Active Directory. Cosa può raggiungere un attaccante con un punto d’appoggio o un insider malintenzionato: segmentazione, igiene delle credenziali, percorsi di escalation dei privilegi, movimento laterale.
  • Configurazione cloud. Identità e accessi, esposizione dello storage, percorsi di rete, logging e gestione dei segreti sui principali cloud pubblici.
  • Applicazioni mobili. App iOS e Android e le API dietro di esse, secondo le guide OWASP Mobile Application Security.

Come testiamo

Prima manuale. Gli strumenti (scanner, proxy, fuzzer) servono a risparmiare tempo sull’ovvio, e i risultati che producono sono verificati a mano prima di comparire in un report. Concateniamo i risultati per dimostrare l’impatto reale invece di elencare severità isolate, e ci fermiamo e vi chiamiamo quando raggiungiamo qualcosa che non va toccato oltre.

Le regole di ingaggio sono scritte e firmate: autorità scritta del proprietario degli asset, perimetro, esclusioni, tecniche ammesse, finestre di test, gestione dei dati, regole di sicurezza e di stop, contatti di emergenza. Nessun denial-of-service, nessuna ingegneria sociale a meno che non si tratti di un incarico red team, nessuno sfruttamento oltre quanto necessario a provare l’impatto. Il test riduce il rischio; non garantisce che non resti alcuna vulnerabilità e non rimedia per conto vostro.

Dopo il test

I risultati alimentano direttamente il rimedio — il nostro se usate Ingegneria sicura o CaaS, oppure quello del vostro team con il nostro supporto. Il retest verifica i risultati concordati entro la finestra concordata, e la dichiarazione di completamento del test dà al procurement ciò che serve — non è una certificazione né un’attestazione regolatoria, e un test non può dimostrare che non esistano altri problemi.

Consegne

Cosa ricevete

  • Sintesi esecutiva

    Due pagine per il management — cosa abbiamo testato, cosa abbiamo trovato, l'impatto sul business e cosa correggere per primo.

  • Report tecnico

    Ogni risultato con severità (CVSS e la nostra valutazione di business), evidenze, passi di riproduzione e una correzione specifica. Scritto per lo sviluppatore o l'amministratore che farà il lavoro.

  • Retest

    I risultati concordati (critici e alti per impostazione predefinita) ritestati dopo la vostra correzione, entro la finestra concordata, con un report aggiornato e una dichiarazione di completamento del test e retest che potete condividere.

  • Call di debrief

    Una sessione di presentazione dei risultati con il vostro team — domande, priorità e cosa dicono i risultati sul resto del parco.

  • Dichiarazione di completamento del test e retest

    Una dichiarazione di una pagina con perimetro, date, metodologia e stato del retest dei risultati specificati, adatta ai questionari di procurement. Non è una certificazione, un'attestazione regolatoria, un parere di conformità né un incarico di assurance indipendente.

  • Gestione delle evidenze

    Le evidenze di test — richieste, screenshot, esportazioni — sono conservate solo nel luogo concordato nelle regole di ingaggio e vengono restituite o cancellate in modo sicuro alla fine dell'incarico, così nulla di sensibile resta con noi più a lungo di quanto il perimetro consenta.

Modello di incarico

Come si svolge

Modello
Prezzo fisso per perimetro; regole di ingaggio, finestre di test e contatti di emergenza concordati per iscritto prima del primo giorno.
Tempi tipici
Definiti dal perimetro nella proposta — test, reporting e finestra di retest sono ciascuno concordati nel contratto.
  1. 01

    Perimetro

    Asset, ambienti, credenziali, esclusioni, finestre di test e chi chiamare se qualcosa si rompe. Autorizzazione scritta del proprietario degli asset.

  2. 02

    Test

    Test manuale secondo OWASP WSTG (web/API) e PTES (rete), supportato da strumenti dove fanno risparmiare tempo, mai al posto del ragionamento.

  3. 03

    Report

    Bozza di report come concordato nel perimetro; ve la illustriamo, poi la finalizziamo.

  4. 04

    Retest

    Voi correggete, noi verifichiamo i risultati concordati entro la finestra, e report e dichiarazione vengono aggiornati.

FAQ

Le domande che fa un CISO scettico

Qual è la differenza tra un pentest e una scansione delle vulnerabilità?

Una scansione è automatica e trova firme note. Un pentest è una persona che concatena ciò che lo scanner trova — e ciò che non può trovare — in un impatto reale, come leggere i dati di un altro cliente o raggiungere la vostra rete interna. Usiamo gli scanner come uno degli input; il report è scritto dalla persona che ha fatto il test.

Quali metodologie e standard seguite?

OWASP Web Security Testing Guide per applicazioni web e API, PTES per gli incarichi di rete, e le guide OWASP Mobile e LLM dove pertinenti. Le revisioni cloud seguono i benchmark dei provider (CIS) e le nostre checklist di configurazione.

I vostri tester sono certificati?

Pubblichiamo le certificazioni individuali solo quando possiamo documentarle, e non partiamo dai badge. Chiedeteci cosa possiamo mostrarvi — esempi redatti e referenze dove i clienti lo permettono — e giudicate il lavoro.

Il test metterà fuori uso i nostri sistemi?

Testiamo la produzione solo con accordo esplicito, in finestre concordate, senza tecniche di denial-of-service e con un contatto di stop immediato da entrambe le parti. La maggior parte dei test web e API avviene su staging con dati simili alla produzione.

Possiamo vedere un report di esempio prima di acquistare?

Chiedetecelo — dove un esempio adeguatamente redatto è disponibile e autorizzato alla condivisione, vi mostriamo il livello di dettaglio che riceverete.

Testatelo prima che lo faccia qualcun altro

Inviateci il perimetro — URL, intervalli IP, account cloud — e torniamo con una proposta a prezzo fisso con metodologia e tempi.