Requerimientos para Security Development Lifecycle de Microsoft

Esta es la cuarta entrega de la serie de seguridad Informática en la ingeniería de software que nos envía el amigo Pablo Andrés Garzón, si no has leído los anteriores artículos, te invito que lo hagas.

El tercer artículo cubrirá el primer nivel tratado en el SDL el cual se enfoca en la necesidad de considerar los aspectos de seguridad en una fase temprana del ciclo de vida, ya que es fundamental para el desarrollo de un sistema seguro, para esto se debe definir en la fase de la planificación ya que permite que los desarrolladores y arquitecto identifiquen los principales problema que se pueden presentar en la implementación de los controles de seguridad y así tener medidas que controle atrasos en la integración con los diferentes módulos desarrollados por el equipo.

Los análisis de requisitos enfocados con la seguridad permiten conocer cómo será el diseño de la aplicación contemplando los requisitos de seguridad mínimo que se debe tener, también contempla como será su comportamiento en un entorno operativo planificado y como se manejara el temas de las vulnerabilidades para el control y seguimiento de estas recordando que el temas de control de bugs es de gran importancia para el ciclo de vida del software ya que una mala implementación de este nos podría producir costos elevados en tiempo y en dinero lo cual sería un problema para la empresa u organización.

Calidad Gates/Barra de Errores

La barra de error es una de las tareas más difíciles que puede enfrentar un equipo de desarrollo de software durante la evolución de ciclo de vida, para esto decidir el nivel de importancia que se le dará a un error y la probabilidad de que ese error no se pueda corregir en el tiempo de entrega de la versión puede tener muchos problemas que afecta al grupo de desarrollo.

Aunque uno de los puntos más difíciles de tratar es que los programadores, arquitectos y otros miembros del grupo tienen diferentes puntos de vista de la clasificación del error o la probabilidad de poder gestionarlo en la fase de entrega de la versión, pero estos grupos cometen errores en sus decisiones de clasificación por factores individuales o por la experiencia ya tratada en una anterior clasificación recordando que la clasificación de un error puede variar dependiendo el proyecto a realizar y sobre esto se enfocan en los siguientes puntos como:

Cuánto código tendría que regresión-probarse una vez realizada la corrección.
Cómo cerrar para liberar el proyecto es.
¿Cuántos usuarios se verían afectados por el cambio.
Si el error está bloqueando otros problemas de ser probado o fijo.

Antes que toquemos la barra de error es importantes conocer una de las anteriores propuestas de Microsoft en la clasificación de errores de seguridad: Dread que significa en su acrónimo:

Daño potencial.
Reproducibilidad.
Capacidad de aprovechamiento.
Usuarios afectados.
Capacidad de descubrimiento.

Para este a cada parámetro del DREAD se le debe asignar un valor de 1 a 10, siendo el más grave el 10 y el 1 el menor. Después de esto se promedian para general la calificación DREAD.

Para esto describiremos la siguiente tabla donde se detalla la clasificación mencionada a continuación.

DREAD Parameter	Rating	Razonamiento
Daño potencial	5	Un atacante podría leer y modificar datos en la base de datos de productos.
Reproducibilidad	10	Puede reproducir cada vez.
Capacidad de aprovechamiento	2	Requiere un conocimiento experto y inversión de tiempo grandes.
Usuarios afectados	1	Sólo afecta a pequeño subconjunto de la base de usuarios.
Capacidad de descubrimiento	1	Página afectada no vinculada desde cualquier página de usuario.
Valoración general	3.8

Aunque recordemos que un evaluador pude ver diferente la asignación de la clasificación de errores propuesta en un inicio, entonces nos podríamos preguntarnos cuál de las clasificaciones realizadas por cada miembro es la mejor para el DREAD o como podremos controlar la variabilidad de los valores subjetivos.

Después de conocer la anterior forma de trabajar de Microsoft en la clasificación de seguridad enfoquémonos en el actual que es la barra de error de seguridad la cual clasifica las vulnerabilidades según su efecto, para esto la persona encargada de clasificar el error asigna un valor de efecto de seguridad de una lista de valores STRIDE la cual es una tecla de acceso, para este caso se utiliza para clasificar las amenazas encontradas en el ciclo de vida del desarrollo de seguridad y es unos de los componentes básicos de varias herramientas que gestionan el SDL, los valores STRIDE son:

Suplantación
Manipulación
Repudio
Revelación de información
Denegación de servicio (DoS)
Elevación de privilegios (EoP)

Aunque la categoría de STRIDE no es suficiente para clasificar un error, Debemos tener en cuenta el entorno donde se aplica el código ya que este puede afectar al cliente o al servidor, por ejemplo un ataque de denegación de servicios que toma un único usuario no sería tan elevado como dejar fuera un servidor donde varios usuarios realizan operaciones de tiempo continuo como son las aplicaciones provistas por entidades bancarias o del estado, también debemos considerar quien puede ejecutar el ataque como una personas con autenticación en el sitio o una persona anónima que no posee una acceso de privilegios a esta para este caso tendría mayor elevación la persona que realiza el ataque anónimamente que la persona autenticada.

