Abbiamo ricevuto il report del penetration test in PDF con tabelle tecniche: come lo trasformiamo in una lista di fix?

Non fatevi spaventare dal numero di pagine. Di 75 pagine, almeno 50 sono output generici di scanner automatici e testi copia-incollati. Le aziende che fanno i test spesso replicano lo stesso identico avviso sugli header di sicurezza su cinquanta pagine diverse come se fossero finding separati, giusto per far sembrare il report più corposo e giustificare la fattura.

A noi era capitato un report simile con 42 finding. Presi dal panico stavamo per fermare l'intero sprint, poi analizzandolo bene abbiamo visto che 28 punti su 42 erano solo note informative o header a bassa priorità mancanti. I problemi veri che minacciavano la sicurezza dei dati erano solo due falle nella logica di autorizzazione, e li abbiamo chiusi in tre giorni.

Fissate subito una call di chiusura di 45 minuti con la società di test. È un vostro diritto sicuramente incluso nel contratto. Condividete lo schermo insieme ai vostri dev e fatevi spiegare a voce i finding critici; lasciate che i programmatori chiedano direttamente come sono riusciti a triggerare la vulnerabilità.

Il punteggio base CVSS non riflette sempre il rischio reale. Ad esempio, un finding che richiede che l'attaccante sia già un utente autenticato con certi privilegi potrebbe avere un punteggio simile a una remote code execution non autenticata. Date priorità assoluta alle falle sfruttabili dall'esterno senza bisogno di alcuna credenziale.

capitato anche al nostro team, abbiamo copiato la tabella del pdf su un foglio di calcolo aggiungendo colonne per stato nome dev e stima effort. onestamente smarcati uno a uno e chiesto il retest, finito tutto in due settimane.

Per gli auditor del gruppo ospedaliero con cui dovete firmare non è fondamentale aver azzerato ogni singola voce all'istante. Presentare un piano di remediation ufficiale che dimostri che le falle critiche sono state chiuse e che i rischi minori hanno una roadmap di risoluzione ragionevole di solito basta e avanza per ottenere l'approvazione corporate.

La prima volta che ricevemmo un pentest report ci sentimmo tutti totalmente inadeguati; ti viene l'ansia che il codice scritto fino a quel momento sia un colabrodo. Con il tempo abbiamo capito che, per prassi, gli auditor devono segnalare anche la minima virgola di configurazione. Non buttate giù il morale del team, vedrete che gran parte delle voci si risolve con dieci minuti di configurazione server.

Vorrei fare una domanda. I primi tre mesi vanno bene, i problemi emergono al quarto mese.

Se non lo rendete scritto fin dall'inizio, poi nascono discussioni.

Sono emerse tre opinioni diverse, si completano a vicenda. Ogni punto non scritto è un punto che in futuro le due parti ricorderanno diversamente.

Io seguirei questa strada.

Direi di non avere fretta. insomma il vero problema non è il numero, ma su cosa si basa quel numero.

Io seguirei questa strada.

C'è anche un aspetto di misurazione. Avere il backup accessibile sulla stessa rete e con le stesse credenziali lo rende parte del bersaglio.

Direi di non avere fretta. Nessun processo migliora senza tracciamento, perché non sai cosa correggere.

È tutto, scusate se mi sono dilungato.

Riassumo quanto detto finora. La maggior parte degli incidenti non inizia da una vulnerabilità, ma da una password trapelata.

La sicurezza non è assoluta; significa rendere l'attacco non conveniente. È tutto, scusate se mi sono dilungato.

Racconto cosa mi è successo magari vi è utile. Prendere misure senza fare un inventario lascia aperta una porta che non vedi.

Correggetemi se sbaglio.

su questo punto non sono d'accordo. insomma se cerchi di cambiare tutto insieme, niente si stabilizza.

questa è la mia opinione, non la scrivo come veerità assoluta.

Corretto.

Secondo me è difficile essere così netti sul lato report penetration test. Le modifiche ai dati di pagamento non vanno mai verificate tramite il canale di provenienza.

Buon lavoro.

Anche da noi è così. comunque cercare di farlo da soli è la strada più costosa.

La sicurezza non è assoluta; significa rendere l'attacco non conveniente. Questa è la mia opinione non la scrivo come verità assoluta.