Ir al contenido
Aramis:Insight

Roles

Arquitecto de Seguridad

Dibuja el plano: cómo encajan identidad, red y protección de datos.

Áreas de competencia

  • Arquitectura de Ciberseguridad
  • Planeación de Requisitos de Sistemas
  • Arquitectura Empresarial

Aramis:Current Daily

Una lista breve de lectura para un Arquitecto de Seguridad, de menos de 30 minutos por edición.

2026-09-19. 9 minutos en total

  1. La IA acelera a los adversarios y transforma la superficie de ataque [Informes de CrowdStrike y Mandiant 2026]

    Segu-Info, 2026-09-18. Leer, 9 min.

    Por qué importa para este rol: La distancia entre cinco días hasta el exploit y cuarenta y tres hasta el parche es un dato de diseño, no de operación. Identifique qué servicios expuestos a internet no sobrevivirían a esa ventana y proponga reducir su exposición o aislarlos, en vez de prometer que el parcheo irá más rápido.

    Corrección del 2026-09-21: Una versión anterior atribuía a Mandiant los 43 días de parcheo y el 31% de las brechas. El artículo atribuye esas dos cifras al Verizon DBIR 2026 y precisa que los 43 días son la mediana para vulnerabilidades con explotación conocida. La atribución se corrigió el 2026-09-21 sin nota, y esta la registra.

Preguntas de muestra

Tres preguntas reales de la evaluación de este rol, con la respuesta, el razonamiento y el enunciado NICE que cada una mide. La evaluación completa se nutre de cientos como estas.

Pregunta de muestra 1

Hace seis meses, Ferrow Retail implementó una nueva arquitectura de gateway de API específicamente para detener los ataques de credential stuffing contra el endpoint de inicio de sesión de sus clientes, combinando device fingerprinting, limitación de tasa de solicitudes (rate limiting) y desafíos de MFA escalonados con base en el riesgo. El vicepresidente de Ingeniería desea saber si el diseño realmente está funcionando antes de comprometer presupuesto para expandirlo a otras áreas. Como arquitecto de seguridad, ¿qué enfoque determina mejor la efectividad del diseño?

  1. A.Confirmar que la configuración del gateway en producción coincide con el documento de diseño original, verificando que el device fingerprinting, el rate limiting y el MFA escalonado estén habilitados exactamente como se especificó en el diseño.
  2. B.Revisar la telemetría de inicios de sesión en busca de actividad de credential stuffing bloqueada e intentada, así como las tasas de apropiación de cuentas antes y después de la implementación, y ejecutar una prueba adversarial controlada que replique técnicas conocidas de credential stuffing contra el gateway.
  3. C.Encuestar al equipo de ingeniería que construyó el gateway sobre su confianza en que previene el credential stuffing, dado que ellos implementaron los controles y conocen mejor el modelo de amenazas.
  4. D.Comparar el conjunto de controles implementado por Ferrow contra la lista de verificación publicada por un proveedor con las funciones recomendadas contra el credential stuffing, para confirmar que cada capacidad listada esté presente en la implementación.
Ver la respuesta y el razonamiento

Respuesta correcta: B

La opción B es correcta porque mide resultados reales, telemetría de ataques, cambios en la tasa de toma de control de cuentas y pruebas adversariales. Esto es lo que se requiere para determinar la eficacia, en lugar de limitarse a confirmar la intención. La opción A es incorrecta porque comparar la configuración implementada con el documento de diseño solo confirma que los controles están presentes, no que funcionen contra tráfico real de ataques. Esta es la trampa clásica de verificar la intención del diseño en lugar del resultado. La opción C es incorrecta porque la confianza declarada por quienes construyeron los controles es subjetiva y carece de validación empírica. La opción D es incorrecta porque una lista de verificación del proveedor mide la integridad general de las funciones, no la eficacia frente a los atacantes y el tráfico específicos de Ferrow.

Esta pregunta mide: T1426: Determine cybersecurity design and architecture effectiveness

Pregunta de muestra 2

