GESTIÓN DE LA

SEGURIDAD DEL
SOFTWARE
Ms.C. Jhosep Valenzuela
Contenido

I. Seguridad en el ciclo de vida de desarrollo de software

1. Principios de seguridad de sistemas
2. Ciclo de vida de desarrollo de un sistema (SDLC)
3. Actividades centrales del SLDC
4. Metodologías de desarrollo
5. Modelos de madurez
6. Gestión de cambios y configuración
I. Seguridad en el ciclo de vida
de desarrollo de software
1. Principios de seguridad de sistemas
ARQUITECTURA Y DISEÑO DE SEGURIDAD DEL SISTEMA
Abstracciones claras Mecanismo menos común Modularidad y capas Dependencias parcialmente Acceso mediado eficientemente
ordenadas
Uso compartido minimizado Complejidad reducida Evolución segura Componentes confiables Confianza jerárquica

Umbral de modificación inversa Protección jerárquica Elementos de seguridad Privilegio mínimo Permiso de predicado
minimizados
Confiabilidad autosuficiente Composición distribuida segura Canales de comunicación
confiables

CAPACIDAD Y COMPORTAMIENTO INTRÍNSECO DE SEGURIDAD DEL SISTEMA

Protección continua Gestión segura de metadatos Autoanálisis Responsabilidad y trazabilidad Valores predeterminados seguros

Falla segura y recuperación Seguridad económica Seguridad de rendimiento Seguridad de factores humanos Seguridad aceptable

SEGURIDAD EN EL CICLO DE VIDA DEL SISTEMA

Procedimientos repetibles y Rigor procesal Modificación segura del sistema Documentación suficiente
documentados

ENFOQUES DE CONFIANZA EN UN SISTEMA SEGURO

Concepto de monitor de Defensa en profundidad Aislamiento
referencia

Referencia: NIST, Special Publication 800-160, Volume 1

2. Ciclo de vida de desarrollo de un sistema
(SDLC)
SDLC - Etapa Objetivo Revisión
Iniciación Garantizar que los controles se Seguridad (revisiones de
Desarrollo / Adquisición diseñen, desarrollen e implementen diseño y código, escaneo
correctamente y sean consistentes de aplicaciones y pruebas
con la arquitectura de seguridad de de regresión).
Implementación la información organizacional Privacidad (revisiones para
establecida. garantizar que se cumplan
Garantizar que los controles las leyes y políticas de
continúen siendo efectivos en el privacidad aplicables y que
Operaciones y las protecciones de
entorno operativo y puedan
Mantenimiento privacidad estén integradas
protegerlas contra amenazas en
constante evolución. en el diseño del sistema).
Eliminación - -

Referencia: NIST, Special Publication 800-53A Rev. 4

3. Actividades centrales del SDLC

La seguridad es más eficaz si se planifica y gestiona durante todo el ciclo de vida de un

sistema.
El uso de modelos de ciclo de vida formalizados ayuda a garantizar buenas prácticas de
codificación y la incorporación de seguridad en cada etapa del desarrollo del producto.
Estas actividades centrales son esenciales para el desarrollo de sistemas sólidos y
seguros:
 Definición conceptual
 Determinación de requisitos funcionales
 Desarrollo de especificaciones de control
 Revisión de diseño
 Codificación
 Revisión de código
 Pruebas del sistema
 Mantenimiento y gestión del cambio
Referencia: CISSP Official Study Guide
Definición conceptual

Es una declaración simple acordada por todas las partes interesadas (desarrolladores,
clientes y administración) que establece el propósito del proyecto, así como los requisitos
generales del sistema.
La definición conceptual es una declaración de propósito de muy alto nivel y no debe tener
más de uno o dos párrafos.
Los requisitos de seguridad desarrollados en esta fase son generalmente de muy alto nivel.
Se refinarán durante la fase de desarrollo de especificaciones de control. En este punto del
proceso, los diseñadores comúnmente identifican la(s) clasificación(es) de datos que serán
procesados por el sistema y los requisitos de manejo aplicables.

