La baja de un usuario no termina cuando Recursos Humanos registra la salida. Una misma persona puede conservar correo, VPN, aplicaciones SaaS, repositorios, accesos a clientes, tokens, credenciales locales y cuentas administradas por proveedores distintos. Si la empresa revoca solo el directorio principal, deja abiertas rutas que ya no tienen una necesidad laboral.

El objetivo tampoco es desconfiar de quien se retira. Es ejecutar una decisión de negocio de forma completa, oportuna y demostrable. El proceso debe conectar la salida o cambio de función con cada identidad, privilegio, equipo y secreto que la persona utilizaba. Así se protege a la empresa y se evita que una cuenta huérfana termine en manos de terceros.

La baja de usuarios comienza antes del último día

Recursos Humanos conoce la fecha y condición de la salida; la jefatura sabe qué funciones deben transferirse; TI administra parte de las cuentas; y los dueños de aplicaciones autorizan accesos específicos. Si la notificación aparece solo como un ticket genérico al final de la jornada, cada área interpreta el alcance y los tiempos por separado.

Conviene definir un evento formal que active el flujo, con fecha efectiva, responsable y tratamiento según riesgo. Una salida planificada permite inventariar accesos y transferir información. Una desvinculación inmediata puede exigir revocar sesiones y credenciales en un momento acordado, antes de recuperar el equipo. La urgencia no elimina la coordinación: hace más importante que el orden esté decidido de antemano.

Qué accesos deben entrar en el alcance

La cuenta corporativa es solo el punto de partida. El inventario debe considerar identidades en aplicaciones de negocio, nubes, VPN, repositorios, plataformas de proveedores, herramientas de colaboración, accesos físicos y cuentas locales. También debe incluir llaves de API, certificados, tokens y secretos compartidos que podrían seguir funcionando aunque la cuenta personal quede deshabilitada.

Por eso, la baja depende de un inventario de activos tecnológicos y de dueños de aplicación identificados. Si nadie puede relacionar a una persona con los sistemas que usa, el equipo de TI buscará a ciegas. Centralizar identidades mediante un directorio o inicio de sesión único reduce dispersión, pero no reemplaza el control de aplicaciones que quedan fuera de esa integración.

Deshabilitar primero, eliminar después

CIS Control 6.2 propone revocar el acceso mediante la deshabilitación inmediata de cuentas ante una terminación, pérdida de derechos o cambio de rol. Deshabilitar conserva trazabilidad y permite revisar acciones anteriores; eliminar de inmediato puede destruir relaciones necesarias para una auditoría o para recuperar información de negocio. La retención posterior debe responder a reglas definidas, no transformarse en una excusa para mantener la cuenta activa.

La revocación debe abarcar sesiones vigentes, factores de autenticación, contraseñas de aplicación, certificados y tokens. Cuando existan secretos compartidos, la salida exige rotarlos y comprobar qué integraciones dependen de ellos. Para cuentas con mayor impacto, la empresa puede incorporar una revisión específica de accesos privilegiados, credenciales de emergencia y cuentas técnicas conocidas por la persona.

Los cambios de rol crean el mismo riesgo

Mover a alguien de área suele parecer menos riesgoso que una salida, pero puede acumular permisos incompatibles. La persona recibe nuevos accesos y conserva los anteriores porque nadie define qué debe retirarse. NIST SP 800-53, en AC-2 Account Management, pide alinear la administración de cuentas con procesos de terminación y transferencia. El control se completa cuando el nuevo rol tiene solo lo necesario y los permisos anteriores dejan de estar activos.

Las revisiones periódicas ayudan a encontrar acumulaciones, aunque no sustituyen una baja a tiempo. NIST CSF 2.0 ubica la gestión de identidades y credenciales en PR.AA-01. CISA también recomienda conectar los sistemas de gobierno de identidades con los procesos de personal para automatizar la deshabilitación y mantener un registro de cuentas y privilegios asociados a cada individuo.

Qué evidencia demuestra que la revocación funcionó

Un ticket cerrado no prueba que todos los accesos hayan desaparecido. La evidencia puede incluir la identidad de la persona, fecha efectiva, sistemas revisados, hora de deshabilitación, sesiones revocadas, activos recuperados, secretos rotados, excepciones y validación del dueño. Una muestra de bajas recientes permite comparar la lista esperada con el estado real de las cuentas.

La medición debe centrarse en brechas útiles: cuentas aún activas después de la salida, aplicaciones sin responsable, revocaciones fuera de plazo y excepciones sin vencimiento. Una Auditoría de Seguridad de AllDefense puede revisar el flujo completo, desde el evento de personal hasta la evidencia técnica, para identificar dónde se pierde el alcance sin inventar una cobertura que la organización no posee.

Una baja confiable no depende de recordar todas las cuentas el último día. Depende de un proceso compartido entre personas, jefaturas, TI y dueños de sistemas, con inventario, tiempos y comprobación. Ese diseño también mejora altas y cambios de rol: cada acceso nace con un responsable y puede retirarse cuando deja de existir su justificación.

Fuentes consultadas

• NIST SP 800-53 Rev. 5: AC-2 Account Management.
• NIST Cybersecurity Framework 2.0: PR.AA.
• CIS Control 6.2: Establish an Access Revoking Process.
• CISA: Identity and Access Management Recommended Best Practices.

Rodrigo Zamora

Un inventario de activos tecnológicos puede existir y seguir siendo inútil para seguridad. La planilla registra equipos comprados, pero deja fuera máquinas virtuales, servicios en la nube, aplicaciones contratadas por un área o componentes que permanecen conectados después de un proyecto. Ante una vulnerabilidad o un incidente, la empresa conoce el nombre del activo, pero no su función, responsable ni importancia para la operación.

El propósito no es contar equipos. Un inventario confiable debe permitir responder qué existe, quién lo administra, para qué proceso se utiliza, qué dependencias mantiene y cuál es su estado durante el ciclo de vida. Esa información convierte un listado administrativo en una base para decidir sobre exposición, acceso, soporte, continuidad y riesgo.

Qué debe incluir un inventario de activos tecnológicos

NIST CSF 2.0 ubica la gestión de activos en la función Identificar. Sus resultados ID.AM-01 e ID.AM-02 consideran inventarios de hardware, software, servicios y sistemas; también incorporan proveedores, datos, flujos y prioridad según criticidad e impacto. Esto evita reducir el alcance a dispositivos físicos. Una aplicación SaaS, una API, un contenedor o un servicio administrado puede ser tan relevante como el servidor que la empresa ve en una sala técnica.

Para cada activo conviene registrar un identificador estable, tipo, ubicación, propietario de negocio, responsable técnico, servicio que soporta, autorización y etapa del ciclo de vida. En software importan la versión, el fabricante, el propósito y la condición de soporte. El control CM-8 de NIST SP 800-53 pide que el inventario refleje el sistema con el detalle necesario y evite contabilizaciones duplicadas.

