A menudo las organizaciones securizan su dominio protegible implantando una serie de controles tecnológicos que permiten impedir o en todo caso minimizar el impacto de actividades ilícitas por parte de terceras personal, o incluso las realizadas por el propio personal corporativo. Instalación de cortafuegos perimetrales, software de detección y eliminación de malware, proxys, sistemas de detección de intrusos y un largo etcétera, serían algunas de las medidas empleadas.
En este momento el responsable de TI de la organización siente una falsa sensación de seguridad, ya que descuida, entre otras cosas, las posibles vulnerabilidades latentes en el software de los servicios de DMZ. Normalmente estos servicios perimetrales (servidores de correo, DNS…) se sustentan en software de amplia distribución y con un soporte de actualizaciones de seguridad pero, ¿qué ocurre con la pagina web corporativa? Estos sites que ofrecen la imagen y la marca de la organización al resto del mundo son desarrollados de forma personalizada, sin un soporte, muchas veces, de actualizaciones de seguridad. Si quieres que corrija estos errores, paga el esfuerzo que requiere ese desarrollo adicional. Sí, esta frase es bastante común, dado que este tipo de situaciones no se contemplaron en el alcance del proyecto, ni se requirió que el desarrollo siguiera un marco de trabajo de desarrollo seguro.
En bastantes de las auditorias y test de intrusión de aplicativos web que S2 Grupo ha realizado, no sólo se obtuvo el control del site auditado (acceso a insertar modificar o eliminar el contenido de la web), sino que se pudo obtener numerosa información confidencial (credenciales de acceso a zonas privadas, números de cuenta bancarias, cuantas de correo electrónico, documentos confidenciales de la organización…), sin comentar la posibilidad de realizar ataques de phishing y robo de sesiones. Todo ello tan sólo a través de la página web de la corporación, esa ventana al mundo accesible desde el sitio más recóndito del planeta.
Para hacerse una idea de los potenciales puntos de entrada que un intruso tendría a través de la web basta con tener en cuenta el conjunto de parámetros POST y GET de los posibles recursos dinámicos (jsp, asp, php, cgi’s…), así como cookies o cualquier otro tipo de información que sea enviada desde el cliente para que el servidor la procese. En un site de tamaño medio donde su funcionalidad sea informativa y presente una zona privada, el total de puntos de entrada del atacante es inmenso.
He aquí el papel relevante que juega la seguridad en este tipo de servicios, y que en general se tiene totalmente descuidados. Pero, ¿cómo es posible mitigar estos riesgos? Pues aplicando principalmente dos estrategias:
- Usar un Framework de desarrollo seguro que se integre en el ciclo de vida de desarrollo del software.
- Realizar auditorias de seguridad, preferiblemente con test de penetración, cuyo alcance abarque tanto el análisis de las vulnerabilidades de la web como los permisos de la base de datos que la sustenta (en caso de que use, claro). Este último punto es de vital importancia porque en numerosas ocasiones los permisos del usuario de la BD que la aplicación utiliza son inadecuados, permitiendo obtener información que no tendría porqué ser accesible. Recordar que siempre hay que aplicar la máxima del mínimo privilegio.
A todo esto cabe añadir que las aplicaciones en general tienden cada vez mas a desplegar su interfaz gráfico hacia la web, e incluso programas típicos de edición de texto como Microsoft Word tienen sus homólogos en la web (ver Google Docs). Dado el auge de esta tendencia y la escasa preocupación por la seguridad de estos servicios, nos lleva hacia un panorama desolador e inseguro, haciendo necesaria la aplicación de controles preventivos y reactivos, que mitiguen estas amenazas para las organizaciones y usuarios particulares.
Pero, ¿quién tiene la responsabilidad de que estos fallos permitan al intruso acceder a la información confidencial? Indudablemente para mí, el programador web, que a menudo es contratado sin experiencia, no solo en seguridad sino en cuanto a skill de programación se refiere, por empresas que lo único que quieren es obtener un producto en poco tiempo, bonito y que cumpla las especificaciones requeridas por el cliente; preocupándose por la funcionalidad y descuidado el rendimiento y la seguridad de su plataforma. ¿Sería conveniente aplicar algún tipo de castigo? Una de las medidas que el equipo de auditoria del ACE Team de Microsoft aplica sobre sus proyectos de desarrollo es penalizar a los jefes de proyecto y programadores que desarrollen de forma insegura, reduciendo el presupuesto de sus proyectos según el número y grado de vulnerabilidades encontradas. Sería una opción a considerar.
Al respecto, y en la línea de lo comentado, la encuesta de esta semana es la siguiente:
(N.d.E.) En relación con la encuesta anterior, cuyo resultado les muestro debajo, ha quedado claro (siempre teniendo en cuenta el ámbito en el que nos movemos y el público de este blog) que en general, la preocupación por los datos gestionados por las (empresas propietarias de las) redes sociales es legítima y compartida por gran parte de nuestros lectores.
Roberto, me ha gustado tu post, y coincido contigo en todo (sin entraramos a profundizar podriamos estar dias, horas y eternas jornadas de cervezas charlando – seguro – ) pero veo tres aspectos fundamentales en los que te centras:
1 – seguridad de elementos de infraestructura.
2 – seguridad de codigo.
3 – Responsabilidad.
Y es aquí donde me gustaría lanzar una cuestión (cada uno que tenga su opinión) relativa a la seguridad empresarial: ¿la responsabilidad de la seguridad realmente recae sobre un único sujeto?¿y legalmente ante un fallo de los sistemas?
Ahora, el control de la información así como la gestión de los sistemas debe ser horizontal a la empresa, por lo tanto ¿que responsabilidad real existe en el desarrollador? ¿quien es el responsable de la calidad del software? – y la calidad engloba seguridad, hay que asumirlo de una vez –
Sí creamos software, ¿por que el comprador no nos exige resultados de seguridad? ¿por que no exige el resultado de metricas o testing en seguridad?
Si compramos sofware ¿por que el desarrollador no nos ofrece garantias de calidad asociadas a la seguridad y no solo a la funcionalidad? Lo del ACE Team de Microsoft esta bien, pero no me convence mucho.
Creo que el comprador también debe asumir su culpa, la de la no exigencia (por miedo al coste, claro, lo de siempre) de la seguridad (por que desconoce, por que no tiene cultura). Y luego va y se queja que de su página web alguién ha sacado sus usuarios…por favor.
Pero aún hay más, a menudo estamos acostumbrados a dividir las responsabilidades entre equipos de proyecto de desarrollo, de implantación y pruebas, y de explotación. Cada uno con su parcela, cada uno con sus métodos y con sus responsabilidades, pero el factor común en la seguridad es que la mala praxis en cada uno de estos grupos expone el sistema a fallos de seguridad y a fallos disponibilidad de los servicios y datos (Dejame que los diferencie). ¿A quien corresponde asumir la responsabilidad de la mala praxis de estos grupos y la exposición a fallos del sistema y/o vulnerabilidades? ¿a la metodología? ¿al responsable de seguridad? ¿al responsable de ‘presupuestos’? ¿al jefe de proyecto de cada uno de los grupos? ¿al operador/desarrollador/analista? ¿o a la empresa en general? ¿y legalmente?
La asignación de responsabilidades -para mi gusto- es como asegurar que por tener firmado un papel de confidencialidad se le puede dejar a un señor campar a sus anchas por los datos de la empresa, o que una politica de seguridad nos cubre de todos los males aunque no se disponga de medios para que se cumplan.
Al final, como todos sabemos, acabamos cargando contra el remero, y no contra el patrón.
Hola Francisco, en primer lugar agradecerte tu comentarío. Estoy totalmente de acuerdo con tu postura en cuanto a las responsabilidades finales de los posibles fallos de seguridad de las aplicaciones web. No se debe buscar un único responsable, pese a que mi persona instando a la provocación haya querido cargar a lomos de los programadores la responsabilidad de aberraciones como :
(menorque)?php
include($_GET[‘vuln’]);
?(mayorque)
o incluso…
SELECT * FROM usuarios WHERE nombre = ‘” + nombreUsuario + “‘; sin valildación y filtrado previo
Saludos.
Bueno, a veces tienes lo que pagas, si pagas becarios debes poner más atención, pese a que lo que deberias hacer es implantar controles de testing. En cualquier caso yo a este tío lo largaba a la calle…aunque si tiraramos a todos los que hacen males el paro se duplicaria. Es más, si esto llegase a ver la luz (me refiero al codigo) largaba al desarrollador, al jefe de proyecto, a los de pruebas(si los hay), al responsable de seguridad (si lo hay), al responsable de metodología (Si lo hay),… Lo que quiero decir es que estas cosas pasan muchas veces por falta de rigor, conocimiento, y por costes…y más de una vez ‘por mala leche’.
Como todos sabemos, cuanto más grande es el proyecto (en presupuesto) más se lleva el consultor y menos hay para el desarrollador…así que cuando pagas becarios, tienes becarios, si te saltas las fases de pruebas, si no usas frameworks que te alivien la carga de seguridad, si no eres preventivo…entonces la Web 2.0 te lleva al infierno.
Y sigo estando de acuerdo contigo, exceptuando que el desarrollador es el medio pero no el fin…
Cultura de seguridad o ‘la seguridad por contrato’??
Creo que antes de buscar responsabilidades se deben pedir garantías y este es un tema que los técnicos podemos recomendar.
Si el desarrollo no es propio, hay que tomar ciertas medidas para evitar los problemas de seguridad y esto tiene que venir reflejado en la oferta del proyecto. Tal como está el estado del ‘arte de la programación’ nunca vamos a tener una certeza absoluta de ser invulnerables, mucho menos en desarrollos hechos a medida, por eso, las salvaguardas, incluyen tener en cuenta la seguridad en ciclo de vida del software.
Por ejemplo, se debe incluir en los pliegos que los desarrollos seguirán las guías de desarrollo seguro del OWASP o pedir certificaciones como la de ISC2 , http://www.isc2.org/csslp/default.aspx además de que se verifique la validación sobre los errores más típicos de programación del SANS http://cwe.mitre.org/top25/
…
Posteriormente tendrá que ser preceptivo el pasar una auditoría (no automatizada) por parte de un centro independiente para que se valide la entrega de la aplicación.
Esto supondrá sobre costes puesto que no existe una seguridad absoluta, pero es lo menos que podemos pedir.