Oktavia
Automatización de redes multivendor

1. Resumen ejecutivo

Oktavia es una plataforma de automatización de redes para operaciones de TI empresariales. Combina un motor de automatización con una interfaz web unificada para ejecutar auditorías, verificar cumplimiento de configuración, visualizar el estado de la red y gestionar cambios de forma controlada y trazable.

Está diseñada para equipos que necesitan operar con agilidad sin renunciar al control. Cada acción produce artefactos versionables, cada cambio requiere validación previa y todo queda registrado en un historial consultable.

2. El problema que resuelve

Las redes empresariales crecen en complejidad más rápido que los equipos que las operan. Los síntomas se repiten en casi todos los clientes:

• Auditorías manuales que toman días y dependen de que nadie se equivoque al leer una configuración.
• Desviaciones de configuración que nadie detecta hasta que hay un incidente.
• Visibilidad fragmentada entre inventario, cumplimiento, topología y métricas, cada una en su herramienta.
• Falta de trazabilidad sobre quién cambió qué, cuándo y con qué autorización.
• Operación reactiva: se actúa cuando el usuario reporta, no cuando la red se desvía.
• Diagnóstico sin cierre: las herramientas de auditoría encuentran el problema, pero corregirlo sigue siendo trabajo manual fuera de la herramienta.

3. Propuesta de valor

4. Categorías de capacidad

Las capacidades de Oktavia se agrupan en siete categorías. Es la forma de leer la plataforma por problema resuelto, no por pantalla.

5. Módulos de la plataforma

6. El ciclo cerrado

Es lo que separa a Oktavia de una herramienta de auditoría. Encontrar un problema no sirve si corregirlo sigue siendo manual, y aplicar un cambio a ciegas no sirve si nadie verifica que quedó bien. El ciclo es uno solo y se recorre sin salir de la plataforma:

1. Auditar el alcance elegido: un equipo, un rol, un sitio o toda la red.
2. Ver el cumplimiento: qué falló, con qué severidad y qué líneas de configuración faltan.
3. Proponer el cambio contra la intención declarada, no contra una plantilla genérica.
4. Revisar el diff entre configuración deseada y activa en el Gemelo Digital, con el impacto estimado.
5. Aprobar. Una persona, siempre. Ningún cambio se aplica solo.
6. Aplicar con la primitiva segura de cada fabricante.
7. Verificar: se vuelve a auditar y se confirma que el hallazgo cerró.

Cada paso deja artefacto descargable y queda en el historial de trabajos. Si el resultado no convence, hay vuelta atrás.

Verificación antes y después

El veredicto no es sólo «la regla ya pasa». Oktavia compara los resultados de las pruebas de cada equipo antes y después del cambio y los separa en corregidos, regresiones, fallas nuevas y siguen fallando. Una regresión impide cerrar el ciclo. Las fallas de estado que ya existían antes del cambio se muestran aparte y no lo bloquean, porque no las causó.

Argos cierra el ciclo también sobre cambios que ya existen en el Gemelo Digital, como un parche de seguridad preparado por el flujo automático; un parche verificado se marca como tal. Cada veredicto se indexa como reporte de cambio en la IA local, así que el siguiente cambio parecido parte de lo que ya se aprendió.

Cómo se aplica en cada fabricante

7. Alta de servicios nuevos

El mismo ciclo sirve para dar de alta servicios, no únicamente para corregir desviaciones. Se describe lo que se quiere y Oktavia lo propone como intención declarada:

• Túnel entre dos sitios, con las rutas que van por él, y su baja completa cuando el proyecto termina.
• Publicar una red: interfaz lógica, anuncio en OSPF, listas de control de acceso y BGP en los equipos de borde del sitio, con verificación por ping.
• Editar el enrutamiento: identificador de router desde la interfaz lógica, sumarización del sitio recomendada.
• DHCP para una VLAN, con el rango propuesto a partir de lo que Oktavia ya sabe del segmento.
• Adoptar lo existente: leer el respaldo de un equipo y declarar como intención lo que ya tiene configurado, para empezar a auditarlo sin rediseñar nada.

8. Ciclo de vida de sitios y equipos

Abrir y cerrar sitios, y dar de alta, reemplazar y retirar equipos, son flujos de un botón con vista previa, aprobación y verificación. Cada uno se ensaya primero en la red de pruebas (Cisco Modeling Labs), donde Oktavia crea los nodos con un día 0 mínimo y los cablea; encenderlos es siempre decisión del operador.

