Ci hanno chiesto di inviare i log a un SOC: con le nostre dimensioni, quale reparto o figura dovrebbe occuparsene?

Se provate ad appiopparlo ai sistemisti, dopo un mese inizieranno a rimpallarsi le colpe. Il sistemista spara i log e se ne frega, il SOC dice "questo log è incompleto" e il cliente resta nel mezzo. Serve per forza almeno un coordinatore che ne capisca di sicurezza.

Quando inviate dati dai server via syslog o agent, occhio a calcolare il consumo di banda e il carico CPU sulle macchine. Il team sistemistico sa farlo, ma la sincronizzazione dei timestamp e la cifratura dei log richiedono un'attenzione a parte.

Con un team di 40 persone ci siamo trovati nella stessa situazione. Abbiamo preso una consulenza esterna di sicurezza per 20 ore al mese, spendendo circa 18.000 TL mensili. Abbiamo messo a regime il processo togliendo solo 4 ore a settimana al nostro sistemista.

Non iniziate a sparare log alla rinfusa solo perché lo vuole il cliente. La maggior parte dei SOC fa pagare un extra per ogni log inutile che riceve. Se non delimitate bene il perimetro dei sistemi da tracciare, a fine mese vi arrivano fatture astronomiche.

Ma il cliente che tipo di log vuole esattamente? Solo OS e firewall o rientrano nel perimetro anche le query al database e le attività applicative?

Preparate subito una matrice di escalation. Se il SOC chiama di notte, chi deve svegliare? 1) Il sistemista, 2) Il tech lead, 3) Il direttore generale? Non partite con l'integrazione prima di aver messo questo punto nero su bianco.

pure da noi l'hanno accollata ai sistemisti dopo due mesi stavano x dare le dimissioni. sta cosa va gestita assolutamente con un consulente esterno.

In sintesi: l'infrastruttura resta ai sistemisti, il codice ai dev, ma per il triage degli alert e la gestione del fornitore serve categoricamente un supporto specialistico esterno.

Preso nota, grazie. Un report di scansione automatica e un penetration test non sono la stessa cosa.

Ci proverò.

Salvato. I primi tre mesi vanno bene, i problemi emergono al quarto mese.

Quando prendete una decisione, scrivete anche lo scenario peggiore, non solo quello migliore. Correggetemi se sbaglio.

corretto.

Approfondisco l'aspetto tecnico. Se ricevete tre risposte diverse su un argomento, la domanda è posta male.

Riassumo l'argomento, perché sono state date diverse risposte. Le decisioni affrettate diventano decisioni da correggere sei mesi dopo.

Stavo pensando la stessa cosa. Gli ambienti di test dimenticati diventano spesso un punto d'accesso più frequente del sistema live.

Assolutamente. Se devo aggiungere qualcosa: Prendere misure senza fare un inventario lascia aperta una porta che non vedi.

Quando prendi una decisione, guarda prima quali dati hai a disposizione. Spero che le sia utile.

Esattamente così. Se è la prima volta, inizia in piccolo, il ridimensionamento viene dopo.

Se scrivete qui il risultato, sarà utile anche ad altri.

Esattamente così. 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. Questa è la mia opinione, non la scrivo come verità assoluta.