Archivo del autor: Rodrigo Zamora

Ilustración referencial del sector de ATCOM Outsourcing; no corresponde a sus instalaciones ni al incidente

ATCOM Outsourcing figura en el registro atribuido a Qilin

Publicado el

ATCOM Outsourcing figura en un registro de ransomware.live atribuido a Qilin, detectado el 18 de junio de 2026. Se trata de una reivindicación recogida por el rastreador, no de una confirmación independiente de intrusión, robo de información o impacto operativo.

Qué se conoce del registro y la organización

La ficha señala el dominio atcom.cl. En su sitio corporativo, ATCOM ofrece servicios transitorios, outsourcing, outsourcing TI y reclutamiento para empresas en Chile. Esa actividad hace relevante revisar las dependencias entre gestión de personas y servicios tecnológicos, pero no permite inferir qué sistemas, contratos o personas estarían involucrados en la reivindicación.

La ficha de descubrimiento no detalla una causa técnica ni un alcance verificado. En particular, no demuestra una afectación de nóminas, antecedentes de postulantes o plataformas de clientes. Tampoco permite afirmar que una relación comercial haya servido para propagarse a terceros. La información debe leerse como una señal para contrastar con el proveedor, no como confirmación de una cadena de compromisos.

La fecha usada es la de detección por ransomware.live. No se verificó una fecha separada de publicación original de la reivindicación ni la fecha efectiva de la posible intrusión. La revisión se realizó al 13 de septiembre de 2026: no se presenta este antecedente histórico como un ataque ocurrido hoy.

Ilustración referencial de ATCOM Outsourcing y prevención de riesgos tecnológicos; no muestra instalaciones reales
Ilustración editorial generada con IA. Es referencial y no muestra a la organización ni el incidente real.

Qilin: comportamiento documentado y límites

MITRE ATT&CK documenta Qilin, también denominado Agenda, como software S1242. Está asociado a un modelo ransomware como servicio. El identificador corresponde al malware, no a un grupo G ni a un afiliado específico. El nombre de una reivindicación no identifica por sí solo quién habría ejecutado una intrusión.

MITRE identifica a los operadores del servicio como Water Galura, G1050, también GOLD FEATHER. Eso no permite identificar al afiliado del caso. Las siguientes conductas figuran en el perfil del malware: son antecedentes históricos, no técnicas verificadas en ATCOM.

Mitigaciones verificadas en MITRE ATT&CK

Las páginas oficiales de cada técnica vinculan las mitigaciones indicadas. Su aplicación debe ajustarse al entorno y comprobarse; no garantizan por sí solas evitar un incidente.

  • M1038 — Execution Prevention: para T1219.002, permitir únicamente herramientas de soporte aprobadas mediante controles de aplicaciones.
  • M1037 — Filter Network Traffic: para T1021.002, restringir SMB mediante cortafuegos de host a las comunicaciones que realmente necesita la operación.
  • M1053 — Data Backup: para T1486, disponer de copias protegidas fuera del sistema de origen y comprobar que una aplicación prioritaria se puede restaurar.

Una prioridad práctica para el sector

Para empresas con personal externo o servicios TI tercerizados, la primera revisión práctica es identificar cuentas con acceso remoto y la persona que responde por cada una. Una autorización de soporte no debería transformarse en acceso permanente e irrestricto. Conviene comprobar cómo se revocan permisos al terminar una asignación y si los cambios quedan registrados. En paralelo, es útil ensayar cómo continuar procesos esenciales de personal ante la indisponibilidad de una herramienta, sin presumir que esa interrupción ocurrió aquí.

El vínculo con un proveedor exige preguntas específicas: alcance de los accesos, separación de ambientes y canales de notificación. Una respuesta documentada es más útil que asumir, por el nombre del grupo, una técnica de entrada o un daño que las fuentes no acreditan.

Las imágenes de portada e interior son referenciales, generadas con IA. Las fuentes enlazadas permiten distinguir información institucional, registro de la reivindicación y análisis preventivo; no se reproducen datos sustraídos.

Ilustración referencial del sector de Clínica Maitenes; no corresponde a sus instalaciones ni al incidente

Clínica Maitenes confirmó un incidente: el registro de Qilin

Publicado el

Clínica Maitenes confirmó públicamente un incidente de ciberseguridad en junio de 2026. Por separado, ransomware.live la registra bajo el nombre de Qilin con detección del 2 de junio de 2026. Ambas fuentes deben distinguirse: la comunicación institucional no identifica al grupo como responsable.

Qué se conoce del registro y la organización

La Clínica Maitenes informa atención médica en Melipilla y Talagante, con servicios de laboratorio e imagenología. Su comunicado del 13 de junio de 2026 confirmó un incidente que afectó a un sistema de respaldo, la activación de medidas de contención, una investigación interna y la comunicación a ANCI. La institución señaló entonces que la atención y su operación no habían sido interrumpidas.

Hay, por tanto, una confirmación institucional de un incidente, pero no de todos los extremos de la reivindicación. El comunicado revisado no atribuye el hecho a Qilin ni confirma robo de fichas clínicas. Indica que el alcance estaba en evaluación y que, si se confirmaba compromiso de información personal, se contactaría a las personas correspondientes por canales oficiales. No debe convertirse esa condición en una filtración confirmada.

La fecha usada es la de detección por ransomware.live. No se verificó una fecha separada de publicación original de la reivindicación ni la fecha efectiva de la posible intrusión. La revisión se realizó al 11 de septiembre de 2026: no se presenta este antecedente histórico como un ataque ocurrido hoy.

Ilustración referencial de Clínica Maitenes y prevención de riesgos tecnológicos; no muestra instalaciones reales
Ilustración editorial generada con IA. Es referencial y no muestra a la organización ni el incidente real.

Qilin: comportamiento documentado y límites

MITRE ATT&CK documenta Qilin, también denominado Agenda, como software S1242. Está asociado a un modelo ransomware como servicio. El identificador corresponde al malware, no a un grupo G ni a un afiliado específico. El nombre de una reivindicación no identifica por sí solo quién habría ejecutado una intrusión.

Las siguientes conductas figuran en ese perfil. Son antecedentes del ransomware, no técnicas verificadas en este caso.

Mitigaciones verificadas en MITRE ATT&CK