• Alta de sitio: se clona el diseño de su tipo de sitio, con numeración propuesta y editable, el lado del concentrador (BGP, túnel, subinterfaz, VLAN) y los nodos y PCs de prueba en el laboratorio.
• Baja de sitio: limpia el concentrador en orden (BGP no neighbor, túneles, subinterfaces, VLAN y troncales), limpia Oktavia y el laboratorio, y valida que no quedó nada del sitio. Crear, quitar y volver a crear es repetible.
• Alta de equipo: acceso con la credencial de la bóveda, descubrimiento y auditoría, configuración desde la intención, telemetría, ciclo y verificación.
• Reemplazo de equipo: otro modelo con el mismo nombre, mapeo de puertos editable, cambio de enlaces y retiro del equipo viejo una vez que el nuevo está encendido y en servicio (la práctica es verificarlo antes de retirar el viejo). La llave SSH nueva se acepta sólo con confirmación del operador.
• Baja de equipo: paquete de archivo descargable sin secretos y limpieza de intención, inventario, cumplimiento y telemetría.

En Cisco SD-WAN el mismo ciclo pasa por el Manager: alta de edges con su Config Group y su bootstrap, y alta y baja de segmentos LAN. El detalle está en el artículo Probar antes de tocar producción: la red de pruebas de Oktavia.

9. Argos, el ChatOps de red

Argos es el asistente integrado en todas las pantallas de Oktavia. Se le pregunta en lenguaje natural y responde con datos de la red, no con generalidades. Cubre cuatro momentos del trabajo diario:

• Entender: estado de la red, cumplimiento, qué atender primero, diagnóstico de un equipo o un sitio.
• Investigar: camino entre dos direcciones IP con ida y regreso, correlación de fallas contra la configuración, detección de anomalías y equipos caídos.
• Configurar: se describe el servicio en lenguaje natural o se pega la configuración, y Argos la propone como intención declarada para que el operador la edite antes de aplicar.
• Cerrar el ciclo: auditar, ver cumplimiento, llevarlo al Gemelo Digital, aprobar y verificar. Cada paso es un botón, no una frase que haya que teclear.

Dos principios de diseño lo separan de un asistente genérico. Cada respuesta declara si consumió el modelo de lenguaje o se resolvió de forma determinista, así que el costo es visible antes de pulsar. Y ninguna acción que toque la red ocurre sin que una persona la apruebe.

Qué usa IA y qué no

La mayoría de lo que hace Argos no consume el modelo: son consultas y cálculos sobre datos ya recolectados, con resultado reproducible. El modelo entra cuando hay que redactar, priorizar o interpretar lenguaje libre.

El patrón se repite: primero se calcula con los datos, y el modelo sólo redacta o prioriza sobre ese resultado. Nunca inventa hallazgos, trabaja con los que el cálculo produjo.

Cada acción lleva una marca visible antes de pulsarla: ⚙ IAOps es determinista, ◆ IA local corre en el servidor de Oktavia sin enviar nada ni consumir tokens, y ✦ IA usa el modelo en la nube con su costo por consulta.

10. IA local y documentación

Argos responde con los datos de la red; la IA local le agrega lo que dice la documentación. Es un sistema de recuperación aumentada (RAG) que corre completo en el servidor de Oktavia del cliente: los modelos son abiertos y se sirven con Ollama —bge-m3 para los vectores y qwen2.5 de 7B para la respuesta, por omisión— y los vectores se guardan en la misma base PostgreSQL de la plataforma. Nada sale del servidor y no hay tokens por pregunta.

La versión comercial, con el diagrama del flujo y un video de Argos: IA local con el contexto de su empresa.

Cómo responde

• Sólo con lo recuperado. La respuesta se arma con los fragmentos recuperados y los cita: documento, sección y, en los PDF, página.
• Comandos sólo textuales. Un comando de configuración se acepta únicamente si aparece literal en un fragmento citado; no se inventa sintaxis.
• Alcance acotado. La pregunta se hace sobre un equipo, un sitio o toda la red, y la recuperación se limita a ese alcance.
• Los secretos nunca se indexan. Las líneas que mencionan comunidades, llaves o contraseñas se descartan, y el estándar de configuración se genera con los campos secretos enmascarados.
• Tiempo de respuesta. En CPU una respuesta toma alrededor de un minuto; con GPU es mucho más rápida.