Referencia: CISSP Official Study Guide

Determinación de requisitos funcionales

Se enumeran las funcionalidades específicas del sistema y los desarrolladores comienzan

a pensar en cómo deberían interoperar las partes del sistema para cumplir con los
requisitos funcionales.
El resultado de esta fase de desarrollo es un documento de requisitos funcionales.
Las siguientes son las tres características principales de un requisito funcional:
Entrada(s) Los datos proporcionados a una función
Comportamiento La lógica de negocios que describe qué acciones debe tomar el
sistema en respuesta a diferentes entradas
Salida(s) Los datos proporcionados por una función
Al igual que con la declaración del concepto, es importante asegurarse de que todas las
partes interesadas estén de acuerdo con el documento de requisitos funcionales antes de
que el trabajo avance al siguiente nivel.

Referencia: CISSP Official Study Guide

Desarrollo de especificaciones de control

Durante el desarrollo de las especificaciones de control, debe analizar el sistema desde

varias perspectivas de seguridad.
• Primero, se deben diseñar controles de acceso adecuados en cada sistema para
garantizar que solo los usuarios autorizados puedan acceder al sistema y que no se les
permita exceder su nivel de autorización.
• En segundo lugar, el sistema debe mantener la confidencialidad de los datos vitales
mediante el uso de tecnologías de encriptación y protección de datos adecuadas.
• A continuación, el sistema debe proporcionar tanto una pista de auditoría para hacer
cumplir la responsabilidad individual como un mecanismo de detección de actividades
ilegítimas.
• Finalmente, dependiendo de la criticidad del sistema, los problemas de disponibilidad y
tolerancia a fallas deben abordarse como acciones correctivas.
El diseño de la seguridad en un sistema no es un proceso único y debe hacerse de manera
proactiva.
Referencia: CISSP Official Study Guide
Revisión de diseño

En este proceso, que suele ser largo, los diseñadores determinan exactamente cómo
interoperarán las diversas partes del sistema y cómo se diseñará la estructura del sistema
modular.
Durante esta fase, el equipo de gestión de diseño establece tareas específicas para varios
equipos y establece plazos iniciales para completar los hitos de codificación.
Después de que el equipo de diseño complete los documentos de diseño formales, se debe
realizar una reunión de revisión con las partes interesadas para garantizar que todos estén
de acuerdo en que el proceso sigue encaminado para el desarrollo exitoso de un sistema
con la funcionalidad deseada.
Esta reunión de revisión del diseño debe incluir profesionales de seguridad que puedan
validar que el diseño propuesto cumple con las especificaciones de control desarrolladas
en la fase anterior.

Referencia: CISSP Official Study Guide

Codificación

Una vez que las partes interesadas han dado su aprobación al diseño del software, es hora
de que los desarrolladores de software comiencen a escribir el código.
Los desarrolladores deben usar los principios de codificación de software seguro para crear
un código que sea consistente con el diseño acordado y cumpla con los requisitos del
usuario.

Referencia: CISSP Official Study Guide

Revisión de código

Los gerentes de proyecto deben programar varias reuniones de revisión de código en

varios hitos a lo largo del proceso de codificación.
Estas reuniones técnicas generalmente involucran solo al personal de desarrollo, que se
sienta con una copia del código para un módulo específico y lo revisa, buscando problemas
en el flujo lógico u otras fallas de diseño/seguridad.
Las reuniones desempeñan un papel fundamental para garantizar que el código producido
por los diversos equipos de desarrollo funcione de acuerdo con las especificaciones.

Referencia: CISSP Official Study Guide

Pruebas del sistema