Las páginas oficiales de cada técnica vinculan las mitigaciones indicadas. Su aplicación debe ajustarse al entorno y comprobarse; no garantizan por sí solas evitar un incidente.

  • M1053 — Data Backup: para T1486 y T1490, conservar copias aisladas del sistema de origen y probar la restauración en condiciones controladas.
  • M1018 — User Account Management: para T1490, restringir a las cuentas estrictamente necesarias el acceso a respaldos; revisar privilegios y revocaciones.
  • M1040 — Behavior Prevention on Endpoint: para T1486, habilitar protección de comportamiento contra ransomware en sistemas compatibles y validar su funcionamiento antes del despliegue general.

Una prioridad práctica para el sector

En una organización sanitaria, probar respaldos debe involucrar a TI y a responsables asistenciales. La prueba puede verificar si es posible recuperar una aplicación prioritaria, con qué antigüedad de datos y sin usar las credenciales del sistema de producción. El ejercicio debe preservar la confidencialidad y evitar afectar la atención. Tener una copia visible desde una consola no demuestra que pueda restaurarse ni que esté fuera del alcance de una cuenta comprometida.

Para pacientes y colaboradores, la orientación es seguir los canales oficiales de la clínica y verificar mensajes inesperados antes de entregar información. Para las empresas del sector, la enseñanza preventiva es revisar la independencia de los respaldos, sin atribuir a esta institución técnicas no comprobadas.

Las imágenes de portada e interior son referenciales, generadas con IA. Las fuentes enlazadas permiten distinguir información institucional, registro de la reivindicación y análisis preventivo; no se reproducen datos sustraídos.

Ilustración referencial del sector de Comercial Echave Turri Limitada; no corresponde a sus instalaciones ni al incidente

Qilin señala a Comercial Echave Turri en su listado

Publicado el

Comercial Echave Turri Limitada figura en un registro de ransomware.live atribuido a Qilin, detectado el 17 de mayo de 2026. Se trata de una reivindicación recogida por el rastreador, no de una confirmación independiente de intrusión, robo de información o impacto operativo.

Qué se conoce del registro y la organización

El registro vincula a Comercial Echave Turri Limitada con ajj.cl. La página oficial de AJJ ofrece computación, servidores, conectividad y soluciones TI, identifica a Echave Turri en su pie y sitúa su contacto en Santiago. Esa coincidencia permite contextualizar la referencia chilena, pero la información comercial no confirma un compromiso de seguridad.

Para los proveedores tecnológicos, una acusación de este tipo plantea preguntas sobre órdenes de compra, continuidad de soporte y accesos de administración. Son ámbitos que conviene revisar, no sistemas que esta noticia declare afectados. La ficha consultada no precisa un volumen de información, un vector de entrada ni consecuencias verificadas para clientes. Tampoco permite identificar al afiliado que habría intervenido.

La fecha usada es la de detección por ransomware.live. No se verificó una fecha separada de publicación original de la reivindicación ni la fecha efectiva de la posible intrusión. La revisión se realizó al 11 de septiembre de 2026: no se presenta este antecedente histórico como un ataque ocurrido hoy.

Ilustración referencial de Comercial Echave Turri Limitada y prevención de riesgos tecnológicos; no muestra instalaciones reales
Ilustración editorial generada con IA. Es referencial y no muestra a la organización ni el incidente real.

Qilin: comportamiento documentado y límites

MITRE ATT&CK documenta Qilin, también denominado Agenda, como software S1242. Está asociado a un modelo ransomware como servicio. El identificador corresponde al malware, no a un grupo G ni a un afiliado específico. El nombre de una reivindicación no identifica por sí solo quién habría ejecutado una intrusión.

Las siguientes conductas figuran en ese perfil. Son antecedentes del ransomware, no técnicas verificadas en este caso.

Mitigaciones verificadas en MITRE ATT&CK

Las páginas oficiales de cada técnica vinculan las mitigaciones indicadas. Su aplicación debe ajustarse al entorno y comprobarse; no garantizan por sí solas evitar un incidente.

  • M1017 — User Training: para T1566.002, entrenar la detección y el reporte de correos sospechosos; habilitar un canal sencillo para consultar antes de abrir enlaces.
  • M1018 — User Account Management: para T1490, limitar las cuentas que pueden administrar respaldos y revisar periódicamente que esos permisos sigan siendo necesarios.
  • M1053 — Data Backup: vinculada con T1486 y T1490, mantener copias fuera del sistema y probar su restauración; una tarea de respaldo exitosa no prueba recuperabilidad.

Una prioridad práctica para el sector

Una revisión útil para empresas que prestan soporte parte por separar las cuentas comerciales de las credenciales de administración. Conviene inventariar los accesos temporales, comprobar quién puede aprobarlos y retirar los que ya no tengan una necesidad vigente. También es razonable ensayar la recuperación del sistema de pedidos sin depender del mismo equipo desde el cual se administra el respaldo. Son recomendaciones preventivas, no una descripción de fallas comprobadas en AJJ.

Los clientes no deberían interpretar la aparición de un proveedor en un listado como prueba de que sus propios entornos estén comprometidos. La pregunta concreta es qué servicios o accesos compartidos requieren validación y qué evidencia puede proporcionar el canal oficial del proveedor.

Las imágenes de portada e interior son referenciales, generadas con IA. Las fuentes enlazadas permiten distinguir información institucional, registro de la reivindicación y análisis preventivo; no se reproducen datos sustraídos.

Profesionales evaluando infraestructura tecnológica antigua y su renovación

Tecnología sin soporte: cuándo renovar, aislar o retirar

Publicado el

La tecnología sin soporte suele permanecer en una empresa por una razón comprensible: todavía funciona. El servidor permite facturar, el equipo controla una máquina o la aplicación guarda información que nadie quiere perder. Sin embargo, que un sistema siga encendido no significa que su fabricante vaya a corregir la próxima vulnerabilidad. La decisión útil para la gerencia no es reemplazar todo de inmediato, sino resolver qué renovar, qué aislar temporalmente y qué retirar.

Esa diferencia cambia la conversación presupuestaria. Un activo antiguo puede ser manejable durante una transición; uno expuesto a internet y sin actualizaciones puede requerir una medida inmediata. La prioridad depende del servicio que sostiene, sus conexiones y las alternativas disponibles, no solo del año de compra.