Un activo sin responsable sigue fuera de control

Detectar un equipo o una aplicación no resuelve quién puede aceptar una interrupción, autorizar un cambio o decidir su retiro. El responsable técnico conoce la plataforma; el dueño de negocio entiende el proceso y las consecuencias. Ambos roles son necesarios. Si el inventario conserva solo una dirección IP o un nombre de host, seguridad terminará asignando prioridades sin comprender el impacto real.

La propiedad debe sobrevivir a los cambios organizacionales. Un proyecto puede cerrar o un área reorganizarse mientras el servicio continúa activo. Los registros sin dueño vigente se convierten en excepciones permanentes: nadie confirma si aún son necesarios ni incorpora su renovación, respaldo o retiro al presupuesto.

Por qué el inventario falla aunque la empresa use herramientas

Las fuentes observan realidades distintas. Compras sabe qué se adquirió; una herramienta de endpoints ve los equipos donde instaló su agente; la nube conoce recursos de una cuenta; redes detecta conexiones; finanzas identifica suscripciones. Ninguna vista aislada demuestra que el inventario esté completo. Tampoco basta unir exportaciones, porque pueden registrar el mismo activo con nombres diferentes o conservar elementos que ya fueron retirados.

El contraste con la superficie de ataque externa de la empresa permite descubrir dominios, servicios e interfaces ausentes del registro interno. La diferencia entre lo declarado y lo observado no se corrige solo agregando una fila: exige validar pertenencia, propósito, autorización y responsable.

Qué decisiones debe sostener el inventario

Un registro útil permite saber qué activos entran en un análisis, cuáles requieren actualización y dónde una falla afectaría un servicio relevante. También ayuda a verificar cobertura de monitoreo, respaldo, protección de endpoints y gestión de identidades. Cuando una tecnología queda sin soporte, la decisión de renovar, aislar o retirar necesita conocer sus dependencias y propietario, no solo la fecha anunciada por el fabricante.

La misma base mejora la priorización de vulnerabilidades. Un hallazgo crítico sobre un componente inexistente es ruido; uno moderado en un activo público y esencial puede requerir atención inmediata. Si el alcance nace de una lista incompleta, la evaluación también será incompleta.

Cómo comprobar si el inventario es confiable

La revisión debe buscar evidencia, no perfección declarada. Conviene comparar una muestra de activos observados con el registro autorizado, identificar elementos sin dueño, revisar duplicados y comprobar que altas, cambios y bajas dejan trazabilidad. También importa conocer la fecha de la última validación y qué entornos quedan fuera de las herramientas habituales, como dispositivos IoT, sedes remotas, cuentas cloud o servicios operados por terceros.

CIS Control 1 propone administrar los activos empresariales conectados de forma física, virtual, remota o en la nube, y abordar los no autorizados. CIS Control 2 extiende el criterio al software. La automatización ayuda a detectar cambios, pero el contexto empresarial sigue necesitando responsables, criterios de autorización y procesos que mantengan la información vigente.

Dar alcance real a una evaluación

Si la preocupación principal es conocer debilidades técnicas sobre activos confirmados, el servicio de Análisis de Vulnerabilidades de AllDefense permite evaluar un alcance acordado y ordenar los hallazgos relevantes. Si la brecha está en la propiedad, el ciclo de vida o la evidencia del proceso, una Auditoría de Seguridad puede revisar por qué el inventario no refleja la operación.

Antes de sumar otra plataforma, conviene comprobar si la empresa puede explicar qué protege y por qué. El resultado valioso no es una cifra total de activos, sino una base verificable que permita incluir lo desconocido, retirar lo innecesario y asignar decisiones a quienes realmente pueden tomarlas.

Fuentes consultadas

• NIST Cybersecurity Framework 2.0.
• NIST SP 800-53 Rev. 5: Security and Privacy Controls.
• CIS Control 1: Inventory and Control of Enterprise Assets.
• CIS Control 2: Inventory and Control of Software Assets.

Rodrigo Zamora

La seguridad por diseño en proyectos tecnológicos consiste en tomar decisiones de protección antes de que una solución quede contratada, desarrollada o integrada. No es una revisión final para “aprobar seguridad”, sino una forma de definir desde el inicio qué datos utilizará el proyecto, qué dependencias creará, quién podrá administrarlo y qué evidencia permitirá aceptarlo.

Para una empresa chilena, este enfoque reduce una dificultad frecuente: descubrir controles ausentes cuando el presupuesto ya está comprometido, la fecha de salida es inamovible y corregir exige rediseñar. La conversación útil comienza cuando todavía existen alternativas.

La seguridad empieza con el propósito del proyecto

Antes de escoger controles, el equipo necesita entender el resultado de negocio. Conviene identificar qué proceso cambiará, qué información ingresará o generará la solución, con cuáles sistemas se conectará y qué impacto tendría una indisponibilidad, alteración o divulgación. La clasificación de la información ayuda a que estas respuestas modifiquen decisiones concretas sobre acceso, almacenamiento, intercambio y conservación.

NIST Cybersecurity Framework 2.0 sitúa el gobierno y la comprensión del riesgo antes de las actividades de protección. Aplicado a un proyecto, esto implica asignar responsables y criterios de aceptación, no delegar toda la seguridad al área técnica. El dueño del proceso aporta el impacto; Tecnología explica arquitectura y operación; Seguridad plantea escenarios y verificaciones; Compras y Legal convierten requisitos en compromisos cuando participa un proveedor.

Definir resultados, no una lista genérica

Un requisito como “cumplir buenas prácticas” es difícil de comprobar. Resulta más útil describir resultados observables: las cuentas administrativas están separadas de las cuentas de uso diario; los accesos se revocan al terminar una función; los registros permiten reconstruir acciones críticas; la información sensible viaja y se almacena protegida; una restauración puede ejecutarse dentro de los objetivos definidos.

Cada resultado debe tener un responsable, una evidencia y un momento de validación. Algunas verificaciones ocurren en el diseño, otras durante pruebas y otras al preparar la operación. Así, seguridad deja de ser una opinión tardía y se convierte en una condición trazable del proyecto.

Incorporar seguridad al trabajo del proyecto

NIST SP 800-218 propone integrar prácticas de desarrollo seguro al ciclo de vida, en lugar de tratarlas como una fase aislada. Aunque su foco es software, la lógica también ayuda a ordenar proyectos que configuran o adquieren tecnología: preparar a las personas y procesos, proteger los componentes, producir una solución con prácticas definidas y responder a vulnerabilidades.

Esto no exige transformar cada iniciativa en un programa documental. Un proyecto pequeño puede mantener un registro breve de decisiones, responsables y pruebas. Uno crítico puede requerir modelado de amenazas, revisión de arquitectura, análisis de componentes, pruebas especializadas y un plan formal de remediación. La profundidad cambia según exposición e impacto; el principio es que las decisiones no desaparezcan entre correos y reuniones.