Inicialmente, la mayoría de las organizaciones realizan las pruebas iniciales del sistema
utilizando personal de desarrollo para buscar errores obvios.
A medida que avanza la prueba, los desarrolladores y los usuarios reales validan el sistema
frente a escenarios predefinidos que modelan actividades de usuario comunes e inusuales.
Estos procedimientos de prueba deben incluir pruebas funcionales que verifiquen que el
software funcione correctamente y pruebas de seguridad que verifiquen que no haya
problemas de seguridad significativos sin resolver.
Una vez que los desarrolladores están satisfechos de que el código funciona
correctamente, el proceso pasa a la prueba de aceptación del usuario (UAT), donde los
usuarios verifican que el código cumple con sus requisitos y lo aceptan formalmente como
listo para pasar al uso de producción.
Una vez que se completa esta fase, el código puede pasar a la implementación.

Referencia: CISSP Official Study Guide

Mantenimiento y gestión del cambio

Una vez que un sistema está operativo, es necesario realizar una variedad de tareas de
mantenimiento para garantizar el funcionamiento continuo frente a los cambiantes
requisitos operativos, de procesamiento de datos, de almacenamiento y ambientales.
Es esencial que cuente con un equipo de soporte calificado para manejar cualquier
mantenimiento de rutina o inesperado.
También es importante que cualquier cambio en el código se maneje a través de un
proceso de gestión de cambios formalizado.

Referencia: CISSP Official Study Guide

4. Metodologías de desarrollo

La adopción de procesos de gestión del ciclo de vida más formalizados se observa en la

ingeniería de software convencional a medida que la industria madura.
Si la metodología SDLC es inadecuada, es posible que el proyecto no satisfaga las
necesidades comerciales y de los usuarios. Es importante que el modelo SDLC se
implemente correctamente y sea apropiado para su entorno.
Elegir un modelo SDLC es el trabajo de los equipos de desarrollo de software y su
liderazgo.
 Waterfall Model
 Spiral Model
 Agile Software Development
 The DevOps Approach

Referencia: CISSP Official Study Guide

Waterfall Model

Originalmente desarrollado por Winston Royce en 1970, el modelo de cascada busca ver el
ciclo de vida del desarrollo de sistemas como una serie de actividades secuenciales.
El modelo de cascada tradicional tiene siete etapas secuenciales de desarrollo. A medida
que se completa cada etapa, el proyecto pasa a la siguiente fase.
El modelo de cascada, por necesidad, evolucionó a un modelo más moderno. El modelo
iterativo en cascada permite que el desarrollo regrese a la fase anterior para corregir los
defectos descubiertos durante la fase siguiente.
Esto a menudo se conoce como la característica del circuito de retroalimentación del
modelo de cascada.

Referencia: CISSP Official Study Guide

Waterfall Model

El modelo en cascada fue uno de los

primeros intentos integrales de modelar el
proceso de desarrollo de software teniendo
en cuenta la necesidad de volver a las fases
anteriores para corregir las fallas del
sistema.
Sin embargo, una de las principales críticas
a este modelo es que permite a los
desarrolladores retroceder solo una fase en
el proceso.
No prevé el descubrimiento de errores en
una fase posterior del ciclo de desarrollo.

Referencia: CISSP Official Study Guide

Spiral Model

En 1988, Barry Boehm de TRW propuso un modelo de ciclo de vida alternativo que permite
múltiples iteraciones de un proceso estilo cascada.
Debido a que el modelo en espiral encapsula una serie de iteraciones de otro modelo (el
modelo en cascada), se lo conoce como metamodelo o "modelo de modelos".
Teóricamente, los desarrolladores de sistemas aplicarían todo el proceso en cascada al
desarrollo de cada prototipo, trabajando así de manera incremental hacia un sistema
maduro que incorpore todos los requisitos funcionales de una manera completamente
validada. El modelo en espiral de Boehm proporciona una solución a la principal crítica del
modelo en cascada: permite a los desarrolladores volver a las etapas de planificación, ya
que las cambiantes demandas técnicas y los requisitos del cliente requieren la evolución de
un sistema.
El modelo en cascada se enfoca en un esfuerzo a gran escala para entregar un sistema
terminado, mientras que el modelo en espiral se enfoca en iterar a través de una serie de
prototipos cada vez más "terminados" que permiten un control de calidad mejorado.

