Abbiamo ricevuto tre preventivi SOC — che tipo di tabella dovrei impostare per confrontare perimetro e SLA?

Per quanto riguarda gli SLA fate molta attenzione al punto di partenza di MTTD e MTTR. Molte aziende non fanno partire il conteggio dell'SLA dal momento in cui l'allarme entra nei loro sistemi, ma da quando l'analista di turno valida manualmente il ticket. Questa cosa può trasformare un tempo di risposta dichiarato di 15 minuti in 2 ore effettive.

L'anno scorso abbiamo chiuso un contratto per un'infrastruttura simile con un budget di 80.000 TL. Avendo sottostimato la quota di log, al terzo mese i log dei server sono andati oltre soglia e ci hanno sparato una fattura extra da 28.000 TL. In fase di offerta fatevi bloccare fin da subito il costo per l'eccedenza del volume giornaliero di log.

Non fidatevi mai ciecamente della dicitura 24/7 nelle offerte. Nella maggior parte dei casi nel turno di notte c'è solo uno stagista o un addetto L1 reperibile che fissa uno schermo. Se alle 03:00 di notte scatta il sospetto di un ransomware, c'è un esperto L2/L3 in linea pronto a isolare il server o aspetteranno l'inizio del turno alle 09:00 del mattino?

I 4 punti di controllo più critici da inserire nella tabella di confronto sono: 1) Costo extra-soglia per quota giornaliera di GB di log ed EPS. 2) Riporto o meno al mese successivo delle ore di incident response non utilizzate. 3) Frequenza del supporto per sviluppo e ottimizzazione delle regole di detection. 4) Periodo di retention e indicizzazione dei log storici ai fini degli audit.

da noi il casino più grosso erano i falsi allarmi. arrivavano cinquanta notifiche inutili al giorno e alla fine nessuno le guardava più. comunque fate inserire per forza nella tabella quante ore persona/giorno al mese dedicano all'ottimizzazione e al tuning delle regole.

Nota: ho scritto questo basandomi sulla mia esperienza, potrebbe non valere per tutti.

Quando presentate la relazione al CdA, invece dei tecnicismi mettete un riepilogo focalizzato su rischi e costi. Aggiungete una colonna "esclusioni dal perimetro" accanto alle offerte. Se non mettete nero su bianco quali passaggi durante un incidente ricadono sul vostro team interno e quali si accolla la società SOC, in piena crisi le due parti inizieranno a scaricarsi la colpa a vicenda.

Prima di firmare il contratto pretendete un periodo di Proof of Concept (PoC) di 15 giorni. Collegate quantomeno un paio di server critici e qualche utente. Non impegnate cifre del genere senza aver prima visto dal vivo l'usabilità delle dashboard e la reattività nel generare gli allarmi.

Chi si occuperà della gestione dell'EDR sulle workstation degli utenti? Le aziende che hanno fatto l'offerta si limitano a raccogliere i log o avranno la facoltà di isolare direttamente dalla rete il dispositivo sospetto tramite i propri strumenti in caso di minaccia?

Sono una piccola impresa, vi parlo dal mio punto di vista. Non abbiate paura di chiedere, chi non chiede paga sempre di più.

Naturalmente cambia se la vostra situazione è diversa.

nel nostro caso è andata così ma se la verifica in due passaggi è attiva, una passwoord rubata da sola non serve a nulla.

io seguirei questa strada.

Il mio dubbio è stato chiarito grazie.

Ho lavorato a lungo su questo... comunque un report di scansione automatica e un penetration test non sono la stessa cosa.

Quando prendi una decisione guarda prima quali dati hai a disposizione.

Hai fatto bene ad aprire questo thread.

Ottimo lavoro.

Scusate, ma questo non vale in ogni caso. Se il percorso di notifica è lungo, la notifica non arriva; una notifica mancante significa un evento scoperto tardi.

Mi chiedo anch'io.

Concordo pienamente. Le modifiche ai dati di pagamento non vanno mai verificate tramite il canale di provenienza.

Breve riassunto per i nuovi arrivati: Quando prendete una decisione, scrivete anche lo scenario peggiore, non solo quello migliore.

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