Recibimos tres propuestas de SOC: ¿qué tabla debo armar para comparar alcance y SLA?

En la parte de SLA, preste atención al punto de inicio de las definiciones de MTTD y MTTR. Muchas empresas no inician el contador del SLA cuando salta la alerta en el sistema, sino cuando el analista de guardia valida manualmente el ticket. Esto puede elevar un tiempo de respuesta de 15 minutos a 2 horas en la práctica.

El año pasado firmamos un contrato para una infraestructura similar con un presupuesto de 80.000 TL. Como calcularon baja la cuota de logs, al tercer mes nuestros servidores se pasaron del límite y nos cobraron 28.000 TL extra. Al pedir presupuestos, fije de antemano la tarifa por exceso de volumen diario de logs.

Nunca confíe a ciegas en el "24/7" de las propuestas. En la mayoría de los sitios, en el turno noche solo hay un pasante o un L1 de guardia mirando la pantalla. Cuando surge una sospecha de ransomware a las 03:00 AM, ¿hay un especialista L2/L3 en línea para aislar el servidor o van a esperar al turno de las 09:00 AM?

Los 4 puntos de control más críticos que debe añadir a su tabla comparativa son: 1) Costo por exceso de cuota diaria de GB de logs y EPS. 2) Si las horas no utilizadas de respuesta a incidentes se acumulan para el mes siguiente. 3) Frecuencia de soporte para optimización y desarrollo de reglas. 4) Tiempo de retención de logs retroactivos e indexación para auditorías.

de nuestro lado el mayor problema eran los falsos positivos. cuando llegan cincuenta avisos basura al dia ya nadie los mira. la verdad hagan poner si o si en la tabla cuantas horas hombre/dia al mes asignan en la propuesta pa mejorar reglas y tuning.

Nota: esto es mi experiencia, puede no aplicar a todos.

Al presentar a la junta directiva, ponga un resumen enfocado en riesgos y costos en vez de términos técnicos. Abra una columna de "situaciones fuera de alcance" junto a las propuestas. Si no aclaran qué pasos recaen en su equipo interno y cuáles asume la empresa de SOC en un incidente, en medio de la crisis ambas partes se culparán mutuamente.

Antes de firmar el contrato pida una prueba de concepto (PoC) de 15 días. Al menos conecte dos servidores críticos y un par de usuarios. No comprometa ese dinero sin ver en vivo la usabilidad de sus paneles y la rapidez de las alertas.

¿Quién administrará el EDR en los puestos de trabajo finales? ¿Las empresas que cotizan solo recolectan logs o van a usar directamente sus propias herramientas para aislar de la red el dispositivo sospechoso ante una amenaza?

Soy una pequeña empresa, os lo cuento desde mi lado. No tengáis miedo de preguntar, quien no pregunta siempre paga más caro.

Por supuesto, cambia si tu situación es diferente.

a nosotros nos pasó esto luego si la verificación en dos pasos está activa, una contraseña robaad no sirve de nada por sí sola.

yo seguiría por ese camino.

Me han quedado claras las dudas gracias.

Llevé mucho tiempo con este asunto. o sea un informe de escaneo automático no es lo mismo que una prueba de penetración.

Antes de decidir, mirad qué datos tenéis en la mano.

Ha sido una buena idea abrir este hilo.

Buen trabajo.

Perdona, pero esto no es válido en todos los casos. Si el camino de la notificación es largo, la notificación no llega; una notificación que no llega significa un incidente detectado tarde.

Yo también tengo curiosidad.

Estoy totalmente de acuerdo. Los cambios en los datos de pago nunca se verifican por el mismo canal por el que llegan.

Resumen breve para nuevos usuarios: Al tomar decisiones, escribe también el peor escenario, no solo el mejor.

La mayoría de los incidentes no empiezan por una vulnerabilidad, sino por una contraseña filtrada.