Referencia: CISSP Official Study Guide

Spiral Model

Observe que cada “bucle” de la espiral da

como resultado el desarrollo de un nuevo
prototipo de sistema (representado por P1,
P2 y P3).

Referencia: CISSP Official Study Guide

Agile Software Development - Core Philosophy

Estamos descubriendo mejores formas de desarrollar software haciéndolo y ayudando a

otros a hacerlo. A través de este trabajo hemos llegado a valorar:
Individuos e interacciones sobre procesos y herramientas
Trabajo de Software sobre documentación completa
Colaboración con el cliente sobre la negociación del contrato
Responder al cambio sobre el siguiente plan

Referencia: CISSP Official Study Guide

Agile Software Development - Principles
Los 12 principios, tal como se establece en el Manifiesto Ágil, son los siguientes:
1. Nuestra máxima prioridad es satisfacer al cliente mediante la entrega temprana y
continua de software valioso.
2. Da la bienvenida a los requisitos cambiantes, incluso al final del desarrollo. Los
procesos ágiles aprovechan el cambio para la ventaja competitiva del cliente.
3. Entregue software que funcione con frecuencia, desde un par de semanas hasta un par
de meses, con preferencia a la escala de tiempo más corta.
4. Los empresarios y los desarrolladores deben trabajar juntos a diario durante todo el
proyecto.
5. Construir proyectos en torno a personas motivadas. Bríndeles el entorno y el apoyo
que necesitan, y confíe en ellos para hacer el trabajo.
6. El método más eficiente y efectivo para transmitir información a un equipo de desarrollo
y dentro de él es una conversación cara a cara.

Referencia: CISSP Official Study Guide

Agile Software Development - Principles
7. El software que funciona es la medida principal del progreso.
8. Los procesos ágiles promueven el desarrollo sostenible. Los patrocinadores,
desarrolladores y usuarios deberían poder mantener un ritmo constante
indefinidamente.
9. La atención continua a la excelencia técnica y al buen diseño mejora la agilidad.
10. La simplicidad, el arte de maximizar la cantidad de trabajo no realizado, es esencial.
11. Las mejores arquitecturas, requisitos y diseños surgen de equipos autoorganizados.
12. A intervalos regulares, el equipo reflexiona sobre cómo volverse más efectivo, luego
sintoniza y ajusta su comportamiento en consecuencia.
Hoy en día, la mayoría de los desarrolladores de software adoptan la flexibilidad y el
enfoque en el cliente del enfoque Agile para el desarrollo de software.
En un enfoque Agile, el equipo adopta los principios del Manifiesto Agile y se reúne
regularmente para revisar y planificar su trabajo.

Referencia: CISSP Official Study Guide

Agile Software Development

Agile es una filosofía y no una metodología específica.

Han surgido varias metodologías específicas que toman estos principios ágiles y definen
procesos específicos que los implementan (Scrum, Kanban, Desarrollo rápido de
aplicaciones (RAD), Proceso unificado ágil (AUP), el Modelo de desarrollo de sistemas
dinámicos (DSDM) y Programación extrema (XP)).
De estos, el enfoque Scrum es el más popular. Scrum toma su nombre de las reuniones
diarias de equipo, llamadas scrums, que son su seña de identidad.
Cada día, el equipo se reúne para una breve reunión, donde discuten las contribuciones
hechas por cada miembro del equipo, planifican el trabajo del día siguiente y trabajan para
eliminar cualquier impedimento para su progreso.
Estas reuniones están dirigidas por el scrum master del proyecto, una persona con un rol
de gestión de proyectos que es responsable de ayudar al equipo a avanzar y alcanzar sus
objetivos.