Qué indexa

Kit de documentación

En Integraciones → IA local, una lista de nueve elementos dice qué documentación tiene la red y qué le falta. Una parte la genera Oktavia: el estándar de configuración desde la intención, qué audita cada regla de cumplimiento y la memoria técnica por sitio. Otra la escribe el equipo con plantillas en Markdown cuyas secciones «(obligatoria)» se validan al subir: estándar de diseño (HLD), runbooks de troubleshooting, procedimiento de cambios, política de seguridad de red, y circuitos y escalamiento con proveedores. El noveno son las guías del fabricante. El kit trae ejemplos llenos para tres redes de prueba: Cisco IOS hub-and-spoke, Cisco SD-WAN y multivendor con FortiGate, Junos y Cisco.

Dónde se usa

• Preguntas a Argos que empiezan con «según la documentación…».
• «Qué dice la documentación» por cada incidente del diagnóstico.
• «Cómo remediar · IA local» en cada CVE: lee el aviso del fabricante y extrae la corrección y las mitigaciones.

Buenas prácticas

• Curar las fuentes. Guías oficiales y vigentes para las versiones que corren en la red; un documento viejo o de terceros produce respuestas viejas o ajenas.
• PDF con texto. Un PDF escaneado no tiene texto que recuperar; se convierte antes de subirlo.
• Llenar las secciones obligatorias del kit. Son las que más preguntas responden y las que se validan al subir.
• Nombrar los runbooks por el síntoma («vecino BGP caído», «túnel sin tráfico»), que es como se pregunta durante un incidente.
• Regenerar la parte de Oktavia —estándar, reglas y memoria técnica— después de un cambio grande de diseño.
• Dimensionar. En CPU funciona y tarda alrededor de un minuto por respuesta; si se va a usar a diario, conviene una GPU.
• Escalar a la nube sólo de forma explícita. Pasar una pregunta al modelo en la nube es una acción visible, marcada con ✦ IA, y viaja un resumen acotado al equipo o sitio, no la base de documentos.
• Los secretos no se suben. El sistema descarta las líneas con credenciales, pero la buena práctica es que los documentos no las traigan.

11. Seguridad e inventario de servicios

Seguridad de red

Postura de seguridad calculada sobre la configuración recolectada de firewalls y switches, en cuatro dominios: perímetro, plano de gestión, identidades y segmentación. Cada hallazgo trae la línea de configuración que lo sustenta y su recomendación en la sintaxis del fabricante. Incluye puntaje global y por equipo, y filtros por dominio y severidad.

Vulnerabilidades por versión

La versión de software de cada equipo se cruza con NVD, CISA KEV y FIRST EPSS: primero lo que se está explotando activamente, con calificación por equipo, sitio y organización, la versión mínima segura por modelo que alimenta la norma de software, y un reporte de CVE imprimible por red o por sitio. Las imágenes de laboratorio se marcan como aproximadas y no cuentan como exposición real. Más en el artículo Seguridad en Oktavia y Argos.

Qué atender primero

Una lista de CVE no es una decisión. Argos cruza cada vulnerabilidad explotada o probable con la configuración activa del equipo —si la función vulnerable está encendida— y con su rol en la red, y la clasifica en actuar ya, planear, vigilar o confirmar versión. Un equipo de borde con la función expuesta va primero; uno interno con la función apagada, después. El puntaje va de 0 a 100, donde más es mejor, con bandas, y los CVE se filtran por sitio o por equipo.

Reporte de red PCI DSS por sitio

Para los sitios en alcance del entorno de datos de tarjetahabientes —los puntos de venta—, Oktavia arma el reporte de red de PCI DSS v4.0.1 sobre los requisitos 1, 2, 6.3.3, 7, 8 y 10. Cada requisito queda como cumple, no cumple o no evaluado, y sólo cuenta si la familia de fabricante del equipo tiene una verificación para él. Trae la evidencia por equipo y sale en PDF imprimible. Apoya el trabajo del QSA; no lo sustituye.

Remediación y parches de seguridad

