Seguridad en el ciclo del desarrollo del Software

Meer zoals dit

CASO LABORATORIO FERMEX S.A

door Leidy Palacios Ortiz

DEPARTAMENTALIZACIÓN DE LOS COSTOS INDIRECTOS

door DANIELA SANGUINO OSORIO

iso 45001

door valetina huila

DIVISIÓN SOCIAL DEL TRABAJO Y LAS RELACIONES LABORALES

door Liseth Villalonga

EDGAR GARCIA RODRIGUEZ 12380952

Seguridad en el ciclo del desarrollo del Software

testing / QA de seguridad

Implementación / Puesta en producción

Es también importante mantener una correcta separación de los ambientes de desarrollo, testing y producción y procedimientos de traspaso seguro de uno a otro de estos ambientes.

En este punto se deben contemplar tareas tales como: cambio de usuarios y contraseñas iniciales o por defecto, borrado de datos de prueba y cambio de permisos de acceso.

Tanto la aplicación como el software de base deben configurarse de manera segura al momento de poner el software en producción.

El testing de seguridad se basa principalmente en probar la aplicación con escenarios no planificados, incluyendo valores mutados, fuera de rango, de tipo incorrecto o malformados, acciones fuera de orden, etc.

A esto denominamos ‘testing funcional’ y básicamente consiste en validar que la aplicación ‘haga lo que se esperaba que hiciera’.

Tradicionalmente, la labor del equipo de Testing/QA fue la de encontrar y reportar errores funcionales de la aplicación. Para esto, se desarrollan ‘casos de test’ basados en la funcionalidad esperada.

Seguridad en la codificación

Los ‘Frameworks’ de desarrollo de aplicaciones son una buena ayuda en este punto, ya que ofician de intermediario entre el programador y el código, y permiten prevenir la mayoría de las vulnerabilidades conocidas. Ejemplos de estos frameworks son Struts, Ruby on Rails y Zope.

Ejemplo de estas vulnerabilidades son las presentes en el “OWASP Top 10” (Vulnerabilidades de inyección, Cross Site Scripting, errores en manejo de sesiones, etc.)

Una vez concluido el diseño, le toca a los desarrolladores el turno de codificar los distintos componentes de la aplicación. Es en este punto en donde suelen incorporarse, por error u omisión, distintos tipos de vulnerabilidades.

Seguridad en el análisis de requerimientos

Algunos de ellos son: requerimientos de compliance con normativas locales o internacionales (ej: PCI, SOX, “A” 4609, etc.), tipo de información que se transmitirá o procesará (ej: Información pública o confidencial entre otros.

En esta etapa, se deben identificar aquellos requerimientos funcionales que tendrán impacto en los aspectos de seguridad de la aplicación.

¿Qué está pasando en las organizaciones?

Está comprobado que cuánto más temprano se encuentre una falla de seguridad en el ciclo de vida del desarrollo de software, más rápida y económica será su mitigación.

Por lo general, en el mejor de los casos, se coordina un testeo de seguridad una vez que la aplicación ya está desarrollada. Aquí muchas veces se encuentran errores que requieren el rediseño de parte de la aplicación

Lamentablemente es una práctica habitual en muchas organizaciones la “puesta en producción” de sistemas sin la participación del sector de Seguridad. El sector de Seguridad se entera demasiado tarde, y no tiene suficiente margen de acción para el análisis de seguridad de la aplicación desarrollada.

La mayor parte de las organizaciones desarrolla o contrata el desarrollo de aplicaciones propias para su gestión de negocio.