Qué significa tener tecnología sin soporte

El fin del soporte depende del producto, su versión y las condiciones del proveedor. Puede afectar actualizaciones de seguridad, asistencia técnica, repuestos o compatibilidad. Por eso conviene comprobar la política oficial y el contrato, en lugar de asumir que todos esos beneficios terminan juntos.

Por ejemplo, la política de ciclo de vida fijo de Microsoft distingue soporte principal, extendido y determinadas opciones de actualizaciones posteriores. Una extensión contratada puede dar tiempo para migrar, pero debe verificarse su cobertura real. Tampoco convierte una plataforma antigua en una solución indefinida.

El inventario debería identificar versión, responsable, servicio asociado, fecha de término y evidencia del proveedor. El Control 2 de CIS propone gestionar activamente los activos de software. Sin esa base, las compras responden a urgencias y quedan dependencias fuera del presupuesto.

Cómo ordenar las prioridades sin detener el negocio

Primero, pregunte qué ocurre si el equipo deja de estar disponible. No pesa lo mismo un computador de consulta que el único servidor capaz de emitir documentos operativos. Después revise quién puede conectarse, qué privilegios utiliza y si existe una alternativa probada.

Un ejemplo hipotético: una empresa mantiene una aplicación de bodega que solo opera sobre un sistema antiguo. Antes de comprar hardware, necesita saber si podrá migrar la base de datos, conectar los lectores y recuperar el servicio. Renovar el servidor sin resolver esas dependencias puede trasladar el problema a un equipo nuevo.

La revisión de la superficie de ataque externa ayuda a detectar activos accesibles desde internet. Esa exposición debe entrar en la decisión, junto con la criticidad y la posibilidad de recuperación. No es necesario esperar a que exista una alerta pública para identificar un equipo sin responsable o una plataforma abandonada.

Técnico desconectando un equipo antiguo para su retiro controlado
La transición debe contemplar las conexiones, los datos y el servicio que depende del equipo.

Renovar, aislar o retirar: tres decisiones distintas

Renovar cuando el servicio sigue siendo necesario

Actualizar o reemplazar tiene sentido cuando la función sigue aportando valor. Incluya pruebas de compatibilidad, licencias, migración, capacitación y una ventana de cambio. Antes del paso a producción, acuerde criterios de aceptación y una forma segura de volver atrás si la prueba falla.

NIST presenta la gestión de parches como mantenimiento preventivo de la tecnología, con participación de responsables de negocio y TI. Aplicado a esta decisión, el presupuesto debe cubrir la continuidad del mantenimiento y no únicamente la instalación inicial.

Aislar como excepción temporal

Cuando la sustitución necesita preparación, limitar comunicaciones puede reducir exposición. Una segmentación de red bien definida permite autorizar solo los flujos necesarios. También conviene restringir la administración, retirar accesos innecesarios y vigilar conexiones inesperadas.

Estas medidas no reparan el software ni garantizan que sea seguro. La excepción necesita un dueño, controles comprobables y una fecha de salida. Si cada revisión termina aplazando esa fecha sin recursos asignados, la transición se ha convertido en permanencia.

Retirar cuando ya no existe una necesidad justificada

Apagar no basta. Compruebe las dependencias, preserve la información que corresponda, revoque credenciales y certificados, cierre accesos y actualice el inventario. El tratamiento de los discos debe ajustarse a la sensibilidad de los datos y a las obligaciones de conservación aplicables. Un equipo fuera de uso tampoco debería seguir habilitando acceso remoto.

Qué debería quedar aprobado

La decisión puede resumirse en una ficha: activo y servicio, evidencia del fin de soporte, impacto de falla, alternativa elegida, responsable, presupuesto y plazo. Agregue cómo se probará la recuperación y quién aceptará el resultado. Así, gerencia puede distinguir una inversión necesaria de una excepción que acumula riesgo.

El objetivo no es eliminar toda tecnología antigua, sino evitar dependencias sin una salida viable. AllDefense puede acompañar la evaluación de redes y sistemas para convertir ese inventario en un plan de renovación coherente con la operación.

Equipo directivo define RTO y RPO para la continuidad tecnológica

RTO y RPO: cuánto puede esperar su empresa para recuperar

Publicado el

Una caída de dos horas puede ser tolerable para un sistema interno y crítica para el canal que recibe ventas o coordina despachos. Definir RTO y RPO traduce la continuidad del negocio a límites para decidir qué recuperar primero, cuánto invertir y qué pérdida de información resulta aceptable.

La conversación debe ocurrir antes de elegir una solución. Sin conocer el impacto operativo, el área técnica puede proteger todos los sistemas de igual forma: una alternativa costosa e insuficiente para los procesos que necesitan volver antes.

RTO y RPO responden preguntas diferentes

El objetivo de tiempo de recuperación, o RTO, establece cuánto puede permanecer un sistema en recuperación antes de afectar negativamente la misión o los procesos de negocio. El glosario de NIST sobre RTO pone el foco en la duración total, no solo en el tiempo que tarda un servidor en encender. También cuentan la validación, la reconexión de usuarios y el retorno efectivo del proceso.

El objetivo de punto de recuperación, o RPO, mira hacia los datos. Según la definición de NIST, indica el punto en el tiempo hasta el cual debe recuperarse la información después de una interrupción. Un RPO de cuatro horas significa que el diseño debe poder volver, como máximo, a un estado de datos cuatro horas anterior; no promete que la operación completa estará disponible en ese plazo.

El número debe nacer del impacto, no de la tecnología

Pedir “cero pérdida” y “recuperación inmediata” parece prudente, pero exige replicación, capacidad disponible, conectividad y operación capaces de sostener esa promesa. Si el proceso no justifica ese nivel, la empresa inmoviliza recursos. Si lo justifica y la arquitectura no puede cumplirlo, el objetivo crea una expectativa falsa.

La base es el análisis de impacto al negocio. Cada responsable debe explicar qué sucede cuando su proceso se detiene: qué compromisos se incumplen, qué decisiones quedan bloqueadas, qué operaciones manuales existen y cuánto tiempo pueden sostenerse. La guía NIST SP 800-34 Rev. 1 relaciona la planificación de contingencia con la evaluación de sistemas y operaciones para establecer requisitos y prioridades.