• Cómo remediar. La IA local lee el aviso del fabricante y extrae la versión corregida y la mitigación.
• Cambio urgente. Queda como borrador en el Gemelo Digital, en la categoría «Parches de seguridad», con su tablero: propuesto, aprobado, aplicado, verificado cuando las líneas aparecen en el respaldo y corregido cuando el CVE desaparece.
• Declarar en el Configurador. Si la línea de mitigación es un campo del estándar —servidor HTTP apagado, SSH v2, VTY sólo por SSH, vistas SNMP, cifrado de contraseñas, modo de spanning-tree, nivel de logging—, se escribe en la intención del equipo y el cumplimiento la vigila desde entonces. Las líneas que llevan un secreto quedan pendientes para la bóveda.
• Flujo de parches de seguridad. Con un botón, o pidiéndole a Argos «prepara los parches de seguridad», toma los CVE explotados o críticos cuya función está encendida, prepara los borradores y las propuestas al estándar y avisa. Nunca aplica: la aprobación sigue siendo humana.

Estándar de hardening por rol

El estándar de seguridad se declara una vez, en el rol, y lo heredan todos los equipos con ese rol, los existentes y los nuevos: registro hacia el colector, SNMP de sólo lectura restringido, NTP, acceso de gestión sólo por SSH y servicios innecesarios apagados. Los demás alcances guardan sólo lo que varía por sitio o por equipo. El cumplimiento verifica lo que falta y, en Cisco IOS, también lo que sobra; el Gemelo Digital propone la corrección y una persona la aprueba.

Inventario de servicios

Responde la pregunta previa al cumplimiento: qué hay configurado en cada equipo, y cuánto de eso está declarado como intención. Cruza lo observado con lo declarado y con el catálogo de servicios, y clasifica cada servicio en cuatro estados, junto con el alcance de configuración que lo define.

Desde el propio inventario, los puntos ciegos se declaran como intención en un solo paso, sin tocar la red: sólo se empieza a auditar lo que ya estaba ahí.

12. Cobertura por fabricante

13. Integraciones

Oktavia se diseñó para convivir con el ecosistema del cliente, no para reemplazarlo. Puede alimentar y ser alimentada por las herramientas que ya están en operación.

Diferenciador de integración: Oktavia aporta la capa de intención y cumplimiento, el estándar contra el que se compara la red, que un tablero de métricas o un sistema de monitoreo tradicional no tienen. Ellos miden; Oktavia además valida contra un estándar y automatiza la respuesta.

14. Arquitectura y modelo de operación

La plataforma separa la interfaz web del motor de automatización. La interfaz concentra la experiencia de usuario, la organización por tenant y la persistencia; el motor ejecuta contra los dispositivos. Se comunican por una API REST autenticada con clave.

• Persistencia: base de datos relacional con separación de datos por tenant.
• Artefactos: JSON, CSV y archivos de configuración, descargables y versionables.
• Despliegue: contenedores orquestados, en las instalaciones del cliente o en nube privada.
• Acceso a los dispositivos: SSH, NETCONF y API nativa del fabricante, con credenciales cifradas en bóveda.

Modelo de operación

• Todo se ejecuta como trabajos asíncronos con historial completo.
• Cada trabajo produce artefactos versionables y descargables.
• Nunca se aplican cambios directos sin generar y validar artefactos primero.
• Las acciones de remediación son supervisadas y trazables, con aprobador identificado.

15. Seguridad de la plataforma

Oktavia tiene acceso de lectura y, cuando el cliente lo autoriza, de cambio sobre su red. Su propia seguridad es parte del alcance, no un anexo.

Dónde viven los datos

La plataforma se despliega en la infraestructura del cliente, en sus instalaciones o en su nube privada. El inventario, las configuraciones y los artefactos no salen de ahí. La única excepción es el análisis con inteligencia artificial: cuando se ejecuta una acción que consume el modelo, el contenido necesario para esa consulta viaja al proveedor de IA. Argos declara antes de cada acción si va a consumirlo, así que la decisión es del operador caso por caso, y las capacidades deterministas cubren la mayor parte del trabajo sin enviar nada. La IA local, marcada con ◆ IA local, corre en el mismo servidor y tampoco envía nada; su índice nunca guarda secretos.

Credenciales de los equipos

Se guardan cifradas en reposo en la base de datos, con una llave que vive en la configuración del despliegue y no en el código. No se muestran en la interfaz ni se escriben en los registros. Se recomienda usar credenciales de sólo lectura para el descubrimiento, y credenciales de cambio separadas, únicamente si va a haber remediación.

Acceso a la plataforma