Comprar tecnología también requiere diseño

Cuando la solución es de un tercero, la empresa no diseña el producto, pero sí diseña su forma de selección, configuración, integración y uso. La guía de CISA para elegir tecnologías seguras y verificables recomienda que las organizaciones compradoras evalúen características de seguridad y la posibilidad de verificar su funcionamiento.

Importa conocer opciones de autenticación, registros disponibles, gestión de vulnerabilidades, actualizaciones, exportación de datos, subcontratistas y condiciones de salida. El artículo sobre evaluación del riesgo de proveedores tecnológicos desarrolla la supervisión durante la relación; en el proyecto, la tarea específica es convertir esas necesidades en criterios de selección y aceptación antes de depender de la solución.

Crear puertas de decisión verificables

Un proyecto debería detenerse en puntos breves y conocidos: aprobación del diseño, autorización para conectar datos reales, aceptación técnica y paso a producción. En cada puerta se revisan solo las evidencias necesarias para esa decisión. Los hallazgos deben quedar resueltos, compensados o aceptados por quien tenga autoridad, con plazo y responsable.

También se necesita un criterio para cambios. Una nueva integración, el uso de datos más sensibles o la exposición a internet puede invalidar la evaluación original. La trazabilidad permite reconocer cuándo volver a revisar, sin repetir todo el proceso ante ajustes menores.

Preparar la operación antes del lanzamiento

La salida a producción no termina el proyecto de seguridad. Deben quedar definidos el dueño del servicio, las rutas de escalamiento, el tratamiento de vulnerabilidades, las revisiones de acceso, los respaldos, los registros y las condiciones para retirar la solución. Un control que depende de una persona del equipo de implementación puede desaparecer cuando esa persona vuelve a sus funciones habituales.

La asesoría estratégica de ciberseguridad puede ayudar a integrar estos criterios con prioridades, gobierno y riesgo empresarial. Una auditoría de seguridad puede contrastar posteriormente si los requisitos, configuraciones y evidencias acordados siguen operando. El objetivo es simple: que una decisión temprana evite una corrección costosa y deje controles que puedan sostenerse después del proyecto.

Fuentes consultadas

• NIST Cybersecurity Framework 2.0.
• NIST SP 800-218: Secure Software Development Framework 1.1.
• CISA: Choosing Secure and Verifiable Technologies.

Rodrigo Zamora

El riesgo de proveedores tecnológicos no desaparece al firmar un contrato o recibir un cuestionario de seguridad. Una empresa puede conservar la responsabilidad sobre sus procesos mientras pierde visibilidad sobre quién administra la plataforma, qué subcontratistas intervienen, dónde quedan sus datos o cuánto tardaría en recuperar el servicio. La evaluación sirve cuando esas respuestas cambian una decisión, no cuando solo completan un expediente.

Para gerencia, Compras, Tecnología y Seguridad, el desafío es proporcionalidad. No conviene exigir la misma evidencia a una herramienta auxiliar que a la plataforma que procesa ventas, identidades o información sensible.

El riesgo de proveedores tecnológicos nace de la dependencia

Antes de evaluar controles, la organización necesita entender la relación. Importa saber qué proceso sostiene el proveedor, qué información recibe, qué accesos mantiene, con cuáles sistemas se integra y qué ocurriría si deja de operar.

El artículo sobre gobierno de aplicaciones SaaS y Shadow IT aborda servicios adquiridos fuera del proceso formal. La gestión de proveedores tiene un alcance diferente: acompaña relaciones conocidas y aprobadas desde su selección hasta su término, incluso cuando el contrato y el área responsable están plenamente identificados.

Clasificar antes de enviar cuestionarios

La clasificación debería combinar sensibilidad y volumen de datos, privilegios, impacto de una interrupción, capacidad de reemplazo, concentración y dependencia de otros proveedores. CIS Control 15 propone inventariar y clasificar prestadores considerando, entre otros elementos, disponibilidad, regulación, riesgo inherente y riesgo mitigado.

La clasificación de la información aporta una parte de esta decisión, pero no la resuelve completa. Dos proveedores que tratan datos equivalentes pueden requerir niveles distintos de supervisión si uno opera una función reemplazable y el otro concentra una dependencia sin alternativa. La categoría asignada debe definir profundidad de la evaluación, responsables, frecuencia y condiciones que obligan a revisar nuevamente.

Pedir evidencia que corresponda al riesgo

Un cuestionario respondido por el propio proveedor permite conocer su postura declarada, pero no demuestra por sí solo que los controles funcionan. Según el alcance, la evidencia puede incluir informes independientes vigentes, resultados de pruebas, registros de revisiones de acceso, ejercicios de continuidad, tratamiento de hallazgos o confirmación de compromisos contractuales. Un certificado tampoco debe leerse fuera de contexto: interesa su alcance, período, exclusiones y relación con el servicio contratado.

NIST SP 800-161 Rev. 1, actualizada en 2024, integra la gestión del riesgo de la cadena de suministro con las actividades generales de riesgo y contempla productos y servicios durante su ciclo de vida. La consecuencia práctica es evitar una evaluación aislada de Compras. Tecnología conoce las dependencias, el área usuaria entiende el impacto, Legal delimita compromisos y Seguridad analiza si la evidencia responde al riesgo identificado.

El contrato necesita responsables y activadores

Cláusulas sobre notificación de incidentes, accesos, subcontratación, continuidad, devolución y eliminación de datos tienen valor cuando alguien sabe cuándo activarlas. Una obligación de informar “oportunamente” puede resultar insuficiente si la organización necesita escalar una interrupción en minutos. El contrato debe conectarse con responsables operativos, canales vigentes y decisiones que puedan ejecutarse bajo presión.

También conviene distinguir un compromiso del proveedor de una capacidad propia. La empresa puede exigir respaldos y, aun así, necesitar copias o alternativas bajo su control. Puede acordar eliminación de datos y requerir evidencia de cierre. Puede recibir un nivel de servicio y descubrir que este mide disponibilidad técnica, no la recuperación completa del proceso. La revisión debe identificar esas diferencias antes de que se conviertan en una disputa durante un incidente.

Supervisar cambios durante la relación

La aprobación inicial envejece. El proveedor puede incorporar subcontratistas, mover funciones, cambiar controles de acceso, modificar condiciones de soporte o sufrir eventos que alteren su riesgo. NIST CSF 2.0 ubica la cadena de suministro dentro de la función Gobernar y plantea integrar su gestión con el riesgo empresarial. Esto favorece una supervisión basada en cambios relevantes y criticidad, no una solicitud idéntica de documentos para todos cada año.

Las señales deben traducirse en acciones conocidas: pedir nueva evidencia, revisar el alcance, aplicar controles compensatorios, aceptar el riesgo con plazo o preparar una sustitución. Acumular alertas sin dueño no mejora la supervisión. Tampoco sirve registrar una excepción sin fecha, porque termina convirtiendo una debilidad temporal en la condición normal de la relación.

