El ciberataque a Oldelval y la nueva exigencia de confianza para la infraestructura crítica

Qué ocurrió y por qué importa

Oldelval, operadora de una de las redes de transporte de petróleo más relevantes de la Argentina, informó un incidente de seguridad informática que afectó determinados sistemas administrativos. De acuerdo con la información difundida por la compañía y publicada por distintos medios, el episodio no interrumpió el transporte de crudo, los protocolos de respuesta fueron activados y las plataformas involucradas pudieron restablecerse.

Ese dato es importante: no hubo una paralización de la operación. Sin embargo, interpretar el caso únicamente desde esa perspectiva sería insuficiente. En una organización que gestiona infraestructura crítica, la pregunta no es solamente si un ataque logró detener la producción o el transporte. También importa saber qué sistemas fueron alcanzados, qué información pudo quedar expuesta, qué dependencias existían entre los entornos administrativos y operativos, cómo se tomaron las decisiones y qué evidencia quedó disponible para reconstruir lo sucedido.

Oldelval administra más de 1.700 kilómetros de oleoductos y conecta la producción de la Cuenca Neuquina con terminales de almacenamiento, refinación y exportación. Por esa red circula una proporción determinante del petróleo producido en Vaca Muerta. Por eso, aun cuando un incidente se limite a sistemas administrativos, su impacto potencial excede a la propia empresa: involucra productores, refinerías, puertos, contratistas, autoridades, inversores y cadenas de abastecimiento.

El caso vuelve visible una realidad que muchas compañías industriales todavía gestionan de manera fragmentada: la continuidad operativa depende cada vez más de sistemas digitales, proveedores tecnológicos, accesos remotos, plataformas corporativas y flujos de información que atraviesan toda la organización.

Que la operación continúe no significa que el riesgo haya terminado

En ciberseguridad, la ausencia de una interrupción visible no equivale a la ausencia de impacto. Un atacante puede acceder a información sensible, credenciales, documentación técnica, datos de proveedores, contratos, correos o sistemas de gestión sin afectar de inmediato el proceso industrial. Incluso puede permanecer dentro de una red durante días o semanas antes de ejecutar acciones más disruptivas.

Por esa razón, la evaluación posterior a un incidente no debe limitarse a confirmar si la producción siguió funcionando. Debe analizar al menos cuatro dimensiones.

La primera es la confidencialidad: qué información pudo ser consultada, extraída o manipulada. En empresas energéticas, los sistemas administrativos pueden contener datos sobre compras, mantenimiento, personal, contratistas, arquitectura tecnológica y proyectos de expansión. Esa información puede ser valiosa para extorsión, fraude, espionaje o ataques posteriores.

La segunda es la integridad: si los registros, documentos, configuraciones o decisiones pudieron ser alterados. En sectores regulados o intensivos en activos físicos, una modificación aparentemente menor puede afectar procesos de aprobación, mantenimiento, abastecimiento o control.

La tercera es la disponibilidad: cuánto tiempo estuvieron afectados los sistemas y qué actividades debieron ejecutarse de forma manual. Aunque la operación principal continúe, la indisponibilidad de plataformas corporativas puede retrasar pagos, compras, coordinación de cuadrillas, acceso a documentación o comunicación con terceros.

La cuarta es la propagación potencial: si existían caminos técnicos o credenciales que permitieran avanzar desde el entorno administrativo hacia sistemas operativos. La segmentación entre tecnología de la información y tecnología operacional es una barrera esencial, pero su eficacia debe comprobarse con evidencia y pruebas periódicas, no presumirse a partir del diseño teórico.

Infraestructura crítica: el problema no es solo tecnológico

Los incidentes en energía suelen presentarse como fallas de protección técnica. Sin embargo, en la práctica, la capacidad de respuesta depende tanto de la tecnología como del gobierno de la organización.

Un equipo puede contar con herramientas avanzadas de monitoreo y aun así responder de manera deficiente si no están definidos los responsables, los criterios de escalamiento, los canales alternativos de comunicación o la autoridad para aislar sistemas. También puede contener un ataque con éxito, pero luego no lograr demostrar qué controles funcionaron, qué decisiones se tomaron o cuándo se recuperó cada servicio.

En ese punto aparece una diferencia fundamental entre tener medidas de seguridad y gestionar la seguridad. Las medidas son controles individuales: autenticación multifactor, segmentación, backups, monitoreo, antivirus, gestión de vulnerabilidades o restricciones de acceso. La gestión conecta esos controles con riesgos, responsables, evidencia, pruebas, excepciones, métricas y revisiones.

En infraestructura crítica, esa conexión es indispensable. La organización necesita saber no solo que existe un procedimiento de respuesta a incidentes, sino cuándo fue probado por última vez, qué resultados tuvo, quién aprobó los cambios y qué hallazgos siguen abiertos. Necesita demostrar que los backups pueden restaurarse, que los accesos de terceros están vigentes y justificados, que las cuentas privilegiadas se revisan y que las dependencias críticas están identificadas.

Sin esa trazabilidad, la seguridad se convierte en una colección de documentos y herramientas difíciles de verificar cuando ocurre un evento real.

La separación entre IT y OT debe ser verificable

En empresas industriales y energéticas conviven dos entornos con prioridades diferentes. Los sistemas de tecnología de la información, conocidos como IT, administran procesos corporativos como correo, finanzas, recursos humanos, compras y documentación. Los sistemas de tecnología operacional, u OT, controlan equipos, sensores, estaciones, válvulas, bombeo y procesos físicos.

