EF485 - EuroFach Electrónica

INVESTIGACIÓN 41 (i) En ZT no se debe confiar en nada ni en nadie. Lo único es verificar por completo antes de actuar. (ii) Todas las comunicaciones se deben hacer seguras tanto internas como externas e inde- pendientemente de la localización de red. Utilizando cifrado robusto anidado/múltiple o post-cuántico, esteganografía, firma digital, hash, canales subliminares, tecnología OT, etc. (iii) El acceso a los recursos se debe proporcionar en base al riesgo dinámico (que debe incluir el estado observable de la identidad de la entidad/usuario, aplica- ción/APP y el activo que pide y puede incluir otros atributos de comportamiento). (iv) Todas las fuentes de datos y servicios de computación se consideran ‘recursos’. (v) Todos los dispositivos deberían estar en el estado de protección de ciberseguridad máximo y para ello se debería monitorizar. Se debe asegurar que todos los dispositivos (propios y asociados) se encuentren en el mayor estado de protección de ciberseguridad y se debe monitorizar los activos para asegurar que permanezcan en el máximo estado posible. (vi) Toda la autenticación (multi-factor (MFA), mutua, ZK, etc.) y autoriza- ción de recursos (la autorización asigna niveles de privilegios, es decir, qué operaciones puede rea- lizar cada entidad/usuario, sobre cada recurso) debe ser dinámica y se debe aplicar estrictamente antes de conceder el acceso. (vii) Todos los accesos a los recursos individuales se deben conceder/ proporcionar ‘por-sesión’ (nada de dejar abiertas las sesiones. Recordar: ‘la comodidad y la confianza son vulnerabilidades’). (viii) Se debe recoger tanta informa- ción como sea posible sobre el estado actual de la infraestructura de red y comunicaciones (uso de registros, logs, etc.) para mejorar sus actuaciones de protección en ciberseguridad. El malware defensivo se alimenta de todas las combinaciones de estrategias, tácticas, técnicas, subtécnicas, procedimientos, etc., utilizadas por el malware ofensivo (incluso el heurístico) conocidas e inferidas, pero mejorándolas y aplicando un mayor nivel de madurez y calidad. El malware ofensivo para poder realizar sus operaciones/ acciones maliciosas, perversas, etc., se oculta. El malware defensivo para realizar sus actividades/tareas de neutrali- zación (como inactivación, bloqueo, esterilización, anulación, mitigación, reparación retrospectiva, borrado, inhabilitación, etc. contra el malware ofensivo) también se oculta y realiza trayectorias inteligentes y movimientos erráticos a muy alta velocidad para ‘ganar cada jugada’ y bloquear intentos de acciones/infección/intrusión, evitar ser detectado, neutralizar operaciones maliciosas, inactivar acciones hosti- les, anular actividades perversas, etc. realizadas por el malware ofensivo enemigo. LAS VULNERABILIDADES ELEMENTO FACILITADOR DEL MALWARE Actualmente existe un elevadísimo número de vulnerabilidades (N-day, K-hours) y se desconoce el número de vulnerabilidades (0-day, 0-hours, 0-minutes). Además esta cifra crece cada vez más de forma desmesurada en nuestro mundo progresivamente más conectado (vía WBAN/Wireless- Body -Area -Networ k , WPAN/ Wireless-Personal-Area-Network, WLAN/ Wireless-Local-Area-Network, WMAN/ Wireless-Metropolitan-Area-Network, WWAN/Wireless-Wide-Area-Network, etc. incluso de forma satelital), donde proliferan más y más objetos (IoT, IIoT, IoMT/Internet-of-Medical-Things, AIoT, etc.), más digital, más basado y definido por software-firmware (SDR/Software-Defined-Radio, SDN/ Software-Defined-Networking, SBL/ Software-Based-Lock, etc.), cada vez con mayor número de nubes de todo tipo (edge, fog, cloud-computing, públi- cas, privadas, fijas, móviles, etc.), con toda clase de tecnologías en todos los entornos OT/IT (PLC, CPS, SCADA, HMI, ICS, sensores, actuadores, BDs, ERP, CRM, IA, VR, etc.) y donde los datos son uno de los recursos más preciados. El malware (durante su ciclo de vida para realizar sus operaciones, acciones, actividades, etc.) utiliza vulnerabi- lidades (que son, en esencia: fallos, debilidades, errores, deficiencias, bugs, flaws, imprecisiones, confianzas, igno- rancias, etc.) como: (1) Mala calidad del código del cliente. Estas vulnerabilidades se deben a erro- res, bugs, flaws, etc. en la codificación (debido a una carencia de auditoría y análisis tanto estático como diná-