Referencia: CISSP Official Study Guide

Agile Software Development

La metodología Scrum organiza el trabajo en sprints cortos de actividad.

Estos son períodos de tiempo bien definidos, generalmente entre una y cuatro semanas, en
los que el equipo se enfoca en lograr objetivos a corto plazo que contribuyan a las metas
más amplias del proyecto.
Al comienzo de cada sprint, el equipo se reúne para planificar el trabajo que se llevará a
cabo durante cada sprint.
Al final del sprint, el equipo debe tener un producto en pleno funcionamiento que pueda
lanzarse, incluso si aún no cumple con todos los requisitos del usuario.
Cada sprint posterior introduce una nueva funcionalidad en el producto.

Referencia: CISSP Official Study Guide

The DevOps Approach

El enfoque DevOps busca resolver los problemas de desconexión entre desarrollo de

software, el control de calidad y las operaciones de TI al reunir las tres funciones en un solo
modelo operativo.
El modelo DevOps está estrechamente alineado con el enfoque de desarrollo Agile y tiene
como objetivo reducir drásticamente el tiempo necesario para desarrollar, probar e
implementar cambios de software.
Los enfoques tradicionales a menudo resultaron en importantes implementaciones de
software (anualmente), las organizaciones que utilizan el modelo DevOps a menudo
implementan código varias veces al día.
Algunas organizaciones incluso se esfuerzan por alcanzar el objetivo de integración
continua/entrega continua (CI/CD), donde el código puede implementarse docenas o
incluso cientos de veces al día. Esto requiere un alto grado de automatización, incluida la
integración de repositorios de código, el proceso de administración de configuración de
software y el movimiento de código entre entornos de desarrollo, prueba y producción.

Referencia: CISSP Official Study Guide

The DevOps Approach

Referencia: CISSP Official Study Guide

5. Modelos de madurez

Elegir un modelo de madurez del SDLC es el trabajo de los lideres.

 Capability Maturity Model (CMM)
 Software Assurance Maturity Model (SAMM)
 IDEAL Model

Referencia: CISSP Official Study Guide

Capability Maturity Model (CMM)

Propuesto por El Instituto de Ingeniería de Software (SEI) de la Universidad Carnegie

Mellon (USA)
También conocido como Modelo de Madurez de Capacidad de Software (SW-CMM, CMM o
SCMM), que sostiene que todas las organizaciones involucradas en el desarrollo de
software se mueven a través de una variedad de fases de madurez en forma secuencial.
El SW-CMM describe los principios y prácticas subyacentes a la madurez del proceso de
software. La calidad del software depende de la calidad de su proceso de desarrollo.
SW-CMM no aborda explícitamente la seguridad, pero es responsabilidad de los
profesionales de ciberseguridad y los desarrolladores de software garantizar que los
requisitos de seguridad se integren en el esfuerzo de desarrollo de software.

Referencia: CISSP Official Study Guide

Capability Maturity Model (CMM) - Levels

Nivel 1: Inicial A menudo encontrará personas que trabajan de manera desorganizada.

Por lo general, hay poco o ningún proceso de desarrollo de software definido.
Nivel 2: Repetible Se introducen los procesos básicos de gestión del ciclo de vida. Existe
reutilización organizada de código con resultados repetibles de proyectos similares.
Procesos clave: Gestión de requisitos, Planificación de proyectos de software, Seguimiento
y supervisión de proyectos de software, Gestión de subcontratos de software, Garantía de
calidad de software y Gestión de configuración de software.
Nivel 3: Definido Los desarrolladores de software operan de acuerdo con un conjunto de
procesos de desarrollo de software formales y documentados. Todos los proyectos de
desarrollo se llevan a cabo dentro del nuevo modelo de gestión estandarizado.
Procesos Clave: Enfoque en el proceso de la organización, Definición del proceso de la
organización, Programa de capacitación, Gestión integrada de software, Ingeniería de
productos de software, Coordinación intergrupal y Revisiones entre pares.

