OpenCyber Academy
Ingeniería · Capítulo 10 · Español
Código del curso: OCA-138Capítulo 10: OCA-138-C010

Capítulo 10 — Ética y seguridad en ingeniería

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.

Mapa de la lección

Lección 10 publicada. Mapa, ejemplo, EX019.

flowchart TD
  N0["Resultados de aprendizaje y conexión"]
  N1["10.1 Los deberes de un ingeniero"]
  N2["10.2 Seguridad funcional y seguridad, juntas"]
  N3["10.3 Autorización y derecho"]
  N4["10.4 Decidir en condiciones de incertidumbre"]
  N5["10.6 Actividad práctica"]
  N6["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
  N6 --> EX["Ejemplo resuelto"]
  EX --> Q["Ejercicio EX019"]

Dibujo lógico

flowchart LR
  N0["Resultados de aprendizaje y conexión"]
  N1["10.1 Los deberes de un ingeniero"]
  N2["10.2 Seguridad funcional y seguridad, juntas"]
  N3["10.3 Autorización y derecho"]
  N4["10.4 Decidir en condiciones de incertidumbre"]
  N5["10.6 Actividad práctica"]
  N6["Síntesis del capítulo"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX019"]
[Resultados de aprendizaje y conexión]
    |
    v
[10.1 Los deberes de un ingeniero]
    |
    v
[10.2 Seguridad funcional y seguridad, juntas]
    |
    v
[10.3 Autorización y derecho]
    |
    v
[10.4 Decidir en condiciones de incertidumbre]
    |
    v
[10.6 Actividad práctica]
    |
    v
[Síntesis del capítulo]
    |
    v
[Ejemplo resuelto] --> [Ejercicio EX019]

Resultados de aprendizaje y conexión

Al terminar este capítulo, usted podrá (1) aplicar los códigos de ética profesional a las decisiones de seguridad en infraestructura; (2) explicar la relación entre seguridad funcional y seguridad, y dónde entran en conflicto; (3) reconocer los límites legales y de autorización de las pruebas y la investigación; y (4) tomar y documentar una decisión ética en condiciones de incertidumbre, incluido cuándo escalar. Se apoya en el capítulo 5 y enmarca todos los capítulos posteriores, en particular los de pruebas (capítulos 30 y 40) y práctica (capítulo 43).

10.1 Los deberes de un ingeniero

Los códigos profesionales convergen en una jerarquía: anteponer a todo la seguridad, la salud y el bienestar del público; actuar dentro de la propia competencia; ser honesto y objetivo; evitar los conflictos de intereses; proteger la información confidencial. El NSPE Code of Ethics for Engineers hace de la seguridad pública el primer canon fundamental; el ACM Code of Ethics and Professional Conduct pide a los profesionales de la computación que eviten el daño y que sean honestos sobre las capacidades y los límites de los sistemas. En la infraestructura crítica, el público es concreto: pacientes en diálisis, hogares sin agua, personas que esperan una ambulancia. El deber no se cumple siguiendo instrucciones si el resultado es un daño previsible al público.

10.2 Seguridad funcional y seguridad, juntas

La seguridad funcional (safety) protege a las personas y al ambiente del daño causado por el sistema; la seguridad (security) protege al sistema del uso indebido deliberado. En la tecnología operativa ambas interactúan. Un control de seguridad puede crear un peligro para la seguridad funcional: un bloqueo automático de cuenta en la consola de un operador durante una emergencia, o un parche que reinicia un controlador durante un proceso en curso. Un mecanismo de seguridad funcional puede ser un objetivo de ataque: el malware TRITON/TRISIS atacó controladores de sistemas instrumentados de seguridad, como describe el informe de análisis del malware HatMan de CISA. La buena práctica trata ambas en un único análisis de peligros (capítulo 33) y da a las funciones de seguridad funcional independencia respecto de las redes y los sistemas que protegen.

10.3 Autorización y derecho

Probar un sistema que no le pertenece o que no tiene permiso escrito para probar puede ser un delito, sean cuales sean sus intenciones, y en la infraestructura puede poner en peligro a las personas. La autorización debe ser escrita, específica (sistemas, horarios, métodos), otorgada por alguien facultado para darla, e incluir condiciones de detención. La investigación con personas o con datos operativos necesita revisión ética y acuerdos sobre los datos. Las vulnerabilidades que encuentre de forma incidental deben comunicarse al propietario del activo en privado o mediante un programa de divulgación coordinada, como el programa CVD de CISA. Los laboratorios de este libro son sintéticos precisamente por estas razones.

10.4 Decidir en condiciones de incertidumbre

Un procedimiento práctico de decisión ética: (1) enuncie la decisión y a quién afecta; (2) identifique los deberes y los hechos que inciden en ellos; (3) enumere las opciones, incluidas la escalada y la negativa; (4) evalúe las consecuencias para las partes interesadas más vulnerables; (5) elija, documente el razonamiento y los desacuerdos, y fije un punto de revisión. Los ingenieros rara vez enfrentan dilemas limpios; con más frecuencia, el problema es la presión para aprobar algo que aún no se ha demostrado que funcione. «No verificado» es una respuesta honesta y suficiente.

En el ejemplo resuelto que sigue, el ingeniero de verificación del TMRP usa exactamente estos cinco pasos.

10.5 Ejemplo resuelto: la aprobación con plazo (sintético)

El plazo de puesta en marcha del TMRP es el viernes. La prueba T3 (límites de consigna) ha fallado: el controlador de PS4 acepta una consigna fuera del rango seguro cuando se envía como valor NaN. El proveedor propone poner en marcha con una nota para corregirlo en la próxima versión. Como ingeniero de verificación, usted aplica el procedimiento: entre las personas afectadas están los pacientes del hospital si PS4 se comporta de forma impredecible; su deber es con la seguridad pública y con un informe honesto; las opciones son (a) firmar, (b) negarse, (c) poner en marcha con un control compensatorio (escrituras remotas de consigna deshabilitadas en la pasarela, operación solo local para PS4) y una corrección con fecha. Usted recomienda (c), registra T3 como fallida, no como dispensada, y exige repetir la prueba antes de habilitar las escrituras remotas. La decisión queda documentada y la firma el gerente de operaciones, responsable del riesgo operativo.

10.6 Actividad práctica

Escriba una plantilla de autorización de una página para una prueba de un sistema sintético: alcance, métodos excluidos, ventana temporal, condiciones de detención, contactos, tratamiento de los datos y firma. Complete la plantilla para una prueba de banco de la pasarela de telemetría de LRWA y no para una estación en servicio. Indique quién puede firmarla, enumere los métodos excluidos, como cualquier tráfico dirigido a RTU reales, y dé condiciones de detención que un probador pueda reconocer sin interpretación. Incluya un contacto que pueda detener la prueba en cualquier momento y una regla sobre qué ocurre después con los datos capturados. Una plantilla que permitiera a alguien probar PS4 en un periodo de alta demanda ha fracasado en su propósito.

10.7 Errores comunes y límites

La aprobación con plazo del ejemplo resuelto muestra varios de estos errores a la vez: presión para poner en marcha, un proveedor que ofrece una promesa verbal de corregir más tarde y una prueba fallida que fácilmente podría haberse marcado como dispensada. El ingeniero evitó cada uno registrando la falla y acordando por escrito un control compensatorio.

Ejercicios — capítulo 10

EX019 — Conflicto entre seguridad funcional y seguridad. Objetivo: resolver un control que pone en peligro la operación. Entradas: propuesta de bloquear las cuentas de la HMI de los operadores tras cinco inicios de sesión fallidos. Pasos: analice el peligro, proponga una alternativa que preserve la intención de seguridad e indique cómo la verificaría. Evidencia esperada: análisis de media página. Rúbrica: 3 = peligro claro (bloqueo durante una emergencia), la alternativa mantiene la rendición de cuentas y resiste los intentos de adivinar (p. ej., limitación de frecuencia con alertas, anulación con presencia física, cuentas por turno con registro), verificación indicada; 2 = alternativa débil; 1 = solo el peligro; 0 = nada.

EX020 — Hallazgo incidental. Objetivo: actuar dentro de la autorización. Entradas: mientras estudia para un trabajo del curso los documentos de compra de una empresa pública de servicios, observa en una captura de pantalla una página de gestión de un controlador de bombas expuesta a internet, con el proveedor y el modelo visibles. Pasos: indique qué no debe hacer, qué debe hacer y ante quién, y qué puede decir su trabajo del curso. Evidencia esperada: 150 palabras. Rúbrica: 3 = ningún acceso ni sondeo, notificación privada al propietario o mediante CVD, trabajo anonimizado; 2 = falta un paso; 1 = sugiere «comprobar si es real»; 0 = nada.

Síntesis del capítulo

La seguridad pública va primero, comunicada con honestidad. La seguridad funcional y la seguridad deben analizarse juntas, porque cada una puede anular a la otra. Pruebe solo con autorización escrita y específica; comunique en privado los hallazgos incidentales. Decida en condiciones de incertidumbre con un procedimiento documentado, y trate «no verificado» como una respuesta que usted puede, y debe, dar.

Respuestas desarrolladas

EX019. Peligro: un operador bloqueado durante una emergencia no puede actuar; un atacante puede bloquear deliberadamente a los operadores (denegación de servicio). Alternativa: sin bloqueo en las HMI de la sala de control; en su lugar, retardo progresivo tras los fallos, alertas ante fallos repetidos, cuentas nominativas con autenticación fuerte, control de acceso físico a la sala de control y una anulación de emergencia con presencia física y registro. Verifique mediante prueba (los intentos fallidos producen retardos y alertas, nunca bloqueo) y mediante ejercicio (el operador puede iniciar sesión bajo estrés).

EX020. No visite, sondee ni intente iniciar sesión en la página, y no comparta la captura de pantalla. Notifique a la empresa de servicios en privado a través de su contacto de seguridad publicado o, si no existe, mediante un programa de divulgación coordinada como el de CISA, indicando solo lo que observó y dónde. El trabajo del curso puede describir el patrón («interfaces de gestión expuestas en documentos de compra») sin nombrar a la empresa, el proveedor, el modelo ni la ubicación.