No todos los períodos pesan igual. Un cierre contable, una jornada de alta demanda o una ventana de despacho pueden reducir la tolerancia. Conviene documentarlo en lugar de fijar una cifra que oculta el momento más exigente. La decisión pertenece al negocio; TI aporta capacidades, costos y restricciones.

Equipo verifica la recuperación de un servicio tecnológico

Las dependencias cambian el RTO real

Un servicio rara vez vuelve por sí solo. Puede depender de identidad, red, bases de datos, certificados, integraciones, proveedores o personal con accesos especiales. Recuperar la aplicación dentro del plazo no sirve si sus usuarios no pueden autenticarse o si el sistema que entrega los datos sigue detenido. El objetivo debe medirse sobre la capacidad que el negocio utiliza, no sobre un componente aislado.

Este análisis también define la secuencia. Un proceso con RTO breve puede depender de una plataforma aparentemente secundaria que adquiere prioridad. Vincular procesos, sistemas y terceros permite conversar con proveedores sobre tiempos demostrables, no solo porcentajes generales de disponibilidad.

Un respaldo no demuestra que el objetivo pueda cumplirse

Tener copias es necesario, pero no equivale a tener recuperación. El respaldo puede estar incompleto, requerir credenciales no disponibles, depender de infraestructura afectada o tardar más de lo previsto al restaurarse. También puede recuperar archivos y dejar fuera configuraciones, claves o integraciones necesarias para prestar el servicio.

La prueba debe observar el resultado completo: desde activar el procedimiento hasta que usuarios autorizados validan datos y funciones. NIST SP 800-184 plantea la recuperación como una capacidad que se planifica, prueba y mejora. Registrar tiempos y obstáculos permite comparar la capacidad real con los objetivos aprobados.

Qué revisar cuando la prueba no alcanza el objetivo

Un incumplimiento no conduce automáticamente a comprar tecnología. La demora puede estar en una aprobación, un inventario incompleto, una dependencia desconocida, un contrato sin tiempos de respuesta o un procedimiento que nadie ha ensayado. Separar esas causas evita tratar como problema de infraestructura lo que en realidad es una falla de coordinación o gobierno.

Cuando la brecha sí es técnica, las opciones pueden incluir mayor frecuencia de respaldo, replicación, capacidad alternativa o automatización. Deben compararse contra el impacto que reducen y el riesgo residual que queda. El servicio de redes y sistemas puede aportar la visión de infraestructura, mientras una asesoría estratégica ayuda a conectar la decisión con procesos, prioridades y responsables.

Los objetivos útiles se aprueban y se vuelven a probar

RTO y RPO deben quedar asignados a servicios concretos, con propietario, dependencias, supuestos y fecha de revisión. Cambian cuando la empresa incorpora plataformas, externaliza procesos, abre nuevos canales o modifica su tolerancia al riesgo. Una cifra sin responsable termina envejeciendo sin que nadie advierta que dejó de representar la operación.

La prueba puede integrarse a un simulacro de ciberseguridad, pero cumple una función distinta: el simulacro examina decisiones y coordinación; la recuperación valida si el servicio y sus datos vuelven dentro de los límites acordados. Juntas, ambas evidencias permiten saber si la continuidad existe fuera del documento. La pregunta final no es cuántos respaldos tiene la empresa, sino qué capacidad puede recuperar, hasta qué punto y en cuánto tiempo.

Fuentes consultadas

NIST: Recovery Time Objective; NIST: Recovery Point Objective; NIST SP 800-34 Rev. 1: Contingency Planning Guide; NIST SP 800-184: Guide for Cybersecurity Event Recovery.

Equipo directivo participa en un simulacro de ciberseguridad

Simulacro de ciberseguridad: probar antes de una crisis

Publicado el

Un plan de respuesta puede parecer completo hasta que alguien debe decidir con información parcial, presión de tiempo y servicios interrumpidos. Un simulacro de ciberseguridad permite ensayar ese momento sin afectar la operación real. Su valor no está en representar una crisis de forma teatral, sino en comprobar si las personas correctas se coordinan, si conocen sus atribuciones y si las dependencias previstas en el documento existen de verdad.

Qué valida un simulacro de ciberseguridad

Un ejercicio de mesa presenta un escenario progresivo para que los participantes expliquen qué harían y por qué. No es una prueba de penetración ni exige desconectar sistemas. Sirve para observar decisiones, comunicaciones, escalamiento y uso de procedimientos ante una situación verosímil, como una indisponibilidad prolongada, una filtración o la pérdida de acceso a una plataforma crítica.

La diferencia frente a una capacitación es importante. En una clase se explica el comportamiento esperado; en el simulacro se descubre qué ocurre cuando distintas áreas interpretan el mismo evento. Pueden aparecer dudas sobre quién declara el incidente, qué proveedor debe ser contactado, quién autoriza una medida que afecta ventas o qué antecedentes necesita la gerencia para decidir.

El escenario debe exigir decisiones, no repetir el procedimiento

Un buen escenario parte de procesos relevantes para la organización. Si el negocio depende de comercio electrónico, logística, atención de clientes o servicios en sucursales, la historia debe tocar esas capacidades. Copiar un caso genérico de ransomware puede generar conversación, pero difícilmente revelará dependencias propias, responsables ausentes o compromisos contractuales que nadie había considerado.

Los eventos se entregan por etapas. Al comienzo puede existir una alerta ambigua; más tarde aparece evidencia de propagación, una consulta de prensa o la indisponibilidad de un tercero. Cada nueva información obliga a revisar decisiones previas. CISA utiliza este enfoque en sus paquetes de ejercicios de mesa, que incorporan objetivos, escenarios y preguntas para facilitar la discusión.

Facilitadora registra eventos y decisiones de un ejercicio de ciberseguridad

La respuesta no pertenece únicamente a TI

Tecnología y seguridad participan, pero muchas decisiones recaen en otras funciones. Operaciones evalúa el impacto y las alternativas manuales; Legal analiza obligaciones; Comunicaciones prepara mensajes; la gerencia prioriza continuidad, exposición y recursos. Según el escenario, también puede ser necesario incorporar a un proveedor crítico. NIST SP 800-61 Rev. 3 señala que los ejercicios ayudan a preparar tanto al personal como a terceros involucrados en futuras actividades de respuesta.