Referencia: CISSP Official Study Guide

Capability Maturity Model (CMM) - Levels

Nivel 4: Gestionado La gestión del proceso de software pasa al siguiente nivel. Las
medidas cuantitativas se utilizan para obtener una comprensión detallada del proceso de
desarrollo.
Procesos clave: Gestión de Procesos Cuantitativos y Gestión de Calidad del Software.
Nivel 5: Optimización En la organización optimizada se produce un proceso de mejora
continua. Se implementan procesos de desarrollo de software sofisticados que aseguran
que la retroalimentación de una fase llegue a la fase anterior para mejorar los resultados
futuros.
Procesos clave: Prevención de defectos, Gestión de cambios tecnológicos y Gestión de
cambios de procesos.

Referencia: CISSP Official Study Guide

Software Assurance Maturity Model (SAMM)

Referencia: CISSP Official Study Guide

Software Assurance Maturity Model (SAMM)

El Modelo de Madurez de Software Assurance (SAMM) es un proyecto de código abierto

mantenido por el Proyecto de Seguridad de Aplicaciones Web Abiertas (OWASP).
Busca proporcionar un marco para integrar las actividades de seguridad en el proceso de
desarrollo y mantenimiento de software y ofrecer a las organizaciones la capacidad de
evaluar su madurez.
SAMM divide el proceso de desarrollo de software en cinco funciones comerciales:
Gobernanza Las actividades que lleva a cabo una organización para gestionar su proceso
de desarrollo de software. Esta función incluye prácticas de estrategia, métricas, políticas,
cumplimiento, educación y orientación.
Diseño El proceso utilizado por la organización para definir los requisitos de software y
crear software. Esta función incluye prácticas para el modelado de amenazas, la
evaluación de amenazas, los requisitos de seguridad y la arquitectura de seguridad.

Referencia: CISSP Official Study Guide

Software Assurance Maturity Model (SAMM)

Implementación El proceso de construir e implementar componentes de software y

administrar fallas en esos componentes. Esta función incluye las prácticas de creación
segura, implementación segura y gestión de defectos.
Verificación El conjunto de actividades realizadas por la organización para confirmar que
el código cumple con los requisitos comerciales y de seguridad. Esta función incluye
evaluación de arquitectura, pruebas basadas en requisitos y pruebas de seguridad.
Operaciones Las acciones tomadas por una organización para mantener la seguridad a lo
largo del ciclo de vida del software después de que se libera el código. Esta función incluye
la gestión de incidentes, la gestión del entorno y la gestión operativa.

Referencia: CISSP Official Study Guide

IDEAL Model

El SEI también desarrolló el modelo IDEAL (con muchos de los atributos de SW-CMM):
1: Initiating Se describen las razones comerciales detrás del cambio, se construye el
soporte para la iniciativa y se establece la infraestructura adecuada.
2: Diagnosis Los ingenieros de diagnóstico analizan el estado actual de la organización y
hacen recomendaciones generales para el cambio.
3: Establishing La organización toma las recomendaciones generales de la fase de
diagnóstico y desarrolla un plan de acción específico que ayude a lograr esos cambios.
4: Acting Es hora de dejar de "hablar por hablar" y "caminar por el camino". La
organización desarrolla soluciones y luego las prueba, las refina y las implementa.
5: Learning La organización debe analizar continuamente sus esfuerzos para determinar si
ha alcanzado las metas deseadas y, cuando sea necesario, proponer nuevas acciones
para volver a encarrilar a la organización.

Referencia: CISSP Official Study Guide

IDEAL Model

Referencia: CISSP Official Study Guide

6. Gestión de cambios y configuración

En el ambiente de producción, los usuarios inevitablemente solicitarán la adición de nuevas