Durante años, ambos mundos funcionaron con grados mayores de aislamiento. La digitalización, el monitoreo remoto, la analítica y la necesidad de integrar datos redujeron esa separación. El resultado es una operación más eficiente, pero también una superficie de ataque más amplia.

La segmentación sigue siendo una práctica central, aunque no alcanza con instalar barreras de red. También deben revisarse identidades, accesos de proveedores, estaciones de ingeniería, conexiones remotas, dispositivos compartidos, repositorios documentales y flujos de actualización. Una credencial utilizada para soporte, una notebook de un contratista o una integración mal configurada pueden convertirse en puentes entre entornos.

Por eso, la pregunta correcta no es simplemente si IT y OT están separados. La pregunta es si la organización puede demostrar, con información actualizada, qué conexiones existen, quién las autorizó, qué controles las protegen y cuándo fueron revisadas.

Marcos como ISA/IEC 62443 ayudan a estructurar la ciberseguridad industrial, mientras que ISO 27001 y NIST CSF permiten ordenar el sistema de gestión, los riesgos y la respuesta. Ningún marco elimina el riesgo por sí solo. Su valor aparece cuando se traduce en controles aplicados, evidencia vigente y decisiones sostenidas en el tiempo.

Qué debería poder demostrar una empresa después de un incidente

Después de contener un evento, comienza una fase igual de importante: reconstruir, validar y comunicar. Una organización madura debería poder responder con precisión qué ocurrió, qué activos estuvieron involucrados, qué datos pudieron quedar afectados y qué medidas se adoptaron.

También debería poder mostrar una línea de tiempo confiable. Esto incluye cuándo se detectó la actividad anómala, quién recibió la alerta, cuándo se escaló el incidente, qué sistemas se aislaron, cómo se verificó la recuperación y qué autoridades o partes interesadas fueron informadas.

Esa capacidad depende de registros técnicos, pero también de evidencia de gestión. Las decisiones deben quedar documentadas, las excepciones deben tener responsables y las acciones correctivas deben poder seguirse hasta su cierre.

En una auditoría, una licitación o una revisión de seguridad de un cliente, decir que existe un proceso no suele ser suficiente. Cada vez más organizaciones deben demostrar que ese proceso funciona. Un plan de respuesta sin pruebas recientes, un inventario desactualizado o una política sin aprobación vigente ofrecen una confianza limitada.

La evidencia convierte una afirmación en algo verificable. Permite confirmar que los controles operan, que las responsabilidades están asignadas y que las mejoras posteriores al incidente no dependen de la memoria de las personas.

Siete prioridades para fortalecer la resiliencia

1. Identificar los activos y procesos realmente críticos

No todos los sistemas tienen el mismo impacto. La organización debe relacionar activos tecnológicos con procesos de negocio, seguridad física, obligaciones regulatorias y continuidad. Esa clasificación permite priorizar protección y recuperación en función de consecuencias reales.

2. Mapear dependencias entre sistemas administrativos y operativos

Los entornos pueden estar segmentados y, al mismo tiempo, depender de identidades, proveedores, redes o servicios comunes. El análisis debe incluir conexiones formales e informales, accesos temporales y herramientas utilizadas durante mantenimiento o soporte.

3. Gestionar el acceso de terceros como un riesgo continuo

Contratistas, proveedores de infraestructura, fabricantes y especialistas suelen necesitar acceso a entornos sensibles. Cada acceso debe tener una justificación, un alcance, una fecha de revisión y un responsable. Las cuentas olvidadas o excesivamente privilegiadas constituyen uno de los riesgos más persistentes.

4. Probar la respuesta y la recuperación

Un procedimiento no probado es una hipótesis. Los ejercicios de mesa permiten validar decisiones y coordinación. Las simulaciones técnicas comprueban detección, aislamiento y recuperación. Las pruebas de restauración permiten saber si los backups son realmente utilizables.

5. Mantener evidencia actualizada de los controles

Capturas aisladas y planillas manuales pierden vigencia rápidamente. La evidencia debería estar vinculada a controles, responsables, fechas y fuentes. Cuando sea posible, conviene automatizar su recolección y validación para detectar cambios o vencimientos.

6. Integrar ciberseguridad con continuidad y crisis

Un incidente relevante exige decisiones operativas, legales, regulatorias y comunicacionales. Los planes deben coordinar esas dimensiones y definir quién decide, quién comunica y bajo qué criterios se activa cada nivel de respuesta.

7. Convertir los hallazgos en mejoras verificables

El cierre técnico del incidente no debe confundirse con el cierre del riesgo. Cada hallazgo necesita una acción, un responsable, una fecha objetivo y una validación posterior. De lo contrario, la organización puede volver a quedar expuesta por las mismas causas.

La confianza se construye antes del incidente

Cuando una empresa administra infraestructura estratégica, clientes, inversores y autoridades no esperan una promesa de invulnerabilidad. Esperan capacidad de prevención, respuesta, recuperación y aprendizaje.

Esa confianza no se crea durante una crisis. Se construye antes, mediante una gestión continua que relaciona riesgos, controles, responsables y evidencia. Una organización preparada sabe qué proteger, puede explicar por qué priorizó determinadas medidas y demuestra que sus procesos funcionan.

El incidente de Oldelval deja una señal relevante para toda la cadena energética y para otras industrias críticas de América Latina. La digitalización seguirá avanzando y los ataques no desaparecerán. La ventaja estará en las organizaciones capaces de resistir, recuperar la operación y demostrar con trazabilidad cómo gestionaron el evento.

La ciberseguridad madura no consiste en afirmar que todo está bajo control. Consiste en poder probar qué está controlado, qué riesgo permanece y qué se está haciendo para reducirlo.