Capítulo 10 — Ética y práctica autorizada
Mapa de la lección
Lección 10 publicada. Mapa, ejemplo, EX028.
flowchart TD
N0["Resultados de aprendizaje"]
N1["10.1 La autorización viene del propietario"]
N2["10.2 El permiso de trabajo"]
N3["10.3 Divulgación coordinada"]
N4["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Ejemplo resuelto"]
EX --> Q["Ejercicio EX028"]
Dibujo lógico
flowchart LR
N0["Resultados de aprendizaje"]
N1["10.1 La autorización viene del propietario"]
N2["10.2 El permiso de trabajo"]
N3["10.3 Divulgación coordinada"]
N4["Síntesis del capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX028"]
[Resultados de aprendizaje]
|
v
[10.1 La autorización viene del propietario]
|
v
[10.2 El permiso de trabajo]
|
v
[10.3 Divulgación coordinada]
|
v
[Síntesis del capítulo]
|
v
[Ejemplo resuelto] --> [Ejercicio EX028]
Resultados de aprendizaje
Usted podrá (1) distinguir la autorización del permiso de acceso; (2) enumerar los elementos de un permiso de trabajo escrito para pruebas de TO; (3) gestionar las vulnerabilidades descubiertas mediante divulgación coordinada; y (4) rechazar peticiones que pondrían en peligro a personas o excederían el alcance.
10.1 La autorización viene del propietario
Solo el propietario del activo —o alguien en quien el propietario haya delegado por escrito— puede autorizar pruebas sobre un sistema de TO. Un empleado de la planta que siente curiosidad, un proveedor que «ya tiene acceso de todos modos» o un profesor que quiere una demostración no pueden concederla. En el entorno industrial, la autorización también debe venir de operaciones: una prueba legal pero insegura sigue siendo inaceptable. Un compañero de clase de Maya le ofreció exactamente este tipo de autoridad falsa: la dirección IP de un controlador de calefacción «real» encontrado en un buscador y la sugerencia de leer un registro. Nadie que fuera propietario de ese controlador había dado su consentimiento, así que Maya se negó y sugirió comunicar la exposición al CERT nacional.
10.2 El permiso de trabajo
Una autorización sólida para pruebas de TO nombra los sistemas dentro del alcance, la ventana de tiempo, las técnicas permitidas (solo captura pasiva, consultas de solo lectura o pruebas en banco), las personas de guardia, las condiciones de parada («si se produce cualquier alarma de proceso, detenerse y avisar al jefe de turno») y el plan de reversión. La firman el propietario y el responsable de operaciones del área afectada. Para una captura pasiva en el conmutador de control de LDHP, la condición de parada podría decir: «cualquier alarma de HMI-1 o cualquier cambio en el tiempo de escaneo de PLC-H; detener la captura e informar al jefe de turno». La reversión consiste en eliminar la configuración del puerto espejo.
10.3 Divulgación coordinada
Si encuentra un fallo en un producto de un fabricante, comuníquelo al fabricante y, cuando proceda, a CISA, cuyos avisos de ICS publican correcciones coordinadas. La disposición 5.2 de ETSI EN 303 645 exige a los fabricantes de IoT de consumo publicar una política de divulgación de vulnerabilidades; muchos fabricantes industriales mantienen programas similares. Publicar detalles de explotación antes de que exista una corrección puede poner en riesgo a todas las plantas que usan ese producto. Si el trabajo sin conexión de Maya hubiera revelado un fallo real en el firmware de las pasarelas de contadores, la vía sería primero el contacto de divulgación del fabricante; MTR-C, en el capítulo 30, advierte de que algunos fabricantes no tienen ninguno, y en ese caso coordina el CERT nacional o CISA.
Ejemplo resuelto (LDHP sintética)
Un compañero de clase ofrece a Maya la dirección IP de un controlador de calefacción «real» encontrado en un buscador de internet y le sugiere «leer solo un registro para demostrar que funciona». Maya se niega: no hay autorización del propietario, no hay permiso y la consecuencia sobre el proceso es desconocida. En su lugar, anota la categoría de exposición (ATT&CK for ICS T0883) y sugiere a su compañero que comunique la exposición al CERT nacional, que puede contactar con el propietario.
Caso sintético — Lakeside District Heating Plant. El compañero de clase y el controlador expuesto son ficticios; lo que importa es el razonamiento.
Errores y límites
«Solo lectura» no es automáticamente inofensivo: algunos dispositivos heredados se bloquean ante peticiones inesperadas. Los códigos éticos no sustituyen a la ley; quienes aprenden deben conocer la ley sobre uso indebido de sistemas informáticos de su jurisdicción.
Ejercicios — capítulo 10
- EX028 — Condición de parada del permiso. Escriba una condición de parada para una captura de red pasiva en el conmutador de control de LDHP. Rúbrica: 3 = desencadenante observable más acción y a quién se avisa; 2 = solo el desencadenante; 1 = un vago «si hay problemas»; 0 = nada.
- EX029 — ¿Quién puede autorizar? El jefe de proyecto de un contratista envía un correo: «adelante, escanead PLC-H». ¿Es suficiente? Rúbrica: 3 = no; hace falta la aprobación del propietario y de operaciones con alcance y ventana; 2 = no, sin motivo; 1 = sí, con salvedades; 0 = sí.
- EX030 — Divulgar un fallo de un fabricante. Enumere los dos primeros pasos tras encontrar un fallo que bloquea un modelo de controlador en una unidad de banco. Rúbrica: 3 = conservar la evidencia en privado y contactar con el fabricante/PSIRT (y con CISA o el CERT nacional); 2 = uno; 1 = publicarlo en redes sociales; 0 = nada.
Síntesis del capítulo
En TO, la práctica ética es operativa: la autorización escrita del propietario, las condiciones de parada explícitas y la divulgación coordinada protegen a las personas además de a las reputaciones.
Siga estudiando — capítulo 10 de 40
← Capítulo 09 (borrador) · Índice de capítulos del curso · Capítulo 11 (borrador) →