Dispositivos conectados, lo que se puede y no se puede vigilar

4 tareas · 40 min · Principiante

Jueves 29 de octubre, 10:20. En la UCI de la Clínica Santa Eulalia hay bombas de infusión, monitores y ventiladores conectados a una red propia. Ninguno tiene un agente de seguridad y varios no se pueden parchear sin el permiso del proveedor. La red registra con quién habla cada uno. Aprendes a vigilar lo que no se puede tocar, a leer un flujo que se sale de la línea base y a proponer un control que no ponga en riesgo al paciente. Todo es lectura de tablas de ejemplo.

0 de 4 · 0%

Objetivo de la sala

Un dispositivo clínico suele ser un equipo cerrado, con un software que el proveedor controla y que se validó con el equipo tal como está. No admite instalar un agente ni, en muchos casos, aplicar un parche sin que el proveedor lo apruebe. Por eso se vigila desde afuera: el inventario de qué hay y qué versión tiene, y el tráfico de red que genera, observado de forma pasiva.

Un escaneo activo de vulnerabilidades envía tráfico al equipo para provocar respuestas, y un equipo frágil puede reaccionar mal. Hacerlo contra un dispositivo en uso en la UCI se evita, y solo se considera con el área de ingeniería biomédica y en una ventana pactada.

Responde para continuar

¿Por qué se prefiere observar el tráfico de un dispositivo clínico en vez de escanearlo?

Porque los dispositivos clínicos no tienen dirección IP y por tanto no pueden ser escaneados nunca Porque un escaneo puede alterar a un equipo frágil, y el inventario y el tráfico ya dicen mucho Porque un escaneo activo solo funciona en equipos de oficina y no en equipos con firmware

Ver pista de ayuda

La razón es el riesgo de afectar un equipo en uso, no una imposibilidad técnica.

La línea base de un dispositivo es muy corta: casi todos hablan con un solo servidor de gestión, siempre por el mismo puerto y con volúmenes parecidos día a día. Eso hace que lo anómalo salte a la vista: un destino que el dispositivo nunca contactó.

Abre la consola. Ejecuta SELECT * FROM flujos WHERE visto_antes = 'no'.

Responde para continuar

Escribe el identificador del dispositivo que habló con un destino que no había contactado.

Ver pista de ayuda

La columna visto_antes marca los destinos que no estaban en la línea base.

Un destino se evalúa por su dirección, su puerto y su volumen. Las direcciones internas del ejemplo van en 198.51.100.0/24; el resto sale de la clínica. Un volumen miles de veces mayor que el habitual en un equipo cuyo tráfico suele ser de unos cuantos kilobytes no es una actualización pequeña.

Ejecuta SELECT * FROM flujos WHERE id = 'BI-UCI-07' y compara los dos destinos de ese dispositivo.

Responde para continuar

Escribe la dirección IP externa a la que habló ese dispositivo.

Ver pista de ayuda

Es la dirección que no empieza por 198.51.100.

El dispositivo del caso no se puede parchear (el proveedor no lo permite) y está en la UCI. Los controles posibles se miden por lo que le cuestan al paciente. Un control compensatorio reduce el riesgo sin tocar el equipo: limitar desde la red con qué puede hablar, vigilar sus flujos y conservarlos como evidencia, y coordinarlo con ingeniería biomédica.

Responde para continuar

¿Qué control tiene sentido para ese dispositivo?

Apagar la bomba esa misma noche para cortar la conexión, y avisar a la UCI por la mañana Instalarle el firmware más reciente aunque el proveedor no lo haya validado para ese modelo de bomba Limitar ese segmento al servidor de gestión, pactado con biomédica, y guardar los flujos

Ver pista de ayuda

El control va en la red, no en el equipo, y se pacta con quien lo opera.

Inicia sesión para registrar tus puntos y progreso en el ranking.

Entrar · Registrarse

1 Vigilar sin tocar

2 El que habla con un destino nuevo Lab

3 A dónde habla Lab

4 Un control que no pone en riesgo al paciente Lab

Whoami-Labs Pro utiliza cookies