Vantage Payments está diseñando una nueva funcionalidad de pagos instantáneos que involucra cinco microservicios internos, un procesador de tarjetas externo y dos almacenes de datos internos que contienen datos de tarjetahabientes. El documento de diseño presentado para la revisión de arquitectura consta de doce páginas de prosa que describen las responsabilidades de cada servicio, sin ningún diagrama. Durante la revisión, dos revisores ya discrepan sobre cuál servicio es responsable de cifrar los datos de tarjetahabientes en tránsito entre dos de los servicios internos, e incluso sobre si ese tráfico en particular cruza o no un límite de confianza. El arquitecto de seguridad debe decidir qué exigir antes de que el diseño avance a la construcción. ¿Cuál requisito refleja una aplicación correcta del conocimiento de modelado de diseño?

  1. A.Aceptar el documento de diseño tal como fue presentado, ya que los dos revisores que discrepan sobre la responsabilidad del cifrado y el cruce del límite pueden resolver ambas cuestiones comparando las declaraciones de responsabilidades ya escritas para cada uno de los dos servicios en las doce páginas de prosa, sin necesidad de producir ningún diagrama
  2. B.Exigir al equipo que produzca un diagrama de secuencia UML que trace el orden exacto de las llamadas entre los dos servicios en disputa, ya que el servicio que aparezca emitiendo la llamada de cifrado en esa secuencia queda con ello establecido como el servicio responsable de proteger los datos en ese límite
  3. C.Exigir al equipo que produzca un diagrama de flujo de datos que muestre cada almacén de datos y cada flujo entre servicios y hacia el exterior, con los límites de confianza marcados, ya que el cruce de un límite es una propiedad del propio flujo de datos, y marcarlo muestra cuál servicio debe proteger los datos en ese punto sin importar el orden de las llamadas
  4. D.Exigir al equipo que produzca un diagrama de topología de red que muestre en qué subred se ubica cada servicio, ya que dos servicios colocados en subredes distintas quedan con ello mostrados como cruzando un límite de confianza, lo cual resuelve tanto si existe un límite como cuál lado carga con la responsabilidad de protección
Ver la respuesta y el razonamiento

Respuesta correcta: C

El desacuerdo no se refiere al orden de las llamadas ni a la ubicación en la red, sino a si existe un límite de confianza en una ruta de datos específica y quién es responsable de la protección en ese punto. Esto es precisamente lo que debe mostrar un diagrama de flujo de datos con los límites de confianza señalados: enumera todos los almacenes de datos y todos los flujos entre servicios y hacia el exterior. El cruce de un límite es una propiedad del propio modelo de flujo, por lo que marcarlo determina qué servicio debe proteger los datos en ese punto, independientemente de cuál servicio llame primero a otro. Aceptar el texto tal como fue presentado es incorrecto porque el desacuerdo persistió después de leer las doce páginas completas. Las responsabilidades de cada servicio se describieron de forma aislada, de modo que el documento nunca modeló la relación entre servicios donde realmente existe la controversia. Volver a comparar las mismas declaraciones aisladas reproduciría el desacuerdo en lugar de resolverlo. La opción B, el diagrama de secuencia UML, parte de una inferencia razonable, pero equivocada: seguir el orden exacto de las llamadas mostraría qué servicio invoca una rutina de cifrado, pero el orden de invocación es un detalle de implementación, no una decisión de diseño de seguridad. Un servicio puede llamar a otro sin que esa llamada coincida con el cruce de un límite de confianza. Por ello, identificar a quien realiza la llamada no establece quién es responsable de proteger los datos en el límite. La opción D, el diagrama de topología de red, confunde la segmentación de red con los límites de confianza. Dos servicios ubicados en subredes distintas no están separados automáticamente por un límite de confianza en el nivel de la aplicación, y dos servicios en la misma subred pueden tener dicho límite. Los límites de confianza se definen por diferencias de privilegios o sensibilidad de los datos, no por la ubicación física o lógica en la red. Por ello, un diagrama de topología podría dejar sin resolver la controversia aun después de elaborarse.

Esta pregunta mide: K1086: Knowledge of design modeling

Pregunta de muestra 3

La plataforma clínica de intercambio de archivos del Fairview Regional Hospital permite que quien sube un expediente de paciente decida quién más puede verlo o editarlo. El personal clínico de primera línea, buscando que los equipos de atención avancen con rapidez, agrega de manera rutinaria a 'todo el departamento' como lector en expedientes que contienen información de salud protegida, de modo que un expediente destinado a un equipo de atención de cinco personas termina visible para cuarenta clínicos sin ningún papel en la atención de ese paciente. La composición de los equipos de atención cambia de un turno a otro conforme los pacientes se entregan en los relevos, y la dirección del hospital no creará un puesto cuya única función sea clasificar y reclasificar manualmente el nivel de sensibilidad de cada expediente conforme ocurren esos relevos. Se solicita a un arquitecto de seguridad que recomiende un modelo de control de acceso que elimine la capacidad de cada persona que sube archivos de decidir individualmente qué tan ampliamente se comparte un expediente, y que al mismo tiempo otorgue a los integrantes legítimos del equipo de atención el acceso que necesitan, sin clasificación manual expediente por expediente. ¿Qué modelo debe recomendar el arquitecto?

  1. A.Un modelo mandatorio en el que el expediente del paciente específico hereda un nivel de sensibilidad fijo y cada clínico posee un nivel de autorización permanente asignado al momento de su contratación, de modo que la plataforma otorga el acceso automáticamente siempre que el nivel de autorización del clínico iguale o supere el nivel de ese expediente.
  2. B.Un modelo basado en atributos en el que el acceso al expediente del paciente específico se otorga automáticamente a cualquier clínico cuya unidad de atención y turno actuales coincidan con la unidad de atención y el turno registrados en ese expediente, sin ninguna decisión al momento de la carga por parte de individuo alguno.
  3. C.Un modelo basado en roles en el que el acceso sigue el rol que cada clínico tiene asignado dentro del equipo de atención del paciente específico, como médico tratante o enfermero del equipo de atención, de modo que el expediente resulta visible automáticamente para quien ocupe en ese momento el rol correspondiente en el equipo de atención de ese paciente.
  4. D.Un modelo en el que cada paciente cuenta con un grupo de acceso permanente para su equipo de atención, que un coordinador de unidad mantiene manualmente, agregando y retirando clínicos conforme el personal rota para entrar y salir de la atención del paciente específico a lo largo de turnos sucesivos.
