“Application Security” con Microsoft SDL

El otro día estaba en una entrevista de trabajo en el que me preguntaban si tenía experiencia en metodologías de desarrollo seguro de software. Tras salir de allí pensé que nunca había escrito por aquí sobre ese tema y es algo que me costó encontrar cuando me quise enfrentar al reto de asimilarlo. Es por eso que os traigo la primera de varias entradas, ¡espero que os gusten!

Cuando trabajas como responsable de seguridad, participar en los procesos de desarrollo de software es una de las tareas en las que tienes que dar lo máximo.

Como es lógico, las aplicaciones estarán expuestas a todo tipo de usuario. Puede que sean para uso interno (limitando un poco la exposición) o pueden estar abiertas al mundo, pero siempre serán un objetivo para los fallos “espontáneos” o “buscados” de seguridad.

En la forma de trabajo que hemos tenido hasta “hace cuatro días”, se desarrollaba siguiendo un modelo Waterfall, el que se daba (se sigue dando?) en la Universidad en la que todo tenía una secuencia inalterable basada en:

  • Toma de requisitos
  • Diseño
  • Desarrollo
  • Pruebas
  • Mantenimiento (tras lanzamiento)

Todo muy encorsetado, siendo complicado arreglar ciertos problemas o añadir nuevos requisitos sobre la marcha. Es cierto que se logra una mejora al añadir la implementación de prototipos, lo que podría verse como un leve precursor del modelo agile.

En cualquier caso, utilizar este modelo ha llevado en muchas ocasiones a algo parecido al extreme programming donde se termina por lanzar a la papelera el diseño y los requisitos para realizar desarrollos inmersos en un éxtasis de locura, infinidad de horas y mucho café.

El problema de este tipo de forma de trabajar es que da lugar a todo tipo de fallos de seguridad, sobre todo en viejos modelos de pruebas de seguridad “binarios”, lo que se traduce en “si da tiempo hago alguna prueba y si no…, pues no”.

Como podrás entender, en un mundo en el que cada vez hay más tecnología, en el que todo está conectado y en el que los problemas de seguridad pueden arruinar literalmente negocios y grandes empresas, esa forma de desarrollar ya no es viable.

Microsoft y la seguridad

La multinacional de Redmond archiconocida por el sistema operativo Windows, desde hace años colabora de forma sistemática con gobiernos y organizaciones en la búsqueda de las mejores prácticas en materia de ciberseguridad.

Una muestra de esto es su definición del ciclo de vida de desarrollo seguro, más conocido como Microsoft SDL, que se estableció internamente para todos los desarrollos desde el año 2.004.

Como ejemplo, podemos ver cómo los productos Microsoft han mejorado sustancialmente con respecto a los fallos graves de seguridad detectados antes y después de la puesta en práctica del modelo.

Figura 1 – Boletines de seguridad importantes y críticos de Windows antes y después del SDL

Figura 2 – Boletines de seguridad de SQL Server 2000 antes y después del SDL

Figura 3 – Boletines de seguridad para Exchange Server 2000 antes y después del SDL

Introducción a Microsoft SDL

La metodología que nos presenta Microsoft SDL se basa en tres conceptos principales que tendremos que tener siempre en cuenta:

Formación: todos los roles tanto técnicos como de gestión dentro de un proyecto deben estar debidamente formados en seguridad. Puesto que cada día aparecen nuevas vulnerabilidades y nuevos ataques, la formación debe ser continua en el tiempo y de la mejor calidad posible.

Mejora continua: es importante comprender la causa y el efecto de cada vulnerabilidad para evaluar de forma periódica todos los procesos, así podremos implementar los cambios que sean necesarios.

Responsabilidad: será muy importante archivar toda la información necesaria para realizar el mantenimiento de una aplicación cuando aparezcan los problemas. Tener un plan de detección y respuesta ante incidentes de seguridad nos permitirá poner en movimiento a todas las partes implicadas en el mismo.

Es por eso que el modelo de Microsoft SDL se estructura en cinco áreas de capacidades alineadas con las fases clásicas de desarrollo de software:

  • Formación, directivas y capacidades organizativas
  • Requisitos y diseño
  • Implementación
  • Comprobación
  • Lanzamiento y respuesta

Con el paso del tiempo y la creciente utilización de metodologías ágiles, Microsoft ha implementado una versión especial del SDL para este tipo de forma de desarrollar. Dicho modelo lo iremos viendo en las próximas entradas.

¿Te lo vas a perder?

SecurityInside Live: CyberCamp 2017

CyberCamp es el gran evento de ciberseguridad que INCIBE organiza anualmente con el objetivo de identificar, atraer, gestionar y en definitiva, ayudar a la generación de talento en ciberseguridad que sea trasladable al sector privado, en sintonía con sus demandas. Esta iniciativa es uno de los cometidos que el Plan de Confianza en el ámbito Digital, englobado dentro de la Agenda Digital de España, encomienda a INCIBE.

CyberCamp 2017 se celebra en el Palacio de Exposiciones y Congresos de Santander, del 30 de noviembre al 3 de diciembre de 2017. El principal objetivo de CyberCamp es identificar, atraer e impulsar a todos aquellos que tengan talento en materia de ciberseguridad:

  • Identificar trayectorias profesionales de los jóvenes talentos.
  • Llegar a las familias, a través de actividades técnicas, de concienciación y difusión de la ciberseguridad para todos.
  • Despertar e impulsar el talento en ciberseguridad mediante talleres y retos técnicos.

