- Tiempo de lectura: 6 minutos (artículo 2/2)
- Problema: aparecen nuevas amenazas de seguridad al incluir acceso ubicuo en plataformas complejas
- Observación: existen numerosas técnicas y metodologías ya maduras, los entornos web tienen ya más de 20 años de vida
- Propuesta: es necesario incluir las técnicas de segurización de entornos web en los sistemas en los que se ofrezca este tipo de accesos, y educar a los usuarios que los utilizan
Hoy presento aquí la segunda parte del artículo «ciberseguridad: los 5 puntos críticos de las interfaces ubicuas«. En el artículo anterior ya enumeré los puntos que considero clave en mi particular visión de la «cadena de seguridad», según mi criterio y experiencia. En esta nueva entrega vamos a ver cada uno de ellos con un poco más de detalle, pero respetando el formato de artículo corto y ameno que siempre intento hacer. Por supuesto cada uno de estos apartados es un mundo en sí mismo, de hecho la literatura existente sobre cada uno de ellos es muy extensa, y recomiendo dedicarle un rato en caso de estar trabajando en un sistema de estas características.
Veamos de nuevo cuáles son los eslabones de nuestra cadena de seguridad:
1.-El mundo físico
Los servidores físicos son el soporte tangible de nuestros sistemas. Cuando los servidores fallan, nuestro sistema se resiente. La sensación de seguridad comienza por la disponibilidad, y por tanto todos aquellos elementos físicos que sean críticos, y que sean susceptibles de fallar, tienen que ser replicados de una u otra forma.
No hablo únicamente de RAID en los discos, o de copias de seguridad. También serían fatales una pérdida de energía eléctrica, o una caída de la conectividad. Los dispositivos físicos son por tanto susceptibles frente a los sucesos físicos, y esto nos lleva también a la seguridad de acceso. Es necesario establecer niveles de barreras físicas para garantizar que sea siempre personal acreditado el que actúe sobre las máquinas. La manera más sencilla de garantizar todo esto es contratar a alguien especializado, como son los CPD. Hoy en día la oferta de este tipo de empresas especializadas es enorme, podemos crear a golpe de clic toda una infraestructura cloud en un modelo de pago por uso. Conviene elegir una empresa que tenga una cierta trayectoria, e incluso solicitar una visita a las instalaciones siempre que sea posible. En caso de necesitar un CPD propio, es imprescindible contar con personal especializado tanto en la fase de diseño del mismo, como en su puesta en marcha y mantenimiento.
Igualmente, conviene prestar atención y estar al día en lo que respecta a vulnerabilidades que afecten a equipamiento auxiliar. Tal es el caso de switches, routers, balanceadores, equipamiento VPN, etc. Como ejemplo, recientemente se conoció una nueva vulnerabilidad que afecta a varios dispositivos de Cisco, o la reciente publicación de fallos de seguridad en dispositivos Siemens.
2.-Proteger los servicios
Hay que estar al día en seguridad web, crear estas nuevas interfaces de acceso supone enfrentarse a un escenario muy diferente al de una aplicación distribuida que no sea web. El punto de acceso de una aplicación web es mucho más público, y por tanto está expuesto a un mayor número de ataques, y a una morfología de ataque diferente. Aparecen dos nuevos elementos críticos: el servidor web, y la aplicación web. El primero es tecnología ya muy madura, y por tanto se trata más de hacer una elección correcta, contar con un buen administrador que sepa ponerlo a punto, defenderlo adecuadamente, y vigilar su estado. La aplicación web, en cambio, depende de la calidad del código y de las técnicas de programación que se hayan utilizado. El código web es muy propenso a ataques de inyección de código, inyección en base de datos, etc. Conviene utilizar un framework, sea propio o de terceros, que garantice la seguridad en las capas críticas tales como autenticación o acceso a base de datos. Las pruebas tanto de «caja negra» como de «caja blanca» pueden detectar posibles puntos susceptibles de ser atacados.
3.-Proteger el canal
Muchos tipos de ataques se centran en intentar controlar el canal de comunicación, habitualmente tomando el control de algún dispositivo de red en el lado del cliente (por ejemplo mediante un DNS Flooding a la puerta de enlace), o realizando un ataque a la red completa (por ejemplo un ARP Poisoning). Por eso, el primer paso es siempre cifrar en canal, utilizando como mínimo TLS 1.2. El mecanismo habitual en entornos web consiste en generar un certificado que se firma por una autoridad de certificación reconocida por el navegador del usuario. Si el canal no está cifrado, estamos dejando las puertas abiertas a todo tipo de ataques como MitM o session hijacking, lo que supone que un atacante podría conocer toda la información intercambiada entre servidor y usuario, además de poder suplantar la identidad del usuario.
4.-Seguridad en la autenticación
El hecho de cifrar el canal no quiere decir que el proceso de autenticación no sea sensible a ataques, como por ejemplo ataques de fuerza bruta, ataques basados en diccionario, o ataques de réplica de identificación. En el momento de diseñar el mecanismo de autenticación de nuestro sistema hay que prestar especial atención a los posibles espacios abiertos que puedan estar quedando. Conviene implementar técnicas como la autenticación por desafío (impide la réplica de identificación), limitación de intentos de acceso, cifrado del canal con TLS, etc. Es importante tener en cuenta también la comodidad del usuario en este proceso. Por ejemplo, el clásico “sistema de juego de barcos” (tarjeta de identificación por coordenadas) es un mecanismo muy seguro de autenticación, pero muy engorroso. En esta línea, tengo que reconocer que tengo bastantes expectativas puestas sobre el nuevo sistema de autenticación propuesto por yahoo, aunque todavía está por ver la aceptación que tiene por parte de los usuarios, y las implicaciones colaterales de seguridad que pueda tener.
5.-Educar al usuario
Por mucha seguridad que pongamos en los servidores, los servicios, el canal, y el proceso de autenticación, no servirán de nada si el usuario no tiene la educación e higiene necesaria como para entender que debe evitar que su dispositivo se infecte con virus y otro tipo de malware. Es importante explicar los peligros que entraña conectarse desde redes abiertas, la instalación de aplicaciones de dudosa procedencia, etc. Toda nuestra seguridad no valdrá para nada si el usuario tiene involuntariamente instalado un keylogger o un certificado malicioso. Muchos de los ataques más exitosos se basan en la falta de seriedad del usuario en lo que respecta a la seguridad, tal es el caso del popular ataque SSLStrip. Cualquier usuario concienciado con la seguridad inmediatamente será consciente de que el cifrado de su conexión ha desaparecido, ya que el propio navegador indica claramente el nivel de seguridad de la conexión. El usuario tiene que entender que estamos intentando proteger su información y su identidad, y que él es el precisamente el mayor interesado y el mayor responsable sobre sus datos.
Conclusión
La inclusión de interfaces ubicuas en cualquier plataforma requiere tener en cuenta las nuevas implicaciones de seguridad que supone, y es una excelente excusa para auditar, como mínimo, los cinco puntos principales expuestos en este artículo. Los usuarios, que están depositando su confianza en nuestros sistemas, merecen que trabajemos este campo con seriedad.