Ver la respuesta y el razonamiento

Respuesta correcta: C

El control de acceso basado en roles, vinculado al rol del equipo de atención de un paciente específico, permite que el expediente clínico sea visible para quienes ocupan actualmente ese rol y deje de serlo cuando terminan su rotación. Debido a que las asignaciones de roles se determinan mediante los registros de entrega de turno que los equipos de atención ya generan en cada cambio de turno, el modelo da seguimiento automáticamente a esas entregas y elimina toda decisión discrecional sobre el uso compartido sin crear una nueva obligación administrativa. El modelo obligatorio de niveles de autorización concede acceso a todos los profesionales clínicos cuyo nivel cumpla con el nivel del expediente, mucho más allá del equipo de atención asignado, y los niveles establecidos al momento de la contratación no pueden seguir a los equipos que se reorganizan en cada turno. El modelo basado en atributos que establece coincidencias por unidad de atención y turno concede acceso a todas las personas de esa unidad durante el turno, en lugar de limitarlo al equipo de atención reducido, lo que reproduce la exposición excesiva mediante atributos demasiado generales. El grupo de atención seleccionado manualmente define el alcance correcto, pero vuelve a introducir precisamente el mantenimiento manual separado y por paciente para el cual la dirección se negó a asignar personal; por ello, se rezaga con cada entrega de turno y no es escalable.

Esta pregunta mide: K0880: Knowledge of access control models and frameworks

Plantillas de descripción de puesto

Tres borradores listos para editar, pensados para gerentes de contratación y reclutadores: copie uno, reemplace las líneas entre corchetes y publíquelo. Las responsabilidades y los requisitos provienen de los mismos enunciados NICE frente a los que se mide este rol.

Los enunciados usan la redacción oficial del marco NICE, que se publica en inglés.

Arquitecto de Seguridad: Junior

Buscamos un Arquitecto de Seguridad junior. Dibuja el plano: cómo encajan identidad, red y protección de datos. En este nivel se hará cargo de partes bien delimitadas del trabajo, con colegas senior de quienes aprender, y crecerá hacia el resto del rol.

[Empresa] se dedica a [lo que hacen]. La función de seguridad es [tamaño y estructura: p. ej., un equipo de cinco personas que reporta al CTO]. Reemplace este párrafo con el suyo.

Responsabilidades

  • Translate proposed capabilities into technical requirements
  • Communicate enterprise information technology architecture
  • Integrate organizational goals and objectives into security architecture
  • Determine essential system capabilities and business functions
  • Prioritize essential system capabilities and business functions
  • Determine cybersecurity design and architecture effectiveness
  • Create cybersecurity architecture functional specifications
  • Develop enterprise architecture
  • Trabajar en pareja con colegas senior y crecer mediante retroalimentación estructurada.
  • Documentar su trabajo para que el equipo aprenda con usted.

Conocimientos requeridos

  • Design modeling
  • Information technology (IT) architecture models and frameworks
  • Policy-based access controls
  • Enterprise architecture (EA) reference models and frameworks
  • Access control models and frameworks
  • Microprocessors
  • Technology integration processes
  • System optimization techniques

Habilidades

  • Designing the integration of hardware solutions
  • Designing the integration of software solutions
  • Identifying gaps in technical capabilities
  • Assessing security systems designs
  • Applying secure coding techniques

Cómo usar esta plantilla

Copie el borrador, reemplace cada línea entre corchetes, elimine los enunciados que no apliquen a su vacante y agregue rango de compensación y política de ubicación. Las listas de enunciados provienen del marco NICE v2.2.0 del NIST, de modo que los candidatos pueden evaluarse frente a los mismos enunciados con Aramis:Insight.

Arquitecto de Seguridad: Nivel medio

Buscamos un Arquitecto de Seguridad de nivel intermedio. Dibuja el plano: cómo encajan identidad, red y protección de datos. Será responsable de este trabajo en el día a día y colaborará de cerca con el resto del equipo de seguridad.

