Un fornitore ci ha proposto un SOC gestito: cosa significa esattamente e per noi è troppo?

La prima domanda da fare al fornitore dev'essere questa: "In caso di incidente, avete l'autorizzazione diretta a chiudere le porte o isolare i server, oppure aprite solo una segnalazione nei limiti del vostro SLA?". Se devono solo aprire un ticket e chiamarvi, non ha alcun senso pagare quei soldi. Non si spendono migliaia di dollari al mese per ricevere notifiche.

In una software house di 15 persone ci sono cose da sistemare prima di pensare al SOC: MFA obbligatoria su tutti gli account, restrizioni IP sugli accessi cloud, patch management regolare sui server e gestione centralizzata delle identità. Se mancano queste basi, il team del SOC si limiterà a seguire le tracce dell'attaccante già entrato, senza riuscire a fermarlo in tempo.

Invece di un Managed SOC, prendete una buona licenza MDR (Managed Detection and Response). Si paga per utente e per server. Per 15 persone e pochi server, il vostro costo mensile rimane al massimo sui 300-500 dollari invece di 3.500 dollari, e fa lo stesso identico lavoro.

È la tattica di vendita preferita dalle aziende di sicurezza. Appena sentono parlare di sanità o finanza davanti a loro sbattono subito sul tavolo il pacchetto enterprise più costoso. Vendere un centro operativo dedicato 24/7 a un'azienda di 15 persone è chiaramente un upselling esagerato.

pure noi a suo tempo avevamo fato un accordo del genere continuavano a mandare tipo 50 mail di falsi allarmi a settimana. alla fine i dev hanno buttato tutte le mail nello spam e nn è servito a niente soldi buttati.

Siamo un team fintech di 25 persone, al posto del SOC usiamo i tool di sicurezza nativi del nostro cloud provider e un servizio MDR esterno. La spesa totale annua per la sicurezza non supera gli 8.000 dollari e abbiamo superato gli audit SOC 2 senza problemi.

In ottica di conformità HIPAA, verificate che l'azienda con cui stipulate il contratto firmi un BAA (Business Associate Agreement). Qualora sussista il rischio che i log di monitoraggio contengano dati dei pazienti, è un obbligo di legge che anche il fornitore si assuma tale responsabilità legale.

racconto cosa mi è successo magari vi è utile... se la verifica in due passaggi è attiva una password rubata da sola non serve a nulla.

Anche da noi è così.

La discussione si è dispersa, la riassumo. Gran parte del tempo perso si accumula nelle pratiche in attesa di approvazione.

Le modifiche ai dati di pagamento non vanno mai verificate tramite il canale di provenienza. Spero che le sia utile.

Preso nota, grazie.

Vorrei fare una domanda. Se rimproverate i falsi allarmi, nessuno segnalerà più nulla.

Se rimproverate i falsi allarmi, nessuno segnalerà più nulla. Se scrivete qui il risultato, sarà utile anche ad altri.

Stavo pensando la stessa cosa. Le modifiche ai dati di pagamento non vanno mai verificate tramite il canale di provenienza.

Sono della stessa opinione. Le decisioni affrettate diventano decisioni da correggere sei mesi dopo.

Sono curioso di sapere se qualcuno lo fa in modo diverso.

Assolutamente. Se devo aggiungere qualcosa: Ogni punto non scritto è un punto che in futuro le due parti ricorderanno diversamente.

Inizia con un piccolo test, non impegnarti subito su tutto. Sono curioso di sapere se qualcuno lo fa in modo diverso.

Ho vissuto la stessa cosa.

Riassumo quanto detto finora. Avere il backup accessibile sulla stessa rete e con le stesse credenziali lo rende parte del bersaglio.

Scrivo questo per evitare che facciate lo stesso errore. L'errore commesso da cos è un soc gestito è generalmente reversibile ma costoso.