Planificar la salida antes de necesitarla

La salida forma parte del riesgo de proveedores tecnológicos. Antes de depender del servicio, conviene entender cómo exportar datos en un formato utilizable, revocar identidades e integraciones, recuperar configuraciones, transferir conocimiento y comprobar la eliminación. Si el reemplazo exige meses de trabajo o existe una dependencia técnica difícil de separar, ese costo debe ser visible en la decisión inicial y en los planes de continuidad.

Revisar el control, no solo el expediente

Un programa maduro puede explicar cuáles proveedores son críticos, por qué reciben un nivel determinado de revisión, qué evidencia respalda su aprobación y qué cambió desde la última evaluación. Una auditoría de seguridad puede contrastar el proceso declarado con contratos, muestras de proveedores, evidencias operativas y decisiones de riesgo. El objetivo no es producir más formularios, sino comprobar que las dependencias externas se gobiernan con criterios consistentes y verificables.

Fuentes consultadas

• NIST Cybersecurity Framework 2.0.
• NIST SP 800-161 Rev. 1 Update 1: Cybersecurity Supply Chain Risk Management.
• CIS Control 15: Service Provider Management.

Rodrigo Zamora

Una carpeta marcada como “confidencial” no está mejor protegida si cualquier persona puede abrirla, copiarla o enviarla fuera de la empresa. La clasificación de la información sirve cuando la categoría cambia decisiones concretas. Si solo agrega una etiqueta, crea trabajo administrativo sin reducir el riesgo.

Para gerencia, responsables de procesos, seguridad y TI, clasificar consiste en acordar qué impacto tendría la divulgación, alteración o indisponibilidad de la información y aplicar un tratamiento coherente con ese impacto. La herramienta puede automatizar parte del trabajo, pero no decide cuánto daño produciría un contrato alterado, un listado de precios divulgado antes de tiempo o un procedimiento crítico inaccesible.

Clasificación de la información basada en impacto

La sensibilidad no depende únicamente de si un documento contiene datos personales. También puede existir información financiera, comercial, estratégica, operativa o técnica cuya pérdida afecte a clientes, decisiones o continuidad. El punto de partida es el efecto para la organización y las personas, no el formato del archivo ni la aplicación donde se guarda.

FIPS 199 utiliza confidencialidad, integridad y disponibilidad para categorizar información según el impacto potencial de un compromiso. Es un estándar dirigido al ámbito federal estadounidense, no una obligación general para empresas chilenas, pero ofrece una referencia útil: un mismo activo puede exigir protección por razones diferentes. Una lista de remuneraciones preocupa por su divulgación; una orden de pago, por una modificación no autorizada; y un instructivo de emergencia, por no estar disponible cuando se necesita.

Pocas categorías, diferencias observables

Un esquema con muchos niveles tiende a producir dudas y clasificaciones inconsistentes. Uno demasiado simple reúne información con riesgos distintos. No existe una cantidad universal de categorías. La empresa necesita las suficientes para que cada nivel cambie reglas de acceso, intercambio, almacenamiento, respaldo, conservación y disposición.

Nombres como público, interno, confidencial o restringido pueden servir como ejemplos, pero no resuelven nada por sí solos. Cada categoría debe responder qué se puede hacer con la información, quién puede autorizar una excepción y qué control se espera. Si dos niveles terminan con exactamente el mismo tratamiento, la distinción merece ser revisada.

El dueño del proceso debe participar

TI puede configurar permisos o herramientas de etiquetado, pero el área propietaria conoce el uso y las consecuencias del dato. Seguridad aporta criterios comunes; Legal y Cumplimiento contrastan obligaciones; y Tecnología verifica si las reglas pueden aplicarse en los sistemas. Delegar toda la decisión en una sola función suele dejar un catálogo técnicamente ordenado y poco conectado con la operación.

La política de seguridad de la información puede establecer el marco y las responsabilidades. El esquema de clasificación traduce esa dirección en decisiones sobre conjuntos concretos de información. No necesita describir cada producto, pero sí permitir que distintas áreas lleguen a resultados comparables ante situaciones equivalentes.

La categoría debe acompañar el ciclo de vida

Una base puede estar bien protegida en su aplicación principal y perder esa condición cuando alguien la exporta a una planilla, la adjunta a un correo o la carga en un servicio no autorizado. Clasificar el sistema sin considerar las copias entrega una visión incompleta. La regla debe seguir a la información dentro de límites técnicamente viables y conocidos.

El mapa de datos personales aborda finalidades, flujos y terceros para ese tipo específico de información. La clasificación empresarial tiene otro alcance: relaciona sensibilidad e impacto con el tratamiento de información personal y no personal. Ambos instrumentos pueden compartir inventarios, pero responden preguntas distintas.

Comprobar si la clasificación cambia controles reales

El Control 3 de CIS conecta identificar, clasificar, manejar, conservar y eliminar datos. Su salvaguarda 3.7 propone mantener un esquema empresarial, cubrir los tipos sensibles y revisar si la información está categorizada de manera correcta. Esta relación evita medir el programa solo por el número de documentos etiquetados.

Una revisión útil puede tomar muestras de contratos, reportes financieros, respaldos, tickets de soporte o código fuente y reconstruir su tratamiento. Importa observar si el propietario asignado entiende la categoría, si los permisos coinciden con ella, si las copias mantienen el resguardo y si existe evidencia de excepciones. Clasificar todo en el nivel más alto tampoco demuestra madurez: cuando cada archivo parece crítico, los usuarios dejan de distinguir prioridades y los controles más exigentes se vuelven difíciles de sostener.

Pasar de las etiquetas a una capacidad verificable

La clasificación de la información funciona cuando reduce ambigüedad. El área que crea o recibe los datos puede anticipar cómo tratarlos; TI conoce qué controles aplicar; y una revisión puede seguir la decisión desde el criterio hasta la evidencia. Comprar una plataforma antes de resolver esas reglas puede automatizar inconsistencias con mayor velocidad.

Una auditoría de seguridad puede contrastar el esquema declarado con muestras de información, permisos y prácticas de manejo. El objetivo no es multiplicar etiquetas, sino comprobar que la sensibilidad reconocida produce controles proporcionales y decisiones que la organización puede explicar.

Fuentes consultadas

• CIS Control 3: protección y clasificación de datos.
• NIST FIPS 199: categorización por impacto.
• NIST SP 800-60 Vol. 1 Rev. 1: tipos de información y categorías de seguridad.

Rodrigo Zamora

Las copias de seguridad contra ransomware no se evalúan por la cantidad de tareas que terminan en verde. La pregunta útil es otra: si un atacante obtiene privilegios, altera sistemas y busca destruir la capacidad de recuperación, ¿la empresa conserva una copia íntegra, accesible por una ruta independiente y capaz de devolver un servicio a un estado confiable? Responderla exige mirar arquitectura, identidades y pruebas, no solo capacidad de almacenamiento.