Esto no significa convocar a toda la empresa. La selección debe responder a los objetivos del ejercicio. Una sesión centrada en recuperación tendrá participantes distintos de otra diseñada para probar escalamiento ejecutivo. Un grupo demasiado amplio puede diluir las decisiones; uno limitado a especialistas técnicos dejará sin observar los puntos donde suelen aparecer demoras organizacionales.

Facilitar y observar es más importante que actuar

La persona facilitadora controla el ritmo, introduce nuevos antecedentes y evita que la conversación se convierta en una explicación técnica extensa. No debe conducir a los participantes hacia una respuesta predeterminada. Las dudas, desacuerdos y supuestos son precisamente la evidencia que el ejercicio busca producir.

Los observadores pueden registrar cuánto tarda una decisión, qué información se solicita, qué documento se consulta y dónde surge un bloqueo. También conviene distinguir un error del participante de una falla del sistema de gestión. Si nadie conoce el teléfono de un proveedor, el problema puede estar en el directorio; si dos áreas creen tener la misma atribución, corresponde revisar gobierno y responsabilidades.

El hallazgo aporta valor cuando se cierra

La sesión debe terminar con una revisión honesta, pero no con una lista interminable de observaciones. El informe posterior necesita explicar qué ocurrió, qué capacidad quedó demostrada, qué brecha modifica el riesgo y qué acción la resolverá. NIST SP 800-84 recomienda documentar observaciones y mejoras en un informe posterior al ejercicio.

Asignar responsables, prioridad y una forma de verificar el cierre convierte la experiencia en mejora. Algunas acciones requerirán actualizar el plan; otras pueden afectar contratos, contactos, accesos de emergencia o criterios de comunicación. La política de seguridad y sus evidencias también pueden revisarse cuando el ejercicio demuestra que una obligación formal no se traduce en una práctica observable.

Comenzar con alcance acotado y aumentar exigencia

Para una organización que nunca ha ensayado, un ejercicio de mesa breve y bien enfocado suele entregar más valor que una simulación compleja. Cuando roles y procedimientos maduran, se pueden probar funciones específicas, canales alternativos o componentes técnicos. La progresión permite aprender sin introducir riesgos innecesarios en la operación.

AllDefense puede apoyar el diseño y facilitación desde su servicio de Asesoría Estratégica, conectando el escenario con riesgos y procesos reales. Si el ejercicio revela desconocimiento transversal, la concientización en seguridad puede abordar las brechas que corresponden a hábitos y responsabilidades. El objetivo final es sencillo: que la primera vez que la organización discuta una decisión difícil no sea durante el incidente real.

Fuentes consultadas

CISA: Tabletop Exercise Packages; NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations; NIST SP 800-84: Guide to Test, Training, and Exercise Programs.

Equipo revisa las funciones del responsable y encargado del tratamiento

Responsable y encargado del tratamiento: quién decide

Publicado el

Contratar una plataforma, externalizar remuneraciones o almacenar información en la nube no transfiere automáticamente las decisiones sobre los datos personales. La diferencia entre responsable y encargado del tratamiento define quién determina para qué se usan los datos, quién actúa siguiendo instrucciones y qué debe quedar regulado con el proveedor. Confundir estos papeles deja vacíos contractuales precisamente donde la empresa necesita demostrar control.

Responsable y encargado del tratamiento: la decisión separa los roles

El responsable determina los fines y los medios esenciales del tratamiento. Decide, por ejemplo, por qué se recopilan ciertos datos, qué resultado se busca, durante cuánto tiempo son necesarios y con quién pueden comunicarse. El encargado procesa información por cuenta del responsable y dentro del encargo recibido. Puede aportar capacidad técnica y proponer cómo prestar el servicio, pero no debería reutilizar los datos para una finalidad propia incompatible con las instrucciones.

La diferencia no depende solo del nombre escrito en el contrato. Importa observar quién toma las decisiones reales. Si un proveedor define por su cuenta una nueva finalidad o utiliza la información fuera del encargo, su posición puede dejar de corresponder a la de un simple encargado. La Ley 21.719 contempla que, bajo determinadas conductas ajenas a lo convenido, el tercero sea considerado responsable para los efectos legales correspondientes.

No todo proveedor ocupa un único papel

Una misma empresa puede actuar como encargada en una operación y como responsable en otra. Un proveedor tecnológico podría alojar una base de clientes siguiendo instrucciones y, a la vez, tratar los datos de contacto de sus propios usuarios para administrar la relación comercial. Son tratamientos distintos, con propósitos y responsabilidades que no conviene mezclar.

Equipo proveedor revisa instrucciones para el tratamiento de datos personales

Tampoco basta con asumir que toda externalización convierte al proveedor en encargado. Si ambas partes deciden conjuntamente elementos determinantes del tratamiento, o si cada una persigue fines propios, el análisis cambia. La guía del Comité Europeo de Protección de Datos resulta útil como referencia comparada porque trata estas funciones como conceptos operativos: la actividad efectiva pesa más que la etiqueta elegida por las partes.

El contrato debe describir el tratamiento real

El régimen incorporado por la Ley 21.719 a la Ley 19.628 establece que el tratamiento mediante un tercero mandatario o encargado se regirá por contrato. El texto debe considerar el objeto y duración del encargo, su finalidad, los tipos de datos tratados, las categorías de titulares y los derechos y obligaciones de las partes. Estos elementos no son una cláusula decorativa: delimitan qué puede hacer el proveedor con la información.

Una descripción genérica, como “prestar servicios informáticos”, entrega poca claridad frente a una solicitud de derechos, un cambio de alcance o un incidente. El contrato debería corresponder al flujo verdadero: qué información recibe el proveedor, desde dónde, para qué operación, por cuánto tiempo y qué ocurre al finalizar. El mapa de datos personales ayuda a reunir esa base antes de negociar condiciones.

Subcontratar no debe borrar la trazabilidad