Inicio de sesión obligatorio, con integración al proveedor de identidad corporativo. Sobre eso, una lista blanca de acceso por dirección IP o red, administrada desde la propia interfaz, con dos modos: monitor, que registra los rechazos sin bloquear, y estricto, que bloquea. El paso a estricto está protegido: no se puede activar si la dirección del propio operador no queda cubierta. La misma lista se aplica a la interfaz web y al motor de automatización.

Separación de datos

Multi-tenant con separación a nivel de registro: toda consulta va acotada a la organización del usuario. Los datos de un cliente no son alcanzables desde la sesión de otro, ni por error de programación.

Entre componentes

La interfaz web y el motor de automatización se autentican con clave en cada llamada, en las dos direcciones. El motor no expone ninguna operación sin ella.

Claves de API con alcance

Una integración externa nunca recibe la clave de la interfaz: recibe una clave propia, acotada a una organización, de lectura o de escritura y a una lista cerrada de operaciones. Se revoca sin tocar las demás.

Ningún cambio sin aprobación

Es también una propiedad de seguridad, no sólo de proceso: ninguna acción que escriba en la red ocurre sin que una persona la apruebe, y cada aplicación queda registrada con su aprobador, su diff y su artefacto.

Identidad corporativa y segundo factor

El inicio de sesión se integra con el proveedor de identidad del cliente por OpenID Connect. Oktavia soporta Okta, y con él el inicio de sesión único y el segundo factor que la política del proveedor ya exija: el alta, la baja y las contraseñas de los usuarios viven donde ya vive el directorio corporativo, sin un padrón paralelo que mantener. Las contraseñas locales quedan reservadas para contingencia.

La plataforma puede además exigir que la autenticación sea reciente, y no sólo que exista una sesión abierta en el proveedor: pedir un evento de autenticación fresco, restringir los métodos aceptados, por ejemplo llave de acceso, y exigir un nivel de aseguramiento concreto, como el de doble factor de Okta. Es lo que hace que cerrar el navegador vuelva a pedir el segundo factor.

16. Requisitos de integración

Para implementar Oktavia sobre una red existente pedimos al cliente:

• Inventario base de dispositivos.
• Lista de sitios y tipos de sitio.
• Roles operativos por dispositivo.
• Fabricante, plataforma y versión, si existe el dato.
• Direcciones de gestión y método de acceso.
• Credenciales de lectura para el descubrimiento.
• Credenciales de cambio, si va a haber remediación.
• Respaldos o configuración activa disponible.
• Estándares actuales de configuración.
• Restricciones operativas y ventanas de cambio.
• Aprobadores y contactos técnicos.

Datos mínimos por dispositivo

Identidad (nombre, dirección de gestión, sitio, rol), sistema operativo y modelo, interfaces, vecinos de descubrimiento de capa 2, vecinos BGP y OSPF si existen, configuración activa o respaldo, y los servicios operativos base: NTP, DNS, SNMP, SSH, banners y zona horaria.

Orden de preferencia para obtener los datos

1. API nativa del fabricante.
2. NETCONF, RESTCONF o llamadas a procedimiento remoto.
3. Analizadores estructurados del fabricante.
4. Análisis de salida de línea de comandos.
5. Configuración activa o respaldos.

Servidor para Oktavia

Oktavia se instala en un solo servidor Linux x86_64 (Ubuntu 22.04 o 24.04 LTS recomendado) con Docker y Docker Compose v2, físico o virtual, on-premise o en la nube del cliente. Las cifras son estimaciones para dimensionar la máquina: dependen del número de interfaces por equipo, de la frecuencia de auditoría y de cuánto tiempo se guarda la telemetría.

Oktavia Pro incluye inventario y descubrimiento, cumplimiento de configuración y estado, Gemelo Digital con remediación aprobada, respaldos y Argos.

Oktavia Pro con Telemetría y Orquestación de Eventos agrega la recolección SNMP cada 30 segundos, la recepción de syslog, la base de series de tiempo con 7 días de retención y el evaluador permanente de eventos.

Consideraciones

• El disco de telemetría crece con las interfaces por equipo y con la retención: guardar 30 días en lugar de 7 multiplica por cuatro esa parte.
• Los respaldos y resultados de auditoría crecen con la frecuencia de auditoría; la política de retención se acuerda en la implementación.
• Argos con un proveedor de IA en la nube no requiere recursos adicionales. La IA local requiere al menos 16 GB de RAM extra y, de preferencia, una GPU: en CPU una respuesta tarda alrededor de un minuto.
• Conectividad: el servidor necesita alcanzar la gestión de los equipos (SSH, HTTPS/API, NETCONF y SNMP según el fabricante) y recibir syslog (UDP 514) si se activa la telemetría. Los usuarios entran a la consola por HTTPS.