Por qué una copia disponible puede fallar durante la crisis

La plataforma de respaldo forma parte del entorno que se intenta proteger. Si utiliza las mismas cuentas administrativas, el mismo directorio, la misma red y las mismas consolas que producción, una intrusión con privilegios puede alcanzar también catálogos, políticas de retención, instantáneas y repositorios. El respaldo existe, pero comparte el camino de compromiso.

También hay fallas menos visibles. Un trabajo puede completar sin contener todos los datos y configuraciones necesarios para levantar el servicio. Una copia cifrada puede ser eliminada por una cuenta comprometida o depender de llaves, DNS e identidades que nadie incluyó en el alcance. Por eso, el objetivo del CIS Control 11 es restaurar activos a un estado anterior y confiable, no acumular copias.

Copias de seguridad contra ransomware: separar control y destino

Una estrategia resistente necesita al menos una instancia de recuperación aislada. El aislamiento puede ser físico, lógico o temporal. Una copia fuera de línea queda desconectada cuando no se utiliza; una copia inmutable impide modificar o borrar objetos durante un periodo definido. Son capacidades distintas y ninguna reemplaza la revisión de accesos, retención e integridad.

La separación debe alcanzar el plano administrativo. Conviene evitar que una sola identidad pueda controlar producción y destruir todas las versiones recuperables. Las cuentas de respaldo, las credenciales de emergencia y las llaves de cifrado requieren propietarios definidos, autenticación reforzada, privilegios limitados y trazabilidad. La gestión de accesos privilegiados es especialmente relevante aquí: proteger el repositorio sirve de poco si la consola que gobierna su retención queda expuesta a las mismas credenciales.

Recuperar a un estado confiable, no solo abrir archivos

La prueba decisiva es restaurar. Verificar un archivo o ejecutar una validación automática aporta evidencia de integridad, pero no demuestra que una aplicación funcionará con sus dependencias. Una prueba representativa debe comprobar datos, configuración, identidad, conectividad y secuencia de inicio. También debe registrar cuánto tardó el proceso, qué intervención manual exigió y qué diferencias aparecieron frente al objetivo previsto.

Esto conecta con los objetivos RTO y RPO, aunque no los repite. RTO y RPO expresan la tolerancia del negocio; la restauración demuestra si la arquitectura puede cumplirla. Si una base de datos vuelve dentro del plazo, pero la aplicación depende de un directorio o certificado no recuperado, el servicio sigue indisponible. El indicador útil debe llegar hasta una función operativa verificable.

NIST SP 800-184 recomienda planificar la recuperación, priorizar recursos y usar escenarios realistas para probarla y mejorarla. Frente a ransomware, además, plantea inventariar los respaldos y comprobar que no hayan sido cifrados antes de iniciar la restauración. Esa comprobación evita devolver a producción datos dañados o reintroducir condiciones que mantengan el incidente.

Qué evidencia debería revisar la dirección

La dirección no necesita administrar la plataforma, pero sí pedir evidencia comprensible: alcance de los servicios cubiertos, fecha y resultado de la última copia, existencia de una instancia aislada, responsables autorizados, última restauración probada y tiempo realmente observado. Las excepciones deben indicar qué queda fuera, por cuánto tiempo y qué medida compensatoria se aplicará.

El resultado de una prueba también debe mostrar la calidad del punto recuperado. Restaurar el archivo correcto no basta si contiene información inconsistente, cuentas no autorizadas o una configuración vulnerable. La validación requiere participación del dueño del servicio, porque solo el área usuaria puede confirmar que el proceso recuperado cumple su función y que los datos corresponden al momento esperado.

La secuencia de recuperación cambia el resultado

Recuperar demasiado pronto puede contaminar nuevamente el entorno. Antes de restaurar, el equipo debe comprender el alcance, contener el acceso del atacante y preparar una base limpia. Identidades, servicios de red y plataformas de administración suelen ser dependencias previas de las aplicaciones.

Esta coordinación se puede validar mediante un simulacro de ciberseguridad que obligue a decidir qué restaurar, quién autoriza el retorno y qué evidencia permite declarar el servicio confiable. El ejercicio revela dependencias y permisos faltantes sin esperar una crisis real.

Convertir el respaldo en una capacidad verificable

La decisión no comienza por comprar más almacenamiento. Comienza por identificar servicios críticos, trazar sus dependencias y comprobar si producción y recuperación comparten rutas de administración. Con ese diagnóstico se puede definir aislamiento, retención, control de accesos y pruebas acordes con el impacto.

Una auditoría de seguridad puede contrastar la arquitectura declarada con evidencia de configuraciones, permisos, alertas y restauraciones. El valor está en detectar dónde una copia aparentemente disponible deja de ser recuperable. Cuando esa brecha se conoce antes del incidente, la empresa puede corregirla con prioridades claras y demostrar que su continuidad no depende de una suposición.

Fuentes

• CIS Critical Security Control 11: Data Recovery.
• NIST SP 800-184: Guide for Cybersecurity Event Recovery.
• NIST Cybersecurity Framework 2.0.

Rodrigo Zamora

Un programa de concientización en ciberseguridad puede alcanzar asistencia completa y no cambiar la respuesta cuando una persona recibe una solicitud urgente, detecta una exposición de datos o debe informar una actividad sospechosa. Completar cursos demuestra cobertura administrativa. Para conocer la eficacia se necesita observar si las personas reconocen situaciones relevantes, toman decisiones esperadas y utilizan los canales definidos por la empresa.

Definir la conducta antes de preparar el contenido

El punto de partida no debería ser elegir una plataforma o distribuir un curso genérico, sino precisar qué riesgo necesita reducir la organización. Finanzas puede requerir criterios para validar cambios de cuentas bancarias; quienes administran sistemas, reconocer solicitudes anómalas de acceso; una jefatura, escalar una posible filtración sin esperar certeza técnica. El contenido cambia cuando la conducta esperada está definida.

La publicación NIST SP 800-50 Rev. 1 propone gestionar el aprendizaje como un ciclo y distinguir metas, objetivos y resultados observables. Ese enfoque evita confundir “explicar phishing” con “lograr que una solicitud sospechosa sea validada y reportada”. También permite segmentar: todas las personas requieren una base común, mientras quienes poseen privilegios o responsabilidades específicas necesitan formación asociada a su función.

Qué medir en un programa de concientización en ciberseguridad

Asistencia, finalización y resultados de una prueba siguen siendo útiles, pero responden preguntas limitadas: quién recibió el contenido y qué pudo recordar en ese momento. Para evaluar impacto conviene combinar esa información con evidencia de comportamiento y con observaciones cualitativas. NIST recomienda vincular las métricas con los objetivos de aprendizaje y considerar capacidades, actitudes y cambios de conducta, no solo cumplimiento.

