El problema no es el ataque: es la hora de parada
La conversación de ciberseguridad casi siempre se queda en herramientas. Y la pregunta que de verdad decide es otra: cuando el sistema se cae, ¿cuánto cuesta cada hora y cuánto tardamos en volver? Esa respuesta no la da un producto, la da el diseño de la infraestructura y un plan que alguien haya probado antes.
Un número para dimensionarlo. Una parada de cinco minutos que afecta a 200 usuarios son casi 17 horas de productividad perdidas. Y eso es solo lo que se mide: aparte quedan los pedidos que no entran, la oportunidad comercial y la imagen.
Qué suele estar mal cuando llego
- Superficie expuesta sin control. Puertos abiertos que nadie recuerda haber abierto, servicios accesibles desde fuera que deberían vivir dentro.
- Integraciones directas contra el corazón del sistema en lugar de pasar por servidores de integración dedicados.
- Copias de seguridad que nunca se han restaurado. Una copia que no se ha probado no es una copia: es una carpeta grande.
- Plan de respuesta inexistente o en la cabeza de una persona. El día del incidente esa persona está de vacaciones. Siempre.
- Un único punto de fallo del que dependen varios departamentos sin que nadie lo haya dibujado nunca.
Cómo trabajo
1. Diagnóstico con el negocio delante
Primero identificamos qué procesos paran la facturación si el sistema cae, y cuánto cuesta cada hora de esa parada. Sin ese número, cualquier inversión en seguridad es una discusión de opiniones.
2. Reducir la superficie
Revisión de accesos, puertos y rutas de integración. El objetivo es una lista corta y justificada de lo que está abierto al exterior, con todo lo demás detrás de VPN y de servidores de integración dedicados.
3. Recuperación que se pueda demostrar
Política de copias completas e incrementales, con copias fuera del sistema principal, y un ensayo real de restauración. La virtualización permite tener preparada una máquina pequeña que crece cuando hace falta; ese detalle cambia el tiempo de vuelta.
4. Plan de incidente escrito
Quién decide, a quién se avisa, qué se levanta primero y qué se puede esperar. Con una regla que no siempre gusta: primero se vuelve a operar y después se investiga quién tuvo la culpa. Las dos cosas a la vez se hacen mal.
Qué no hago
No hago auditorías de hacking ético ni vendo licencias de herramientas. Si lo que necesitas es un pentest, te digo a quién llamar. Lo mío es el diseño, la decisión y la continuidad: la parte que se gestiona, no la que se instala.
Con qué te quedas
- Un mapa de qué procesos paran y qué cuesta cada hora parada.
- Una lista priorizada de lo que hay que cerrar, con esfuerzo y plazo.
- Una restauración probada, no prometida.
- Un plan de incidente de una página que entiende también quien no es técnico.
Preguntas frecuentes
¿Esto sirve si mi ERP no es el de siempre?
Sí. El enfoque no depende del fabricante: depende de qué procesos de negocio se paran y de cómo está expuesta la infraestructura. He trabajado con entornos multiplataforma y multiempresa.
¿Cuánto dura un diagnóstico?
Entre una y dos semanas según el tamaño, con acceso a las personas que operan el sistema. El entregable es un informe con prioridades, no una lista de hallazgos sin orden.
¿Trabajas con el equipo interno o lo sustituyes?
Con el equipo interno. Son quienes conocen el sistema; mi papel es ordenar las decisiones y sostener el criterio cuando hay que decir que no.
¿Y si ya hemos sufrido un incidente?
Entonces el orden cambia: primero volver a operar, después reforzar. Puedo ayudar en las dos fases, pero la prioridad es que el negocio funcione.
¿Lo hablamos?
Una conversación de treinta minutos basta para saber si puedo ayudarte o si lo tuyo lo resuelve otro perfil. Si es lo segundo, te lo digo.
Escríbeme