[Empresa] se dedica a [lo que hacen]. La función de seguridad es [tamaño y estructura: p. ej., un equipo de cinco personas que reporta al CTO]. Reemplace este párrafo con el suyo.

Responsabilidades

  • Translate proposed capabilities into technical requirements
  • Communicate enterprise information technology architecture
  • Integrate organizational goals and objectives into security architecture
  • Determine essential system capabilities and business functions
  • Prioritize essential system capabilities and business functions
  • Determine cybersecurity design and architecture effectiveness
  • Create cybersecurity architecture functional specifications
  • Develop enterprise architecture
  • Translate functional requirements into technical solutions
  • Review enterprise information technology (IT) goals and objectives
  • Assess the organization's cybersecurity architecture
  • Determine functional requirements and specifications

Conocimientos requeridos

  • Design modeling
  • Information technology (IT) architecture models and frameworks
  • Policy-based access controls
  • Enterprise architecture (EA) reference models and frameworks
  • Access control models and frameworks
  • Microprocessors
  • Technology integration processes
  • System optimization techniques
  • Computer networking protocols
  • Risk management processes
  • Cybersecurity laws and regulations
  • Cybersecurity policies and procedures

Habilidades

  • Designing the integration of hardware solutions
  • Designing the integration of software solutions
  • Identifying gaps in technical capabilities
  • Assessing security systems designs
  • Applying secure coding techniques
  • Analyzing an organization's enterprise information technology architecture
  • Communicating complex concepts
  • Communicating verbally

Cómo usar esta plantilla

Copie el borrador, reemplace cada línea entre corchetes, elimine los enunciados que no apliquen a su vacante y agregue rango de compensación y política de ubicación. Las listas de enunciados provienen del marco NICE v2.2.0 del NIST, de modo que los candidatos pueden evaluarse frente a los mismos enunciados con Aramis:Insight.

Arquitecto de Seguridad: Senior

Buscamos un Arquitecto de Seguridad senior. Dibuja el plano: cómo encajan identidad, red y protección de datos. Definirá la dirección de este trabajo, guiará a quienes lo hacen y responderá por sus resultados.

[Empresa] se dedica a [lo que hacen]. La función de seguridad es [tamaño y estructura: p. ej., un equipo de cinco personas que reporta al CTO]. Reemplace este párrafo con el suyo.

Responsabilidades

  • Translate proposed capabilities into technical requirements
  • Communicate enterprise information technology architecture
  • Integrate organizational goals and objectives into security architecture
  • Determine essential system capabilities and business functions
  • Prioritize essential system capabilities and business functions
  • Determine cybersecurity design and architecture effectiveness
  • Create cybersecurity architecture functional specifications
  • Develop enterprise architecture
  • Translate functional requirements into technical solutions
  • Review enterprise information technology (IT) goals and objectives
  • Assess the organization's cybersecurity architecture
  • Determine functional requirements and specifications
  • Oversee the development of design solutions
  • Develop systems design procedures and processes
  • Develop cybersecurity designs for systems and networks with multilevel security requirements
  • Develop cybersecurity designs for systems and networks that require processing of multiple data classification levels
  • Guiar a los miembros junior del equipo y revisar su trabajo.
  • Representar esta función ante la dirección y ante auditores o clientes.
  • Definir estándares, seleccionar herramientas y ser responsable de la hoja de ruta de esta área.

Conocimientos requeridos

  • Design modeling
  • Information technology (IT) architecture models and frameworks
  • Policy-based access controls
  • Enterprise architecture (EA) reference models and frameworks
  • Access control models and frameworks
  • Microprocessors
  • Technology integration processes
  • System optimization techniques
  • Computer networking protocols
  • Risk management processes
  • Cybersecurity laws and regulations
  • Cybersecurity policies and procedures
  • Privacy laws and regulations
  • Privacy policies and procedures

Habilidades

  • Designing the integration of hardware solutions
  • Designing the integration of software solutions
  • Identifying gaps in technical capabilities
  • Assessing security systems designs
  • Applying secure coding techniques
  • Analyzing an organization's enterprise information technology architecture
  • Communicating complex concepts
  • Communicating verbally
  • Communicating in writing
  • Applying secure network architectures

Cómo usar esta plantilla

Copie el borrador, reemplace cada línea entre corchetes, elimine los enunciados que no apliquen a su vacante y agregue rango de compensación y política de ubicación. Las listas de enunciados provienen del marco NICE v2.2.0 del NIST, de modo que los candidatos pueden evaluarse frente a los mismos enunciados con Aramis:Insight.

Roles relacionados

Roles con trabajo parecido o en una etapa de carrera similar. Cada uno tiene sus propias plantillas de descripción de puesto y una evaluación gratuita.