Una organización puede observar los reportes correctos ante mensajes sospechosos, el uso de canales aprobados, la adopción de autenticación multifactor cuando depende del usuario o la capacidad de aplicar un procedimiento semanas después. Entrevistas breves y observaciones de facilitadores ayudan a explicar por qué un resultado mejora o se estanca. La combinación evita decidir con una cifra aislada.

Tampoco corresponde atribuir cada incidente a una falla de capacitación. El número de eventos depende de controles técnicos, exposición, procesos y actividad de amenazas. Un aumento de reportes puede indicar mayor atención, no un deterioro. La métrica útil necesita contexto, una línea base comparable y una pregunta de gestión: qué conducta se busca fortalecer y qué decisión cambiará según el resultado.

Las simulaciones deben enseñar, no castigar

Una simulación de phishing puede mostrar quién reportó, abrió un adjunto o siguió un enlace, pero no resume la cultura de seguridad. La dificultad, el contexto y la familiaridad con el canal alteran el resultado. Conviene comparar escenarios equivalentes y observar si el mecanismo de reporte resulta accesible y conocido.

NIST aconseja tratar estas actividades como oportunidades de aprendizaje, comunicar que se realizarán ejercicios aleatorios y evitar exponer o sancionar a una persona por su respuesta. También recomienda revisión legal, especialmente al usar marcas, beneficios o temas personales capaces de generar efectos fuera del ejercicio. El propósito es descubrir dónde reforzar capacidades.

El phishing es solo una modalidad. Casos breves sobre pérdida de equipos, uso de aplicaciones no autorizadas, manejo de información personal o solicitudes urgentes de un proveedor pueden revelar brechas más cercanas al trabajo cotidiano. Para equipos con responsabilidades críticas, un simulacro de ciberseguridad permite evaluar coordinación y decisiones que una capacitación individual no alcanza a observar.

Medir por función sin crear vigilancia innecesaria

Un programa común entrega lenguaje compartido, pero la evidencia debe reflejar las responsabilidades. En atención de clientes interesa el manejo y escalamiento de datos; en compras, la validación de proveedores; en administración tecnológica, el uso de cuentas privilegiadas y cambios; en gerencia, la capacidad de reconocer fraude ejecutivo y activar apoyo. Comparar a todas las áreas con una misma prueba oculta esas diferencias.

Los resultados pueden formar parte de registros laborales y contener información sensible sobre desempeño. Se debe definir quién accede, cuánto se conserva, qué detalle llega a la gerencia y para qué se utilizará. Los reportes agregados suelen bastar para orientar el programa. La identificación individual debería reservarse para apoyos concretos u obligaciones justificadas.

Convertir resultados en una mejora verificable

La revisión debe conectar cada hallazgo con una acción. Si las personas reconocen un mensaje dudoso pero no saben dónde reportarlo, el problema puede estar en el canal. Si un área falla ante cambios de datos bancarios, quizá se necesite ajustar el proceso además de capacitar. Cuando la retención cae, conviene introducir refuerzos breves en el trabajo.

El CIS Control 14 sitúa la concientización como un programa mantenido para influir en conductas y desarrollar habilidades. El NIST Cybersecurity Framework 2.0 permite relacionar esos resultados con objetivos más amplios de gestión del riesgo. En la práctica, la evidencia debería alimentar la aplicación de la política de seguridad, las prioridades de cada área y la planificación del siguiente ciclo.

AllDefense puede apoyar este trabajo mediante su servicio de Concientización en Seguridad, diseñando actividades relacionadas con riesgos y funciones reales. Cuando el desafío incluye gobierno, indicadores y responsabilidades entre áreas, la Asesoría Estratégica ayuda a convertir la capacitación en una capacidad gestionable. La señal de avance no es haber enviado más contenidos, sino contar con mejores decisiones y evidencia suficiente para sostenerlas.

Fuentes consultadas

• NIST SP 800-50 Rev. 1: Building a Cybersecurity and Privacy Learning Program.
• NIST Cybersecurity Framework 2.0.
• CIS Critical Security Control 14: Security Awareness and Skills Training.

Rodrigo Zamora

Una configuración segura puede deteriorarse sin que exista un ataque. Basta una regla temporal que nunca se retira, un servicio habilitado para resolver una urgencia o una plantilla que deja de reflejar la operación real. Cuando cada cambio parece razonable por separado, el desvío termina convertido en la configuración normal y la empresa pierde una referencia confiable para evaluar sus equipos.

El objetivo no es endurecer todos los sistemas al máximo. Es acordar una línea base que reduzca exposición sin impedir la función del activo, controlar los cambios y mantener evidencia suficiente para distinguir una decisión aprobada de una diferencia que nadie puede explicar.

Una configuración segura comienza con una línea base útil

La guía NIST SP 800-128 describe la gestión de configuración enfocada en seguridad como parte de la gestión de riesgo. Su propósito es establecer, controlar y vigilar configuraciones mientras se conserva la funcionalidad que el negocio necesita. Esto evita tratar la seguridad como una lista aislada de parámetros.

Una línea base debe indicar a qué familia y versión de activos aplica, quién la aprueba, qué dependencias condicionan sus ajustes y cómo se comprobará. También necesita una versión identificable. Una planilla sin dueño o una captura de pantalla antigua no permite saber si el servidor observado está correctamente configurado o si la referencia quedó obsoleta.

Conviene comenzar por grupos acotados y comparables: estaciones corporativas, servidores con una misma función, equipos de red o plataformas en la nube. Mezclar activos con propósitos distintos produce una línea base tan genérica que cualquier resultado puede parecer aceptable.

Controlar cambios sin congelar la operación

Una configuración aprobada no debe impedir el cambio. Debe permitir reconstruir por qué ocurrió, quién evaluó su impacto, cómo se probó y qué alternativa existe si falla. La familia de gestión de configuración de NIST SP 800-53 Rev. 5 reúne controles sobre líneas base, cambios, parámetros y componentes. La utilidad empresarial está en conectar esas decisiones con el proceso habitual de cambios, no en crear un circuito paralelo que el equipo terminará evitando.

La evidencia mínima depende del impacto. Cambiar una preferencia local no requiere la misma revisión que abrir un servicio a internet o desactivar una protección en cientos de equipos. Definir umbrales permite reservar una aprobación más exigente para cambios que alteran exposición, privilegios, registros, cifrado o recuperación.

Detectar el desvío antes de normalizarlo

El desvío de configuración aparece cuando el estado observado deja de coincidir con la referencia aprobada. Una herramienta puede encontrar la diferencia, pero no decidir por sí sola si se trata de un error, una excepción vigente o una actualización pendiente de incorporar a la línea base. Esa clasificación necesita contexto y un responsable.

