Nos pidieron enviar logs al SOC: con nuestro tamaño, ¿qué departamento o personal debería llevarlo?

Si intentas encasquetárselo a los de sistemas, al primer mes ambas partes empezarán a culparse. El de sistemas manda el log y pasa, el SOC dice 'falta este log' y el cliente se queda en medio. Hace falta al menos un coordinador que entienda de seguridad.

No olvides calcular el consumo de ancho de banda y la carga de CPU de los servidores al transferir datos con syslog o agentes. El equipo de sistemas lo hará, pero la sincronización horaria de los logs enviados y su transmisión cifrada requieren especial atención.

Pasamos por un proceso similar con un equipo de 40 personas. Contratamos consultoría de seguridad externa de 20 horas al mes, el coste era de unas 18.000 TL mensuales. Lo asentamos dedicando solo 4 horas a la semana del tiempo de nuestro chico de sistemas.

No mandéis logs a lo loco solo xq lo pida el cliente. La mayoría de empresas de SOC cobran extra por cada log innecesario que entra. Si no acotáis el alcance de lo que se va a registrar, a fin de mes os vais a encontrar con facturas gigantescas.

¿Qué logs os está pidiendo exactamente el cliente? ¿Solo sistema operativo y firewall o tmb entran las consultas de base de datos y la actividad dentro de la app?

Prepadad ya mismo una matriz de escalado. Si el SOC llama por la noche, ¿a quién van a despertar? 1) ¿Al administrador de sistemas, 2) al líder de software, 3) al director general? No empecéis la integración sin poner esto por escrito.

a nosotros tmb se lo encasquetaron a los de sistemas, a los dos meses los tíos estaban a punto de dimitir. esto hay q llevarlo sí o sí con un consultor externo.

En resumen, el tema de infraestructura debe quedarse en el equipo de sistemas y la parte de código al desarrollador, pero para el seguimiento de alarmas y la coordinación del contrato hay que pedir ayuda externa a un experto sin duda.

Tomo nota, gracias. Un informe de escaneo automático no es lo mismo que una prueba de penetración.

Lo probaré.

Guardado. Los primeros tres meses todo va bien, los problemas aparecen en el cuarto.

Al tomar decisiones, escribe también el peor escenario, no solo el mejor. Corrijanme si me equivoco.

correcto.

Voy a detallar un poco el aspecto técnico. Si obtienes tres respuestas distintas sobre un tema, la pregunta está mal formulada.

Voy a resumir el tema, porque se han dado varias respuestas diferentes. Las decisiones apresuradas son las que hay que corregir seis meses después.

Yo también estaba pensando en lo mismo. Los entornos de prueba olvidados son una puerta de entrada más frecuente que el sistema en producción.

Totalmente. Si tuviera que añadir algo más: Tomar medidas sin hacer inventario es dejar abierta una puerta que no ves.

Antes de decidir, mirad qué datos tenéis en la mano. Espero que le sea útil.

Exactamente así. Si es la primera vez que lo hacéis, empezad poco a poco la escala llegará después.

Si escribís el resultado aquí también servirá de ayuda a otros.

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

La seguridad no es absoluta; significa hacer que el ataque no merezca la pena. Esta es mi opinión, no lo escribo como una verdad absoluta.