Metodologia de Desarrollo de Software Seguro SCS V 2.0
Metodologia de Desarrollo de Software Seguro SCS V 2.0
Metodologia de Desarrollo de Software Seguro SCS V 2.0
CONTENIDO
1. OBJETIVOS ........................................................................................................................................................................................ 4
2. ALCANCE ........................................................................................................................................................................................... 4
3. DEFINICIONES Y ESTÁNDARES...................................................................................................................................................... 4
5. RESPONSABLES ............................................................................................................................................................................. 10
7. METODOLOGÍA DE DESARROLLO................................................................................................................................................ 12
2
SCS
BIBLIOGRAFÍA ........................................................................................................................................................................................... 33
3
SCS
Definir una metodología de desarrollo de software seguro en donde se establezcan las etapas, las
actividades y técnicas necesarias para la construcción y mantenimiento de un proyecto de desarrollo
de software, garantizando la obtención de productos de calidad y seguridad. Existen en la actualidad
varias metodologías de desarrollo de software seguro. Entre ellas se encuentran: Correctness by
Construction (CbyC), Common Criteria, Comprehensive, Security Development Lifecycle (SDL),
Cigital Touchpoints y Lightweight Application Security Process (CLASP). También OWASP, PCI DSS
e ISO 27001:2013 ofrecen una serie de recomendaciones para mejorar la seguridad durante el ciclo
de desarrollo.
La metodología de desarrollo de software seguro define las etapas y actividades que se deben seguir
para la implementación de nuevos desarrollos, mejoras, desarrollos externos y para dar solución a
fallos en el software, garantizando que estos procesos se realicen de forma eficiente, siguiendo las
políticas y procedimientos establecidos.
SP 800-12: Este documento del NIST provee una introducción a la seguridad de los computadores y
provee guías de seguridad para el hardware, software, y los activos de información.
SP 800-14: Provee a una línea base que las organizaciones pueden utilizar para revisar su programa
de seguridad de la información.
FALLA: Una Falla o Incidente se presenta cuando el sistema en producción se comporta de manera
inesperada.
DESARROLLO EXTERNO: Contratación del proceso de construcción de software que puede incluir
las etapas de especificación de requerimientos, organización y planeación, análisis de
requerimientos, diseño y mantenimiento de software.
4
SCS
COMITÉ DE PRODUCTO: Grupo conformado por los dueños de proceso o negocio de la institución
responsable de evaluar, definir y planear la implementación de nuevos productos o servicios.
CLIENTE INTERNO: Un cliente interno es cada uno de los funcionarios de la entidad a quienes se les
presta un servicio.
Con el fin de poder desarrollar software que sea inmune a fallas y posibles amenazas, es importante
incorporar los conceptos de seguridad desde la fase de requerimientos hasta la fase final de
mantenimiento del ciclo SDLC (Software Development Life Cycle). Los conceptos de seguridad se
deben considerar a lo largo de todo el ciclo de desarrollo y deben ser direccionados en cada fase. Si
en alguna de las fases no se prestara atención suficiente a la seguridad de la información esto podría
redundar en la disminución de los esfuerzos prestados a las fases previas.
DISPONIBILIDAD:
Propiedad que determina que la información sea accesible y utilizable por solicitud de una entidad
autorizada. La disponibilidad de la información se debe garantizar por medio de los planes de
continuidad del negocio o planes para la recuperación ante desastres. Se trata de poder acceder a las
aplicaciones y a la información que ellas manejan cuando sea requerido y se cuenta con la respectiva
autorización.
5
SCS
Los acuerdos de servicio (Service level Agreement-SLA) es uno de los ejemplos que pueden citarse
para explícitamente estipular los requerimientos para las aplicaciones que soportan los diferentes
servicios de una determinada organización. El balanceo de cargas y la replicación de información
críticos son otros dos mecanismos que ayudan a mejorar la disponibilidad de la información.
CONFIDENCIALIDAD:
Propiedad que determina la condición de que la información no esté disponible ni sea revelada a
individuos, entidades o procesos no autorizados. La confidencialidad protege contra posibles ataques
en que la información pueda ser sometida al escrutinio público. Hoy en día muchos ataques tienen en
mente el robo de información, por ejemplo, en el caso de la información que está en las tarjetas de
crédito que puede ser fácilmente utilizada para generar robo de dinero y de ahí el interés y el
creciente aumento de estos eventos.
INTEGRIDAD:
Propiedad de salvaguardar la exactitud y estado completo de los activos. Se considera que aplicación
posee resiliencia si cumple el papel de proteger la información contra alteraciones de datos no
autorizadas. Cuando se realiza una operación financiera uno esperaría que la cantidad de dinero
transferido sea igual a la cantidad de dinero que es descontada de la cuenta. En otras palabras,
esperamos que las aplicaciones sean consistentes en el uso de información. Se requiere que la
información que sea transmitida, procesada y almacenada se mantenga consistente según la
intención del que realiza la transacción.
Conocimiento
Característica Propiedad
6
SCS
Propiedad: El proceso de identificación en este aspecto se surte por medio de la presentación ante
el sistema que identifica de algo que nosotros poseemos y en teoría nadie más posee. Ejemplos de
este tipo autenticación son los tokens o smart cards.
AUTORIZACIÓN: Por el hecho de que las credenciales de identidad hayan sido validadas no quiere
decir esto que se le daba dar acceso a todos los recursos que se soliciten. Por ejemplo, puede darse
el caso que a alguien se le pueda dar acceso al software de contabilidad, no obstante, es posible que
el acceso a los datos de salarios deba ser bloqueados a él por su nivel de confidencialidad. La
autorización es el concepto dentro de la seguridad de la información en que los accesos a los
diferentes objetos son controlados y está basado en los derechos y privilegios que son otorgados a
los usuarios de acuerdo a las políticas y a los dueños de la información.
A continuación, expondremos los conceptos de seguridad que deben ser considerados cuando se
trate de diseñar la arquitectura de software seguro:
Separación de Defensa en
Menor privilegio Falla segura
tareas profundidad
7
SCS
DEFENSA EN PROFUNDIDAD: También conocido como defensa por niveles, este es un principio de
seguridad en donde el compromiso de alguno de los niveles de la defensa no implica que otros
niveles sean susceptibles de ataque.
FALLA SEGURA: Este principio de seguridad tiene como objetivos preservar la confidencialidad,
integridad y disponibilidad de la información durante una falla del software, de tal manera que el
estado en el que se estabilice, estos pilares de la seguridad de la información, sean mantenidos.
ECONOMÍA DE MECANISMOS: A este principio de seguridad subyace la concepción que entre más
simple sea el diseño de un componente o sistema la probabilidad de contar con vulnerabilidades
potenciales decrece en proporción a esta simplicidad. Si se mantiene el diseño del software dentro de
un nivel de simplicidad razonable, la superficie de ataque será reducida.
MEDIACIÓN COMPLETA: Este principio de seguridad establece que cuando un determinado sujeto
requiera acceder a un objeto este evento debe ser autorizado y en algunos casos supervisado. Todo
acceso siempre debe ser mediado (autorizado) cada vez que se solicite este recurso, es decir, no
debe haber excepciones dentro de la gestión del control de acceso.
MECANISMOS MÍNIMOS COMUNES: Se evita con este principio que se compartan mecanismos que
son comunes a uno o más usuarios o procesos si el usuario y el proceso poseen diferentes niveles de
privilegios.
ACEPTABILIDAD PSICOLÓGICA: En este principio se busca que las funciones de seguridad que se
implementen en el software sean de fácil uso y lo más transparentemente posible para el usuario
final.
ENLACE DÉBIL: Se propone con este principio que la seguridad de un sistema es tan fuerte como su
punto más débil. Sea este elemento el código, una interface o servicio.
8
SCS
9
SCS
CARGO/ROL RESPONSABILIDADES
Comité de Realizar revisiones periódicas a la metodología con el fin de mantener actualizadas las
Desarrollo técnicas implementadas de acuerdo a los objetivos propuestos.
Gerente de Comite de
Proyectos Desarrollo
Jefe de
Proyectos
Coordinador de
Proyectos
10
SCS
GERENTE DE PROTECTOS
COMITÉ DE DESARROLLO
JEFE DE PROYECTOS:
COORDINADOR DE PROYECTOS:
ANALISTA DE PROYECTOS:
1. Generar el análisis y diseño detallado del sistema, basándose en los artefactos propuestos en
la metodología y considerando posibles riesgos de seguridad de la información.
2. Realizar la codificación y las pruebas preliminares al software.
3. Documentar los procedimientos que se encuentren bajo su responsabilidad
11
SCS
El área de desarrollo debe contar con una metodología para el desarrollo de software seguro que
soporte y apoya los procesos de atención a incidencias, la construcción de nuevos desarrollos, la
ejecución de mejoras y desarrollos externos.
12
SCS
Especificación de
Requerimientos
Organización y
Planeación
Análisis de Seguridad
Requerimientos
Diseño de
Software
Construcción
Las Pruebas
Implantación de
Software
Mantenimiento
de Software
El proceso de desarrollo está dividido en 8 fases, cada una con un propósito específico que
dependiendo del requerimiento deberán ser elaborados, la duración de cada fase depende del
personal involucrado en el proyecto y del producto a generar. En todas las fases del desarrollo se
tiene en cuenta la seguridad de la información.
La metodología de desarrollo seguro debe soportar tanto los desarrollos internos como los externos
requeridos, para cada uno de estos procesos se ejecutarán las fases o actividades necesarias, que
permitan construir nuevas aplicaciones seguras o mejorar el software en producción.
Las fallas o incidentes se presentan por problemas en el código fuente de la aplicación los cuales
son clasificados por la mesa de ayuda y asignados para su solución al área de desarrollo.
13
SCS
Dentro del desarrollo de los proyectos de tecnología se puede determinar la viabilidad de los
desarrollos externos o subcontratados con terceros para el logro de los objetivos de manera eficaz o
eficiente, de igual manera estos desarrollos deben cumplir con las especificaciones de la metodología
diseñadas para este propósito.
Responsabilidad del
Responsabilidad interna
Tercero
Etapas de la Metodología
Etapas Cumplimiento Etapas Cumplimiento
Opcional Opcional
1. Especificación de requerimientos
Las casillas que se encuentran activas hacen referencia a las etapas de la metodología que
dependiendo de la necesidad y del tipo de cumplimiento serán ejecutadas.
Cumplimiento
1. Obligatorio: La ejecución de cada una de las etapas debe cumplirse ya que es necesario
para la correcta ejecución del proceso.
14
SCS
8.1.1 OBJETIVO
Cliente Interno:
Comité de Producto:
Comité de Desarrollo:
En la siguiente grafica se describe el proceso que conlleva la recepción de una falla, mejora, o un
nuevo requerimiento (Nuevo desarrollo o desarrollo externo) por el área de soporte y calidad.
15
SCS
Usuario Tipo de Requerimiento Tipo de Recepción Responsable Area Soporte Responsable Area Desarrollo
Usuario
Mejora
Cliente Interno
Desarrollo
Externo
Para especificar los requerimientos se debe establecer un documento estándar que contenga la
descripción del requerimiento, modelo del proceso u operaciones, el diseño de las pantallas, los
formatos de impresión (reportes, información), las restricciones del sistema, la dinámica contable y los
diagramas de flujo de cada uno de los procesos identificados (Interacción del sistema).
La Matriz de validación contendrá las acciones de prueba a ejecutar, los resultados esperados y los
resultados obtenidos del sistema tanto a nivel operativo como a nivel contable. Los casos de prueba
permiten validar que el aplicativo desarrollado realice las funciones para las que ha sido creado en
base a los requerimientos del Cliente interno y mantenga la seguridad de la información.
La elaboración de los reportes será solicitada por el Cliente interno por medio del formato de diseño
de reportes, el documento contendrá información acerca de los campos, filtros, niveles de agrupación,
periodicidad, tipo de presentación y los perfiles que tendrán acceso a los reportes. Su función es dar
16
SCS
a conocer al personal de desarrollo cuales son los datos, el orden, el formato que el Cliente interno
desea aplicar en el reporte, etc.
1. Especificación de requerimientos
2. Matriz de evaluación
3. Diseño de reportes
4. Manual de usuario
5. Actas
17
SCS
8.1.7 OBJETIVO
Proporcionar los elementos necesarios que ayuden a soportar el desarrollo del proyecto, asegurando
que puede ser llevado a cabo bajo en el tiempo estimado y con los recursos disponibles.
Objetivos Específicos
1. Delimitar el requerimiento
2. Identificar los riesgos a la seguridad de la información
3. Estimar los costos y recursos
Comité de Desarrollo:
Organización y Métodos
18
SCS
1. Organización y planeación
2. Análisis del requerimiento
3. Alternativa de desarrollo
4. Estimación de recursos
5. Cronograma de actividades
6. Control de avance
8.2.1 OBJETIVO
Comité Desarrollo: Evalúa, coordina, sugiere, aprueba o rechaza el análisis presentado por el
analista de desarrollo, como posible solución al requerimiento asignado.
Organización y métodos: Liderar y trabajar en forma conjunta con el grupo técnico en el análisis de
los métodos de trabajo existentes y en la implantación de las modificaciones que permitan obtener la
mayor eficiencia en el uso de los recursos tanto humanos como materiales con que están dotadas las
unidades operativas o funcionales.
El analista realizará el diagrama de casos de uso para describir las funciones que deberán realizar los
usuarios del sistema, cada caso de uso especifica la interacción entre el actor y la aplicación. La
razón de ser de este tipo de diagrama se concentra en lo que hará el sistema, no como lo hace.
Los diagramas de caso de uso se elaboran generalmente en la etapa de análisis de software, son
creados para facilitar la comunicación entre los programadores y el personal involucrado en los
proyectos desde etapas iniciales del ciclo de vida.
Explican el comportamiento paso a paso de un caso de uso, los casos de uso extendidos describen el
modo en el que interactúa un usuario con el sistema desde que inicia, realiza los procesos y finaliza la
sesión. Al describir un caso de uso se debe tener en cuenta toda la secuencia de acciones necesarias
19
SCS
para cumplir la funcionalidad que este requiere. Este punto se debe realizar en el caso de que los
requerimientos lleguen sin especificación de requerimientos.
El comité de desarrollo deberá verificar que la estructura del documento de análisis se encuentre
acorde al contenido de la plantilla elaborada para esta etapa y que los requerimientos y los casos de
uso describan la funcionalidad requerida por el usuario. Cuando el documento sea aprobado el
analista podrá continuar con la etapa de diseño.
ü Análisis de requerimientos
ü Diagrama de casos de uso
ü Especificación de los casos de uso
20
SCS
8.3.1 OBJETIVO
Aplicar las distintas técnicas y principios para establecer la forma en la que el sistema dará solución
a los requerimientos identificados en la etapa de análisis. Durante el desarrollo de esta etapa se
elaborará el esquema físico de la base de datos, se elegirá el lenguaje de programación, se diseñara
la arquitectura a utilizar y se elaborará el diccionario de datos.
Comité de desarrollo: Evaluar, Coordinar, aprobar o rechazar el diseño presentado por el analista
de desarrollo, como posible solución al requerimiento asignado
Analista de desarrollo:
En este ítem se deberá anexar una descripción explicativa de las herramientas empleadas o a
emplear durante el análisis, diseño, implementación y pruebas de los diferentes requerimientos a
desarrollar.
§ Proveedor
§ Tipo de licenciamiento
§ Versión.
La Arquitectura del Software es el diseño de más alto nivel de la estructura de una aplicación, nos
permite identificar los elementos, las relaciones y la forma de como interactúa el sistema con su
entorno.
La arquitectura debe detallar la estructura del sistema, las relaciones que tienen sus elementos con sí
mismos y con los que hacen parte de su entorno. Cuando se elabore el bosquejo, se deberá
especificar el punto exacto donde ocurre la interacción con los sistemas, interfaces, bases de datos o
procesos externos.
El siguiente ejemplo presenta el diseño de una aplicación que adopta una arquitectura en capas
donde el objetivo primordial es la separación de la lógica de presentación de la lógica de negocios y
21
SCS
Arquitectura de la aplicación
Web Service
Usuarios
Lógica de Presentación
Lógica de Negocios
Lógica Acceso Datos
SGBD
Es un modelo de datos de alto nivel donde se representa gráficamente las entidades (nombre de
objetos del mundo real), las propiedades y relaciones que hay entre cada uno de los objetos, este
diagrama es elaborado con el objetivo de representar la estructura lógica general de la base de datos.
El objetivo del diccionario de datos es dar precisión sobre los metadatos evitando así malas
interpretaciones y/o ambigüedades en etapas posteriores. En el diccionario se detalla la estructura de
las Entidades, sus campos, tipos de datos, llaves primarias, foráneas, índices, etc.
Se define como la lista de términos que los posibles lectores del documento pueden desconocer.
22
SCS
El comité de desarrollo deberá verificar que la estructura del documento de diseño se encuentre
acorde al contenido de la plantilla elaborada para esta etapa, que el diagrama Entidad relación
contenga las Entidades relevantes (con sus interrelaciones y atributos) para el sistema y el diccionario
de datos describa las características de la información que deberá ser almacenada en una base de
datos.
23
SCS
8.3.6 OBJETIVO
Analista de Desarrollo:
Coordinador de desarrollo
ü Coordinar y evaluar el desarrollo o la mejora elaborada por el analista
El Plan de Desarrollo del Software es elaborado con el fin de proveer una visión global del enfoque de
desarrollo propuesto por el programador, busca proporcionar de manera oportuna la información
necesaria para evaluar y controlar la implementación de todo requerimiento o nueva funcionalidad.
El manual técnico incluye la descripción detallada de los módulos y programas que constituyen el
sistema, las funciones o procedimientos que se utilizan y los parámetros que se requieren, así como
la estructura de las tablas de la base de datos, etc. El analista de desarrollo deberá elaborar el
manual técnico por cada uno de los desarrollos a su cargo.
El proceso de construcción consiste en traducir el diseño lógico de un sistema a código fuente; para
ello, se utilizará un lenguaje de alto nivel elegido en anteriores etapas teniendo en cuenta el propósito
del requerimiento. Para cada uno de los lenguajes de programación existen documentos o estándares
para que el proceso se realice de manera adecuada. Durante la programación es de gran importancia
documentar todos los objetos elaborados con la finalidad de realizar el mantenimiento del software en
posteriores etapas y además se deberán realizar las pruebas preliminares las cuales buscan detectar
posibles errores en la aplicación antes de pasar el desarrollo hacia otras etapas.
1. Plan de desarrollo
2. Manual técnico
3. Formato de paso
4. Archivos de código fuente
24
SCS
8.4.1 OBJETIVO
Coordinador de Desarrollo:
Analista de desarrollo
El analista a partir de la matriz de validaciones elaborada por el Cliente Interno debe diseñar un plan
de pruebas preliminares detallado definiendo el alcance, los requerimientos hardware o software,
personal, estrategias de las pruebas detalladas por perfil, entre otras.
El documento es requisito esencial para el paso a pruebas del requerimiento. El Plan pruebas ofrece
un resumen de los elementos de prueba, este resumen debe incluir información sobre los objetivos, el
enfoque general, y los casos de prueba a realizar, etc.
El responsable de las pruebas debe actualizar el manual usuario una vez hayan culminado
satisfactoriamente las pruebas generales del software.
Con el fin de garantizar que el sistema ha sido desarrollado correctamente, el responsable de las
pruebas debe realizar las debidas pruebas funcionales, de sistema, de integridad, confiabilidad, de
confidencialidad y de rendimiento, que garanticen el correcto desempeño del sistema bajo el mayor
número de situaciones posibles a las que se pueda enfrentar.
Cuando el sistema esté listo y se haya elaborado el plan de pruebas, el desarrollador debe diligenciar
el formato de paso que contiene la información del proceso a realizar, los objetos y su ubicación,
descripción de la solución, responsables del desarrollo, aprobación y paso a producción. Una vez
diligenciado debe entregarlo al área de soporte y calidad quienes tienen la responsabilidad de
ejecutar esta tarea.
El área de soporte y calidad debe elegir el o los usuarios idóneos para realizar este proceso
teniendo en cuenta que: debe tener amplios conocimientos sobre la aplicación desarrollada, así se
25
SCS
garantiza que se cubran la mayor cantidad de casos de prueba y se verifica que el producto cumpla
satisfactoriamente con los requerimientos iniciales. Además, se debe definir la organización del
Equipo de Pruebas teniendo en cuenta los siguientes ítems:
Se debe establecer el ambiente adecuado para la ejecución de las pruebas teniendo en cuenta las
siguientes actividades:
8.4.4.3 EJECUCIÓN
El reporte será enviado al comité de desarrollo quien valorara cada una de las observaciones y
elaborará un acta con los cambios a realizar por el área y las devolverá al comité de pruebas para su
conocimiento.
Si los cambios a realizar implican una modificación o una adición a los requerimientos iniciales el
Cliente Interno debe elaborar un acta donde especifique el propósito del requerimiento.
Una vez finalicen las pruebas al software, el responsable de las pruebas debe diligenciar el formato
de paso con los cambios realizados en la presente etapa y con las firmas de aprobación
correspondientes para el paso a producción del software.
El analista debe realizar las correcciones, implementar los nuevos requerimientos y las mejoras al
software apoyándose en las etapas de la metodología de desarrollo según el análisis que se realice
para cada una de las tareas definidas.
1. Formato de paso
2. Plan de pruebas
3. Actualización de documentos
26
SCS
8.5.1 OBJETIVO
Asegurar que el paso del desarrollo se lleve a cabo de acuerdo a los pasos descritos en el plan de
implantación, con el propósito de disminuir los problemas que se presentan durante la ejecución de
esta actividad.
La implantación se clasifica en cuatro categorías, que se deben identificar para determinar el tipo, el
impacto y complejidad del plan a ejecutar:
Método Directo: el objetivo de este método es abandonar el sistema anterior y adoptar directamente
el nuevo sistema.
Método Paralelo: el objetivo de este método es poner en funcionamiento el nuevo sistema en paralelo
con el antiguo, esto para hacer un seguimiento de la eficiencia y eficacia del nuevo sistema.
Método piloto: en este método el nuevo sistema se pone en funcionamiento en una parte de
organización, si no genera eventualidades o fallas será implantado en el resto de las áreas.
Método en Fases: en este método el sistema se divide en partes o fases y no se puede pasar a la
siguiente fase sin haber finalizado en su totalidad la fase actual.
27
SCS
1. Plan de implantación
8.6.1 OBJETIVO
Comité de TI
Cliente Interno
Analista de proyectos
El comité de desarrollo, comité de pruebas, comité de soporte, comité de TI o el dueño del negocio
definirán durante las reuniones que realizaran periódicamente cuales son las mejoras, cambios o
adaptaciones a realizar sobre el software de la Entidad teniendo en cuenta los siguientes tipos de
mantenimiento:
ü Mantenimiento Correctivo
El objetivo del mantenimiento correctivo es identificar y eliminar los posibles defectos o fallas
del sistema en producción.
ü Mantenimiento Preventivo
Surge cuando se realizan modificaciones al software para mejorar sus propiedades o añadir
características adicionales sin alterar su funcionamiento.
28
SCS
Mantenimiento
de Software
Análisis de
Requerimientos
Seguridad
Diseño de
Software
Construcción
Pruebas
Implantación de
Software
29
SCS
30
SCS
ANEXOS
Mesa Ayuda Comite Producción Analista de Desarrollo Personal Pruebas Personal Producción
especificación Requerimientos
Soporte
Manual Usuario
Analisis Requerimientos
Plan Desarrollo
Manual Técnico
Pruebas
Calidad
Soporte Actualización
Pruebas Manual
Usuario
Formato Paso
Evaluación, Verificación
Indicadores Gestión
Producción
SLA
Acciones:
Preventiva, Correctivas Plan Implantación
y de Mejora
31
SCS
32
SCS
Business Continuity Institute (2013) Good Practice Guidelines: A guide to global good practice in business
continuity, Business Continuity Institute, Caversham.
Disaster Recovery Institute International (DRII) (2012) Professional Practices for Business Continuity
Practitioners, DRII, New York.
ISO 22301 (2012) – Societal security – Business continuity management systems – Requirements
ISO 22301 (2012) – Societal security – Business continuity management systems – Guidance
www.sans.org
www.nist.org
www.microsoft.com
33
SCS
34