Cargando
SecurityInside.info
  • Sobre SecurityInside
  • GitHub
  • Click to open the search input field Click to open the search input field Buscar
  • Menú Menú
  • Link to X
  • Link to Rss this site
  • Link to Youtube

Listado de la etiqueta: microsoft sdl

«Application Security» con Microsoft SDL

14 marzo, 2018/en Desarrollo, Formación, Gobierno IT, ISO 27001, Vulnerabilidades/por Cristóbal Espinosa

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?

https://cdn.securityinside.info/microsoft-sdl.png 450 800 Cristóbal Espinosa https://securityinside.info/wp-content/uploads/logo.png Cristóbal Espinosa2018-03-14 13:25:542024-11-06 12:21:30«Application Security» con Microsoft SDL
auditar-api

Revisando nuestros servicios: auditar API (parte 1)

15 febrero, 2017/en Auditoría, Desarrollo, Pentesting/por Cristóbal Espinosa

Poder ofrecer la información de valor que genera tu empresa de una forma eficiente y segura es tan importante que puede ser el punto de inflexión entre convertirla en un Unicornio o llevarla directamente a la ruina.

En el mundo de hoy, contar con una buena API que permita a terceros consumir tu información te va a permitir extender tu negocio más allá de lo que puedes ofrecer de forma individual. Es habitual conceder acceso a una parte pública de la información, pero otra parte sensible suele estar vinculada a algún contrato, cuota o condiciones particulares.

Una API abierta a terceros te permitirá abrir tu información y servicios a todo tipo de clientes, gestionando hasta dónde quieres que puedan llegar. Sólo tienes que ponerte a desarrollar en tu proceso de integración continua, darle caña a las pruebas unitarias, los test de integración, la documentación y todo lo que tu metodología dicte. Por fin tienes una API de calidad dispuesta a echar humo con miles de clientes y…

…entonces llego yo y te pregunto… ¿has tenido en cuenta la seguridad en el ciclo de vida de tu API?

Tu respuesta tiene una alta probabilidad de ser «ehhh…. no!». Lo normal es que sea así y que se hayan cometido errores de desarrollo que impliquen vulnerabilidades en nuestra API que puedan impactar en nuestro producto.

¿Como incorporo la seguridad a mi API?

api_security

Si no has empezado a desarrollarla, entonces te recomiendo que tengas en cuenta algún modelo como «Microsoft Security Development Lifecycle» (echando un vistazo aquí, aquí o aquí, aunque hablaremos de esto en breve) y lo hagas bien desde el principio.

Si ya tienes tu API funcionando, en la próxima entrada realizaremos una pequeña prueba que te puede ayudar a evaluar su seguridad.

En cualquier caso, deberías tener en cuenta siempre estos checks básicos:

1) Fase de Autenticación:

  • Habilita tu API únicamente con SSL, todos los accesos debería ser https. Prohibe http o dale un uso meramente informativo.
  • Nunca envíes usuarios, contraseñas, tokens… en la url.

2) Fase de Autorización:

  • Pon especial atención en el escalado de privilegios tanto en horizontal como en vertical.
  • Acentúa los controles en las peticiones que actualicen o eliminen información.
  • Utiliza roles para administrar permisos de tus usuarios.
  • Protege al máximo las funcionalidades destinadas a usuarios administrativos.

3) Gestión de sesión:

  • Habilita un tiempo máximo de sesión (timeout).
  • Asegúrate de tener medidas para invalidar tokens si es necesario.

4) Validación de entradas:

  • Los ataques web habituales pueden afectar a tu API, así que pon atención en los conocidos ataques de injección, xss…

5) Codificación de salidas:

  • Revisa bien la estructura de tu salida json, xml,…
  • Inserta cabeceras de seguridad acordes al uso que se le va a dar a tu API.

Empieza por echar un vistazo a estas recomendaciones. En la próxima entrada seguiremos viendo detalles para tener tu API lo más segura posible. ¿Te lo vas a perder?

https://www.securityinside.info/wp-content/uploads/auditar-api.png 450 800 Cristóbal Espinosa https://securityinside.info/wp-content/uploads/logo.png Cristóbal Espinosa2017-02-15 11:34:422024-11-06 12:22:17Revisando nuestros servicios: auditar API (parte 1)

Categorías

  • Anonimato (18)
  • Auditoría (30)
  • Charlas y ponencias (68)
  • Cloud Security (9)
  • Control de acceso (29)
  • Desarrollo (32)
  • Dispositivos (19)
  • Eventos (25)
  • Exploiting (6)
  • Forense (6)
  • Formación (39)
  • Gobierno IT (36)
  • Hacking (20)
  • Herramientas (26)
  • I+D (13)
  • Ingeniería inversa (6)
  • ISO 27001 (10)
  • Live (20)
  • Malware (22)
  • Noticias (54)
  • Pentesting (12)
  • Privacidad (39)
  • Sin categoría (1)
  • Vulnerabilidades (24)

Archivo

  • mayo 2026
  • abril 2025
  • septiembre 2024
  • junio 2024
  • abril 2024
  • marzo 2024
  • enero 2021
  • septiembre 2020
  • abril 2020
  • febrero 2020
  • enero 2020
  • octubre 2019
  • septiembre 2019
  • julio 2019
  • junio 2019
  • mayo 2019
  • abril 2019
  • febrero 2019
  • enero 2019
  • octubre 2018
  • agosto 2018
  • mayo 2018
  • abril 2018
  • marzo 2018
  • febrero 2018
  • diciembre 2017
  • noviembre 2017
  • octubre 2017
  • septiembre 2017
  • julio 2017
  • junio 2017
  • mayo 2017
  • abril 2017
  • marzo 2017
  • febrero 2017
  • enero 2017
  • diciembre 2016
  • noviembre 2016
  • octubre 2016
  • septiembre 2016
  • julio 2016
  • junio 2016
  • mayo 2016
  • abril 2016
  • marzo 2016
  • febrero 2016
  • enero 2016
  • diciembre 2015
  • noviembre 2015
  • octubre 2015
  • septiembre 2015
  • agosto 2015
  • julio 2015
  • junio 2015
  • mayo 2015
  • abril 2015
  • marzo 2015
[2015 - 2024] - SecurityInside.info - Segura gracias a Defender Eye
  • Link to X
  • Link to Rss this site
  • Link to Youtube
Desplazarse hacia arriba Desplazarse hacia arriba Desplazarse hacia arriba