forumApri un argomento

Il report del penetration test dice 'risolvere entro 30 giorni' — operativamente cosa significa rimediare alle vulnerabilità?

AAslı A***PartecipanteMembro della community
Iscrizione
ott 2023
Messaggio
19
#1

Ad Austin gestiamo un piccolo software di tracciamento flotte per aziende di logistica. Un cliente enterprise, prima di firmare il contratto, ha preteso che facessimo svolgere un penetration test a una società di cybersecurity indipendente. Abbiamo speso 4.500 dollari per il test e ieri ci è arrivato un report dettagliato di 40 pagine.

Nell'executive summary c'è scritto: 'Si raccomanda di rimediare alle vulnerabilità critiche di livello alto e medio entro 30 giorni'. Nel team abbiamo 3 sviluppatori a tempo pieno, ma non avendo mai affrontato un audit aziendale formale non sappiamo esattamente cosa comporti questo processo a livello operativo.

Queste correzioni spettano ai nostri programmatori o dobbiamo girarle al provider dei server? È realistico chiudere tutto in 30 giorni e, soprattutto, come dimostriamo formalmente al cliente di aver tappato le falle?

NNazlı T***Nuovo membro
Ruolo
Impiegato contabile
Settore
Prodotti ittici
Tipo di organizzazione
Azienda di produzione da 40 persone
Iscrizione
mag 2026
Messaggio
32
Più utile#2

Risposta breve: la remediation delle vulnerabilità è il processo in cui le falle scoperte nel pentest vengono ordinate per livello di rischio, corrette a livello di codice, server o architettura, e infine verificate tramite un test di convalida per certificarne la chiusura. La finestra di 30 giorni è lo standard di settore per i problemi critici e alti, ma non significa necessariamente dover azzerare ogni singola voce all'istante.

Appena avete il report in mano, la prima cosa da fare è dividere i punti per ambito di competenza. Falle come SQL injection, bypass dell'autorizzazione o cross-site scripting spettano interamente ai vostri sviluppatori sul codice sorgente. Al contrario, patch del sistema operativo del server, configurazione TLS o porte aperte vanno gestite dal vostro sistemista tramite i pannelli del cloud provider su cui poggia l'infrastruttura.

Risolvere tutte le vulnerabilità medie entro 30 giorni potrebbe sovraccaricare il vostro team. In questo caso la mossa migliore è applicare controlli di mitigazione. Ad esempio, se non potete riscrivere subito una porzione di codice vulnerabile, potete bloccare temporaneamente gli attacchi impostando una regola sul Web Application Firewall e documentare questa scelta motivandola nel report.

L'unico modo ufficiale per dimostrare al cliente enterprise che le falle sono chiuse è richiedere un re-test alla società che ha eseguito il penetration test. Di solito i contratti di pentest includono una singola verifica gratuita da fare entro 30 o 60 giorni dal primo test. L'azienda riprova gli exploit e rilascia una lettera di attestazione pulita che conferma la risoluzione.

IIrmak V***Partecipante
Ruolo
Contabilità di base
Settore
E-commerce
Tipo di organizzazione
azienda all'interno di un gruppo
Iscrizione
feb 2025
Messaggio
312
#3

Fate attenzione ai punteggi CVSS nel report. I valori pari o superiori a 7.0 sono considerati alti o critici. Di solito riguardano problemi di autenticazione e falle note su librerie datate. I vostri programmatori dovrebbero concentrarsi subito sull'aggiornamento delle librerie e sui filtri di validazione dell'input.

FFatih O***Partecipante
Ruolo
Project manager
Settore
Edilizia
Tipo di organizzazione
ditta individuale
Iscrizione
nov 2023
Messaggio
1
#4

Abbiamo passato un audit simile pure noi. Su 12 rilievi, 4 erano alti. I dev hanno congelato lo sviluppo per due settimane lavorando solo su quello. I 3 problemi di infrastruttura li abbiamo sistemati in 2 giorni con le regole del firewall sul cloud. L'azienda di sicurezza ha fatto la verifica 5 giorni dopo rilasciandoci il report pulito.

KKoray C***PartecipanteMembro della community
Iscrizione
ott 2022
Messaggio
180
#5

La richiesta del cliente di chiudere tutto in 30 giorni è un po' una formalità burocratica. Voci a basso impatto come information disclosure minori o banner con le versioni visibili non creano veri rischi operativi. Concentrate gli sforzi sui pericoli di data breach che possono impattare davvero il cliente.

TTuğrulPartecipante
Ruolo
Energia solare
Iscrizione
feb 2024
Messaggio
88
#6

Contattate subito l'azienda che ha eseguito il penetration test e verificate se nel contratto è previsto il diritto a un re-test. Se c'è, segnatevi chiaramente sul calendario la data di scadenza entro cui completare i fix e richiedere il test.

ÖÖmer I***VeteranMembro della community
Iscrizione
lug 2024
Messaggio
50
#7

