24 junio 2009

¿Construimos Software Seguro?

¿Por qué encontramos tantos fallos de seguridad en los desarrollos una vez éstos han subido a producción? Pensemos por un momento en las aplicaciones de Internet y en la cantidad de veces que se han reportado vulnerabilidades que permitían acceder a las bases de datos de los clientes por culpa de fallos en los desarrollos. La seguridad juega un papel muy importante en estos productos y no se le presta la atención que merece.

Conozco casos donde los desarrolladores reportan la ausencia de requisitos de seguridad a sus responsables y las excusas por parte del equipo de diseño siempre suelen ser las mismas: no hay tiempo, los plazos son escasos, no hay presupuesto. Pero luego a quienes se apunta con el dedo cuando empiezan a aparecer los bugs, es a los desarrolladores.

¿No sería mejor empezar a pensar en seguridad desde que comienza el ciclo de vida del software y no después de subir el producto a producción, cuando los costes se vean aumentados por la necesidad de tener que aplicar parches y más parches?.

Las organizaciones deben definir una serie de prioridades y la mayoría de las veces la seguridad no suele ser de alta prioridad. A menudo, no es rentable hacer un sistema tan seguro como sea posible, ya que el riesgo es bajo y el coste es alto.

Cuando recibimos los estudios de viabilidad de los clientes, revisamos en busca de requisitos de seguridad pero éstos son escasos y en muchas ocasiones inexistentes. Si los analistas son buenos éstos se encargan de incluir algunos, pero como las estimaciones de los proyectos suelen ser en la mayoría de los casos muy ajustadas, tienden a omitirlos.

El software está en la raíz de la mayoría de los problemas de seguridad informática, si éste no se comporta de forma adecuada surgirán problemas de integridad, disponibilidad, confidencialidad... Los bugs y vulnerabilidades son la causa de un mal diseño y una mala implementación. Debemos empezar a concienciarnos: la seguridad debe estar presente en todas las fases del ciclo de vida de un producto.


En el inicio, durante la fase de análisis se debe realizar un análisis de impacto y pensar en las amenazas y vulnerabilidades a las que puede verse afectado nuestro producto, para ello debemos incorporar modelos de amenazas. Además todo arquitecto debe recoger: las políticas, los riesgos y las normas jurídicas.

En la fase de diseño se debe realizar un análisis de riesgos, el cual debe ser realizado por expertos en seguridad quienes son capaces de reconocer en que situaciones se producen los ataques más comunes. Durante la fase de implementación, si los programadores necesitan formación en seguridad, se les debe de proporcionar dicha formación.

En el plan de pruebas funcionales, también debe estar presente la seguridad ya que pueden surgir nuevas salvaguardas a incluir. Se deben incluir pruebas de seguridad, test de intrusión, pruebas de carga, pruebas de denegación de servicio y planes de mitigación de riesgos. En estos casos podemos utilizar herramientas para el análisis de vulnerabilidades como:

Además debemos incluir una buena auditoría, ya que es una parte esencial en la seguridad del software.

Pero todas estas medidas no se harán efectivas si no están incluidas en el Gobierno de TI, es decir, si no hay concienciación en materias de seguridad desde las altas esferas.

Es extraordinariamente rentable invertir en seguridad en las etapas iniciales del proyecto, podemos hablar de ahorros del 20% (Secure Business Quarterly)

En definitiva, se recomienda establecer los controles desde que se establecen los requisitos. Os recomiendo la lectura de Systems Security Engineering Capability Maturity Model (SSE-CMM) y dar un paseo por OWASP.

13 comments :

Dani dijo...

Creo que uno de los mayores problemas que se siguen usando lenguajes inseguros como C en lugar Ada. Alguien piensa igual?

José A. Guasch dijo...

@Dani, yo creo que el gran problema sigue siendo los que están entre teclado y silla.