Al contar con la clasificación provista por STRIDE y las características de ámbito adicionales la persona encargada de clasificar el error puede dar más detalle del valor a dar para la barra de error.

La siguiente tabla nos muestra una barra de error de seguridad la cual define cuatro niveles de gravedad:

Critica.
Importante.
Moderada.
baja.

Valor STRIDE	Cliente / Servidor	Ámbito	Gravedad
Suplantación	Cliente	Capacidad para que el atacante presentar una interfaz de usuario es diferente de pero visualmente idéntico a la interfaz de usuario que de debe confiar para tomar decisiones de confianza válida en un escenario predeterminado/común de los usuarios . Una decisión de confianza se define como la toma de usuario una acción creer alguna información se presenta por una entidad determinada en cualquier momento, el sistema o de algún origen local o remoto específico.	Importante
		Capacidad para que el atacante presentar una interfaz de usuario es visualmente idéntico a la interfaz de usuario pero diferente de ese de están acostumbrados a confiar en un escenario concreto de usuarios . " Acostumbrado a confiar " se define como un usuario nada habitualmente ya está familiarizado con según la interacción normal con el sistema operativo o aplicación pero no suelen considerar como una decisión de confianza de ". "	Moderada
		Capacidad de intruso presentar una interfaz de usuario es diferente de pero visualmente idéntico a la de que es una parte única de un escenario de ataque más grande de interfaz de usuario .	Baja
	Servidor	Equipo se conecta con un servidor es capaz de hacerse pasar por un usuario diferente o un equipo de su elección utiliza un protocolo diseñado y comercializado para proporcionar una autenticación segura.	Importante
		Equipo o usuario del cliente es capaz de hacerse pasar por un usuario diferente, aleatorio o un equipo mediante un protocolo que se ha diseñado y comercializado para proporcionar una autenticación segura.	Moderada
Alteración/Repudio	Cliente	Modificación permanente de cualquier usuario datos o los datos utilizados para tomar decisiones de confianza en común o escenario predeterminado que persiste después de reiniciar la aplicación de sistema operativo.	Importante
		Modificación temporal de los datos que no se conservan después de reiniciar la aplicación de sistema operativo.	Baja
	Servidor	Modificación permanente de cualquier usuario que utilizó para hacer la confianza de datos o las decisiones de en común o escenario predeterminado persiste después de reiniciar la aplicación de sistema operativo.	Importante
		Modificación permanente de cualquier usuario que utilizó para hacer la confianza de datos o las decisiones de en un escenario concreto que persiste después de reiniciar la aplicación de sistema operativo.	Moderada
		Modificación temporal de datos en común o escenario predeterminado no se conserva después de reiniciar la aplicación de sistema operativo.	Moderada
		Temporal modificación de datos en un escenario concreto que no se conserva después de reiniciar la aplicación de sistema operativo.	Baja
Divulgación de Información	Cliente	Casos donde el atacante puede buscar y leer información en el sistema, incluida la información del sistema que no se pretende ni diseñado para ser expuestos.	Importante
		Casos donde el atacante puede leer información en el sistema desde ubicaciones conocidas , incluida la información del sistema que no se pretende ni diseñado para ser expuestos.	Moderada
		Cualquier divulgación de información denegado (es decir, la revelación de datos aleatorios).	Baja
	Servidor	Casos donde el atacante puede buscar y leer información desde cualquier lugar en el sistema, incluida la información del sistema que no se pretende ni diseñado para ser expuestos.	Importante
		Casos donde el atacante puede leer fácilmente información sobre el sistema desde ubicaciones conocidas , incluida la información del sistema que no se pretende ni diseñado para ser expuestos.	Moderada
		Cualquiera revelación de información (por ejemplo, la revelación de datos aleatorios) incluidos los datos en tiempo de ejecución.	Baja
Denegación de servicio	Cliente	Daños "en el sistema DoS ": Requiere la reinstalación del sistema o componentes.	Importante
		"Permanentes DoS": Requiere el reinicio en frío o hace que la comprobación/error de pantalla azul.	Moderada
		"DoS temporales ": Requiere el reinicio de aplicación.	Baja
	Servidor	Anónimo, deberá ser "fácil aprovechar" por enviar una pequeña cantidad de datos o de lo contrario se inducidos rápidamente.	Importante
		Instalación DoS anónimas, temporales sin amplificación en un común de predeterminado.	Moderada
		Denegación de servicio autenticada, permanente.	Moderada
		Instalación DoS autenticados, temporales con amplificación en un común de predeterminado.	Moderada