funciones, la corrección de errores y otras modificaciones al código.
Luego, esos cambios deben registrarse en un repositorio central para respaldar los futuros
requisitos de auditoría, investigación, resolución de problemas y análisis.
El proceso de gestión del cambio tiene tres componentes básicos:
i. Control de solicitudes
ii. Control de cambios
iii. Control de liberación
El proceso de gestión de configuración tiene los siguientes componentes:
i. Planeamiento
ii. Identificación e implementación de configuraciones
iii. Control de cambios de configuración
iv. Monitoreo
Referencia: CISSP Official Study Guide
6. Gestión de cambios y configuración

Gestión de cambios:
1. Control de solicitudes Proporciona un marco organizado dentro del cual los
usuarios pueden solicitar modificaciones, los administradores pueden realizar
análisis de costo/beneficio y los desarrolladores pueden priorizar tareas.
2. Control de cambios Los desarrolladores pueden recrean la situación encontrada
por el usuario y analizar los cambios apropiados para remediar la situación,
involucra crear y probar una solución antes de implementarla en un entorno de
producción.
Incluye: Control de calidad, implementación de actualizaciones o cambios, la
documentación adecuada de cualquier cambio codificado y la seguridad.
3. Control de liberación Verificar que cualquier código insertado como código de
depuración y/o puertas traseras se elimine antes de lanzar el nuevo software a
producción. Garantiza que solo se realicen cambios aprobados en los sistemas de
producción. El control de versiones también debe incluir pruebas de aceptación.

Referencia: CISSP Official Study Guide

6. Gestión de cambios y configuración

Gestión de configuración:
La gestión de configuración de sistemas centrada en la seguridad implica un conjunto de
actividades que se pueden organizar en cuatro fases principales:
• Planificación
• Identificación e Implementación de Configuraciones
• Control de Cambios de Configuración
• Monitoreo
Respalda la seguridad del sistema y la gestión del riesgo organizacional.

Referencia: NIST, Special Publication 800-128

6. Gestión de cambios y configuración

1. Planificación
Incluye el desarrollo de políticas y procedimientos para incorporar SecCM en los programas
de seguridad y TI existentes, y luego difundir la política en toda la organización.
La política aborda áreas tales como la implementación de planes SecCM, la integración en
planes de programas de seguridad existentes, tableros de control de configuración (CCB),
procesos, herramientas y tecnología de control de cambios de configuración, el uso de
configuraciones seguras comunes y configuraciones de referencia, monitoreo y métricas
para el cumplimiento con la política y los procedimientos establecidos de SecCM.
Por lo general, es más rentable desarrollar e implementar un plan SecCM, políticas,
procedimientos y herramientas SecCM asociadas a nivel de gestión de riesgos de la
organización o de la misión/proceso comercial.

Referencia: NIST, Special Publication 800-128

6. Gestión de cambios y configuración

2. Identificación e Implementación de Configuraciones

Una vez completadas las actividades de planificación y preparación, se desarrolla, revisa,
aprueba e implementa una configuración básica segura para el sistema. La configuración
de referencia aprobada para un sistema y los componentes asociados representa el estado
más seguro de acuerdo con los requisitos y restricciones operativos.
Para un sistema típico, la línea de base segura puede abordar los ajustes de configuración,
las cargas de software, los niveles de parches, cómo funciona el sistema de información
dispuestos física o lógicamente, cómo se implementan los diversos controles de seguridad
y la documentación.
Siempre que sea posible, se utiliza la automatización para permitir la interoperabilidad de
las herramientas y la uniformidad de las configuraciones de referencia en todo el sistema.

Referencia: NIST, Special Publication 800-128

6. Gestión de cambios y configuración

3. Control de Cambios de Configuración

