◇ OpenCyber Academy
Tecnólogo · Capítulo 3 · Español

Capítulo 3 — Fundamentos de programación

Aprendizaje gratuito y abierto para quienes desean proteger a las personas y la tecnología. No se necesita una cuenta para estudiar ni consultar las respuestas.

Capítulo 3 — Fundamentos de programación

Mapa de la lección

Lección 03 publicada. Mapa, ejemplo, EX007.

flowchart TD
  N0["Resultados de aprendizaje"]
  N1["3.1 Por qué los tecnólogos escriben scripts"]
  N2["3.2 Diccionarios para búsquedas"]
  N3["3.3 Los datos ausentes son un resultado"]
  N4["3.4 Salida legible"]
  N5["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5
  N5 --> EX["Ejemplo resuelto"]
  EX --> Q["Ejercicio EX007"]

Dibujo lógico

flowchart LR
  N0["Resultados de aprendizaje"]
  N1["3.1 Por qué los tecnólogos escriben scripts"]
  N2["3.2 Diccionarios para búsquedas"]
  N3["3.3 Los datos ausentes son un resultado"]
  N4["3.4 Salida legible"]
  N5["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX007"]

[Resultados de aprendizaje]
    |
    v
[3.1 Por qué los tecnólogos escriben scripts]
    |
    v
[3.2 Diccionarios para búsquedas]
    |
    v
[3.3 Los datos ausentes son un resultado]
    |
    v
[3.4 Salida legible]
    |
    v
[Síntesis del capítulo]
    |
    v
[Ejemplo resuelto] --> [Ejercicio EX007]

Resultados de aprendizaje

Usted será capaz de (1) escribir programas breves en Python usando solo la biblioteca estándar; (2) usar listas, diccionarios y bucles para procesar registros; (3) tratar los datos ausentes de forma explícita; y (4) mantener los scripts legibles para colegas que no son programadores.

3.1 Por qué los tecnólogos escriben scripts

Gran parte del trabajo de seguridad de TO consiste en comparar listas: los activos de la documentación frente a los activos vistos en la red, los flujos aprobados frente a los observados, las fechas de los certificados frente a la fecha de hoy. Hacerlo a ojo con cientos de filas es lento y propenso a errores. Un script de veinte líneas lo hace siempre de la misma manera, y su salida puede adjuntarse a un ticket. El primer script de este tipo de Priya comparaba la documentación de la empresa contratista con una observación pasiva y producía la salida de cinco líneas del capítulo 11: dos coincidencias, una cámara solo en la red, HMI-C solo en los documentos y el conflicto de versiones de PLC-R2.

3.2 Diccionarios para búsquedas

Un diccionario de Python asocia una clave (el nombre del dispositivo) a un valor (la versión de firmware). Comprobar «¿está documentado este dispositivo?» se convierte en name in docs, que es rápido y legible. Los conjuntos dan la unión y la diferencia directamente: set(a) - set(b) enumera lo que está en a pero no en b. El script de inventario de Priya mantiene un diccionario procedente de los documentos de la empresa contratista y otro procedente de la observación pasiva, cada uno de los cuales asocia el nombre de un dispositivo a su cadena de firmware. La unión de los dos conjuntos de claves es la lista completa de dispositivos sobre los que informar; las diferencias son los dos grupos interesantes: CAM-DOCK, solo en la red, y HMI-C, solo en los documentos.

3.3 Los datos ausentes son un resultado

Cuando falta un valor, dígalo en la salida. dict.get(key) devuelve None en lugar de provocar un fallo, y el script puede imprimir «-» y un estado como «only-in-docs». Omitir en silencio las filas incompletas es la manera en que las brechas desaparecen de los informes. El primer borrador de Priya hacía exactamente eso: solo recorría las coincidencias, así que CAM-DOCK, que faltaba en los documentos, nunca aparecía. Un colega preguntó dónde estaba la cámara. Su corrección fue de una línea, recorrer sorted(set(docs) | set(seen)), de modo que cada dispositivo se imprime con un estado y el que falta lo indica. La salida del capítulo 11 muestra ahora docs=- para CAM-DOCK en lugar de omitirla.

3.4 Salida legible

Alinee las columnas con anchos de f-string (f"{name:9}") y ponga la decisión al final de cada línea. Así, un revisor puede recorrer la última columna en busca de cualquier cosa que no sea «match». En la salida del capítulo 11, la última columna dice only-on-network, match, only-in-docs, match y VERSION-CONFLICT, así que un responsable de instalaciones puede encontrar las tres líneas que requieren acción sin leer las cadenas de firmware. Los nombres de dispositivo se rellenan hasta nueve caracteres, lo que mantiene alineadas las columnas de documentación y de red incluso para CAM-DOCK. Un revisor que vea un estado que no es ninguno de los cinco valores documentados sabe que el script se ha encontrado con una entrada que no entiende.

Ejemplo resuelto (NCS sintética)

Priya escribe un bucle sobre dos diccionarios, uno procedente de la documentación de la empresa de refrigeración y otro de una observación pasiva de la red. Su primer borrador solo imprimía las coincidencias; un colega preguntó dónde estaba CAM-DOCK. Lo reescribió para recorrer la unión de las claves, de modo que cada dispositivo aparezca con un estado. La versión completa es el laboratorio del capítulo 11.

Caso sintético — Northgate Cold Storage. Los datos son inventados.

Errores y límites

Los scripts que leen dispositivos en funcionamiento necesitan un permiso de trabajo y límites de frecuencia cuidadosos; los scripts de este curso solo leen archivos. Nombre las variables por lo que contienen, no x e y.

Ejercicios — capítulo 3

Síntesis del capítulo

Los scripts pequeños y legibles que informan de cada fila, incluidas las ausentes, convierten la comparación de listas en evidencia repetible.

Siga estudiando — capítulo 03 de 30

← Capítulo 02 (borrador) · Índice de capítulos del curso · Capítulo 04 (borrador) →