redseguridad 076

La defensa en profundidad María del Carmen Ortega Solís Gerente de Negocio de Servicios Gestionados en Ingenia se pidiese hasta la huella dactilar. Y que para hacer una operación hubie- se que pasar siete controles. Pero, entonces, la centralita de atención al usuario se colapsaría de llamadas. A esto se une que los cambios tecnológicos en este sector evolu- cionan constantemente. Desde un móvil se pueden realizar (según las distintas entidades) operaciones, compras, pagos en establecimien- tos, anular tarjetas, etc. Y lo que nos queda por inventar… Defensa en profundidad Entonces, ¿qué hay que hacer para mantener los servicios seguros? La recomendación es poner en práctica lo que se conoce como "defensa en profundidad"; esto es, no se pone una barrera sino todas, de manera que si en ese equilibrio seguridad-funciona- lidad hay un punto de debilidad, no pueda ser explotado porque el resto de medidas lo haga imposible. Las barreras son: „ Seguir unas normas de pro- gramación y buenas prácticas para desarrollos seguros, prestan- do especial atención a los sitios de intercambio de información (formu- larios), campos de entrada en la URL, gestión de sesiones y flujos de navegación, así como realizar análi- sis periódicos de código fuente. „ Sistemas bastionados. Esto es, configurar los sistemas y aplicacio- usuarios tuvieran que actualizar sus navegadores o dejarían de tener ser- vicio, y ello incluía administraciones y empresas en las que el usuario no decidía su política de actualización. Esto es un ejemplo ilustrativo que a estas alturas está superado en las organizaciones con una gestión de la seguridad responsable. Con poste- rioridad a Poodle se han detectado más vulnerabilidades que han afec- tado a los protocolos más seguros, cada una con su impacto. El objetivo del ejemplo es mostrar cómo la seguridad no es un tema unilateral que es cosa de los expertos. Hay que tener en cuenta quiénes son los "clientes" de Internet y encon- trar un equilibrio entre la seguridad del servicio y la permisividad en las condiciones exigidas a los usuarios. Obviamente, no es lo mismo una web informativa en puro html que un ser- vicio con intercambio de información sensible; todo en su justa medida. ¿Qué ocurre con la banca elec- trónica? Se trata de un servicio muy delicado donde el usuario es cual- quier persona que tenga una cuenta bancaria y acceso a Internet. Los usuarios potenciales son muchos y no todos pueden tener el navegador actualizado ni saben de protocolos o configuraciones. A todos los responsables de segu- ridad les encantaría tener un formu- lario de acceso al servicio en el que E n octubre de 2014 se publicó una vulnerabilidad relacionada con el pro- tocolo SSL 3.0 denominada Poodle . Descubierta por un grupo de inves- tigadores de Google, fue muy difun- dida debido a que permitía descifrar fácilmente mensajes que debían ser "seguros". Pero el SSL 3.0 tenía ya más de 15 años. Entonces, ¿por qué había que preocuparse de ella? Los protocolos TLS ( Transport Layer Security ) llevaban tiempo funcionan- do con un sistema de cifrado más seguro y habían evolucionado hasta en tres versiones (1.0, 1.1 y 1.2). El ataque para explotar esta vulne- rabilidad se realizaba en dos fases. La primera, que es la verdadera fortaleza del mismo, consistía en aprovechar la compatibilidad que mantenían los navegadores para adaptar su operati- vidad ante la variedad infinita de sitios que hay en Internet. Si un navegador intentaba establecer una conexión segura con el protocolo más fuerte y la misma fallaba, comenzaba a probar con otros más débiles hasta obtener la negociación requerida y visitar el sitio; de esta manera, se forzaba el uso del protocolo vulnerable. La protección era actualizar o con- figurar los servidores web para que no permitiesen accesos con cifrados débiles o cambiar la configuración del navegador. Una configuración en el servidor limitada al último protoco- lo disponible suponía que muchos banca online opinión 76 red seguridad primer trimestre 2017