Maestria en Seguridad Informtica

Ciclo de Vida
de desarrollo
Seguro
Actividad 1
CICLO DE VIDA DE DESARROLLO DE SEGURIDAD NELSON HUANCA VICTORIA

Contenido
Actividades de seguridad simplificadas de SDL .......................................................................... 2

Actividades de seguridad obligatorias ......................................................................................... 2

Requisitos anteriores a SDL: formacin en materia de seguridad .................................................... 2

Procedimiento 1 de SDL: requisitos de formacin........................................................................ 2

Primera fase: Requisitos ................................................................................................................... 3

Procedimiento 2 de SDL: requisitos de seguridad........................................................................ 3

Procedimiento 3 de SDL: umbrales de calidad y lmites de errores ............................................. 3

Procedimiento 4 de SDL: evaluacin de los riesgos de seguridad y privacidad ........................... 3

Segunda fase: diseo ....................................................................................................................... 4

Procedimiento 5 de SDL: requisitos de diseo ............................................................................. 4

Procedimiento 6 de SDL: reduccin de la superficie de ataques ................................................. 4

Procedimiento 7 de SDL: modelos de riesgos.............................................................................. 5

Tercera fase: implementacin ...................................................................................................... 5

Procedimiento 8 de SDL: usar herramientas aprobadas .............................................................. 5

Procedimiento 9 de SDL: prohibir funciones no seguras .............................................................. 5

Procedimiento 10 de SDL: anlisis esttico ................................................................................. 5

Cuarta fase: comprobacin ............................................................................................................... 5

Procedimiento 11 de SDL: anlisis dinmico de los programas ................................................... 5

Procedimiento 12 de SDL: pruebas de exploracin de vulnerabilidades mediante datos aleatorios 6

Procedimiento 13 de SDL: revisin de los modelos de riesgos y de la superficie de ataques ..... 6

Quinta fase: lanzamiento .................................................................................................................. 6

Procedimiento 14 de SDL: plan de respuesta a incidentes .......................................................... 6

Procedimiento 15 de SDL: revisin de seguridad final ................................................................. 6

Procedimiento 16 de SDL: lanzamiento o archivado .................................................................... 7

Actividades de seguridad opcionales ................................................................................................ 7

Revisin de cdigo manual .......................................................................................................... 7

Anlisis de vulnerabilidades de aplicaciones similares ................................................................ 7

Conclusin....................................................................................................................................... 7

BIBLIOGRAFIA ................................................................................................................................ 8

1
CICLO DE VIDA DE DESARROLLO DE SEGURIDAD NELSON HUANCA VICTORIA

CICLO DE VIDA DE DESARROLLO DE SEGURIDAD (SDL, SECURITY

DEVELOPMENT LIFECYCLE)
TARIJA, FEBRERO DE 2017

El ciclo de vida de desarrollo de seguridad (SDL) es un proceso de control de seguridad orientado al desarrollo de
software. Siendo una iniciativa corporativa y una directiva obligatoria desde el ao 2004, SDL ha desempeado un
papel muy importante en la integracin de la seguridad y de la privacidad en el software y la cultura de Microsoft.
Con un enfoque tanto holstico como prctico, SDL tiene como objetivo reducir el nmero y la gravedad de las
vulnerabilidades en el software. SDL introduce la seguridad y la privacidad en todas las fases del proceso de
desarrollo.

El proceso SDL de Microsoft se basa en tres conceptos bsicos: formacin, mejora continua de los procesos y
responsabilidad.

Actividades de seguridad simplificadas de SDL

En trminos sencillos, el proceso SDL de Microsoft es un conjunto de actividades de seguridad obligatorias, que se
presentan en el orden en que deben llevarse a cabo y se agrupan por cada una de las fases de un ciclo de vida de
desarrollo de software tradicional. Muchas de las actividades descritas aportaran ciertos beneficios en materia de
seguridad si se implementaran de manera independiente. Sin embargo, la experiencia en Microsoft demuestra que
las actividades de seguridad realizadas como parte de un proceso de desarrollo de software aportan mayores
beneficios que las actividades implementadas de manera poco sistemtica o de modo ad hoc.

Es posible agregar actividades de seguridad opcionales a discrecin del equipo de proyecto o del asesor de seguridad
a fin de alcanzar los objetivos deseados en el mbito de la seguridad y la privacidad. Para mayor brevedad, no se
incluyen descripciones detalladas de las actividades de seguridad.