Dada la naturaleza en constante evolución de un sistema y la misión que respalda, el
desafío para las organizaciones no es solo establecer una configuración de referencia
inicial que represente un estado seguro, sino también para mantener una configuración
segura frente a las importantes olas de cambio que se propagan por las organizaciones.
En esta fase de SecCM, el énfasis se pone en la gestión del cambio para mantener la línea
de base segura y aprobada del sistema.
A través del uso de prácticas SecCM, las organizaciones aseguran que los cambios son
formalmente identificados, propuestos, revisados, analizados por impacto en la seguridad,
probados y aprobados antes de su implementación.
Las organizaciones pueden emplear controles de acceso, automatización de procesos,
capas abstractas, ventanas de cambio y actividades de verificación y auditoría para limitar
los cambios no autorizados y/o no documentados en el sistema.

Referencia: NIST, Special Publication 800-128

6. Gestión de cambios y configuración

4. Monitoreo
Validar que el sistema se adhiere a las políticas y procedimientos de la organización y la
configuración segura aprobada.
Planear e implementar configuraciones seguras y luego controlar el cambio de
configuración generalmente no es suficiente para garantizar que un sistema que alguna vez
fue seguro lo siga siendo.
El monitoreo identifica componentes del sistema no descubiertos/no documentados,
configuraciones incorrectas, vulnerabilidades y cambios no autorizados, todo lo cual, si no
se aborda, puede exponer a las organizaciones a un mayor riesgo.
El uso de herramientas automatizadas ayuda a las organizaciones a identificar de manera
eficiente cuándo el sistema no es coherente con la configuración de referencia aprobada y
cuándo son necesarias acciones correctivas.
El seguimiento de SecCM se realiza a través de actividades de evaluación y elaboración de
informes.
Referencia: NIST, Special Publication 800-128
Resumen

Los datos son el recurso más valioso que poseen muchas organizaciones.
En este punto, sin duda reconoce la importancia de colocar controles de acceso adecuados
y pistas de auditoría en estos valiosos recursos de información.
Finalmente, se pueden implementar varios controles durante el proceso de desarrollo del
sistema y la aplicación para garantizar que el producto final de estos procesos sea
compatible con la operación en un entorno seguro. Dichos controles incluyen aislamiento
de procesos, segmentación de hardware, abstracción y arreglos contractuales como
acuerdos de nivel de servicio (SLA).
La seguridad siempre debe introducirse en las primeras fases de planificación de cualquier
proyecto de desarrollo y monitorearse continuamente a lo largo de las fases de diseño,
desarrollo, implementación y mantenimiento de la producción.
Preguntas de revisión

1. Christine is helping her organization implement a DevOps approach to deploying code.

Which one of the following is not a component of the DevOps model?
A. Information security
B. Software development
C. Quality assurance
D. IT operations
Preguntas de revisión

2. Vincent is a software developer who is working through a backlog of change tasks. He

is not sure which tasks should have the highest priority. What portion of the change
management process would help him to prioritize tasks?
A. Release control
B. Configuration control
C. Request control
D. Change audit
Preguntas de revisión

3. What software development model uses a seven-stage approach with a feedback loop
that allows progress one step backward?
A. Boyce-Codd
B. Iterative waterfall
C. Spiral
D. Agile
Preguntas de revisión

4. Jane is conducting a threat assessment using threat modeling techniques as she

develops security requirements for a software package her team is developing. Which
business function is she engaging in under the Software Assurance Maturity Model
(SAMM)?
A. Governance
B. Design
C. Implementation
D. Verification
Preguntas de revisión

5. Which one of the following is not a principle of Agile development?

A. Satisfy the customer through early and continuous delivery.
B. Businesspeople and developers work together.
C. Pay continuous attention to technical excellence.
D. Prioritize security over other requirements.
Preguntas de revisión

6. In which phase of the SW-CMM does an organization use quantitative measures to gain
a detailed understanding of the development process?
A. Initial
B. Repeatable
C. Defined
D. Managed
Preguntas de revisión

7. Which one of the following is not part of the change management process?
A. Request control
B. Release control
C. Configuration audit
D. Change control