17. Proceso de implementación

1. Onboarding de datos. Recibir el inventario base, homologar nombres, roles, sitios, plataformas y modelos, y cargar el archivo inicial.
2. Descubrimiento controlado. Validar alcanzabilidad, ejecutar el descubrimiento por lotes, recolectar respaldos y normalizar el inventario observado.
3. Línea base de intención. Definir los servicios por alcance, cargar las variables de servicio, activar las verificaciones de cumplimiento y configurar el catálogo de servicios del cliente.
4. Validación. Correr la auditoría completa, revisar los tableros y ajustar reglas y excepciones.
5. Operación y remediación. Proponer el cambio, simularlo, aprobarlo, aplicarlo y recalcular el cumplimiento para confirmar el cierre.

Tiempo estimado hasta dejar Oktavia operativa

18. Licenciamiento

La plataforma completa es Oktavia Pro. La telemetría continua y la orquestación de eventos se licencian aparte porque tienen otro perfil de consumo, almacenan series de tiempo y corren un evaluador permanente, y no toda red las necesita desde el primer día.

Oktavia Pro

Descubrimiento multifabricante, inventario, cumplimiento de configuración y de estado, configuración deseada por equipo y por alcance, ciclo completo de remediación con Gemelo Digital, alta de servicios nuevos con su rollback, topología con trazado de rutas y análisis de políticas de firewall, seguridad de red, inventario de servicios, inteligencia IP, respaldos de configuración, reportes avanzados, provisioning, operaciones programadas, FinOps, multi-tenant y Argos completo con la IA local.

Telemetría y Orquestación de Eventos

Métricas en tiempo real, tableros de telemetría compatibles con Grafana, y el motor de automatización de eventos: reglas de condición a acción que reaccionan de forma automática ante caídas de sesión BGP, caídas de vecino OSPF, interfaces abajo y umbrales de CPU, memoria, temperatura y errores.

Incluido en toda licencia: soporte y actualizaciones

Mientras la licencia está vigente, cualquier instalación de Oktavia recibe los parches de seguridad, las actualizaciones y las funciones nuevas de la plataforma, sin costo adicional.

19. Casos de uso

• Auditoría de cumplimiento de configuración sobre múltiples sitios en minutos.
• Detección automática de desviación de configuración tras una ventana de mantenimiento.
• Generación de configuración deseada para dispositivos nuevos por rol y por sitio.
• Trazado de la ruta activa entre dos puntos con siguiente salto, interfaz de salida y detección de asimetría.
• Visibilidad de capacidad en interfaces de área amplia antes de la saturación.
• Validación de conectividad posterior al mantenimiento en toda la red.
• Control de cambios con diff entre configuración deseada y activa antes de aplicar.
• Onboarding de una red nueva con tipos de sitio y sitios configurados antes del primer descubrimiento.
• Postura de seguridad de firewalls con la evidencia de configuración que sustenta cada hallazgo.
• Descubrir qué servicios están configurados y nadie audita, y declararlos sin tocar la red.
• Saber si un flujo pasa: qué política de firewall lo decide en cada salto, con su traducción de direcciones y su registro.
• Ubicar una dirección IP hasta el puerto de acceso cruzando la tabla ARP con la tabla MAC.
• Adoptar la configuración que un equipo ya tiene como intención declarada, para empezar a auditarla sin rediseñar nada.
• Corregir una desviación de punta a punta: proponer, aprobar, aplicar y verificar que cerró.
• Levantar un túnel entre dos sitios con sus rutas, y darlo de baja completo cuando el proyecto termina.
• Publicar una red nueva en OSPF y BGP de los equipos de borde del sitio, con verificación por ping incluida.
• Preguntar qué dice el runbook o la guía del fabricante durante un incidente, con la cita, sin que la documentación salga del servidor.
• Preparar el reporte de red PCI DSS de los puntos de venta, con evidencia por equipo, para la revisión del QSA.
• Llevar los CVE explotados con la función encendida a parches de seguridad listos para aprobar, y verificar que el CVE desapareció.