Cómo evaluar ingenieras de ciberseguridad: la forma correcta
La trampa del hiring de seguridad
La mayoría evalúa talento de ciberseguridad igual que cualquier ingeniera: tests de código y trivia. Una ingeniera de seguridad escribe código. Debería ser buena en algoritmos y system design. Pero si contratas basado solo en eso, te pierdes la señal real de seguridad — y terminas con ingenieras smart que no saben pensar sobre amenazas.
El fix es construir evaluación que mida lo que las ingenieras de seguridad realmente hacen: threat modeling, razonamiento de trade-offs y juicio arquitectónico.
Tres componentes de evaluación que funcionan
1. Escenario de threat modeling (30 min, take-home)
El formato: describe un sistema (e.g., "una web app para scheduling de salud con autenticación, calendar sharing y recordatorios de cita por SMS"). Pide a la candidata identificar los top 3 riesgos de seguridad, rankearlos por severidad y explicar la mitigación del más alto.
Qué mides:
- ¿Pueden pensar desde perspectiva de atacante?
- ¿Consideran toda la attack surface?
- ¿Pueden rankear riesgo por likelihood e impacto, no por fear factor?
- ¿Sus mitigaciones son prácticas o teóricas?
Qué es buena respuesta: No "asegúrate de usar HTTPS y queries parameterizadas" — todo el mundo sabe eso. Una buena respuesta luce como: "El riesgo más alto es interceptación de SMS para recordatorios porque el canal SMS no está encriptado y un atacante con acceso SMS puede reschedule citas o leer nombres de pacientes. Mitigación: no envíes identificadores de paciente en SMS, solo un código que usen para lookup local. Segundo riesgo: calendar sharing no autorizado si la lógica no valida ownership correctamente. Tercero: credential stuffing en login — implementa rate-limiting per IP y per username, ofrece passwordless sign-in."
Esa respuesta es específica, fundamentada en el sistema actual y distingue entre riesgo inevitable y prevenible.
2. Code review + juicio de vulnerability (45 min)
Presenta un snippet de código realista con un flaw de seguridad enterrado. Ejemplos:
Snippet Python con riesgo SQL injection:
query = f"SELECT * FROM users WHERE email = '{email}'" # Flagged como malo
Pero pregunta: "¿Cuál es el riesgo real aquí?" Una candidata que dice "SQL injection" técnicamente acierta pero está incompleta. Una que dice "SQL injection, sí, pero solo si el email no se valida primero — ¿cuál es la validación?" piensa como ingeniera de seguridad.
3. Evaluación de arquitectura: defense-in-depth (60 min)
Dales un problema de arquitectura: "Diseña la capa de autenticación para una plataforma con APIs públicas y privadas, donde un compromise de token es catastrófico. Defiende tus elecciones."
Qué mides:
- ¿Layerean defensas (tokens + rate-limiting + IP restrictions)?
- ¿Pueden explicar por qué un control único no basta?
- ¿Piensan sobre detección y recuperación, no solo prevención?
Cómo ponderar la evaluación
Para generalista de seguridad:
- 40% threat modeling
- 30% code review
- 30% arquitectura
El follow-up importa
La evaluación async te da señal pero no es completa. En follow-up: "Recórreme tu threat model. ¿Qué se te perdió? ¿Qué reconsiderarías?" "¿Cómo explicarías esta mitigación a una ingeniera que dice 'eso es overkill'?" "Cuéntame de cuando tuviste que balancear seguridad y velocidad."
Qué NO evaluar
- OWASP Top 10 memorizado (lo pueden googlear)
- Trivia "qué cipher es mejor" (context-dependent)
- Velocidad resolviendo LeetCode (no relevante)
- Pasar una cert específica (certs son piso, no techo)
Construir vs comprar
Algunas plataformas ofrecen evaluaciones pre-construidas. Son punto de partida. Pero las mejores evaluaciones están customizadas a tu rol y threat model. Compra plataforma; construye preguntas.
ClarityHire ofrece evaluaciones de seguridad customizables con salas de coding live, file uploads para diagramas de arquitectura y evaluación multi-stage.
El outcome
Evalúa razonamiento de amenaza, no trivia, y contratarás ingenieras que piensan defensivamente por default. Esas ingenieras se vuelven multiplicadores de fuerza — influencian toda tu cultura ingenieril hacia decisiones security-first.
Esa es la contratación que importa.