Los servicios digitales suelen apoyarse en otras compañías para alojamiento, soporte, mensajería o analítica. Esa cadena puede ser legítima, pero la organización necesita conocerla. La Ley 21.719 dispone que el encargado no podrá delegar total o parcialmente el encargo sin autorización específica y escrita del responsable, y mantiene su responsabilidad sobre lo delegado en los términos establecidos por la norma.

En la práctica, la autorización pierde valor si no se identifica al subencargado, la función que cumplirá y el lugar desde el cual tratará la información. También es importante que los compromisos relevantes sigan la cadena contractual. De otro modo, el responsable podría exigir controles a su proveedor directo que no alcanzan a la infraestructura donde finalmente residen o se procesan los datos.

Los derechos y la seguridad necesitan acuerdos operativos

Ante una solicitud de acceso, rectificación o supresión, el responsable debe saber qué información conserva el encargado y en qué plazo puede obtenerla o modificarla. Algo similar ocurre con la seguridad: se requiere acordar cómo se comunicarán incidentes, quién preservará evidencias, qué medidas se aplicarán y cómo se verificará el cierre del servicio. La obligación contractual debe poder ejecutarse, no quedar reducida a una declaración amplia de cumplimiento.

La profundidad del control dependerá del riesgo. Un servicio que trata datos sensibles o sostiene una operación crítica requiere mayor evidencia que un proveedor con acceso limitado a datos de contacto. Esta evaluación permite ajustar exigencias, revisiones y niveles de supervisión sin imponer el mismo tratamiento contractual a todas las relaciones.

Definir el rol antes de firmar evita correcciones tardías

La pregunta inicial no debería ser qué plantilla contractual utilizar, sino quién decide realmente el propósito y los elementos esenciales de cada tratamiento. Después corresponde identificar instrucciones, dependencias, subcontrataciones, medidas de seguridad y condiciones de término. Si el servicio ya existe, la misma revisión permite comparar el contrato con la operación y detectar diferencias.

AllDefense puede apoyar este análisis mediante sus servicios de Protección de Datos Personales y Revisión de Cumplimiento. El resultado esperado es una relación verificable: cada tratamiento con un propósito definido, instrucciones coherentes y responsabilidades que puedan demostrarse cuando el titular, la organización o la autoridad necesiten respuestas.

Fuentes consultadas

Biblioteca del Congreso Nacional: Ley 21.719; Biblioteca del Congreso Nacional: Ley 19.628, texto actualizado; Comité Europeo de Protección de Datos: Directrices 07/2020.

Equipo revisando la superficie de ataque externa de una empresa

Superficie de ataque externa: qué expone su empresa

Publicado el

La presencia digital de una empresa rara vez termina en su sitio web oficial. Subdominios antiguos, portales de proveedores, accesos remotos, servicios en la nube y ambientes de prueba también pueden quedar visibles desde Internet. La superficie de ataque externa reúne esos puntos observables y muestra una realidad incómoda: un activo puede estar expuesto aunque el área de seguridad no sepa que existe o no tenga claro quién lo administra.

Qué integra la superficie de ataque externa

El concepto abarca los recursos tecnológicos a los que un tercero puede llegar desde Internet. Incluye aplicaciones web, direcciones IP públicas, concentradores VPN, interfaces de administración, servicios de correo, almacenamiento en la nube y dominios relacionados con la organización. También comprende la información técnica que permite vincular esos recursos, como certificados, registros DNS y tecnologías detectables de forma pública.

No todo activo visible representa una vulnerabilidad. Un portal publicado puede ser necesario y estar correctamente protegido. El riesgo aparece cuando la exposición es innecesaria, utiliza tecnología sin soporte, conserva una configuración débil o carece de un responsable capaz de decidir qué hacer con ella. Por eso, contar direcciones y puertos no basta: cada hallazgo necesita contexto empresarial.

El inventario interno no siempre refleja lo que ve Internet

Los inventarios suelen construirse desde compras, herramientas de gestión o registros de infraestructura. Esa información es valiosa, pero puede dejar fuera activos creados por un proyecto, una filial o un proveedor. Una migración también puede terminar sin retirar el servicio anterior. Meses después, el nuevo sistema está documentado y el antiguo continúa respondiendo en una dirección pública.

Técnico verifica un dispositivo de red expuesto en una sucursal

Las sucursales y servicios contratados agregan otra dificultad. Un equipo de acceso remoto instalado para resolver una contingencia puede permanecer conectado; una aplicación administrada por un tercero puede cambiar de dirección sin actualizar el inventario corporativo. La revisión externa sirve para contrastar lo registrado con lo que realmente puede descubrir cualquier persona fuera de la organización.

Visibilidad antes de evaluar vulnerabilidades

Un análisis de vulnerabilidades solo puede evaluar el alcance que recibe. Si una empresa entrega una lista incompleta de activos, los equipos desconocidos quedarán fuera aunque sean los más expuestos. La gestión de superficie de ataque invierte esa lógica: primero descubre y atribuye, luego valida qué pertenece a la organización y recién entonces incorpora los activos confirmados al proceso de evaluación.

Esto no reemplaza una auditoría ni un escaneo técnico. Responde una pregunta anterior: ¿qué existe afuera y quién debe hacerse cargo? El artículo sobre auditoría de seguridad y análisis de vulnerabilidades explica las diferencias entre esos enfoques. La visibilidad externa ayuda a que ambos trabajen sobre un perímetro más completo y verificable.

Priorizar por consecuencia, no por cantidad

Una fotografía de la exposición puede producir muchos datos, pero no todos merecen la misma urgencia. Conviene distinguir un sistema crítico de una página informativa, confirmar si procesa información sensible, revisar la fortaleza del acceso y determinar si la tecnología mantiene soporte. Una vulnerabilidad incluida en el catálogo de vulnerabilidades explotadas de CISA adquiere un peso diferente cuando está presente en un servicio alcanzable desde Internet.

La atribución también evita decisiones apresuradas. Un dominio con el nombre de la empresa podría pertenecer a una campaña fraudulenta y no a su infraestructura; un servicio desconocido podría ser legítimo y estar bajo contrato. Antes de bloquear, retirar o escalar un hallazgo, hay que reunir evidencia suficiente sobre propiedad, propósito y dependencia operativa.

Señales de una exposición difícil de gobernar