Hay lenguajes en los que se confía en la seguridad o mecanismos por defecto que ofrecen, muchos no ponen su empeño y simplemente programan diciendo "haga lo que haga, no fallará, porque es imbatible", y cuando en cierta conferencia te presentan mecanismos que echan por tierra esos métodos, te tiras de los pelos, te tiran de los pelos y ves como tu forma de trabajo de los últimos años se va al traste.

La seguridad debe ser un conjunto de todo.

Anónimo dijo...

El cliente es el primero que no pide seguridad en la aplicaciones.

Ayer me contaron un caso: pantalla de login/pass para un acceso de clientes. El arquitecto le dice al cliente de ponerle un captcha, y el cliente responde: Un Captcha?? qué es eso?? eso no es de Google??

Increíble pero cierto.

:D

Johann dijo...

Pienso que existe la tendencia a pensar que solo algunos sectores son susceptibles (ejemplo: sector financiero), estos son los que suelen implementar más mecanismos y controles de seguridad, si en un proyecto los plazos a cumplir son cortos, y el equipo de desarrollo no puede destinar el tiempo suficiente a diseñar una arquitectura segura y probarla, es muy probable que se invierta luego mucho más en arreglar estos bugs que se detectan después, o peor aún que no se detecten.

Y aunque una o más personas del equipo estén comprometidos con hacer software seguro, no es suficiente, se necesita aprender a transmitir de la manera más entendible posible este concepto a los responsables y stakeholders del proyecto, para que sea un requerimiento y no simplemente una iniciativa extra de algunos pocos.

Anónimo dijo...

@Johann: Estas en lo cierto, hay sectores donde el cliente si solicita mayor seguridad (administración pública, sector financiero), y por cumplir con los plazos de entrega e incluso por toparse con "malos diseñadores" quienes tienen pocos conocimientos de seguridad, el resultado final es un aplicación poco robusta y con muchos bugs.

Saludos

Asfasfos dijo...

Yo creo que es un problema de mentalidad y de base, los programadores quieren sacar el trabajo echando leches porque les meten presión y luego lo hacen como lo hacen...además de que casi ninguno tiene conocimientos de seguridad ya que no se los han dado y ni ganas que tienen de aprenderlos por separado.

Por no hablar de que las pruebas que se realizan para que el software sea funcional...y ya sabeis que cuanta mas seguridad tiene un software menos funcional es este...vamos que quedan muchos años en España para que cambie esto :)

Lobosoft dijo...

La verdad es que no, no construimos software seguro. Como ya se ha apuntado por aquí, priman las prisas, el tener que sacar el producto a tiempo a pesar de estimaciones en las que hay que hacer un F1 en el tiempo que se tarda en montar un mueble del IKEA, donde si les dices a los clientes, o a las altas esferas, que convendría tener algo más en cuenta la seguridad de la aplicación te preguntan, primero que para qué, y después si vas a tardar menos con eso. Y al final,no se hace.

Afortunadamente, hay proyectos en los que sí se tiene en cuenta, pero si no se hacen ni pruebas unitarias ni funcionales, menos aún se harán de seguridad. Y así nos va...

Anónimo dijo...

Pues estoy un poco de acuerdo, con todos y con ninguno.

Personalmente, soy uno de esos programatas que le fascina la seguridad. Mi empresa tiene su metodología certificada y lo que quieras, donde hay un pequeño apartado para el risk managament. Si el propio diseñador, te pone los ojos como platos cuando tu le recuerdas que eso existe en la metodología, de la que sus superiores piensan que es un super-dotado, ¡pues vaya!.

En general, no hay bugs, sino malos requisitos, y por ende mal diseño, análisis y planificación.

Eso de que las administraciones públicas piden seguridad, ¡en fin!, debe ser en los concursos en los pliegos que se presentan para que quede bonito; porque luego me consta que como bien se dice ni siquiera se hacen unas pruebas unitarias o funcionales concienzudamente, sino es para cumplir la metodología de cara a la galería.