Figura 1. Ciclo de vida de desarrollo de software de Microsoft: simplificado

Actividades de seguridad obligatorias

Si se determina que un proyecto de desarrollo de software debe someterse al proceso, el equipo de desarrollo
deber realizar correctamente diecisis actividades de seguridad obligatorias para lograr la conformidad con el
proceso SDL de Microsoft. Estos procesos se revisan constantemente como parte de un riguroso proceso de
evaluacin anual.

Requisitos anteriores a SDL: formacin en materia de seguridad

Procedimiento 1 de SDL: requisitos de formacin

Todos los miembros de un equipo de desarrollo de software deben recibir una formacin apropiada con el fin de
mantenerse al corriente de los conceptos bsicos y ltimas tendencias en el mbito de la seguridad y privacidad. Las

2
CICLO DE VIDA DE DESARROLLO DE SEGURIDAD NELSON HUANCA VICTORIA

personas con roles tcnicos (desarrolladores, evaluadores y administradores de programas) que estn directamente
implicadas en el desarrollo de programas de software deben asistir como mnimo una vez al ao a una clase de
formacin en materia de seguridad.

Primera fase: Requisitos

Procedimiento 2 de SDL: requisitos de seguridad

La necesidad de considerar la seguridad y la privacidad desde el primer instante es un aspecto fundamental del
desarrollo de un sistema seguro. La fase de planificacin inicial es el momento ms apropiado para definir los
requisitos de fiabilidad de un proyecto de software. Al definir los requisitos en una fase temprana, los equipos de
desarrollo podrn identificar los principales hitos y resultados, y es posible integrar la seguridad y la privacidad de
modo que los planes y programaciones se alteren lo menos posible. Al principio de un proyecto, se realiza un anlisis
de los requisitos de seguridad y privacidad, el cual incluye la especificacin de los requisitos de seguridad mnimos
de la aplicacin en el entorno operativo previsto, as como la especificacin y la implementacin de un sistema de
seguimiento de los elementos de trabajo y de las vulnerabilidades de seguridad.

Procedimiento 3 de SDL: umbrales de calidad y lmites de errores

Se usan umbrales de calidad y lmites de errores para establecer niveles mnimos aceptables de calidad en materia
de seguridad y privacidad. Al definir estos criterios al comienzo de un proyecto, se comprendern mejor los riesgos
asociados a los problemas de seguridad y los equipos podrn identificar y corregir los errores de seguridad durante
el desarrollo. El equipo de proyecto debe negociar los umbrales de calidad (por ejemplo, todas las advertencias del
compilador se deben evaluar y corregir antes de proteger el cdigo) para cada fase de desarrollo; a continuacin, el
asesor de seguridad debe aprobarlos y puede agregar aclaraciones especficas del proyecto as como requisitos de
seguridad ms estrictos segn proceda. El equipo de proyecto tambin debe ilustrar la conformidad con los umbrales
de calidad negociados para cumplimentar la revisin de seguridad final.
Un lmite de errores es un umbral de calidad que se aplica a todo el proyecto de desarrollo de software. Se usa para
definir los umbrales de gravedad de las vulnerabilidades de seguridad; por ejemplo, en la aplicacin no hay
vulnerabilidades conocidas que estn clasificadas como crticas o importantes en el momento de su lanzamiento.
Una vez definido, el lmite de errores no debe bajarse nunca. Un lmite de errores dinmico es un objetivo no fijo que
probablemente no se entienda muy bien en el mbito del desarrollo.

Procedimiento 4 de SDL: evaluacin de los riesgos de seguridad y privacidad

Las evaluaciones de los riesgos de seguridad (SRA) y de privacidad (PRA) son procesos obligatorios que identifican
los aspectos funcionales del software que requieren una revisin exhaustiva. Dichas evaluaciones deben incluir la
siguiente informacin:
1. (Seguridad) Partes del proyecto que van a requerir modelos de riesgos antes del lanzamiento.
2. (Seguridad) Las partes del proyecto que van a requerir revisiones del diseo de seguridad antes del lanzamiento.
3. (Seguridad) Partes del proyecto (si procede) que van a requerir pruebas de penetracin por parte de un grupo
externo al equipo de proyecto y acordado mutuamente.
4. (Seguridad) Requisitos de anlisis o de pruebas adicionales que el asesor de seguridad considera necesarios para
mitigar los riesgos de seguridad.
5. (Seguridad) mbito especfico de los requisitos en materia de pruebas de exploracin de vulnerabilidades
mediante datos aleatorios.
6. (Privacidad) Cul es el nivel de impacto sobre la privacidad? La respuesta a esta pregunta se basa en las
siguientes pautas:

3
CICLO DE VIDA DE DESARROLLO DE SEGURIDAD NELSON HUANCA VICTORIA

P1 Alto riesgo para la privacidad. La caracterstica, el producto o el servicio almacena o transfiere datos de
identificacin personal, cambia la configuracin o las asociaciones de los tipos de archivo, o instala
software.

P2 Riesgo moderado para la privacidad. El nico comportamiento que afecta a la privacidad en la

caracterstica, el producto o el servicio es una transferencia de datos annimos nica e iniciada por el
usuario (por ejemplo, el usuario hace clic en un vnculo y el software abre un sitio web).

P3 Bajo riesgo para la privacidad. La caracterstica, el producto o el servicio no tiene ningn

comportamiento que afecte a la privacidad. No hay ninguna transferencia de datos personales ni annimos,
no se almacenan datos de identificacin personal en el equipo, no se modifica ninguna configuracin en
nombre del usuario y no se instala ningn software.

Segunda fase: diseo

Procedimiento 5 de SDL: requisitos de diseo

El momento ms oportuno para influir en la fiabilidad del diseo de un proyecto es la etapa inicial de su ciclo de
vida. Es muy importante que se estudien detenidamente las cuestiones de seguridad y de privacidad durante la fase
de desarrollo. La mitigacin de los problemas de seguridad y de privacidad es mucho menos costosa si se realiza en
la etapa inicial del ciclo de vida de un proyecto. Los equipos de proyecto deben evitar abordar deprisa y corriendo
las caractersticas de seguridad y de privacidad y las mitigaciones cerca del final del desarrollo de un proyecto.

Adems, es de suma importancia que los equipos de proyecto entiendan la diferencia entre caractersticas seguras
y caractersticas de seguridad. Es perfectamente posible que se implementen caractersticas de seguridad que, en
realidad, son inseguras. Las caractersticas seguras se definen como caractersticas cuya funcionalidad est
debidamente diseada con respecto a la seguridad, incluida una rigurosa validacin de todos los datos antes de su
procesamiento o una implementacin criptogrficamente robusta de bibliotecas para los servicios de cifrado. El
trmino caractersticas de seguridad describe la funcionalidad de un programa que tiene implicaciones para la
seguridad, como la autenticacin Kerberos o un firewall.
La actividad de los requisitos de diseo incluye varias acciones obligatorias. Algunos ejemplos son la creacin de
especificaciones de diseo en materia de seguridad y privacidad, la revisin de las especificaciones y la especificacin
de requisitos mnimos de diseo criptogrfico. Las especificaciones de diseo deben describir las caractersticas de
seguridad o de privacidad que van a estar directamente expuestas a los usuarios, como las que requieren la
autenticacin del usuario para obtener acceso a datos especficos o que necesitan el consentimiento del usuario
para usar una caracterstica con un alto riesgo para la privacidad. Adems, todas las especificaciones de diseo deben
describir cmo se implementa de manera segura toda la funcionalidad proporcionada por una caracterstica o
funcin determinada. Se recomienda validar las especificaciones de diseo con la especificacin funcional de la
aplicacin. La especificacin funcional debe:
Describir de manera exacta y completa el uso previsto de una caracterstica o funcin.
Describir cmo se implementa de forma segura la caracterstica o funcin.

Procedimiento 6 de SDL: reduccin de la superficie de ataques

La reduccin de la superficie de ataques est estrechamente relacionada con los modelos de riesgos, si bien aborda
los problemas de seguridad desde una perspectiva ligeramente diferente. La reduccin de la superficie de ataques
es una forma de reducir el riesgo dando a los atacantes menos oportunidades para aprovechar un posible punto
dbil o una posible vulnerabilidad. Para reducir la superficie de ataques, se cierra o se restringe el acceso a los

4
CICLO DE VIDA DE DESARROLLO DE SEGURIDAD NELSON HUANCA VICTORIA