Si no puedes asistir, no te preocupes ya que emiten los Talleres y Conferencias en directo a través de videostreaming:

 

Leer más

aws-summit-madrid-16

SecurityInside Live: AWS Summit 2017

Tanto si eres nuevo en la nube o un usuario experimentado, no pierdas la ocasión de descubrir las últimas novedades Cloud en el Summit AWS de Madrid. Este evento gratuito está diseñado para presentar a nuevos clientes todas las funcionalidades sobre la plataforma AWS, y ofrecer a los clientes existentes información sobre las mejores prácticas de arquitectura y nuevos servicios.

El Keynote del AWS Summit de Madrid presentará Adrian Cockcroft, Vice President Cloud Architecture Strategy de Amazon Web Services. Durante su discurso de apertura, presentará las últimas novedades sobre las soluciones de AWS y podrás escuchar grandes historias de éxito de clientes AWS. Después del Keynote, podrás escoger entre diferentes sesiones dependiendo de tus intereses.

Leer más

security-api

Security API – Dale a tus empleados lo que necesitan (de forma segura)

Hace poco vimos en SecurityInside consejos a tener en cuenta para revisar la seguridad de tu API. Como comentamos, ofrecer servicios de información en el mundo de hoy si no tienes API, te da una desventaja considerable que podría terminar por arruinar tu negocio.

Es por eso que tu departamento de desarrollo debe tener en mente trabajar en una buena api (sencilla y segura) que de servicio tanto a clientes como a las plataformas y herramientas internas.

Hay muchas formas de desarrollar APIs, pero en mi caso me he decantado últimamente por Flask para Python sobre Elastic Beanstalk de Amazon Web Services.

Security API, ¿por qué?

Cada vez que arranco un proyecto de seguridad con una nueva empresa, me presento desde el punto de vista de vida laboral. Cuento mis años como becario, desarrollador, jefe de proyecto, consultor y luego el paso al mundo de la seguridad. Me miran como diciendo “¿para qué todo este rollo?”. Sencillo, es la forma de introducir que soy un apasionado de la seguridad y que mi objetivo principal es asegurar los activos de la empresa, pero siempre tratando de hacer la vida sencilla a los compañeros que tienen que lidiar con todas las medidas y controles de seguridad que se implanten.

Conozco profesionales de la seguridad que nunca se han manchado las manos picando código y que aplican medidas maravillosas que fortifican los activos mientras complican el trabajo diario. Lo importante es la seguridad, pero mi perfil de desarrollador me hace pensar siempre en hacerlo de forma que ellos tengan todas las facilidades para trabajar. Seguros, pero trabajando.

Por todo esto, hace no mucho empecé a dar vueltas a la idea de crear una “security api” que diera servicio a determinadas necesidades de los compañeros de los diferentes departamentos. De esta forma, aplico medidas de seguridad generales y les doy la posibilidad de solicitar ciertos permisos, accesos, … de forma automática en base a roles.

¿Cómo funciona?

Básicamente todo funciona en base a usuarios que se autentican con login, password y 2fa (Google Authenticator, Android, iOS). Cada usuario tiene un rol y subrol con el que se indica qué cosas tienen permitidas y todo se gestiona mediante JSON Web Tokens.

Flask api template

Os he dejado en Github un nuevo repositorio que contiene el esqueleto de una api desarrollado en Python utilizando la biblioteca Flask.

Podéis lanzarlo en local para desarrollo y hacer pruebas de forma sencilla utilizando Postman, ya que os he dejado también un fichero con ejemplos de uso. Tendréis queja… 😀

Vamos viéndo cosillas

En el fichero principal (flask_api.py) veréis unas cuantas cosas que os voy a ir explicando.

Al principio, tenéis una función que se lanza tras arrancar el server, ahí se pueden configurar diferentes cosas (dar de alta la ip del server en determinados grupos de seguridad, enviar notificaciones, …):

Después se incluyen dos apartados para la gestión de códigos 404 y 405:

Una siempre interesante función ping para comprobar rápidamente si el server está vivo:

La parte más interesante del ejemplo, la gestión del login y creación del token:

Y la implementación concreta dentro del fichero flask_api_functions.py:

Para entender ciertas cosas como la forma de enviar el header “Authentication”, pásate por el README.md del repositorio y ejecuta las pruebas con postman, verás que es la mar de sencillo.

El ejemplo es sólo parte del script completo. Si quieres utilizarlo o modificarlo, puedes descargarlo desde nuestro repositorio en GitHub.

 

Importante antes de terminar

Flask no está preparado para funcionar directamente en un entorno de producción, para hacerlo tienes que tener en cuenta un par de cosas (está todo en la documentación del repositorio).

En mi caso particular, ya os he dicho que lo tengo montado en Elastic Beanstalk de Amazon Web Services, si queréis os puedo contar cómo lo he hecho en otra entrada.

Por supuesto, si tenéis alguna duda sobre esta entrada, preguntad que estaré encantado de echar una mano.

Saludos!

SecurityInside Live: Check Point Cyber Day 2017

La omnipresente transformación digital y el Internet de las Cosas piden cambios fundamentales en el presente y futuro de la ciberseguridad. Los últimos ataques ocurridos a nivel mundial demuestran la necesidad de implementar estrategias innovadoras para securizar las empresas.

Hoy asistimos al Check Point Cyber Day 2017, una jornada dedicada a los CIOs, CISOs, IT Security Managers y todos los interesados en conocer el futuro de la ciberseguridad de la mano de expertos nacionales e internacionales en esta materia.

Leer más