La matriz de conectividad, lo esperado y lo observado

Una matriz de conectividad es una tabla con una fila por cada pareja de origen y destino que se quiso comprobar: desde dónde, hacia qué equipo y puerto, qué se esperaba y qué se observó. Lo esperado sale del diseño y de la política del cliente; lo observado, de una comprobación hecha desde un punto de prueba.

Su valor es que permite pasar de «las reglas dicen» a «ocurre». Su límite es que cada fila es una foto: el resultado vale desde ese punto, ese día, con ese estado de la red. Un puerto «abierto» desde la zona de usuarios no es automáticamente una vulnerabilidad, y uno «bloqueado» desde un punto no prueba que lo esté desde todos los demás de la zona. Se informa lo que se midió, con su punto de origen, sin extrapolar.

La pasada principal sobre la matriz es la de los casos en que esperado y observado no coinciden. Hay dos tipos y no valen lo mismo. El que importa para la seguridad es el de lo que debía estar cerrado y estaba abierto: significa que alguien puede hacer algo que el diseño no preveía. El otro, lo que debía funcionar y no funciona, es una discrepancia de operación y se verá en la tarea 5.

Para el informe hace falta la cifra exacta del primer tipo, con el filtro correcto: solo los casos esperados como bloqueado y observados como abierto.

Cada caso lleva su identificador: es lo que se cita en el informe, en la reunión de cierre y en la verificación posterior. La planta de producción es la zona que el cliente más protege, así que, entre todos los casos abiertos, el que une la zona de usuarios con el controlador de la máquina es el que más pesa en la conversación.

Busca en la matriz el caso que parte de la zona Usuarios y llega al controlador de la corrugadora. No lo confundas con el que llega al equipo de supervisión: son dos casos con destinos distintos.

Un caso abierto sin explicación es un dato; con su regla es un hallazgo. La columna «regla» de la matriz dice qué regla del cortafuegos decidió esa conexión, según el registro, y el texto de las reglas citadas está en la tabla de reglas. Si no hay regla (el tráfico no pasó por el cortafuegos), la explicación está en las rutas o en las interfaces, que es lo que se vio en la sala anterior.

Para el caso que acabas de localizar, cita la regla que lo decidió. Ese identificador es el que irá en la evidencia del hallazgo.

El caso contrario también aparece en la matriz: algo que el diseño dice que debe pasar y la prueba muestra bloqueado. En Cartonera Valle Hondo, el portal de proveedores no llega al ERP porque ninguna regla lo permite y cae en la denegación final. No es una vulnerabilidad: nadie obtiene acceso de más. Pero es una discrepancia entre el diseño y la realidad que el cliente querrá saber.

Un informe maduro separa las dos cosas: los hallazgos de seguridad por un lado y las observaciones funcionales por otro. Mezclarlos alarga el informe, quita fuerza a los hallazgos y hace que el cliente descarte lo uno con lo otro.