servicios del sistema, se aplica el principio de privilegios mnimos o se usan en la medida de lo posible defensas por
capas.

Procedimiento 7 de SDL: modelos de riesgos

Los modelos de riesgos se usan en entornos donde existe un riesgo significativo para la seguridad. Este
procedimiento permite a los equipos de desarrollo considerar, documentar y describir de manera estructurada las
implicaciones para la seguridad de los diseos en el marco de su entorno operativo previsto. Los modelos de riesgos
tambin permiten estudiar los problemas de seguridad en el nivel de los componentes o aplicaciones. La creacin
de un modelo de riesgos es un trabajo de equipo que implica a los administradores de programas o proyectos,
desarrolladores y evaluadores; adems, es la principal tarea de anlisis de seguridad que se realiza en la fase de
diseo del software.

Tercera fase: implementacin

Procedimiento 8 de SDL: usar herramientas aprobadas

Todos los equipos de desarrollo deben definir y publicar una lista de las herramientas aprobadas y de las
comprobaciones de seguridad asociadas, como las advertencias y las opciones del compilador o del vinculador. Esta
lista la debe aprobar el asesor de seguridad del equipo de proyecto. En trminos generales, los equipos de desarrollo
deben procurar usar la versin ms reciente de las herramientas aprobadas a fin de aprovechar las nuevas
protecciones y funciones de anlisis de seguridad.

Procedimiento 9 de SDL: prohibir funciones no seguras

Un gran nmero de las funciones y API de uso comn no son seguras de cara al actual entorno de amenazas. Los
equipos de proyecto deben analizar todas las funciones y API que se van a usar con un proyecto de desarrollo de
software y prohibir las que consideran inseguras. Una vez determinada la lista de funciones prohibidas, los equipos
de proyecto deben usar archivos de encabezado (por ejemplo, banned.h y strsafe.h), compiladores ms recientes o
herramientas de anlisis de cdigo para comprobar si hay funciones prohibidas en el cdigo (incluido cdigo
heredado si procede) y reemplazarlas por alternativas ms seguras.

Procedimiento 10 de SDL: anlisis esttico

Los equipos de proyecto deben realizar un anlisis esttico del cdigo fuente. Este tipo de anlisis permite revisar el
cdigo de seguridad de forma escalable y contribuye a asegurar que se observan las directivas de codificacin segura.
En general, por s solo, el anlisis de cdigo esttico no puede reemplazar una revisin de cdigo manual. El equipo
de seguridad y los asesores de seguridad deben ser conscientes de las ventajas y desventajas de las herramientas de
anlisis esttico y deben estar preparados para ampliar dichas herramientas con otras o con la revisin humana,
segn procede.

Cuarta fase: comprobacin

Procedimiento 11 de SDL: anlisis dinmico de los programas

Es necesario comprobar los programas de software en tiempo de ejecucin para asegurar que su funcionalidad sea
acorde con el diseo. Esta tarea de comprobacin debe especificar las herramientas que supervisan el
comportamiento de las aplicaciones para detectar si la memoria est daada, si hay problemas con los privilegios de
los usuarios u otro tipo de problemas de seguridad crticos. El proceso SDL usa herramientas en tiempo de ejecucin
como AppVerifier, junto con otras tcnicas como pruebas de exploracin de vulnerabilidades mediante datos
aleatorios, para lograr los niveles de cobertura deseados de las pruebas de seguridad.

5
CICLO DE VIDA DE DESARROLLO DE SEGURIDAD NELSON HUANCA VICTORIA

Procedimiento 12 de SDL: pruebas de exploracin de vulnerabilidades mediante datos aleatorios

Este tipo de pruebas es una forma especializada de anlisis dinmico que se usa para provocar errores en los
programas introduciendo deliberadamente datos aleatorios o de formato incorrecto en una aplicacin. Esta
estrategia se deriva del uso previsto de la aplicacin y de sus especificaciones funcionales y de diseo. Es posible que
el asesor de seguridad requiera un nmero adicional de estas pruebas o ample su mbito o duracin.

Procedimiento 13 de SDL: revisin de los modelos de riesgos y de la superficie de ataques

