Antes de aprender nombres, aprende a preguntar
Code Cyber no es una colección de definiciones para memorizar ni una promesa de que un producto, una empresa o una persona pueda volverse «segura» al terminar una lectura. Es una ruta para aprender a formular afirmaciones acotadas sobre sistemas, mecanismos, pérdidas posibles y evidencia. La primera habilidad no es recordar una sigla: es poder decir qué sistema estás mirando, qué cambio te interesa, qué parte observaste y qué todavía no sabes.
Una persona que usa un teléfono ya interactúa con sistemas complejos. Escribe un mensaje, pulsa enviar y ve una confirmación. Entre esas acciones hay una aplicación, un sistema operativo, una conexión, uno o más servicios remotos, cuentas, datos almacenados y decisiones de interfaz. El objetivo de este capítulo es darte un mapa para seguir esa cadena sin exigir terminal, programación ni matemáticas avanzadas. El mapa será deliberadamente pequeño. Un mapa de una ciudad no representa cada tubería; permite elegir una ruta y saber qué información falta.
La obra comienza en la Parte 0 porque los capítulos posteriores usan palabras que parecen cotidianas pero tienen límites técnicos: sistema, proceso, servicio, identidad, permiso, versión, dato y evidencia. El glosario de NIST define autenticación como verificación de identidad y autorización como permiso de acceso (NIST CSRC Glossary, Authentication, Authorization); aquí no resolveremos todavía sus protocolos. Tampoco veremos aún cómo se protege una clave o cómo se valida un incidente. Aprenderemos a reconocer dónde comienzan esas preguntas y a no contestarlas antes de tener un modelo.
Qué promete la ruta y qué no promete
Code Cyber enseña a construir y criticar modelos. En ingeniería de sistemas, el sistema se analiza junto con sus elementos, contexto y ciclo de vida (NIST SP 800-160 Vol. 1 Rev. 1, §§2.1 y 3); aquí lo convertimos en una regla pedagógica: un modelo es una representación seleccionada para responder una pregunta, no el sistema completo. Si el objetivo es saber por qué un mensaje tardó, importan la aplicación, el camino, los servicios y los tiempos. Si el objetivo es saber quién pudo leerlo, importan otras fronteras, claves, copias, cuentas y operadores. La misma aplicación puede ser el sistema entero para una pregunta de uso y un componente para una pregunta de seguridad.
Por eso cada afirmación de la obra debería poder completarse con «en qué sistema, versión, condiciones, horizonte y evidencia». «La aplicación es segura» carece de esos referentes. «La aplicación de teléfono 5.4 conserva la sesión después de cerrar la ventana durante esta prueba» es una afirmación más estrecha, que se puede observar y discutir. Que una afirmación sea estrecha no la hace débil: la vuelve revisable.
La ruta tampoco convierte una lectura en autorización para actuar sobre sistemas ajenos. Entender un mecanismo no concede permiso para probarlo. Los ejercicios usan situaciones sintéticas, observación y razonamiento; no piden explorar servicios reales ni recolectar datos personales. Más adelante, los capítulos de la Parte I enseñarán a separar autorización, alcance, observación, evidencia e incertidumbre. Aquí sólo construiremos las preguntas que permitirán leerlos.
Al terminar este capítulo no deberías afirmar que conoces una red, una identidad o una vulnerabilidad sólo porque puedes nombrarla. Deberías poder decir qué pieza falta para justificar esa afirmación. Esa diferencia entre reconocer y razonar será una regla de estudio para toda la obra.
El caso conductor: un mensaje desde el teléfono
Usaremos un caso sencillo que cambiará de escala a medida que avance la Parte 0. Ana escribe «llego a las seis» en una aplicación de mensajería de su teléfono y pulsa enviar. La aplicación muestra un indicador de envío; unos segundos después, el teléfono de Bruno muestra una notificación. Nuestro primer modelo no necesita conocer la marca del teléfono, el proveedor de nube ni el protocolo concreto. Necesita distinguir los participantes y las transiciones.
Podemos nombrar provisionalmente: teléfono de Ana, aplicación cliente, sistema operativo, conexión de red, servicio de mensajería, almacenamiento del servicio, aplicación y teléfono de Bruno. Hay también personas, cuentas y operadores, pero no los fusionaremos con dispositivos. En la arquitectura web, un recurso y su representación no son la misma cosa (W3C Web Architecture, §§2–3); el teléfono es un dispositivo físico; la aplicación es un programa instalado; el servicio remoto es un sistema que acepta mensajes y produce respuestas; la notificación es una representación visible de un cambio, no el mensaje completo observado en todos los lugares.
La primera pregunta es «¿qué pasó para que la interfaz mostrara enviado?». Una explicación posible es que el cliente entregó una petición al servicio y recibió una respuesta aceptada. HTTP define los roles cliente/servidor relativos a una interacción, no una garantía de que una etiqueta de interfaz represente almacenamiento o lectura (RFC 9110, §§3, 3.3, 5, 9 y 15). Otra posibilidad es que la aplicación guardó el mensaje localmente y está esperando red. Ambas pueden producir una marca parecida. La pantalla no nos permite elegir sin preguntar por el estado y la comunicación. El texto visible es una observación de interfaz; «Bruno ya lo recibió» es una afirmación adicional.
En la segunda vuelta preguntamos dónde puede existir el contenido. Puede estar temporalmente en memoria del proceso, en una cola local, en una petición en tránsito, en almacenamiento del servicio, en una copia de recuperación o en el teléfono de Bruno. No afirmamos que exista en todos esos lugares: enumeramos posibilidades que el modelo debe adjudicar. Cerrar la aplicación no significa automáticamente borrar cada copia; recibir una notificación no demuestra que la persona haya leído el contenido.
En la tercera vuelta preguntamos qué relación une las acciones. Un nombre de contacto no es necesariamente una identidad técnica; una cuenta no es necesariamente una persona presente; una dirección de red no es necesariamente un dispositivo estable. Estas distinciones aparecerán en capítulos posteriores. En este capítulo sólo sirven para impedir que el primer dibujo convierta una etiqueta de interfaz en una explicación total.
El caso evoluciona, pero no se resuelve con una marca de producto. Si el mensaje no aparece, puede fallar el cliente, la red, el servicio, la cuenta, la notificación o la observación de Bruno. El modelo nos dice qué observar después. Ese es su valor.
Desliza horizontalmente para leer el diagrama a tamaño completo.
El ciclo de estudio: pregunta, modelo, predicción, observación, revisión
La secuencia central de este capítulo es:
pregunta → modelo → predicción → observación → revisión
Desliza horizontalmente para leer el diagrama a tamaño completo.
La pregunta fija qué diferencia práctica queremos resolver. «¿Por qué no llegó?» es un comienzo, pero todavía mezcla envío, aceptación, entrega y lectura. Podemos hacerla más precisa: «¿El teléfono de Ana recibió una respuesta del servicio después de enviar la petición?» o «¿La notificación de Bruno se generó después de que el servicio almacenara el mensaje?» Cada pregunta necesita un modelo distinto.
El modelo selecciona entidades, relaciones, estados y fronteras relevantes. Un modelo inicial puede decir que el cliente tiene estado local pendiente, que el servicio puede aceptar o rechazar una petición y que la notificación es una salida separada. No necesitamos saber aún si el servicio usa una cola concreta. Declaramos la omisión: el mapa no describe cifrado, identidad, retención ni operadores.
La predicción dice qué observaríamos si el modelo explica el caso. Si pendiente significa que el cliente no recibió aceptación, esperaríamos reintentos o una indicación de falta de confirmación. Si el servicio aceptó pero la notificación falló, esperaríamos un estado de entrega distinto del estado de presentación. Una predicción que cualquier resultado satisface no ayuda a revisar el modelo.
La observación es lo que encontramos bajo un método y un lugar concretos: una etiqueta de interfaz, una respuesta del servicio, una marca temporal o una prueba controlada. «Veo enviado» no es igual a «el servicio almacenó el mensaje». Tampoco es igual a «Bruno lo leyó». El método puede ser una pantalla, una documentación, una conversación con el operador o una prueba sintética; cada método tiene alcance.
La revisión compara predicción y observación. Si coinciden, el modelo gana apoyo limitado; no queda demostrado para todos los casos. Si contradicen, primero comprobamos si observamos la capa correcta y si la predicción dependía de un supuesto oculto. Después cambiamos el modelo o reducimos la afirmación. Revisar no es «hacer que los datos encajen» inventando una excepción; es conservar qué falló y por qué.
Un ejemplo de revisión paso a paso
Hipótesis inicial: «cuando la aplicación muestra enviado, el servicio ya almacenó el mensaje». Predicción: una consulta posterior desde un cliente autorizado debería encontrarlo. Observación: la pantalla muestra enviado, pero una prueba controlada de lectura devuelve que aún no está disponible. Tenemos varias posibilidades: la etiqueta sólo significa que la petición salió; la lectura consulta otra región; la prueba no posee el mismo contexto; o el servicio perdió el mensaje. No elegimos la más alarmante.
Revisamos el modelo separando estados: redactado, petición enviada, aceptado, almacenado, entregado, presentado y leído. Ahora la observación de pantalla sólo respalda uno de esos estados si conocemos su semántica. La afirmación se reduce a «la aplicación presentó la etiqueta enviado» hasta conseguir evidencia del contrato que conecte esa etiqueta con aceptación. La revisión mejora el mapa aunque todavía no resuelva el caso.
Desliza horizontalmente para leer el diagrama a tamaño completo.
Cómo construir un modelo inicial sin infantilizarlo
Empieza por el propósito. Pregunta «¿para qué existe este sistema en esta conversación?». Un teléfono puede ejecutar una aplicación, registrar actividad, guardar fotos y servir como cámara; no hay una definición única fuera de la pregunta. Después enumera entidades que puedan cambiar o tomar decisiones: dispositivo, programa, proceso, servicio, cuenta, persona, dato, operador y dependencia.
Añade relaciones con verbos, no sólo líneas: «aplicación envía petición», «servicio devuelve respuesta», «sistema operativo asigna recursos», «cliente conserva estado local». Un diagrama lleno de cajas sin verbos parece preciso, pero no permite predecir. Pregunta qué cruza cada frontera: mensaje, credencial, configuración, evento o decisión.
Anota estado. Un estado es una condición relevante en un momento: mensaje pendiente, sesión abierta, almacenamiento confirmado, notificación generada. No lo confundas con una etiqueta universal. Dos componentes pueden tener estados diferentes sobre el mismo objeto. La aplicación puede mostrar pendiente mientras el servicio ya procesó la petición, si la respuesta aún no llegó.
Anota dependencias y omisiones. El servicio puede depender de almacenamiento, reloj, identidad, red, configuración y otro proveedor. No necesitas desarrollar cada dependencia; basta con declarar que puede cambiar la predicción. «El diagrama no representa copias de respaldo» es mejor que insinuar que no existen.
Finalmente, escribe el dominio de validez: «este modelo describe una interacción de envío normal, no recuperación de cuenta, notificaciones fuera de línea ni lectura humana». Un modelo con límites explícitos puede ampliarse. Uno que oculta límites produce confianza inmerecida.
Desliza horizontalmente para leer el diagrama a tamaño completo.
Cómo usar la navegación y los prerrequisitos
La Parte 0 es una preparación de doce capítulos, no una carrera que deba completarse de memoria. Los capítulos 0.2 a 0.5 construyen el mapa de sistema, estado, ejecución y datos. 0.6 introduce palabras de identidad y autoridad sin enseñar aún sus protocolos. 0.7 a 0.9 siguen mensajes, red y web. 0.10 trata cambio de configuración y versiones. 0.11 separa error, defecto, fallo, abuso y ataque. 0.12 enseña a leer diagramas y registros. La Parte I comienza después con afirmaciones y evidencia.
Cada capítulo declara prerrequisitos requeridos y recomendados. «Requerido» significa que el modelo depende de una distinción que conviene revisar; no significa que el lector deba aprobar una prueba formal. «Recomendado» señala una ruta que reduce carga, pero puede recorrerse con curiosidad y una búsqueda posterior. Si ya sabes seguir una petición desde cliente a servidor, puedes saltar 0.7 y volver si el capítulo usa una palabra ambigua.
La navegación debe responder «qué puedo leer ahora» y «por qué este capítulo sigue». El índice muestra la ruta planificada, mientras la lectura publicada depende de sus gates editoriales. No confundas que un capítulo aparezca en el índice con que su contenido haya cerrado auditoría. El estado es una propiedad editorial, no una calificación de tu aprendizaje.
Usa una libreta o documento local con tres columnas: término, modelo actual y pregunta abierta. No copies definiciones sin anotar un contraejemplo. Para «servicio», escribe un servicio remoto que responde peticiones y un proceso local que ofrece una función a otro proceso; después pregunta qué cambia si el proceso se detiene. El propósito es crear relaciones, no coleccionar tarjetas.
Cómo leer una figura, un claim y una fuente
Una figura no es decoración ni una fotografía fiel del sistema. Antes de leer flechas, pregunta qué pregunta pretende responder, qué entidades incluye, qué relación expresa cada flecha y qué quedó fuera. Una flecha «envía» no demuestra entrega; un bloque «nube» no identifica proveedor, región ni autoridad. La leyenda y el texto alternativo deberían comunicar la conclusión y sus límites.
En este capítulo las seis figuras quedan planificadas como recursos conceptuales: mapa del ciclo de estudio, mensaje de extremo a extremo, estados del mensaje, frontera sistema-entorno, revisión de una predicción y mapa de estudio. Las especificaciones de producción conservan pregunta, propósito, entidades, relaciones, convenciones y errores prohibidos. Hasta que exista el recurso auditado, el lector debe usar la prosa y no imaginar que una figura planificada ya demuestra una relación.
Un claim es una afirmación atómica que merece trazabilidad. «El cliente envió una petición» y «el servicio almacenó el contenido» son claims diferentes porque necesitan observaciones y fuentes distintas. El ledger de claims registra tipo, fuente, localizador, versión o fecha, confianza y estado. drafted describe el estado editorial del capítulo; no es una prueba de la verdad de cada claim.
Una fuente primaria define, especifica, mide o documenta el mecanismo en cuestión. Un estándar puede decir qué significa un campo; no prueba que una implementación lo cumpla. Una documentación de producto puede describir una versión; no se extiende automáticamente a otra. Una página de búsqueda puede orientar, pero no es el localizador final. Cuando la fuente no sostiene el alcance exacto, se reduce el claim o se marca la brecha.
La lectura rigurosa pregunta: ¿qué dice la fuente literalmente?, ¿en qué sección?, ¿qué versión?, ¿qué supuestos?, ¿qué no cubre? En una obra de seguridad, «la fuente menciona mensajes» no basta para afirmar entrega, confidencialidad o identidad. La procedencia de la fuente es parte del modelo.
Cómo resolver ejercicios sin buscar la frase correcta
Los ejercicios no están diseñados para reconocer una oración del capítulo. Piden construir, comparar, transferir o revisar. Antes de responder, subraya el verbo: modelar no es listar; predecir no es describir después; revisar no es defender la primera historia. Una buena respuesta incluye qué se observó, qué se infiere, qué supuesto conecta ambos y qué dato cambiaría la conclusión.
En el caso del teléfono, una pregunta puede pedir tres hipótesis para una notificación ausente. No basta «falló Internet». Una hipótesis debe nombrar la capa y predecir: red sin entrega, servicio que procesó sin notificar, cliente que perdió estado local o teléfono de Bruno sin sincronización. Después diseña una observación que distinga al menos dos, sin acceder a datos ajenos. Si ninguna observación las separa, la conclusión correcta es no determinada.
Los criterios de evaluación son señales de razonamiento, no una lista de palabras obligatorias. Si el criterio pide distinguir estado local y remoto, mencionar ambos términos sin explicar la transición no alcanza. Si pide un caso negativo, debes mostrar qué resultado no encajaría y cómo revisarías el modelo. Una respuesta puede ser técnicamente prudente y aun así incompleta si no conecta la evidencia con la decisión.
Un segundo escenario para transferir el mapa
Considera una cámara doméstica que guarda vídeo localmente y sincroniza una copia en un servicio remoto. La cámara muestra «grabando», pero una persona no encuentra el clip en la aplicación. El modelo del mensaje ayuda, pero no se copia literalmente. Hay sensor, proceso local, almacenamiento, conexión, servicio remoto, cuenta, política de retención y aplicación de consulta. «No aparece» puede significar que nunca se capturó, que sólo existe en la tarjeta, que la sincronización está pendiente, que la consulta mira otra cuenta o que el clip expiró.
La pregunta debe acotarse: «¿el sensor produjo un segmento local durante el intervalo?» es distinta de «¿el servicio remoto lo conserva?» y de «¿la persona autorizada puede verlo?». La predicción y la observación cambian con cada pregunta. Un indicador de grabación puede ser una observación de interfaz, no prueba de almacenamiento duradero. Un respaldo remoto puede existir y no aparecer por una diferencia de cuenta o región.
Este escenario muestra transferencia: el modelo mental sobre entidades, estado, dependencias y fronteras viaja a otra tecnología; los nombres y mecanismos concretos no. En capítulos posteriores se estudiarán los controles propios de cada capa. Aquí sólo exigimos que no se atribuya al teléfono una decisión del servicio ni al servicio una propiedad que sólo observamos en la interfaz.
Un registro de estudio que se pueda revisar
Para que el aprendizaje no dependa de una impresión, conserva un pequeño registro por capítulo. Escribe la pregunta que intentabas contestar, el modelo inicial en dos o tres frases, una predicción, la observación que usaste y la revisión resultante. Añade una línea «fuera de alcance». Si vuelves al capítulo semanas después, podrás comprobar si cambió tu modelo o sólo tu vocabulario.
Ejemplo del caso conductor: pregunta «¿qué significa enviado?»; modelo inicial «la aplicación entrega una petición a un servicio»; predicción «una respuesta del servicio seguirá a la acción»; observación «la interfaz muestra el estado»; revisión «la interfaz por sí sola no distingue petición enviada de almacenamiento confirmado». Fuera de alcance: lectura humana, retención, operadores y autorización de terceros. El registro es corto, pero hace visible la diferencia entre lo que viste y lo que completaste mentalmente.
Usa también una lista de términos con contraejemplos. Para servicio, contrasta un servicio remoto que responde peticiones con un proceso local que ofrece una función a otro proceso. Para estado, contrasta un mensaje pendiente con una etiqueta estática del manual. Para fuente, contrasta una especificación que define un protocolo con una observación de que una implementación concreta lo siguió. Estos contrastes evitan que una palabra familiar absorba varios mecanismos.
Desliza horizontalmente para leer el diagrama a tamaño completo.
Lo que ya puedes explicar
Ya puedes describir un sistema pequeño por su propósito, componentes, relaciones, estado, fronteras, dependencias y omisiones. Puedes seguir una pregunta sobre un mensaje desde el teléfono hasta un servicio remoto sin convertir dispositivo, cuenta, aplicación y persona en la misma entidad. Puedes construir una predicción, comparar una observación y revisar el modelo cuando no encajan.
También puedes usar el índice para elegir un prerrequisito, leer una figura como argumento, separar un claim de su fuente y resolver un ejercicio mediante transferencia. Puedes escribir una conclusión con alcance: «la interfaz mostró una etiqueta» es diferente de «el servicio almacenó y entregó el mensaje». Esa precisión será el punto de partida de la Parte I.
Lo que todavía no estamos afirmando
Todavía no estamos afirmando cómo se autentica una cuenta, quién puede autorizar una acción, qué protocolo entrega un mensaje, qué cifra protege un canal, cuánto tiempo conserva datos un proveedor ni si un fallo constituye vulnerabilidad, amenaza o riesgo. Tampoco estamos afirmando que una observación de pantalla sea evidencia suficiente para una decisión profesional.
Esas preguntas requieren nuevos modelos, fuentes y pruebas. El límite no es una evasión; es parte de la honestidad del mapa. Cuando avancemos, cada capítulo añadirá mecanismos y cambiará algunas simplificaciones. Si una nueva evidencia contradice este mapa, no se protege por ser el primero: se identifica qué frontera o supuesto estaba mal elegido.
Desliza horizontalmente para leer el diagrama a tamaño completo.
Síntesis
Usar Code Cyber significa aprender a hacer preguntas que un modelo pueda responder, no acumular nombres. El ciclo pregunta→modelo→predicción→observación→revisión convierte la curiosidad en una práctica revisable. El caso del mensaje desde un teléfono muestra por qué una etiqueta visible no equivale automáticamente a aceptación, almacenamiento, entrega o lectura.
Un modelo útil declara entidades, relaciones, estado, dependencias, fronteras y omisiones. Un claim útil tiene alcance y fuente. Un ejercicio útil exige transferir y revisar. Una figura útil responde una pregunta sin ocultar lo que no representa. La preparación termina cuando puedes explicar qué sistema observas, qué entidad intercambia datos, dónde podría permanecer el estado y qué observación cambiaría tu explicación.
Comprobación de comprensión
- ¿Qué diferencia hay entre observar una etiqueta de enviado y observar que el servicio almacenó un mensaje?
- ¿Por qué el mismo teléfono puede ser sistema en una pregunta y componente en otra?
- Construye dos hipótesis para una notificación que no aparece y una predicción para cada una.
- ¿Qué información aporta una frontera y qué puede quedar fuera de ella?
- ¿Por qué cerrar una aplicación no basta para afirmar que desaparecieron todas las copias?
- ¿Qué diferencia existe entre un claim y una fuente?
- ¿Qué debe hacer un modelo cuando una observación contradice su predicción?
- ¿Qué parte del caso de mensajería puedes transferir a una cámara y qué parte debes reconstruir?
Problema de transferencia
Una aplicación de notas en un teléfono muestra «guardado» y después el usuario cambia de dispositivo. En el segundo dispositivo no aparece la nota. Construye un modelo con al menos seis entidades y cuatro estados; formula tres hipótesis rivales; escribe una predicción y una observación segura para distinguir cada par relevante. Indica qué afirmación puedes hacer si sólo tienes la pantalla del primer teléfono, qué evidencia necesitarías para hablar del servicio remoto y qué parte del modelo queda fuera de alcance. No uses cuentas reales ni intentes consultar servicios ajenos.
Fuentes principales
- NIST CSRC Glossary — términos de sistema, servicio, autenticación y autorización; cada uso se mantiene orientativo y no sustituye los capítulos posteriores.
- NIST SP 800-160 Vol. 1 Rev. 1, §§2–3 — sistemas, ciclo de vida, propiedades y límites de claims de ingeniería.
- RFC 3986, §§1.1–1.2 — identificadores, recursos y separación entre referencia y recurso.
- RFC 9110, §§3, 3.3, 5, 9 y 15 — roles de cliente/servidor, campos, métodos y códigos de estado.
- W3C Web Architecture, §§2–3 — recursos, representaciones y agentes en la arquitectura web.
- NIST SP 800-53A Rev. 5, §§2–3 — diferencia entre evaluación, evidencia, alcance y conclusión evaluativa.