La falta de un propietario claro es una señal relevante. También lo son los certificados próximos a vencer en servicios que nadie reconoce, los subdominios que apuntan a plataformas abandonadas, las interfaces administrativas públicas y los activos que aparecen fuera del ciclo habitual de parches. Cuando distintas áreas contratan tecnología sin un mecanismo común de alta y baja, la superficie tiende a crecer con más rapidez que el inventario.

Descubrir un activo no resuelve el riesgo. Debe existir una ruta para validarlo, asignarle responsable, evaluar su necesidad y registrar la decisión. Si sigue expuesto, tendrá que incorporarse a monitoreo, gestión de vulnerabilidades y controles de acceso. Si ya no cumple una función, su retiro debe considerar dependencias y realizarse de forma controlada.

La superficie de ataque externa cambia con la empresa

Una revisión puntual entrega una línea base, pero comienza a envejecer cuando se publica una aplicación, cambia un proveedor o se abre una nueva sede. NIST CSF 2.0 y CIS Control 1 sitúan la identificación y gestión de activos como fundamentos del manejo del riesgo. En la práctica, esto exige combinar descubrimiento periódico con procesos internos que informen altas, cambios y retiros.

AllDefense puede apoyar esta revisión mediante su servicio de Evaluación de Amenazas, conectando la observación externa con el contexto del negocio. Cuando aparecen brechas de arquitectura, la segmentación de red empresarial puede limitar el alcance de un acceso inicial. El resultado útil no es un listado más extenso, sino una vista verificable que permita decidir qué corregir primero y qué exposición dejar de aceptar.

Para contrastar la exposición identificada con políticas, controles y evidencias de su empresa, revise el alcance del servicio de auditoría de seguridad de AllDefense.

Fuentes consultadas

CISA: Internet Exposure Reduction Guidance; NIST Cybersecurity Framework 2.0; CIS Control 1: Inventory and Control of Enterprise Assets; CISA: Known Exploited Vulnerabilities Catalog.

Equipo revisando la segmentación de red empresarial y sus zonas de seguridad

Segmentación de red empresarial: cómo limitar un incidente

Publicado el

Cuando impresoras, cámaras, notebooks, servidores y sistemas de gestión comparten una red con pocas restricciones, un problema localizado puede transformarse en una interrupción amplia. La segmentación de red empresarial reduce ese riesgo: separa entornos con funciones y niveles de confianza distintos, y controla qué comunicaciones pueden cruzar entre ellos. No evita por sí sola un incidente, pero limita sus caminos y facilita detectar comportamientos fuera de lo esperado.

Por qué una red plana amplifica el impacto

Muchas redes crecen de forma acumulativa. Se agrega una sucursal, una red inalámbrica, cámaras IP, telefonía, acceso remoto o una plataforma nueva, pero la arquitectura original se mantiene. El resultado suele ser una conectividad cómoda para operar y también para desplazarse: si un equipo queda comprometido, puede alcanzar servicios que nunca necesitó usar.

La consecuencia no se limita a los ciberataques. Una configuración incorrecta, un dispositivo defectuoso o una tormenta de tráfico también puede afectar áreas que deberían permanecer independientes. Segmentar ayuda a contener fallas, acotar diagnósticos y conservar funciones esenciales mientras se resuelve el problema.

La segmentación de red empresarial no es solo crear VLAN

Una VLAN puede separar tráfico, pero el valor de seguridad aparece cuando esa división responde a una decisión de negocio y existen controles entre las zonas. Si todas pueden comunicarse libremente, la separación será principalmente administrativa. El diseño debe considerar qué activos hay, quién los utiliza, qué dependencias son legítimas y qué ocurriría si una zona quedara indisponible o fuera comprometida.

Técnico revisa equipos de red separados por funciones en una empresa

Por eso no existe una plantilla universal. Una empresa puede necesitar separar usuarios, servidores, invitados, telefonía y cámaras; otra deberá distinguir además ambientes productivos, laboratorios, sucursales o infraestructura operacional. La arquitectura útil es la que refleja cómo funciona la organización y protege lo que realmente sostiene su operación.

Separar por función, confianza y consecuencia

Un criterio razonable combina tres preguntas. Primero, ¿qué función cumple el activo? Segundo, ¿cuánto control existe sobre él? Un notebook administrado no ofrece el mismo nivel de confianza que un dispositivo personal o el equipo de un proveedor. Tercero, ¿cuál sería la consecuencia de un acceso indebido? Un sistema crítico o un servidor de respaldo merece límites más estrictos que una red de visitas.

Esta mirada evita dos extremos: mantener todo conectado por comodidad o crear tantas zonas que la operación se vuelva inmanejable. La segmentación debe ser suficientemente clara para reducir exposición, pero también comprensible para quienes administran la red. Un diagrama actualizado y responsables definidos son tan importantes como la configuración de los equipos.

El control entre zonas vuelve útil la separación

Cada comunicación permitida debería tener una razón. Las reglas pueden considerar origen, destino, servicio, identidad del usuario o condición del dispositivo, según la madurez y tecnología disponible. El principio práctico es habilitar solo lo necesario y registrar los intentos relevantes, especialmente alrededor de sistemas sensibles y accesos de administración.

Esto coincide con el enfoque de confianza cero de NIST: la ubicación dentro de la red no debería otorgar confianza implícita. También complementa la recomendación de CIS de diseñar una arquitectura que contemple segmentación, mínimo privilegio y disponibilidad. Segmentar, entonces, no reemplaza la gestión de identidades, la protección de endpoints ni el monitoreo; les entrega un contexto más controlable.

Señales de que conviene revisar la arquitectura

No es necesario esperar un incidente. Hay señales cotidianas que justifican una revisión: crecimiento rápido, equipos conectados sin inventario, Wi-Fi de invitados que alcanza recursos internos, cámaras y controles de acceso en la misma red de usuarios, proveedores con accesos amplios o reglas antiguas cuyo propósito ya nadie conoce. También es relevante cuando una empresa adopta servicios en la nube o integra una nueva sucursal.

La guía de CISA sobre ransomware señala que la segmentación puede contener el impacto de una intrusión y limitar el movimiento lateral. Esa capacidad depende de que las barreras estén realmente aplicadas y probadas. Una zona crítica que conserva excepciones excesivas puede parecer aislada en el diagrama y no estarlo en la práctica.