En muchas ocasiones, una aplicacin se desva de manera significativa de las especificaciones funcionales y de diseo
creadas durante las fases de requisitos y de diseo de un proyecto de desarrollo de software. Por ello, es muy
importante que se revisen los modelos de riesgos y la medicin de la superficie de ataques de una aplicacin una
vez completado su cdigo. De este modo, se asegura que se toman en consideracin los cambios de diseo o de
implementacin realizados en el sistema y que se revisan y se mitigan los nuevos vectores de ataque creados como
resultado de los cambios.

Quinta fase: lanzamiento

Procedimiento 14 de SDL: plan de respuesta a incidentes

Cada lanzamiento de software sujeto a los requisitos de SDL debe incluir un plan de respuesta a incidentes. Incluso los
programas sin vulnerabilidades conocidas en el momento de su lanzamiento pueden estar expuestos a nuevas
amenazas. El plan de respuesta a incidentes debe incluir:
Un equipo de ingeniera sostenida identificado o, si el equipo es demasiado reducido para tener recursos de
ingeniera sostenida, un plan de respuesta a emergencias en el que se identifica el personal de ingeniera,
marketing, comunicaciones y administracin que representa el primer punto de contacto en caso de una
emergencia de seguridad.
Contactos con capacidad para tomar decisiones y disponibilidad las 24 horas del da y los 7 das de la semana.
Planes de servicios de seguridad para cdigo heredado de otros grupos dentro de la organizacin.
Planes de servicios de seguridad para cdigo de terceros bajo licencia, incluidos nombres de archivo, versiones,
cdigo fuente, datos de contacto de terceros y permiso contractual para realizar cambios (si procede).

Procedimiento 15 de SDL: revisin de seguridad final

La revisin de seguridad final es una inspeccin deliberada de todas las actividades de seguridad realizadas con una
aplicacin de software antes de su lanzamiento. Esta revisin la lleva a cabo el asesor de seguridad con ayuda del
personal de desarrollo habitual y de los responsables de los equipos de seguridad y de privacidad. La revisin de
seguridad final no consiste en penetrar y parchear, ni tampoco en realizar las actividades de seguridad que se han
omitido o se han olvidado. Suele consistir en un estudio de los modelos de riesgos, las solicitudes de excepciones,
los resultados de las herramientas y el rendimiento teniendo en cuenta los umbrales de calidad y los lmites de
errores previamente determinados. La revisin de seguridad final da lugar a uno de estos tres resultados:
Revisin de seguridad final superada. Se han corregido y mitigado todos los problemas de seguridad y de
privacidad identificados en la revisin de seguridad final.
Revisin de seguridad final superada con excepciones. Se han corregido y mitigado todos los problemas de
seguridad y de privacidad identificados en la revisin de seguridad final y/o todas las excepciones se han resuelto
de modo satisfactorio. Los problemas que no se pueden resolver (por ejemplo, vulnerabilidades debido a
problemas heredados del nivel de diseo) se registran y se corrigen en la siguiente versin.
Revisin de seguridad final con remisin a una instancia superior. Si un equipo no cumple todos los requisitos
de SDL y el asesor de seguridad y el equipo de proyecto no alcanzan un acuerdo aceptable, el asesor de seguridad
no podr aprobar el proyecto, por lo que no se podr realizar su lanzamiento. Los equipos debern intentar

6
CICLO DE VIDA DE DESARROLLO DE SEGURIDAD NELSON HUANCA VICTORIA

cumplir en la medida de lo posible todos los requisitos de SDL antes de proceder al lanzamiento del proyecto o
remitir el asunto a instancias superiores para que tomen una decisin al respecto.

Procedimiento 16 de SDL: lanzamiento o archivado

Las versiones RTM (Release To Manufacturing) y RTW (Release To Web) dependen de la finalizacin del proceso SDL.
El asesor de seguridad asignado a la versin debe certificar (mediante la revisin de seguridad final y otros datos)
que el equipo de proyecto ha cumplido los requisitos de seguridad. De manera similar, para todos los productos que
tienen al menos un componente con el nivel de impacto en la privacidad P1, el asesor de privacidad del proyecto
debe certificar que el equipo de proyecto ha cumplido los requisitos de privacidad para que se pueda enviar el
software.
Adems, se han de archivar todos los datos e informacin pertinentes a fin de permitir el mantenimiento del
software despus de su lanzamiento. Dichos datos incluyen todas las especificaciones, cdigo fuente, archivos
binarios, smbolos privados, modelos de riesgos, documentacin, planes de respuesta a emergencias, trminos de
licencia y de mantenimiento de software de terceros as como otros datos necesarios para poder llevar a cabo las
tareas de mantenimiento posteriores al lanzamiento.

