Gobierno de seguridad
Por qué existe este diario
Hay demasiado contenido de seguridad explicando qué hay que hacer y casi ninguno contando qué pasa cuando lo intentas. Esto es lo segundo: los casos, las decisiones y los errores de un CISO, con la parte incómoda incluida.
TL;DR
Publico los problemas reales del rol (presupuesto, directorio, equipos, decir que no) en primera persona y con el error incluido. Cada caso es una composición anonimizada: la lección es literal, los detalles identificables no. Un expediente cada dos semanas.
Busque «gestión de vulnerabilidades» y encontrará diez mil artículos sobre qué hay que hacer. Busque qué ocurre cuando lo intenta con el presupuesto que realmente tiene, el equipo que realmente tiene y un director comercial que prometió una fecha, y encontrará muy poco.
Este diario es lo segundo.
Lo que va a leer aquí#
Escribo en primera persona sobre las decisiones que tomo y sobre las que me salieron mal. No sobre marcos, salvo cuando el marco es el problema.
Para el directorio
Si dirige una organización y su CISO nunca le ha traído un error propio, no tiene un CISO prudente: tiene uno que ha aprendido que traerle malas noticias sale caro. Eso es un problema de incentivos suyo, no de carácter de esa persona.Cinco temas se repiten, y son las cinco categorías del sitio:
| Categoría | De qué va |
|---|---|
| Gobierno de seguridad | Programas, políticas y métricas que sobreviven al segundo año |
| AppSec | Ciclo de desarrollo, remediación y la distancia entre detectar y arreglar |
| Gestión de riesgo | Aceptación, excepciones y lo que pasa cuando caducan |
| Comunicación con el directorio | Traducir riesgo técnico a una decisión que alguien firma |
| Liderazgo y equipos | Construir, sostener y a veces reconstruir |
Cómo trato los casos reales#
Esta es la parte que más me ha costado resolver, y la que más me importa.
Escribir sobre incidentes reales tiene un problema evidente: las organizaciones donde ocurrieron confiaron en mí. La solución fácil sería escribir en abstracto, pero entonces el texto pierde exactamente lo que lo hace útil.
Cada caso es una composición. Mezclo varios incidentes de organizaciones distintas y cambio sector, tamaño y fechas. La decisión, el error y la lección quedan intactos; los detalles identificables desaparecen.
En la práctica
La regla que aplico antes de publicar: que el director general de cualquiera de esas organizaciones pueda leer el artículo sin reconocerse. Si dudo, no se publica. He descartado tres borradores por esto.Una advertencia sobre lo que aquí se cuenta#
Todo artículo lleva una etiqueta TLP en su cabecera. No es decoración: es el mismo estándar de FIRST que usamos para compartir inteligencia de amenazas, y aquí indica cuánto puede circular lo que ha leído.
Riesgo
Un artículo marcadoTLP:AMBER describe patrones que siguen siendo explotables
en muchas organizaciones. Compartirlo fuera de un círculo profesional no ayuda
a nadie y sí orienta a quien no debería estar orientado.Cada entrada lleva también un nivel de severidad, que no mide la gravedad técnica sino cuánto duele la lección:
Baja Media Alta Crítica
De dónde viene el formato#
Llevo años tomando notas después de cada comité y cada incidente. Este sitio es esa libreta, ordenada y publicable. De ahí el vocabulario: expedientes numerados, clasificación, severidad y cronologías.
La libreta
Empiezo a anotar después de cada comité qué pregunté, qué me preguntaron y qué debería haber dicho.El patrón
Al releer tres años de notas, los mismos cuatro problemas aparecen en organizaciones que no tienen nada que ver entre sí. No eran mis circunstancias: era el rol.Este diario
Publico el primer expediente.
La matriz que va a ver a menudo#
Aparece en casi todos los comités de riesgo, y en casi todos por el motivo equivocado. Volveré sobre ella más de una vez.
| Insignificante | Menor | Moderado | Mayor | |
|---|---|---|---|---|
| Casi seguro | Media | Alta | Crítica | Crítica |
| Probable | Baja | Media | Alta | Crítica |
| Posible | Baja | Media | Media, posición de este caso | Alta |
| Improbable | Baja | Baja | Media | Alta |
El día que entendí que mi trabajo no era evitar incidentes fue el día que empecé a hacerlo bien.
Lo que no va a encontrar#
Ni resúmenes de noticias, ni listas de herramientas, ni análisis del CVE de la semana. Eso ya lo hace mucha gente y lo hace mejor.
Tampoco encontrará anuncios, seguimiento ni recursos de terceros. Este sitio no carga nada de fuera: ni tipografías externas, ni analítica, ni incrustaciones. Si el sitio de alguien que escribe sobre seguridad no puede sostener eso, es una mala carta de presentación.
# Lo que el navegador recibe al pedir cualquier página de este sitio.
# «default-src 'none'» significa: nada está permitido salvo lo que se declare.
Content-Security-Policy "default-src 'none'; script-src 'self' 'wasm-unsafe-eval';
style-src 'self'; img-src 'self'; font-src 'self'; connect-src 'self';
base-uri 'none'; frame-ancestors 'none'; object-src 'none'"Error común
El error que quiero no cometer con este blog es el más común del sector: escribir para impresionar a otros técnicos en lugar de para ser útil a quien tiene que decidir. Si un artículo no termina en algo que usted pueda hacer el lunes, me he equivocado.Cadencia#
Un expediente cada dos semanas. Prefiero publicar menos y que cada entrada aguante una relectura dentro de un año.
Lección aprendida
Casi todo lo que he aprendido de este oficio lo aprendí después de que algo saliera mal, y casi nada de ello estaba en un curso. Escribirlo es la única forma que conozco de que le sirva a alguien más sin que tenga que pagar el mismo precio.Bienvenido.