Reducir la propagación sin paralizar la operación

La transición funciona mejor por etapas. Antes de cambiar reglas conviene observar flujos, documentar dependencias y priorizar los activos cuya indisponibilidad tendría mayor efecto. Luego se puede probar una separación acotada, medir interrupciones y ajustar. Este enfoque disminuye el riesgo de bloquear procesos legítimos y permite demostrar valor con resultados concretos.

AllDefense puede apoyar el diagnóstico y diseño desde su división de Redes y Sistemas, integrando conectividad, infraestructura y controles de seguridad. Cuando el punto de partida no está claro, una auditoría de seguridad permite identificar rutas innecesarias, dependencias críticas y prioridades antes de intervenir la operación. El objetivo no es acumular complejidad, sino reducir el alcance posible de una falla o intrusión.

Fuentes consultadas

CISA: StopRansomware Guide; NIST SP 800-207: Zero Trust Architecture; CIS Control 12: Network Infrastructure Management.

Equipo revisando una política de seguridad de la información y sus evidencias de aplicación

Política de seguridad de la información: del papel a la evidencia

Publicado el

Aprobar una política de seguridad de la información es sencillo comparado con aplicarla. El documento puede definir principios correctos, recibir la firma de gerencia y permanecer disponible para una auditoría. El problema aparece cuando la operación no puede demostrar que las decisiones, responsabilidades y controles descritos allí realmente funcionan.

Una política útil no intenta explicar cada configuración técnica. Establece la dirección que la empresa espera seguir, los límites de riesgo que está dispuesta a aceptar y quién debe decidir cuando aparece una excepción. Su valor se comprueba después, en procedimientos, registros y conductas observables. Sin esa conexión, la política se convierte en una declaración institucional que convive con prácticas distintas.

Qué debe lograr una política de seguridad de la información

NIST incorporó la función Govern en la versión 2.0 de su Cybersecurity Framework para situar la estrategia, las expectativas, las políticas, los roles y la supervisión antes de las funciones técnicas de identificar, proteger, detectar, responder y recuperar. El orden conceptual importa: los equipos necesitan criterios para priorizar, asignar recursos y resolver responsabilidades antes de desplegar controles.

ISO/IEC 27001 sigue una lógica similar al tratar la seguridad como un sistema que debe establecerse, implementarse, mantenerse y mejorarse. Esto no significa que toda empresa deba certificarse ni declarar que opera un sistema formal. Sí muestra que la política pierde sentido cuando se separa de los riesgos, los procesos y la estructura real de la organización.

La brecha está entre lo declarado y lo que ocurre

Una política puede exigir accesos según funciones, pero los permisos antiguos continúan activos después de un cambio de cargo. Puede ordenar respaldos periódicos, mientras nadie conserva evidencia de restauraciones. También puede asignar la comunicación de incidentes a un cargo que cambió de nombre o dejó de existir. Ninguna de esas brechas se descubre leyendo el documento de manera aislada.

La distancia aumenta cuando cada área interpreta la política por su cuenta. TI la traduce en configuraciones, Personas en obligaciones para colaboradores, Compras en condiciones para proveedores y Operaciones en restricciones que deben convivir con la continuidad del trabajo. Si no existe un responsable que conecte esas decisiones, surgen controles duplicados, vacíos de ejecución y excepciones informales.

Administrador verifica evidencias técnicas de controles de seguridad en sistemas y red
La aplicación de una política se demuestra en registros, revisiones y resultados verificables de la operación.

La evidencia convierte principios en controles

La evidencia no debería producirse únicamente cuando llega una auditoría. Debe aparecer como consecuencia normal del proceso: aprobaciones de acceso, registros de cambios, revisiones de privilegios, pruebas de restauración, tratamiento de excepciones, resultados de capacitación o seguimiento de hallazgos. Su forma depende del riesgo y del tamaño de la empresa; acumular documentos sin propósito tampoco demuestra efectividad.

Lo importante es que exista una relación verificable entre la regla, la actividad y el resultado. Si la política establece que los accesos deben revisarse, la empresa debería poder mostrar quién realizó la revisión, con qué alcance, qué desviaciones encontró y cómo fueron resueltas. Esa trazabilidad permite distinguir un control operativo de una práctica que solo se presume.

Una política vigente necesita dueño y capacidad de ajuste

La aprobación de gerencia entrega autoridad, pero la gestión cotidiana requiere un responsable que coordine revisiones, reciba excepciones y promueva correcciones. El propietario de la política no ejecuta todos los controles; mantiene la coherencia entre áreas y evita que los cambios tecnológicos, organizacionales o regulatorios vuelvan obsoleto el documento.

Las excepciones también deben formar parte del modelo. Una empresa puede necesitar conservar una aplicación heredada, mantener un acceso temporal o postergar una medida por continuidad operacional. Ignorar esa realidad no reduce el riesgo. Resulta más útil registrar la decisión, establecer controles compensatorios, asignar una fecha de revisión y dejar claro quién aceptó la exposición residual.

Cómo evaluar si la política realmente funciona

Una revisión efectiva combina documento y operación. Contrasta los compromisos escritos con muestras de evidencia, entrevistas a quienes ejecutan los procesos y observación de controles relevantes. No se limita a preguntar si existe una política; busca determinar si las responsabilidades se entienden, las excepciones se gestionan y los resultados llegan a quienes deben tomar decisiones.

Para las instituciones sujetas a la Ley 21.663, la gestión continua de la seguridad adquiere además una dimensión regulatoria expresa. En otras organizaciones, la exigencia puede provenir de contratos, clientes, estándares, protección de datos o gobierno corporativo. En ambos casos, la diferencia entre cumplimiento formal y capacidad real está en la evidencia disponible.

Del documento a una capacidad de gestión

La política cumple su función cuando orienta decisiones y permite comprobar cómo la empresa gestiona sus riesgos. Si solo aparece durante una licitación o auditoría, todavía no está integrada a la operación. Una auditoría de seguridad puede identificar esa distancia, mientras una asesoría estratégica ayuda a ordenar responsabilidades, criterios y prioridades. AllDefense también desarrolla revisiones de cumplimiento para relacionar obligaciones con evidencias y medidas aplicables.

Fuentes