Concesión de privilegio	Cliente	Usuario remoto, la capacidad ejecutar código arbitrario o para obtener más privilegios lo esperado.	Crítica
		Usuario remoto, ejecución de código arbitrario con usuario amplia acción.	Importante
		Usuario local con pocos privilegios puede elevar su propia cuenta a otro usuario, administrador o sistema local.	Importante
	Servidor	Usuario anónimo remoto, la capacidad ejecutar código arbitrario o para obtener más privilegios lo esperado.	Crítica
		Control remoto autenticado el usuario, la capacidad de ya sea ejecutar código arbitrario o para obtener más privilegios lo esperado.	Importante
		Usuario local autenticado, la capacidad ejecutar código arbitrario o para obtener más privilegios lo esperado.	Importante

Seguridad y evaluación de riesgos de privacidad

Antes de tocar el tema de evaluación de riesgos en el ciclo de vida del software conozcamos el concepto general aplicado en seguridad el análisis de riesgos supone más que el hecho de calcular la posibilidad de que ocurra cosas negativas en un proceso o en algún evento.

Los puntos que debemos considerar en el análisis de riesgos son los siguientes:

Obtener una evaluación económica del impacto de los sucesos,
Tener en cuenta la probabilidad de que ocurran los problemas posibles.
Conocer que es lo que más queremos proteger asegurando que obtendremos un beneficio y no una pérdida, para esto se debe identificar los recursos (software, hardware, información, personal, etc.) y considerar las posibles amenazas que se pueden encontrar.

Para aclarar más el concepto tomemos en cuenta la siguiente tabla donde podremos entender el funcionamiento que se aplica en el análisis de riesgos.

Tipo de Riesgo	Factor
Robo de hardware	Alto
Robo de información	Alto
Vandalismo	Medio
Fallas en los equipos	Medio
Virus Informáticos	Medio
Equivocaciones	Medio
Accesos no autorizados	Medio
Fraude	Bajo
Fuego	Muy Bajo
Terremotos	Muy Bajo

Por último el enfoque del análisis de riesgos en el ciclo de vida del software debe identificar las funciones de software a las cuales se le debe aplicar una revisión más profunda para esos se debe incurrir en los siguientes aspectos.

Que parte del proyecto requerirá modelo de amenazas.
Que parte del proyecto requerirá el diseño de seguridad.
Que parte del proyecto requerirá pruebas de penetración las cuales las puede realizar una empresa externa a la involucrada al proyecto.
qué es la evaluación de impacto de privacidad?

La respuesta a esta pregunta se basa en las siguientes directrices:

Alto riesgo de privacidad de P1. La función, producto o servicio almacena o transfiere PII, cambios de configuración o asociaciones de tipo de archivo o instala el software.
Riesgos de privacidad mod P2. El comportamiento único que afecta a la intimidad en la función, producto o servicio es una transferencia de datos anónimos, iniciado por el usuario, de una sola vez (por ejemplo, el usuario hace clic en un vínculo y el software va a un sitio Web).
P3 bajo riesgo de privacidad. No comportamientos existen dentro de la función, producto o servicio que afectan a la privacidad. No se transfiere ningún dato personal o anónima, no IPI se almacena en el equipo, ninguna configuración de cambian en nombre del usuario y no está instalado ningún software.
La necesidad de pruebas adicionales que podría considerar el analista para así mitigar los riesgos de seguridad.
Ámbito específico de la aplicación enfocado en las pruebas de requisitos

ROSI (Retorno de Inversión en Seguridad de la Información)

Para terminar hay una de las cosas que nunca eh escuchado mencionar en el SDL y me parece importante ya que se puede aplicar y es la implementación del ROSI el cual es bien conocido como el retorno de inversión en seguridad de la información el cual garantiza la continuidad de negocio a medio y a largo plazo, Centrándonos en ROSI, la esencia del cálculo se basa en calcular los costos ahorrados como consecuencia de evitar incidentes de seguridad o de mitigar los efectos de los mismos en caso de ocurrencia. Es por esto que en ROSI el beneficio es en realidad el ahorro conseguido (además de otro tipo de beneficios como pueden ser mejorar la imagen de la empresa consiguiendo así nuevos clientes), algunos se preguntaran porque mencione el rosi o porque se podría aplicar es tan sencillo que teniendo en cuenta la implementación de controles de seguridad y la continuidad de la seguridad en cada fase del ciclo de vida del software podremos manejar un nivel de costos los cuales podrían favorecer o a su vez o no favorecer en niveles de tiempo y dinero así manejando la definición de ROSI la cual trata cuanto no pierdo por implementar controles de seguridad es tan interesante que debería ser considerada en SDL y demás enfoques o metodologías enfocadas en la seguridad del ciclo de vida del software teniendo en cuenta que la mayoría de proyectos que fracasan son por términos de mal manejo en definiciones y controles de seguridad a implementar por esto es tan necesario que se tenga en cuenta el rosi no solo en la seguridad de la información si no también en la seguridad del ciclo de vida del software y en los demás campos que se pueden aplicar.

Para mayor información diríjase a los siguientes links.

Escrito por:
Pablo Andrés Garzón Vera
Ingeniero de Sistemas (Universidad Manuela Beltrán)
Magister en Dirección Estratégica en Ingeniería de software (Universidad de León).
Para La Comunidad DragonJAR

Boletín de la Comunidad DragonJAR #0016