OWASP, Open Web Application Security Project o Proyecto Abierto de Seguridad en Aplicaciones Web, es un proyecto que tiene como finalidad mejorar la seguridad en las aplicaciones web.
También es una comunidad abierta, dedicada a permitir que las organizaciones desarrollen, adquieran y mantengan aplicaciones en las que se pueda confiar.
El proyecto OWASP está respaldado por la Fundación OWASP, la cual nace el 1 de diciembre de 2001 y está registrada como organización sin ánimo de lucro en Estados Unidos desde el 21 de Abril de 2004.
Entre sus actividades destacan:
- Proyectos de software de código abierto liderados por la comunidad
- Más de 200 capítulos locales en todo el mundo
- Decenas de miles de miembros
- Conferencias educativas y de formación líderes en la industria
En su página nos indican cuales son los valores clave que definen al proyecto, según sus palabras, tienen un carácter:
- Abierto: Todo en OWASP es radicalmente transparente desde nuestras finanzas hasta nuestro código
- Innovador: Fomentamos y apoyamos la innovación y los experimentos para encontrar soluciones a los desafíos de seguridad del software.
- Global: Se anima a cualquier persona en todo el mundo a participar en la comunidad OWASP.
- Integridad: Nuestra comunidad es respetuosa, solidaria, veraz y neutral con respecto a los proveedores.
Por todo ello y por su carácter abierto, al acercarnos a OWASP podremos ampliar contactos con otros miembros de la comunidad (networking), iniciar o si ya se tienen, aumentar los conocimientos en seguridad y acceder a la posibilidad de participar en los proyectos que ya existan o crear otros nuevos.
Hay que resaltar que se trata de una organización sin ánimo de lucro a la que se incorporan, en forma de patrocinadores o socios, organizaciones comerciales, lo que crea una sinergia en la que se benefician todas las partes, ya que suelen funcionar por consenso para conseguir sus objetivos comunes.
OWASP es conocido, entre otros muchos proyectos, principalmente gracias a la clasificación en 10 categorías ordenadas que hace de los riesgos más críticos de las aplicaciones web.
OWASP Top 10
El proyecto OWASP Top 10 se inició en 2003 y es una lista de las diez categorías de riesgos de seguridad más críticos para las aplicaciones Web. Cabe destacar que la lista se elabora mediante consenso.
En sus inicios, el documento tuvo como objetivo concienciar a desarrolladores y gestores, y actualmente es el estándar de facto para la seguridad en las aplicaciones.
Además, en la página del Top 10, podemos encontrar resaltada la frase:
Reconocido mundialmente por los desarrolladores como el primer paso hacia una codificación más segura.
Con lo que se está invitando a que el documento sea el punto de partida para incorporar, a la propia cultura de los individuos y las organizaciones, el desarrollo seguro y minimizar así los riesgos en sus aplicaciones web.
Desarrollar software teniendo en cuenta los riesgos más críticos de las aplicaciones web, permite alcanzar un hito importante en el camino hacia el desarrollo de software seguro, además del reconocimiento implícito del sector.
Evento y conferencias de lanzamiento 2021
La versión 2021 de OWASP Top 10 fue lanzada el viernes 24 de septiembre de 2021, acompañada de una serie de conferencias gratuitas con una duración total de alrededor de 24 horas, las cuales se celebraron desde ese mismo viernes hasta el sábado siguiente.
El evento fue difundido en vivo por YouTube, y los vídeos fueron grabados además en la propia plataforma, aunque durante un periodo de tiempo los enlaces no serán públicos y es necesario registrarse para obtener los enlaces a ellos. Posteriormente los vídeos serán publicados en el canal OWASP Foundation de YouTube.
Cómo se obtuvieron los datos para OWASP 2021
Los datos para generar las categorías de riesgos y su clasificación se obtuvieron siguiendo una aproximación híbrida.
Las ocho primeras categorías se deciden en base a datos del análisis de alrededor de 500.000 aplicaciones, cedidos por varias organizaciones y donantes anónimos.
Las dos últimas categorías se deciden teniendo en cuenta los resultados de una encuesta que se hace a las organizaciones sobre los riesgos, que según ellas, deberían ser tenidos en cuenta.
Cambios con respecto a la versión de 2017
Los cambios que afectan a la clasificación de OWASP se pueden observar en la siguiente figura:
Si ya conocías OWASP, la mayoría de las categorías se mantienen con las características que tenían en la versión de 2017, algunas se han sumado a otras y se han creado tres nuevas, que son:
- A04: Diseño inseguro
- A08: Fallos de integridad del software y de los datos
- A10: Falsificación de solicitudes del lado del servidor (SSRF)
Nótese que en esta edición, a la hora de asignarles un nombre a las categorías, se ha tenido en cuenta la causa raíz y no la consecuencia.
Por ejemplo, al hablar de la categoría de 2017 “A03:2017 – Exposición de datos sensibles“, nos estamos refiriendo a la consecuencia y no a la causa raíz, ya que la exposición de datos sensibles, puede ser debida a un fallo en la protección de los datos en tránsito o en reposo, por lo que se le cambia el nombre a la categoría, que pasa a llamarse “A02:2021-Fallos Criptográficos”, que es la causa raíz. En resumen, para comprender el cambio de nombre, se podría decir que los “Fallos criptográficos” (2021) causan que se produzca la “Exposición de datos sensibles” (2017).
Otro de los cambios de esta nueva versión, que no afecta en sí a la clasificación, pero que es bienvenido, es que se ha diseñado un logotipo para cada una de las categorías, que podremos usar para acompañar las referencias o las explicaciones que hagamos de ellas. Esto permite identificarlas de una manera más visual, por ejemplo a la hora de comunicarlas a distintas audiencias o hagamos referencias a ellas.
A continuación pasaremos a hablar sobre las tres nuevas categorías de OWASP Top 10 2021, ya que al ser de reciente creación, no se conocen tanto o no se dispone de la misma cantidad de información como para las categorías que ya existían previamente.
Es muy recomendable conocerlas para aplicar cuanto antes las recomendaciones que se proponen, lo que nos ayudará a evitar los nuevos riesgos.
A04: Diseño inseguro
En esta categoría de riesgos se habla de un aspecto relacionado con la implementación, el diseño. Es una categoría descriptiva a priori, aunque después veremos que también se pueden asignar métricas a las distintas etapas del ciclo de vida del desarrollo de software.
El diseño y la implementación no tienen necesariamente que estar relacionados en el ámbito la seguridad, ya que se puede tener un diseño inseguro y se puede tener una implementación segura. Sería el caso en el que se implementa la política de contraseñas diseñada, se ha revisado el código y se han corregido los problemas relacionados con la seguridad que se pudiesen haber detectado, pero no se ha tenido en cuenta en el diseño, por ejemplo, la autenticación de dos factores (A2F; en inglés 2FA: Two-Factor Authentication).
Puede haber un diseño inseguro y se puede tener una implementación segura.
En cada organización hay unos motivos particulares por los que no se tuvieron en cuenta los requisitos de seguridad a la hora del diseño, pero en general se deberían incluir las negociaciones sobre seguridad en las fases más tempranas de los proyectos, y tenerlos en cuenta en fases posteriores.
Por ello, en las fases tempranas se deberían compilar los requisitos de seguridad, con el objetivo de reservar recursos para las fases posteriores.
Según la definición que nos proporciona OWASP:
El diseño seguro es una cultura y metodología que evalúa constantemente las amenazas y garantiza que el código esté diseñado y probado de manera sólida para prevenir métodos de ataque conocidos.
Por lo que en todo momento se debe prestar atención a los aspectos de la seguridad. Además de tenerlo en cuenta, deberíamos actuar.
Una opción es actuar en la fase del diseño de pruebas, que debe incorporar formas de verificar que los requisitos de seguridad se cumplen. Por ejemplo, al proporcionar datos de entrada correctos o incorrectos, el sistema de información con el que estamos trabajando, se debe seguir comportando de la manera esperada, que podría ser permitiendo o no el acceso en el caso de que estemos comprobando los requisitos de seguridad para la autenticación.
Así, se deben incorporar, a las pruebas que ya tengamos, las comprobaciones de requisitos de seguridad.
Como se ha visto, el desarrollo seguro no es una herramienta o un complemento que se pueda agregar al software existente, sino que debe ser una parte integrante de la cultura de la organización.
El Ciclo de Vida de Desarrollo Seguro del Software (CVDSS o SSDLC por sus siglas en inglés, Secure Software Development LifeCycle) requiere de elementos que contemplen la seguridad como una parte importante de ellos, aspecto importante a la hora de seleccionar los elementos de nuestro sistema de información: bibliotecas de componentes seguros, patrones de diseño seguros, metodologías robustas y herramientas que nos permitan el modelado de amenazas.
Modelo de garantía de madurez de software, SAMM
El Modelo de garantía de madurez de software, SAMM (Software Assurance Maturity Model) es la propuesta que hace OWASP para incorporar prácticas de seguridad a cualquier Ciclo de Vida de Desarrollo de Software (CVDS).
Esta es una de las características más interesantes de SAMM, ya que su aplicación es independiente del CVDS que estemos usando, al complementarlo con una capa nueva que abarcaría todo el ciclo, pero sin modificarlo.
SAMM permite crear un CVDSS sobre nuestro CVDS sin modificaciones adicionales.
Para comenzar, llevaríamos a cabo, sobre nuestro CVDS actual, una primera evaluación de las distintas prácticas de seguridad que propone SAMM y asignaríamos nosotros mismos una puntuación inicial de 0 a 3 del nivel de madurez que identifiquemos en ellas.
Una vez realizada la evaluación inicial, sabremos el estado actual de nuestro CVDS. Esta evaluación, junto con el análisis de riesgos que hayamos realizado previamente, nos permitirá identificar las acciones a realizar. Una vez hecho esto, ya tendríamos un Ciclo de Vida de Desarrollo Seguro de Software, CVDSS.
Todo ello nos permitiría actuar en base a nuestras necesidades particulares para implantarlo de manera progresiva, ya que solo tendremos que ir aumentando el nivel de madurez de cada práctica de seguridad.