Medir todo con la misma frecuencia tampoco aporta el mismo valor. Los activos expuestos, las consolas administrativas y los servicios críticos merecen una detección más cercana que equipos aislados de bajo impacto. Los logs de seguridad ayudan a reconstruir quién realizó el cambio y cuándo, siempre que las identidades sean atribuibles y los eventos relevantes estén definidos de antemano.

Las excepciones deben tener vencimiento

Una línea base rígida puede generar excepciones informales. Resulta preferible reconocerlas y decidirlas. Cada excepción debería registrar el activo y el parámetro afectados, la razón operativa, el riesgo aceptado, los controles compensatorios, el responsable y una fecha de revisión o cierre. Sin vencimiento, una necesidad temporal se transforma en una deuda invisible.

Revisar una excepción no significa renovarla automáticamente. Se debe comprobar si la causa continúa, si el activo cambió y si apareció una alternativa. Cuando la excepción afecta tecnología que ya no recibe soporte, la decisión también debe considerar si corresponde renovar, aislar o retirar el componente.

Un benchmark es un punto de partida, no la decisión final

El Control 4 de CIS plantea establecer y mantener configuraciones seguras para activos y software. Los benchmarks reconocidos ayudan a iniciar la conversación con parámetros concretos, pero deben ajustarse a la versión, función y dependencias del entorno. Aplicarlos sin pruebas puede afectar servicios; diluirlos hasta que todo cumpla elimina su propósito.

La adaptación debe conservar la trazabilidad: qué recomendación se adoptó, cuál se modificó y por qué. Así, una actualización del benchmark o de la plataforma no obliga a comenzar desde cero y permite identificar decisiones que necesitan reevaluación.

Qué debería demostrar una revisión independiente

Una revisión útil no se limita a confirmar que existe un documento. Debe tomar una muestra de activos y relacionar la línea base aplicable, el estado observado, los cambios aprobados y las excepciones vigentes. También debe comprobar que la referencia sigue alineada con el riesgo y que los desvíos generan decisiones verificables.

El NIST Cybersecurity Framework 2.0 permite ubicar esta práctica dentro del gobierno y la gestión continua del riesgo. La política de seguridad respaldada por evidencia define el criterio; la configuración segura muestra cómo se materializa en activos concretos.

Una auditoría de seguridad puede evaluar una muestra priorizada, separar fallas de gobierno de problemas técnicos y proponer una hoja de ruta. El resultado esperado no es una fotografía perfecta, sino la capacidad de reconocer cuándo una configuración cambia, decidir si el cambio es aceptable y corregirlo antes de que pierda dueño.

Rodrigo Zamora

El Shadow IT rara vez comienza con una intención de saltarse las reglas. Aparece cuando un área necesita compartir archivos, automatizar una tarea o atender clientes y encuentra una aplicación SaaS antes de que exista una respuesta corporativa. El problema no es solo que la herramienta haya sido contratada sin pasar por TI. El riesgo crece cuando nadie puede explicar qué datos contiene, quién administra sus accesos, con qué sistemas se integra o cómo se abandonará el servicio.

Bloquear todas las iniciativas puede empujar el uso fuera de la vista. Aprobarlas sin condiciones traslada decisiones críticas a una tarjeta de crédito. Una gestión útil del Shadow IT busca descubrir, asignar responsables y decidir qué aplicaciones regularizar, reemplazar o retirar según su valor y su exposición.

Shadow IT: descubrir sin convertirlo en una cacería

La primera conversación debería explicar para qué se usa cada servicio y qué necesidad resuelve. Si el levantamiento se presenta como una búsqueda de culpables, las áreas ocultarán las herramientas que más necesitan. En cambio, una revisión breve con negocio, TI, seguridad y compras permite identificar plataformas contratadas directamente, versiones gratuitas, extensiones de navegador e integraciones creadas por usuarios.

El Control 2 de CIS recomienda administrar activamente el software para que solo las soluciones autorizadas sean instaladas y ejecutadas. En servicios SaaS, “inventario” no puede limitarse a una lista de nombres: debe mostrar suficiente contexto para tomar una decisión.

Un inventario que permita tomar decisiones

Por cada aplicación conviene registrar propósito, área usuaria, responsable de negocio, administrador, modalidad de autenticación, datos tratados, integraciones, criticidad, costo y fecha de renovación. También importa saber si existe un método de exportación y quién ejecutaría el cierre. Una herramienta barata puede resultar costosa si concentra información sensible o si retirar su integración detiene un proceso comercial.

La guía del NCSC para utilizar SaaS de forma segura propone comprender la finalidad del servicio, sus opciones de autenticación y administración, el manejo de permisos, los datos involucrados y la forma de compartirlos. Estas preguntas convierten un inventario estático en una vista operativa.

Regularizar, reemplazar o retirar

No toda aplicación descubierta merece el mismo tratamiento. Una herramienta sin datos sensibles ni integraciones críticas puede regularizarse con un dueño y una configuración básica. Otra que duplica una capacidad corporativa podría migrarse. Un servicio sin soporte, sin exportación o con controles insuficientes puede requerir retiro, pero solo después de identificar dependencias y conservar la información necesaria.

La decisión debería combinar valor de negocio, sensibilidad de los datos, privilegios concedidos, alcance de las integraciones, continuidad y capacidad del proveedor. El NIST Cybersecurity Framework 2.0 ayuda a ubicar estas decisiones dentro del gobierno del riesgo, en vez de tratarlas como excepciones técnicas aisladas.

La identidad y los datos muestran el costo real

Dos aplicaciones aparentemente similares pueden tener riesgos distintos. Una usa inicio de sesión corporativo, permite revocar usuarios y almacena información pública; la otra conserva contraseñas propias, tiene administradores compartidos y recibe bases de clientes. El mapa de datos personales permite saber qué información entra y sale, mientras la gestión de accesos privilegiados aclara quién puede cambiar configuraciones o extraer contenido.

Integrar el servicio con el proveedor de identidad reduce cuentas olvidadas y facilita el retiro cuando una persona cambia de cargo. Sin embargo, el inicio de sesión único no corrige permisos excesivos dentro de la aplicación. El dueño del servicio debe revisar roles, invitados, enlaces públicos y aplicaciones conectadas con una periodicidad acorde con su criticidad.

El contrato no reemplaza la operación

El Control 15 de CIS plantea inventariar, clasificar, evaluar y supervisar proveedores. Para un SaaS, eso incluye acordar notificación de incidentes, ubicación y devolución de datos, subcontratación, continuidad, niveles de servicio y término de la relación. La cláusula sirve solo si la empresa sabe quién la activará y conserva evidencia de que los controles operan.

También debe definirse una salida antes de depender del servicio. ¿Los datos pueden exportarse en un formato utilizable? ¿Quién revoca integraciones y claves? ¿Cómo se comprueba la eliminación? ¿Cuánto tiempo necesita el proceso? Estas respuestas evitan que la renovación automática sea la única estrategia de continuidad.