Actividades de seguridad opcionales

Las actividades de seguridad opcionales suelen llevarse a cabo cuando existe la posibilidad de que una aplicacin de
software vaya a usarse en entornos o escenarios crticos. En muchas ocasiones, las especifica el asesor de seguridad
como parte de un conjunto negociado de requisitos adicionales con el fin de asegurar un mayor nivel de anlisis de
seguridad para determinados componentes de software. Los procedimientos descritos en esta seccin son algunos
ejemplos de tareas de seguridad opcionales pero no representan una lista exhaustiva.

Revisin de cdigo manual

La revisin de cdigo manual es una tarea opcional del proceso SDL que suelen llevar a cabo miembros altamente
cualificados del equipo de seguridad y/o el asesor de seguridad. Si bien las herramientas de anlisis se encargan en
gran medida de detectar y marcar las vulnerabilidades, no son perfectas. Por consiguiente, la revisin de cdigo
manual suele centrarse en los componentes crticos de una aplicacin. En la mayora de los casos, se recurre a esta
revisin cuando se procesan o se almacenan datos confidenciales, como datos de identificacin personal (PII).
Tambin se utiliza para examinar otras funciones crticas, como las implementaciones criptogrficas. Pruebas de
penetracin
Las pruebas de penetracin consisten en un anlisis de seguridad de caja blanca de un sistema de software que
llevan a cabo profesionales cualificados en el mbito de la seguridad simulando las acciones de un hacker. Estas
pruebas tienen como objetivo detectar posibles vulnerabilidades debidas a errores de codificacin, errores en la
configuracin del sistema u otros puntos dbiles de la implementacin operativa. En muchas ocasiones, se llevan a
cabo junto con revisiones de cdigo automatizadas y manuales para alcanzar un nivel de anlisis mayor de lo normal.

Anlisis de vulnerabilidades de aplicaciones similares

En Internet, hay un gran nmero de fuentes de informacin acreditadas sobre las vulnerabilidades de software. En
algunos casos, los anlisis de vulnerabilidades de aplicaciones de software similares pueden arrojar luz sobre los
problemas de diseo o implementacin con los que se puede encontrar el software en fase de desarrollo.
Conclusin
Si bien el proceso anteriormente descrito establece un umbral mnimo para la conformidad con SDL, no se trata de
un proceso estndar. Los equipos de desarrollo deben usar este documento como gua para implementar SDL de
acuerdo con el tiempo, los recursos y los procedimientos empresariales de la organizacin.

7
CICLO DE VIDA DE DESARROLLO DE SEGURIDAD NELSON HUANCA VICTORIA

Los conceptos de ingeniera anteriormente descritos se consideran generalmente como procedimientos de

seguridad apropiados y no son especficos de Microsoft ni de la plataforma Windows. Se pueden aplicar a diversos
sistemas operativos, plataformas de hardware y metodologas de desarrollo. Incluso un enfoque poco sistemtico
en el que se usan algunas de estas tcnicas probablemente tenga un efecto beneficioso sobre la seguridad y la
privacidad de una aplicacin en fase de desarrollo.

El proceso SDL de Microsoft es un proceso de libre disposicin que permite mejorar la seguridad y la privacidad de
un software. Se ha aplicado a cientos de programas de software y a cientos de millones de lneas de cdigo de
produccin. SDL consta de acciones obligatorias que siguen el proceso de desarrollo de software tradicional, si bien
es lo suficientemente flexible para que se puedan agregar otras directivas y tcnicas de modo que se cree una
metodologa de desarrollo de software nica para una organizacin. La combinacin de procesos, formacin y
herramientas aporta diversos beneficios, como una mayor previsibilidad, capacidad tcnica y un software ms
seguro, lo que se traduce en un menor riesgo para la organizacin y el usuario del software.

BIBLIOGRAFIA
What is the Security Development Lifecycle ?extraido de https://www.microsoft.com/en-us/sdl/, vistiado el 2 de
febrero de 2017

Implementacin simplificada del proceso SDL de Microsoft, Microsoft.