Respecto a ADA, pues si hombre si, en principio, ya se sabe, va en los tanques, la propia Indra, utiliza en Torrejon este lenguaje para sus simuladores de vuelo, pero exento de errores no esta, y también de buena cepa se, que son proyectos autocontenidos es decir, no hay casi documentación, y ó existen muy buenas practicas en todo el código "legacy" y alla se las componga el que llegue, o mejor te casas con el proyecto de por vida, porque es la única manera de enterarte bien por donde van los tiros... Es como si te dan un ferrari o un volvo y no usas cinturón, sin una cabeza pensante, con capacidad de análisis, sin una metodología, un rigor y sentido común, ADA es tan malo, como cualquier otro lenguaje o quizas peor, porque te puede llevar a pensar que estas seguro hasta que te explota el avión.

En conclusión, a mi me parece que el verdadero problema, y más aún en España, es desgraciadamente, que se diga lo que se diga, no se valora la formación, ni las ganas de hacer bien las cosas, ni la elegancia en el código (veáse mantenibilidad, robustez, cálidad y seguridad), no se valora la honradez ni la ética profesional.

Al final todo el mundo pasa por el aro, y el problema es realmente cultural, y no tanto de tu equipo de programadores o coetaneos sino de la estructura y piramide de desarrollo profesional, donde triunfa más el mamoneo, los chupagaitas, las sonrisas baratas, y el como llevo 10 años trabajando, da igual que en mi p. vida me haya preocupado de leer un puñetero libro de patrones o de saber lo que es un "plan de ataque" y una batería de pruebas bien hechas, porque yo lo valgo, me se muchas palabritas de tecnologías diferentes, soy amigo del jefe, y además soy un fiera, cobrando por un sw, que después voy a volver a cobrar por mantenerlo. ¡Graso error!, claro esta, pero resulta que en el otro lado (organización cliente), me da igual banco, aerolinea o empresa gubernamental, triunfa el mismo cantar, ES UN CIRCULO VICIOSO.

Saludos. ¿Quién vigila a los vigilantes?

PD: 71000 libras/año por programar reconocimiento facial en Reino Unido (3 años de experiencia, lenguaje C++, paradigma sencillez). Dan ganas de intentar cambiar las cosas desde el extranjero, ¿no?.

c4x30x dijo...

yo considero que no existe una seguridad de 100% ya que el ser humano no es perfecto y siempre va a haber alguien que supere ideas que "son seguras", pero la idea es que se construya software de calidad y seguro ante todo o al menos intentando volverlo seguro, hombre por lo menos a todos los ataques conocidos, algo que es muy importante es crear concientizacion ya que la seguridad comienza por el usuario.

Zerial dijo...

Muchas veces el cliente no quiere la seguridad, no por ignorancia, sino porque es tipico que lo quieran lo antes posible. Cuando uno les presenta una propuesta que incluya test de la aplicacion, implementaciones y mejoras de seguridad, etc etc lo rechazah, porque obviamente se demora mas.
Por otro lado me ha tocado que cuando piden un sistema con login, pass, captcha y todas esas cosas, los usuarios terminan poniendole user admin y pass admin. Problema de capa 8, entre la silla y el teclado.

Apesar de todo esto, quiera o no lo quiera el cliente, creo que los desarrolladores debemos hacer las cosas lo mas seguras posibles.

Anónimo dijo...

Alguien sabe si existe alguna certificación internacional tipo ISO para la fase de desarrollo de sofware seguro? sobretodo para el codigo. Gracias.

Anónimo dijo...

@Anónimo: a ver si te sirve esto.

ISO 27001 Software Development Lifecycle Vulnerabilities Checklist

Lo puedes descargar:
http://www.itservicestrategy.com/iso-27001-software-development-lifecycle-vulnerabilities-checklist

Un saludo

Laura García dijo...

@Johann: Estas en lo cierto, hay sectores donde el cliente si solicita mayor seguridad (administración pública, sector financiero), y por cumplir con los plazos de entrega e incluso por toparse con "malos diseñadores" quienes tienen pocos conocimientos de seguridad, el resultado final es un aplicación poco robusta y con muchos bugs.

Saludos