Cómo recuperar control sin centralizar cada decisión

Una ruta rápida y conocida reduce el incentivo a contratar por fuera. Las aplicaciones de bajo riesgo pueden seguir un conjunto simple de requisitos; las que procesan datos sensibles, conceden acceso amplio o sostienen procesos críticos necesitan revisión adicional. Los umbrales deben ser comprensibles para negocio y no depender de interpretar una política extensa.

Los logs de seguridad aportan trazabilidad cuando responden preguntas concretas sobre accesos, cambios e integraciones. No todos los servicios ofrecerán el mismo nivel de registro, por lo que esa limitación debe influir en la clasificación y en los controles compensatorios.

El resultado esperado no es una lista perfecta, sino un proceso que detecta nuevas aplicaciones, decide con criterios consistentes y revisa lo que cambia. Una auditoría de seguridad puede tomar una muestra de servicios, reconstruir su alta y salida, y convertir las brechas encontradas en una hoja de ruta. Así, la empresa conserva la velocidad que dio origen al SaaS sin renunciar a la responsabilidad sobre sus datos y operaciones.

Rodrigo Zamora

La gestión de accesos privilegiados no comienza al comprar una plataforma. Empieza cuando la empresa puede explicar quién tiene capacidad para cambiar configuraciones, crear usuarios, detener respaldos o acceder a información sensible, para qué necesita ese poder y durante cuánto tiempo. Una cuenta administrativa sin dueño claro puede convertir un error, una credencial robada o una relación laboral terminada en un problema de alcance mayor.

Para gerencia, TI y seguridad, la decisión relevante no es si existen administradores: siempre serán necesarios. Lo importante es evitar que los privilegios sean permanentes, compartidos o más amplios de lo que exige cada función, y conservar evidencia suficiente para revisar su uso.

Gestión de accesos privilegiados: el riesgo no es solo la contraseña

Activar autenticación multifactor protege el ingreso, pero no decide qué puede hacer la persona una vez autenticada. Tampoco resuelve una cuenta genérica utilizada por varios técnicos ni elimina permisos que sobrevivieron a un cambio de cargo. Por eso, la gestión de accesos privilegiados complementa la autenticación: gobierna el alcance, la duración y la responsabilidad asociada a cada permiso crítico.

El término incluye más que la cuenta “administrador”. Abarca roles elevados en servicios de nube, consolas de respaldo, directorios, hipervisores, equipos de red, bases de datos y aplicaciones de negocio. También incluye cuentas de servicio que ejecutan procesos sin intervención humana. Su criticidad depende de lo que permiten cambiar o extraer, no del cargo de quien las utiliza.

Qué debería poder demostrar la empresa

Un inventario útil relaciona cada acceso con una identidad, un responsable, un propósito, los activos alcanzados y una fecha de revisión. Si se trata de una cuenta técnica, además debe identificar el proceso que depende de ella y quién autoriza sus cambios. Así es posible distinguir una necesidad operativa de un permiso heredado que nadie se atreve a retirar.

La identidad administrativa debería estar separada de la cuenta de uso cotidiano. Leer correo o navegar con privilegios elevados amplía innecesariamente la exposición. Las cuentas de emergencia también requieren un dueño, condiciones de activación, custodia y revisión posterior; llamar “break glass” a una contraseña compartida no la convierte en un control.

Menos privilegios permanentes, más decisiones explícitas

El NIST Cybersecurity Framework 2.0 plantea que los permisos deben administrarse y revisarse considerando mínimo privilegio y separación de funciones. El catálogo NIST SP 800-53 desarrolla estos principios en sus controles de acceso, mientras los Controles 5 y 6 de CIS separan la administración de cuentas de la asignación y revocación de privilegios.

En la práctica, esto favorece permisos aprobados cerca del momento de uso, con alcance y vencimiento definidos. No todas las empresas necesitan automatizar de inmediato el acceso justo a tiempo, pero sí deberían saber cuáles privilegios permanecen activos, por qué y hasta cuándo. Una excepción sin fecha de cierre termina convirtiéndose en la configuración normal.

También conviene separar quien solicita, quien aprueba y quien revisa, sobre todo en cambios de alto impacto. En equipos pequeños, la separación completa puede no ser viable. Allí la compensación razonable es dejar una aprobación explícita y una revisión independiente posterior, en vez de fingir que dos funciones recaídas en la misma persona son controles distintos.

La trazabilidad empieza antes del registro

Los registros pierden valor cuando varias personas usan la misma cuenta administrativa. Aunque la plataforma conserve una hora y una dirección IP, la organización no podrá atribuir la acción con precisión. Una identidad individual para cada operador, junto con el registro del permiso concedido, permite conectar la solicitud, la aprobación y la actividad realizada.

Esto no significa guardar todo indefinidamente. El artículo sobre logs de seguridad explica que primero deben definirse las preguntas que la empresa necesita responder. En accesos privilegiados, suelen ser quién obtuvo el permiso, sobre qué activo, con qué aprobación, qué acción crítica ejecutó y cuándo terminó la autorización.

Cuándo tiene sentido una solución PAM

Una plataforma de gestión de accesos privilegiados puede custodiar secretos, rotar credenciales, aprobar sesiones y registrar actividades. Su valor aumenta cuando aplica un proceso ya definido. Si las cuentas críticas siguen sin inventario, las cuentas de servicio carecen de dueño o nadie conoce las dependencias, la herramienta automatizará solo una parte del problema.

Antes de seleccionar tecnología, conviene revisar si la organización conoce sus cuentas y roles críticos, puede asociarlos a responsables, ha definido el alcance necesario y dispone de un mecanismo de emergencia. Después será posible comparar capacidades de PAM contra brechas concretas, en lugar de evaluar funciones aisladas de un catálogo.

Qué revisar primero

La prioridad debería seguir el impacto de un uso indebido. Normalmente merece atención temprana el proveedor de identidad, la consola de nube, el directorio corporativo, los respaldos, la virtualización, los equipos de red y las cuentas de servicio con alcance amplio. La segmentación de red limita recorridos técnicos; el gobierno de privilegios reduce qué acciones puede autorizar una identidad comprometida. Ambos controles responden preguntas distintas.

Una revisión inicial puede tomar una muestra de cambios recientes y reconstruir quién los solicitó, aprobó, ejecutó y verificó. Las brechas encontradas permiten ajustar la política de seguridad de la información con evidencia real. La comparación entre auditoría y análisis de vulnerabilidades ayuda a distinguir los alcances de cada revisión. El objetivo no es eliminar la administración, sino hacer que cada privilegio poderoso sea necesario, temporal y atribuible.

Si necesita contrastar los privilegios asignados con las políticas y evidencias de su empresa, conozca el servicio de auditoría de seguridad de AllDefense y defina qué controles conviene evaluar.

Rodrigo Zamora