I passaggi fondamentali per la risoluzione delle vulnerabilità: 1) Dividete i risultati tra falle nel codice e vulnerabilità di server/rete, 2) Date la priorità a quelle con punteggio CVSS pari o superiore a 7, 3) Per ogni vulnerabilità corretta nel codice, fate eseguire uno scenario di test ai vostri sviluppatori, 4) Una volta completati i fix, richiedete una lettera di attestazione ufficiale alla società di test.

UUğur V***PartecipanteMembro della community
Iscrizione
ago 2023
Messaggio
282
#8

quando si vede un report così corposo per la prima volta si rischia di farsi prendere dal panico, è del tutto normale. metà del documento è composto da screenshot e definizioni generiche. boh se vi mettete a guardarlo a mente lucida vi renderete conto che si tratta di errori di logica che i vostri dev riescono a ripulire in 1-2 settimane.

GGamze Y***PartecipanteMembro della community
Iscrizione
feb 2022
Messaggio
14
#9

lato server di solito si trratta solo di sistemare la configurazione ma gli errori di logica lato codice possono richiedere tempo ma non esitate a fare domande dirette a chi ha fatto il test, sono tenuti a spiegarvi i dettagli del problema.

HHakan Y***Nuovo membro
Ruolo
Specialista risorse umane
Settore
Pubblicità e promozione
Tipo di organizzazione
startup appena avviata
Iscrizione
set 2026
Messaggio
4
#10

Riassumendo: il codice lo sistema il vostro team, i settaggi del server li fate dal pannello cloud. In 30 giorni chiudete le vulnerabilità critiche/alte e spiegate le soluzioni temporanee adottate; alla fine fate rifare il test alla stessa società di sicurezza e consegnate al cliente l'attestazione pulita.

correzione: mi ricordavo male il numero, era un po' più basso.

AAhmet N***Esperto
Ruolo
Addetto al negozio
Settore
Edilizia
Tipo di organizzazione
azienda all'interno di un gruppo
Iscrizione
lug 2022
Messaggio
153
#11

Lascio un avvertimento. Se è la prima volta, inizia in piccolo, il ridimensionamento viene dopo.

Io seguirei questa strada.

SSerdar K***Veteran
Ruolo
Growth marketing
Iscrizione
mag 2023
Messaggio
264
#12

Lo sentiamo dire da tempo, ma da noi non è mai andata così. Quando decidiamo senza misurare, finiamo sempre nello stesso punto.

Io seguirei questa strada.

ZZehra G***Partecipante
Ruolo
Direttore operativo
Settore
Catering
Tipo di organizzazione
boutique agency
Iscrizione
feb 2024
Messaggio
162
#13

se volete procedere così risolvete questo punto fin dall'inizio. boh le decisioni affrettate diventano decisioni da correggere sei mesi dopo.

io seguirei quetsa strada.

OOğuzPartecipante
Ruolo
Ex fondatore
Tipo di organizzazione
startup appena avviata
Iscrizione
ago 2023
Messaggio
76
#14

Racconto la mia esperienza. Il vero problema non è il numero ma su cosa si basa quel numero.

Naturalmente cambia se la vostra situazione è diversa.

NNurayPartecipante
Ruolo
Casa editrice
Tipo di organizzazione
attività con due sedi
Iscrizione
ott 2023
Messaggio
92
#15

Sono nella stessa situazione, per questo chiedo. Le soluzioni che funzionano su piccola scala crollano quando si cresce, l'ho imparato tardi.

Il fatto che tutti facciano una cosa non significa che sia quella giusta. Io seguirei questa strada.

OOsman E***PartecipanteMembro della community
Iscrizione
giu 2024
Messaggio
401
#16

Se scendiamo nei dettagli: Inizia con un piccolo test, non impegnarti subito su tutto.

BBeyza B***PartecipanteMembro della community
Iscrizione
lug 2025
Messaggio
254
#17

non ho alcuna esperienza in materia di cos'è la risoluzione delle vulnerabilità quindi chiedo. insomma inizia con un piccolo test, non impegnarti subito su tutto.

se avete domande scrivete rispondo per qunato possibile.

VVeli T***PartecipanteMembro della community
Iscrizione
ott 2023
Messaggio
152
#18

Esatto, e non è nemmeno così noto. Se la verifica in due passaggi è attiva, una password rubata da sola non serve a nulla.

È tutto, scusate se mi sono dilungato.

VVolkan Ö***Esperto
Ruolo
Stagista
Settore
E-commerce
Tipo di organizzazione
startup appena avviata
Iscrizione
ott 2022
Messaggio
51
#19

Ti seguo.

KKemal P***Nuovo membro
Ruolo
Sviluppatore software
Settore
Trasporti
Tipo di organizzazione
Azienda da 120 dipendenti
Iscrizione
set 2026
Messaggio
79
#20

La discussione si è dispersa, la riassumo. Le soluzioni che funzionano su piccola scala crollano quando si cresce, l'ho imparato tardi.

Correggetemi se sbaglio.

Rispondi