Capítulo 1

Acciones asociadas con la seguridad: confidencialidad, integridad y disponibilidad.

No repudio: Acción, autenticación, autorización y auditoría

Existe una prevalencia de software inseguro que puede atribuirse a lo siguiente:

■ Restricciones del triángulo de hierro
Schedule (Cronograma).- Necesidad de tiempo.
Scope (Alcance).- Recursos (personas) con las habilidades y los conocimientos técnicos adecuados.
Budget (Costo).- Presupuesto
■ Seguridad como una ocurrencia tardía: El costo de reparar un software inseguro en una etapa anterior del ciclo (SLDC)
■ Seguridad versus usabilidad: Se considera que la incorporación de funciones seguras hace que el software se vuelva
muy complejo, restrictivo e inutilizable. La seguridad del software debe equilibrarse con la usabilidad y el rendimiento

 Core: El término CIA se usa comúnmente en la industria de la seguridad para referirse a la confidencialidad,
integridad y disponibilidad
 Confidencialidad: falta o insuficiencia de protección contra la divulgación de información no autorizada.
La técnica empleada para lograr la confidencialidad depende de si los datos están en reposo, en tránsito o en
uso
 Integridad: es la medida de la resistencia del software y tiene que ver con la alternancia o modificación de datos
y el funcionamiento confiable del software.
 Disponibilidad: acceso al software o los datos o información que maneja
En primer lugar, el software o los datos que procesa deben ser accesibles solo por aquellos que están
autorizados (quién) y, en segundo lugar, debe ser accesible solo en el momento (cuándo) que se requiera
Un acuerdo de nivel de servicio (Service Level Agreement SLA) es un ejemplo de un instrumento que se puede
utilizar para establecer y regular explícitamente los requisitos de disponibilidad
 Autenticación: es el proceso de determinar la identidad de un usuario
Métodos o factores generales en la autenticación:
 Algo que sabes (Usuario y contraseña) | conocimiento (Knowledge)
 Algo que tienes (token) | propiedad (Ownership)
 Algo sobre ti (biometría) | característica (Characteristic )
FFIEC: Consejo de Examen de Instituciones Financieras Federales
 Autorización: se hace cargo y aplica los niveles de acceso predeterminados al usuario, se utilizan tres elementos:
 Un solicitante (a veces denominado sujeto). Puede ser un proceso o un objeto, se clasifican por nivel de
privilegios (administrativo, administrador, anónimo)
 El objeto: acciones CRUD (creación, lectura, actualización o eliminación de un objeto)
 Tipo o nivel de acceso que se concederá
 Auditoría y no repudio: los campos de auditoría deben incluir quién (el sujeto que puede ser un usuario o
proceso) hizo qué (operaciones como crear, leer, actualizar, eliminar, etc.), dónde (el objeto en el que se realiza
la operación, como un archivo o tabla) y cuándo (marca de tiempo de la operación)
 El no repudio aborda la negación de las acciones realizadas por un usuario o el software en nombre del usuario.
La rendición de cuentas para garantizar el no repudio se puede lograr mediante la auditoría cuando se usa junto
con la identificación
Desafíos de la auditoria:
 Impacto en el rendimiento
 Sobrecarga de información
 Limitación de capacidad
 Protección de interfaces de configuración
 Protección de registros de auditoría
 Diseño de Software
 Privilegio mínimo: Principio de seguridad en el que a una persona o proceso se le otorga solo el nivel mínimo de
derechos de acceso para que complete una operación asignada
 Separación de funciones (o) principio de compartimentación (separación de privilegios)
 Defensa en profundidad (o) defensa en capas: los puntos únicos de compromiso completo se eliminan o mitigan
mediante la incorporación de una serie o múltiples capas de salvaguardas de seguridad y contramedidas de
mitigación de riesgos.
 Fail Secure (protección contra fallas): Mantener la confidencialidad, la integridad y la disponibilidad mediante la
configuración predeterminada de un estado seguro
 Economía de los mecanismos: principio Keep It Simple porque la probabilidad de un mayor número de
vulnerabilidades aumenta con la complejidad del diseño y el código de la arquitectura del software
 Mediación completa: Garantiza que un sujeto no eluda la autoridad en solicitudes posteriores de un objeto, al
verificar la autorización (derechos y privilegios) en cada solicitud del objeto
 Diseño abierto: La revisión del diseño en sí no resultará en el compromiso de las salvaguardas en el software.
 Mecanismos menos comunes: No permite compartir mecanismos que son comunes a más de un usuario o
proceso si los usuarios y procesos se encuentran en diferentes niveles de privilegio.
 Aceptabilidad psicológica: Maximizar el uso y la adopción de la funcionalidad de seguridad en el software al
garantizar que la funcionalidad de seguridad sea fácil de usar y al mismo tiempo transparente para el usuario
 Enlace más débil: Resistencia de su software dependerá en gran medida de la protección de sus componentes
más débiles
 Aprovechamiento de los componentes existentes: Se enfoca en garantizar que la superficie de ataque no
aumente y que no se introduzcan nuevas vulnerabilidades al promover la reutilización de componentes de
software, código y funcionalidad existentes

 Modelos de seguridad: Definen qué acciones puede realizar un sujeto en objetos específicos. Los controles de
acceso asumen que la identidad del usuario ha sido verificada a través de un proceso de autenticación.
 Lista de control de acceso (ACL): Contiene los sujetos que tienen derechos de acceso a un objeto
 Modelo de confidencialidad de Bell-LaPadula: Emplea mecanismos de control de acceso tanto obligatorios
como discrecionales
 Regla de seguridad simple: Ningún sujeto puede leer información de un objeto con una clasificación de
seguridad superior a la que posee el propio sujeto.
 Regla de "no lectura": El sistema debe tener sus niveles de acceso dispuestos en forma jerárquica, con
niveles de acceso superiores e inferiores definidos
 No amortización o propiedad estrella: un sujeto puede escribir en un objeto solo si su clasificación de
seguridad es menor o igual que la clasificación de seguridad del objeto
 Modelo Take-Grant (toma-concesión): Modelo de toma-concesión para el control de acceso se basa en la teoría
de grafos, se puede utilizar para determinar definitivamente los derechos
Los bordes entre ellos representan los derechos entre el sujeto y los objetos. Hay dos derechos únicos para este
modelo: tomar (t: derecho de extracción, g: derecho de concesión, r: derecho de lectura y w: derecho de
escritura) y otorgar
Un conjunto de cuatro reglas: tomar, otorgar, crear y eliminar
Su valor radica en su capacidad para analizar una implementación y responder preguntas sobre si una
implementación específica está completa o podría ser capaz de filtrar información
  Matriz de control de acceso: las acciones permitidas a un sujeto con un objeto se enumeran en un formato de
matriz, su mayor debilidad: la dificultad de implementación
 Basado en roles (RBAC): en lugar de que a cada usuario se le asignen permisos de acceso específicos para los
objetos asociados con el sistema informático o la red, a los usuarios se les asigna un conjunto de roles que
pueden realizar
 Control de acceso basado en reglas (RBAC): utilizamos elementos como listas de control de acceso para ayudar
a determinar si se debe otorgar el acceso o no
 Control de acceso obligatorio (MAC): Tiene sus raíces en los sistemas de control militar.
Son “un medio de restringir el acceso a objetos en base a la sensibilidad (representada por una etiqueta) de la
información contenidos en los objetos y la autorización formal (es decir, autorización) de los sujetos para
acceder a información de tal sensibilidad "
El propietario o el sujeto no puede determinar si se debe otorgar acceso a otro sujeto; es el trabajo del sistema
operativo decidir
Coloca la responsabilidad de determinar el acceso de seguridad sobre los diseñadores de un sistema,
requiriendo que todas las relaciones de objeto y sujeto se definan antes de su uso en un sistema
 Control de acceso discrecional (DAC): son un medio para restringir el acceso a objetos en función de la
identidad de sujetos y / o grupos al que pertenecen
El propietario de un objeto puede decidir qué otros sujetos pueden tener acceso al objeto y qué acceso
específico pueden tener
Las listas de control de acceso son el mecanismo más común utilizado para implementar el control de acceso
discrecional
 Modelo de seguridad multinivel: Esquema de clasificación militar: Alto secreto, Secreto y Confidencial.
Se asignan etiquetas a grupos separados y estos grupos actúan como contenedores, manteniendo la
información y los procesos separados según las etiquetas. Estos pueden ser de naturaleza jerárquica, en los que
algunos contenedores pueden considerarse superiores o incluir contenedores inferiores
 Diagramas de flujo de datos (DFD) están diseñados específicamente para documentar el almacenamiento,
movimiento y procesamiento de datos en un sistema
 Modelos de casos de uso. Examina el sistema desde un modelo de perspectiva funcional.
 Modelos de integridad: la integridad puede ser tan importante o incluso más importante que la
confidencialidad
 Modelo de integridad de Biba: Los datos con un nivel de integridad más alto son más precisos o confiables
que los datos con un nivel de integridad más bajo
 Primer regla: la política de marca de agua baja o la regla de “no escribir” (opuesta la de Bell-LaPadula).
Evita que los sujetos escriban en objetos de un nivel de integridad más alto
 Segunda regla: El nivel de integridad de un sujeto se reducirá si actúa sobre un objeto de menor nivel de
integridad
 Modelo de Clark-Wilson: Utilizando transacciones como base para sus reglas
 Elementos de datos restringidos (CDI). Sujetos a controles de integridad
 Elementos de datos no restringidos (UDI). No sujetos a controles de integridad
 Procesos de verificación de integridad (IVP) . garantizan que los datos de CDI cumplan con las
restricciones de integridad (para garantizar que el sistema esté en un estado válido)
 Procesos de transformación (TP). son procesos que cambian el estado de los datos de un estado válido a
otro. Los datos de este modelo no pueden ser modificados directamente por un usuario, solo puede ser
cambiado por TP de confianza
 Modelos de flujo de información: Comprender cómo fluye la información a través de un sistema, los
componentes que actúan sobre él
 Brewer-Nash Model (Chinese Wall - Modelo de pared china): Diseñado para hacer cumplir la confidencialidad
en las operaciones empresariales comerciales.

 Adversarios
 Script Kiddie. Solo puede usar scripts publicados para realizar ataques
 Hacker. Explora cómo funciona un sistema y cómo sortear sus límites pero con intenciones maliciosas
 Elite. Elemento distintivo con habilidades muy notables
 Capítulo 2
La gestión de riesgos: es el acto de equilibrio entre la protección de los activos de TI y el costo de implementar los los
controles de seguridad del software

SP 800-64 (Publicación Especial 800-64) del Instituto Nacional de Estándares y Tecnología (NIST) establece una
estrategia integral para gestionar el riesgo de los activos de tecnología de la información durante el SDLC

SP 800-30: términos y fórmulas más comunes con los que un CSSLP debe estar familiarizado.
 El riesgo es la posibilidad de sufrir daños o pérdidas.
 Los riesgos sistemáticos son aquellas posibilidades de pérdida que son predecibles en circunstancias estables
típicas (incendios, robos y errores de software)
 Los riesgos no sistemáticos son aquellos que son impredecibles en conjunto porque provienen de fuentes que
son difíciles de predecir (recesión, las epidemias y los errores de diseño del protocolo)
 El riesgo empresarial está asociado con el funcionamiento del negocio como negocio
 Los activos son aquellos elementos que son valiosos para la organización, cuya pérdida puede potencialmente
causar interrupciones en la capacidad de la organización para cumplir sus misiones
 Naturaleza tangible: percibidos por los sentidos físicos como los Datos
 Naturaleza intangible: incluyen la lealtad del cliente, los derechos de propiedad intelectual como derechos de
autor, patentes, marcas comerciales y reputación de marca
 Vulnerabilidad: debilidad o falla dando como resultado la violación o falla de la política de seguridad
 Amenaza es simplemente la posibilidad de que ocurra un evento no deseado, no intencionado o dañino
 Mitigar se refiere a cualquier acción tomada para reducir la probabilidad de que ocurra una amenaza
 Ataque es cuando el agente de amenaza activa una acción intencional que intenta causar daño
 Exploit es cuando un ataque ocurre como resultado de que un atacante se aprovecha de una vulnerabilidad
conocida
 Probabilidad es la posibilidad de que ocurra una amenaza en particular
 Impacto es el alcance de la gravedad de las interrupciones a la capacidad de la organización para lograr su objetivo
 Factor de exposición es la oportunidad de que una amenaza cause una pérdida
 Contramedidas son controles de seguridad que se aplican después de que se ha materializado una amenaza
 Salvaguardas son controles de seguridad que son de naturaleza más proactiva
 Riesgo total es la probabilidad de que ocurra un evento no deseado. Es el riesgo general del sistema, antes de que
se apliquen los controles de seguridad, también es la suma de todos los riesgos asociados
 Riesgo residual es el riesgo que permanece después de la implementación de controles de seguridad mitigantes
(contramedidas o salvaguardas)
 Gestión de riesgos es el proceso general de toma de decisiones para identificar amenazas y vulnerabilidades y sus
impactos potenciales, determinar los costos para mitigar tales eventos y decidir qué acciones son rentables para
controlar estos riesgos
 Evaluación o análisis de riesgos es el proceso de analizar un entorno para identificar los riesgos (amenazas y
vulnerabilidades) y mitigar las acciones para determinar (cuantitativa o cualitativamente) el impacto
 Evaluación de riesgo cualitativa es el proceso de determinar subjetivamente el impacto de un evento, implica el uso
del juicio de expertos, la experiencia o el consenso del grupo para completar la evaluación
 FIPS 199 expresar una colección de información cualitativa es en forma de matriz cualitativa (las columnas:
confidencialidad, integridad y disponibilidad. Las filas Alto, medio, bajo)
 Análisis de efectos del modo de falla (FMEA) es una metodología estructurada para la evaluación de los modos de
falla y sus efectos en el sistema
 La expectativa de pérdida única (SLE) se utiliza para estimar la pérdida potencial, es la pérdida monetaria o el
impacto de cada aparición de una amenaza
SLE= Valor del activo ($) * Factor de exposición (%)
 La tasa anual de ocurrencia (ARO) es una expresión de la cantidad de incidentes de una amenaza particular que se
pueden esperar en un año
 La expectativa de pérdida anual (ALE) es un indicador de la magnitud del riesgo en un año
ALE= SingleLossExpectancy (SLE) x AnnualizedRate of Occurrence (ARO)
 Capítulo 3
PII: identificar a un individuo específico.
PHI: Información de salud personal
PFI: información financiera personal

Ley Sarbanes-Oxley (SOX): Ley de Reforma Contable de Empresas Públicas y Protección al Inversionista, SOX fue
promulgada en 2002 para mejorar la calidad y transparencia en los informes financieros y auditorías independientes y
servicios contables para empresas públicas, tiene 11 títulos que exigen requisitos específicos para los informes
financieros y abordan:
1. Junta de Supervisión Contable de Empresas Públicas
2. Independencia del auditor
3. Responsabilidad corporativa
4. Divulgaciones financieras mejoradas
5. Conflictos de intereses de los analistas
6. Autoridad y recursos de la Comisión
7. Estudios e informes
8. Responsabilidad corporativa y por fraude criminal
9. Mejoras en las sanciones por delitos de cuello blanco
10. Declaraciones de impuestos corporativos
11. Fraude empresarial y responsabilidad
Los controles de seguridad y las directivas de la Comisión de Intercambio de Seguridad (SEC)
La Sección 302 que cubre la responsabilidad corporativa de los controles financieros
La Sección 404 que trata de la evaluación de la administración de los controles internos

BASILEA II es la Ley de Reglamentación Financiera Europea que se desarrolló originalmente para proteger contra los
riesgos de las operaciones financieras y el fraude, fue desarrollada inicialmente para ser un estándar internacional para
reguladores bancarios

Ley Gramm-Leach-Bliley (Ley GLB): Ley de privacidad financiera que tiene como objetivo proteger la información
financiera personal (PFI) de los consumidores contenida en instituciones financieras. También se conoce como la Ley de
Modernización Financiera de 1999
Regla de privacidad financiera - que rige la recopilación y divulgación de PFI. Incluidas en su alcance son las
empresas que también son de naturaleza no financiera
Regla de salvaguardas: se aplica solo a las instituciones financieras (bancos, cooperativas de crédito, empresas
de valores, compañías de seguros, etc.) y exige que estas instituciones diseñen, implementen y mantengan
salvaguardas para proteger la información de los clientes.
Disposiciones de pretextos de esta ley brindan protección a los consumidores de personas y empresas que
fingen falsamente (pretexto) la necesidad de obtener PFI.

Ley de Portabilidad y Responsabilidad del Seguro Médico (HIPAA): se ocupa de la información médica personal (PHI).
Instituida por la Oficina de Derechos Civiles (OCR) en 1996 para garantizar la confidencialidad y seguridad de la
información del paciente

Ley de protección de datos de 1998 se promulgó para regular la recopilación, el procesamiento, la conservación, el uso y
la divulgación de la información privada o personal de un individuo. La Directiva de Protección de Datos Personales de la
Unión Europea (EUDPD) de hecho declara que la protección de datos personales es un derecho humano fundamental y
requiere que los datos personales que ya no sean necesarios para los fines para los que fueron recopilados en primer
lugar deben ser eliminados o modificados para que ya no puede identificar a la persona de la que se recopilaron
originalmente los datos.
La Ley de Protección de Información Personal y Documentos Electrónicos (PIPEDA) es en Canadá lo que la EUDPD es en
la Unión Europea.
Ley de uso indebido de computadoras Esta ley establece disposiciones para proteger el material informático contra el
acceso y / o modificación no autorizados.

Ley de privacidad de dispositivos móviles Exigiría que los vendedores de dispositivos móviles, fabricantes, proveedores
de servicios y proveedores de aplicaciones revelen a los consumidores la existencia de cualquier software de monitoreo.
Las entidades también tendrían que revelar qué tipo de información está sujeta a monitoreo, quién recolectaría o
transmitiría la información y cómo se usaría la información, Además deberá obtener el consentimiento expreso del
consumidor antes de que el software de monitoreo recopile información.

Leyes de incumplimiento de la seguridad estatal: algún tipo de regulación o proyecto de ley para abordar las violaciones
de seguridad
Código civil de California 1798.82 (comúnmente conocido como el proyecto de ley estatal 1386), establece que
la información personal sea destruida cuando la entidad recolectora ya no la necesite. También notifiquen a los
propietarios de información personal que su protección de información ha sido violada

Desafíos con los mandatos regulatorios: interpretaciones abiertas, subjetividad del auditor, jurisdicción localizada,
variaciones regionales y aplicación inconsistente

Los requisitos de privacidad deben tenerse en cuenta y considerarse importantes como requisitos de seguridad.
Algunos estándares y mejores prácticas, como PCI DSS, no permiten la recopilación de cierta información privada y
confidencial
 La categorización de los datos en niveles de privacidad, según el impacto en la divulgación, alteración y / o
destrucción, puede proporcionar información para garantizar que se establezcan los niveles adecuados de controles
de privacidad
 La Política de Uso Aceptable (AUP) y las pantallas de inicio de sesión y los banners que se muestran al iniciar sesión
son mecanismos que se utilizan comúnmente para solicitar el consentimiento del usuario
 Anonimato de datos: proceso de eliminar información privada de los datos con las técnicas:
1. Reemplazo o sustitución: sustituye por información no identificable
2. Supresión u omisión: Se omite información identificable de la información que se divulga
3. Generalización: La información identificable específica se reemplaza utilizando una forma más generalizada
4. Pertubación o aleatorización: implica realizar cambios aleatorios en los datos
Onion Routing (Tor) es una plataforma que los desarrolladores de software pueden aprovechar para diseñar
software con anonimato y privacidad integrados, incluso en redes públicas
 Disposición: Todo el software es vulnerable hasta que él y los datos que procesa, transmite y almacena se eliminan
de forma segura.
 Modelos de seguridad: son una abstracción formal de la política de seguridad que se compone del conjunto de
requisitos de seguridad que deben formar parte del sistema o software, para que sea resistente a los ataques. se
pueden clasificar ampliamente en modelos de confidencialidad, modelos de integridad y modelos de control de
acceso
 El Informe de estado del arte (SOAR) El objetivo de la garantía del software es establecer una base para obtener
una confianza justificada de que el software demostrará consistentemente propiedades deseables. Estas
propiedades deseables pueden variar desde calidad (libre de errores), confiabilidad (funcionando según lo
diseñado), usabilidad (no restrictiva para realizar lo que el usuario espera), interoperabilidad (funcionar en
entornos heterogéneos dispares), tolerancia a fallas y, por supuesto, seguridad (resistente a ataques, tolerante a
la violación y rápido para recuperarse de un estado inseguro).
 Protección de anillo: Lo implementan los sistemas operativos (SO) basándose en la arquitectura del sistema
operativo Honeywell Multics: cuanto más bajo es el nivel de anillo, mayor es el nivel de acceso y viceversa
  Límite de confianza (o perímetro de seguridad) es el concepto abstracto que determina el punto en el que
cambian los niveles de confianza, deben tenerse en cuenta en el diseño y la arquitectura del software
 Base de cómputo confiable (TCB) (Trusted Computing Base) proviene de los Trusted Computer System
Evaluation Criteria (TCSEC) conocido como el 'Libro naranja’ es un estándar del Departamento de Defensa (DoD)
del Gobierno de los Estados Unidos que establece requisitos básicos para evaluar la eficacia de los controles de
seguridad informática integrados en un sistema informático. Garantiza que la política de seguridad se aplique en
todo momento, incluye todos los componentes (hardware, software y firmware), mecanismos (proceso,
comunicaciones entre procesos) y factores humanos que brindan seguridad. Supervisa 4 funciones básicas:
 Activación del proceso
 Conmutación de dominio de ejecución
 Protección de memoria
 Operaciones de entrada / salida (E / S).
Otras regulaciones:
 La autenticación para operaciones bancarias a través de Internet se rige por las reglas del Consejo de
Examen de las Instituciones Financieras Federales (Federal Financial Institu- tions Examination Council
FFIEC): establecen que la autenticación debe ser de naturaleza multifactorial como mínimo
 La propiedad intelectual es un término legal que reconoce que las creaciones de la mente pueden ser y son
propiedad a la que se le puede otorgar el control exclusivo al creador. Las formas comunes de protección
legal son patentes, derechos de autor, marcas comerciales y secretos comerciales

Capítulo 4
Ross Anderson, un reconocido experto en seguridad, ha declarado que las inversiones en la calidad del software darán
como resultado una reducción de los problemas de seguridad, ya sea que el programa de calidad aborde los problemas
de seguridad o no

Las funciones de seguridad son elementos de un programa diseñado específicamente para proporcionar algún aspecto
de seguridad

El desarrollo seguro de software consiste en garantizar que todos los elementos de un paquete de software se
construyan de manera que funcionen de forma segura. Si el software no está desarrollado para ser seguro, ni siquiera se
puede confiar en que las características de seguridad funcionen como se desea

Los SDL contienen:

 Un programa actual de educación y concienciación del equipo
 Uso de puertas de seguridad como punto para verificar el cumplimiento de los requisitos y objetivos de seguridad

Herramientas (seguimiento de errores, modelado de amenazas y fuzzing)

Modelos SDLC (ciclo de vida de desarrollo de software) predominantes que se utilizan para desarrollar software. Éstos
incluyen:
 Modelo de cascada: modelo de cascada original de Winston W. Royce de 1970
 Especificación de requisitos
 Diseño
 Construcción (también conocida como implementación o codificación)
 Integración
 Prueba y depuración (también conocida como verificación)
 Instalación
 Mantenimiento
Publicación Especial 800-64 REV 1d del Instituto Nacional de Estándares y Tecnología (NIST), que cubre
'Consideraciones de seguridad en el ciclo de vida del desarrollo de sistemas de información', divide el modelo SDLC
de cascada lineal en fases genéricas:
 Inicio
 adquisición / desarrollo
  implementación / evaluación
 operaciones / mantenimiento
 Modelo iterativo: modelo de creación de prototipos. la versión final de lanzamiento a fabricación (RTM)
 Modelo en espiral: tiene elementos tanto del modelo en cascada como del modelo de prototipos, cada fase tiene
una actividad de revisión de evaluación de riesgos
 Metodologías de desarrollo ágiles: se construyen sobre la base del desarrollo iterativo con el objetivo de minimizar
las tasas de falla del proyecto
 Modelo de programación extrema (XP): modelo de programación "centrado en las personas". Factores de éxito:
 Comenzar con las soluciones más simples
 La comunicación entre los miembros del equipo.
 Scrum: el software se mantiene en un estado constante de preparación para su lanzamiento
 Ciclo de vida de desarrollo de seguridad de Microsoft, diseñado para lograr dos objetivos:
 Reducir la cantidad de vulnerabilidades de seguridad en un producto.
 Reducir la gravedad de las vulnerabilidades de seguridad que permanecen en un producto.

Existen varias metodologías de garantía de software que ayudan en el diseño, desarrollo, prueba e implementación de
software seguro y de calidad:
 Metodología socrática: es una técnica útil para abordar problemas que surgen de personas que tienen puntos de
vista opuestos sobre la necesidad de seguridad en el software que construyen. Es una forma de interrogatorio y
también se conoce como el Método de Elenchus, puede denominarse la metodología de "cuestionar al
interrogador". El método socrático sugiere que usted devuelve la pregunta al interrogador en una forma negativa
 Six Sigma (6 σ): Se utiliza para la mejora de procesos al medir si un producto (software) o servicio tiene una calidad
casi perfecta mediante la eliminación de defectos. Las submetodologías:
 DMAIC (Definir, Medir, Analizar, Mejorar y Controlar) - que se utiliza para la mejora incremental de los
procesos existentes
 DMADV (Definir, Medir, Analizar, Diseñar y Verificar) - que se utiliza para desarrollar nuevos procesos
 Integración del modelo de madurez de capacidad (CMMI): metodología de mejora de procesos, que proporciona
orientación para la mejora de la calidad. Áreas en las que se utiliza:
 Desarrollo (productos)
 Entrega (servicios)
 Adquisición (productos y servicios)
Niveles de CMMI
 Inicial (Nivel 1): los procesos son ad hoc, mal controlados, reactivos y altamente impredecibles.
 Repetible (Nivel 2): también de naturaleza reactiva, los procesos se agrupan a nivel de proyecto y se
caracterizan por ser repetibles y administrados mediante el seguimiento de costos y cronogramas de gestión de
proyectos básicos.
 Definido (Nivel 3): la madurez de los procesos organizacionales se establece y mejora continuamente. Los
procesos se caracterizan, se comprenden bien y son proactivos por naturaleza.
 Administrado cuantitativamente (Nivel 4): los procesos se miden y controlan con las métricas adecuadas.
 Optimización (Nivel 5): tienen la capacidad de adaptarse rápida y eficazmente a los objetivos comerciales
cambiantes
Cada uno de los restantes Niveles de Madurez está compuesto por un cierto número de Áreas Claves de Proceso,
conocidas a través de la documentación del CMM por su sigla inglesa: KPA. Las KPAs pueden clasificarse en 3 tipos
de proceso: Gestión, Organizacional e Ingeniería.
Las prácticas que deben ser realizadas por cada Área Clave de Proceso son:
i) Compromiso de la realización,
ii) La capacidad de realización,
iii) Las actividades realizadas,
iv) Las mediciones y el análisis,
v) La verificación de la implementación.
 Proceso de acreditación y certificación de aseguramiento de la información del DoD (DIACAP). Es el proceso del
Departamento de Defensa (DoD) para garantizar que la gestión de riesgos se aplique en los sistemas de información.
DIACAP define un conjunto formal y estándar de actividades, tareas generales y un proceso de estructura de gestión
 para todo el DoD para la certificación y acreditación (C&A) de un DoD IS que mantendrá la postura de
Aseguramiento de la Información (IA) durante todo el ciclo de vida del sistema. El DIACAP es un mecanismo para
negociar los requisitos y las capacidades de IA entre DoD IS y sus enclaves de apoyo.
El DIACAP es un proceso de cinco (5) fases.
1. Iniciar y planificar la certificación y acreditación de garantía de la información (C&A)
2. Implementar y validar controles de garantía de información asignados
3. Tomar la decisión de acreditación y determinación de certificación
4. Mantener la autoridad para operar y realizar revisiones
5. Desmantelamiento
 Evaluación de vulnerabilidades, activos y amenazas operacionalmente críticas (OCTAVE®): metodología de
evaluación estratégica de seguridad de la información basada en riesgos
 Fase 1: Crear perfiles de amenazas basados en activos: Esta evaluación se realiza para determinar el riesgo a
nivel organizacional.
 Fase 2: Identificar las vulnerabilidades de la infraestructura: Esta evaluación se realiza para determinar los
riesgos técnicos
 Fase 3: Desarrollar planes y estrategias de seguridad: s hace planes para abordar las amenazas y mitigar las
vulnerabilidades
 STRIDE: metodología de modelado de amenazas que se realiza en la fase de diseño del desarrollo de software en la
que las amenazas se agrupan y categorizan en las siguientes seis categorías:
 suplantación de identidad (Spoofing)
 alteración
 repudio
 divulgación de información
 denegación de servicio
 elevación de privilegios
 DREAD es una metodología de calificación o cálculo de riesgo aplicando cinco dimensiones.
 Daños potenciales: ¿cuál será el impacto sobre la explotación?
 Reproducibilidad: ¿cuál es la facilidad para recrear el ataque / exploit?
 Explotabilidad: ¿Qué nivel mínimo de habilidad es necesario para lanzar el ataque / explotación?
 Usuarios afectados: ¿cuántos usuarios se verán potencialmente afectados por un ataque / explotación exitoso?
 Capacidad de detección: ¿cuál es la facilidad para encontrar la vulnerabilidad que genera la amenaza?
 Manual de metodología de pruebas de seguridad de código abierto (OSSTMM) metodología de prueba revisada
por pares para realizar pruebas de seguridad y cómo medir los resultados utilizando métricas aplicables.
El resultado de una auditoría de seguridad OSSTMM es un informe conocido como Informe de auditoría de pruebas
de seguridad (STAR), que incluye las acciones específicas realizadas en las pruebas, las métricas correspondientes y
el estado de la fuerza de los controles
 Método de hipótesis de defectos (FHM): método de análisis y predicción de vulnerabilidades que utiliza pruebas de
penetración integrales para probar la solidez de la seguridad del software, a identificar solo las amenazas conocidas,
consta de cuatro fases:
 Fase 1: Hipotetizar posibles fallas en el software a partir de la documentación.
 Fase 2: Confirmación de fallas mediante la realización de pruebas de penetración de simulación reales y pruebas
de verificación de escritorio.
 Fase 3: Generalización de fallas confirmadas para descubrir otras posibilidades de debilidades en el software
 Fase 4: Abordar las fallas descubiertas en el software para mitigar el riesgo, ya sea agregando contramedidas en
la versión actual o diseñando protecciones para versiones futuras
 Marco de Zachman: alinear la tecnología de la información (TI) con el negocio mediante una matriz de 6 x 6
 Filas: Seis transformaciones de reificación (estratega, propietario, diseñador, constructor, implementador y
trabajadores)
 Columnas: Seis interrogantes de comunicación (qué, cómo, dónde, quién, cuándo y por qué)
 Objetivos de control para la tecnología de la información y afines (COBIT®): es un marco de gobierno de TI para
cerrar brechas entre los requisitos de control, los problemas técnicos y los riesgos comerciales. Permite el desarrollo
de políticas y agrega énfasis en el cumplimiento normativo, consta de seis publicaciones
 Resumen ejecutivo
  Marco
 Objetivos de control
 Directrices de auditoría
 Conjunto de herramientas de implementación
 Pautas de manejo
 Comité de Organizaciones Patrocinadoras (COSO): brinda orientación sobre gobierno organizacional.
El marco COSO de Enterprise Risk Management (ERM), que enfatiza la importancia de identificar y administrar los
riesgos en toda la empresa, es ampliamente adoptado y utilizado.
 Arquitectura (SABSA): Marco para desarrollar arquitecturas de seguridad empresarial basadas en riesgos y para
ofrecer soluciones de seguridad que respalden iniciativas comerciales. Los requisitos de seguridad se determinan a
partir del análisis de los requisitos comerciales

OWASP

La siguiente listas tienen corresponden a la Debilidad y a la forma en que puede afrontarse la debilidad
 Inyección
 Los datos suministrados por el usuario no son validados, filtrados o
sanitizados
 Se invocan consultas dinámicas o no parametrizadas
 Se utilizan datos dañinos dentro de los parámetros de búsqueda en
consultas
 Los datos dañinos se usan directamente o se concatenan
 La opción preferida es utilizar una API segura, que evite el uso de un
intérprete por completo y proporcione una interfaz parametrizada
 Realiza validaciones de entradas de datos en el servidor, utilizando "listas
blancas"
 Para cualquier consulta dinámica residual, escapa caracteres especiales
utilizando la sintaxis de lenguaje
 Utiliza LIMIT y otros controles SQL dentro de las consultas para evitar la
fuga masiva de registro

 Pérdida de Autenticación
 Reutilización de credenciales  Implemente autenticación multi-factor
 Ataques de fuerza bruta o automatizados  No utilice credenciales por defecto en su software
 Permitir contraseñas por defecto  Implemente controles contra contraseñas débiles
 Procesos débiles o inefectivos en el proceso de recuperación de  Alinear la política de longitud, complejidad y rotación de contraseñas
credenciales  Mediante la utilización de los mensajes genéricos iguales en todas las
 Almacena las contraseñas en texto claro o cifradas con métodos de hashing salidas
débiles  Limite o incremente el tiempo de respuesta de cada intento fallido de
 No posee autenticación multi-factor inicio de sesión
 Expone Session IDs en las URL   Utilice un gestor de sesión en el servidor, integrado, seguro y que genere
un nuevo ID de sesión aleatorio con alta entropía después del inicio de
sesión. El Session-ID no debe incluirse en la URL, debe almacenarse de
forma segura y ser invalidado después del cierre de sesión o de un tiempo
de inactividad determinado por la criticidad del negocio.

 Exposición de Datos Sensibles

 ¿Se transmite datos en texto claro? Esto se refiere a protocolos como
HTTP, SMTP, TELNET, FTP. Verifique también todo el tráfico interno
(balanceadores de carga, servidores web o sistemas de backend)
 Se utilizan algoritmos criptográficos obsoletos o débiles
 Se utilizan claves criptográficas predeterminadas
 ¿El User-Agent del usuario verifica que el certificado enviado por el
servidor sea válido?
 Clasifica e identifica los datos procesados, almacenados o transmitidos por
el sistema. Aplica los controles adecuados para cada clasificación
 No almacenes datos sensibles innecesariamente
 Cifra todos los datos sensibles cuando sean almacenados.
 Cifra todos los datos en tránsito utilizando protocolos seguros como TLS
 Utiliza únicamente algoritmos y protocolos estándares y fuertes e
implementa una gestión adecuada de claves.
 Deshabilita el almacenamiento en cache de datos sensibles
 Almacena contraseñas utilizando funciones de hashing
 Verifica la efectividad de tus configuraciones y parámetros de forma
independiente

 Entidades Externas XML (XXE):

Los atacantes pueden explotar procesadores XML vulnerables si cargan o incluyen contenido hostil en un documento XML, explotando código vulnerable,
dependencias o integraciones.
Estos defectos se pueden utilizar para extraer datos, ejecutar una solicitud remota desde el servidor, escanear sistemas internos, realizar un ataque de denegación de
servicio y ejecutar otro tipo de ataques.
 La aplicación acepta XML directamente, carga XML desde fuentes no  De ser posible, utilice formatos de datos menos complejos como JSON y
confiables o inserta evite la serialización de datos confidenciales
 SAML utiliza XML para garantizar la identidad de los usuarios y puede  Actualice los procesadores y bibliotecas XML que utilice la aplicación,
 ser vulnerable.
 Si las entidades XML son pasadas a la infraestructura SOAP,
probablemente sea susceptible a ataques XXE.
 Ser vulnerable a ataques XXE significa que probablemente la aplicación
también es vulnerable a ataques de denegación de servicio
Actualice SOAP a la versión 1.2 o superior
 Deshabilite las entidades externas de XML y procesamiento DTD
 Implemente validación de entrada positiva en el servidor (“lista blanca”),
filtrado y sanitización
 Verifique que la funcionalidad de carga de archivos XML o XSL valide el
XML entrante
 Las herramientas SAST pueden ayudar a detectar XXE en el código fuente
 Si estos controles no son posibles, considere usar parcheo virtual,
gateways de seguridad de API, o Firewalls de Aplicaciones Web (WAFs)
para detectar, monitorear y bloquear ataques XXE

 Pérdida de Control de Acceso

Las herramientas SAST y DAST pueden detectar la ausencia de controles de acceso pero, en el caso de estar presentes, no pueden verificar si son correctos. Es
detectable utilizando medios manuales o de forma automática en algunos frameworks que carecen de controles de acceso.
El impacto técnico incluye atacantes anónimos actuando como usuarios o administradores; usuarios que utilizan funciones privilegiadas o crean, acceden, actualizan o
eliminan cualquier registro
 Pasar por alto las comprobaciones de control de acceso modificando la  Con la excepción de los recursos públicos, la política debe ser denegar de
URL forma predeterminada
 Permitir que la clave primaria se cambie a la de otro usuario  Implementa los mecanismos de control de acceso una vez y reutilízalo en
 Elevación de privilegios. Actuar como un usuario sin iniciar sesión, o toda la aplicación
actuar como un administrador habiendo iniciado sesión como usuario  Los controles de acceso al modelo deben imponer la propiedad (dueño) de
estándar los registros, en lugar de aceptar que el usuario puede crear, leer, actualizar
 Manipulación de metadatos, como reproducir un token, manipular una o eliminar cualquier registro.
cookie o un campo oculto para elevar los privilegios  Los modelos de dominio deben hacer cumplir los requisitos exclusivos de
 La configuración incorrecta de CORS permite el acceso no autorizado a los límites de negocio de las aplicaciones
una API  Deshabilita el listado de directorios del servidor web y asegúrate que los
 Forzar la navegación a páginas autenticadas como un usuario no metadatos/fuentes de archivos (por ejemplo de GIT) y copia de seguridad
autenticado no estén presentes en las carpetas públicas
 Acceder a una API sin control de acceso mediante el uso de verbos POST,  Registra errores de control de acceso y alerta a los administradores cuando
PUT y DELETE corresponda
 Limita la tasa de acceso a las APIs para minimizar el daño de herramientas
de ataque automatizadas
 Los tokens JWT deben ser invalidados después de la finalización de la
sesión por parte del usuario
 Los desarrolladores y el personal de QA deben incluir pruebas de control
de acceso en sus pruebas unitarias y de integración

 Configuración de Seguridad Incorrecta

Los atacantes a menudo intentarán explotar vulnerabilidades sin parchear o acceder a cuentas por defecto, páginas no utilizadas, archivos y directorios desprotegidos
Los defectos frecuentemente dan a los atacantes acceso no autorizado a algunos datos o funciones del sistema. Ocasionalmente, estos errores resultan en un completo
compromiso del sistema.
 Falta hardening adecuado en cualquier parte del stack tecnológico, o  Proceso de fortalecimiento reproducible que agilice y facilite la
permisos mal configurados en los servicios de la nube implementación de otro entorno asegurado. Los entornos de desarrollo, de
 Se encuentran instaladas o habilitadas características innecesarias control de calidad (QA) y de Producción deben configurarse de manera
 Las cuentas predeterminadas y sus contraseñas siguen activas y sin idéntica y con diferentes credenciales para cada entorno.
cambios  Usa una plataforma minimalista sin funcionalidades innecesarias,
 El manejo de errores revela a los usuarios trazas de la aplicación u otros componentes, documentación o ejemplos. Elimina o no instales
mensajes demasiado informativos frameworks y funcionalidades no utilizadas.
 Para los sistemas actualizados, las nuevas funciones de seguridad se  Sigue un proceso para revisar y actualizar las configuraciones apropiadas
encuentran desactivadas o no se encuentran configuradas de forma de acuerdo a las advertencias de seguridad y sigue un proceso de gestión
adecuada o segura de parches
 Las configuraciones de seguridad en el servidor de aplicaciones no se  La aplicación debe tener una arquitectura segmentada que proporcione una
encuentran especificados con valores seguros. separación efectiva y segura entre componentes y acceso a terceros
 El servidor no envía directrices o cabeceras de seguridad a los clientes o se  Envía directivas de seguridad a los clientes (por ej. cabeceras de
encuentran configurados con valores inseguros seguridad)
 El software se encuentra desactualizado o posee vulnerabilidades  Utiliza un proceso automatizado para verificar la efectividad de los ajustes
y configuraciones en todos los ambientes.

 Cross-Site Scripting (XSS)

Existen herramientas automatizadas que permiten detectar y explotar las tres formas de XSS, y también se encuentran disponibles kits de explotación gratuitos.
El impacto de XSS es moderado para el caso de XSS Reflejado y XSS en DOM, y severa para XSS Almacenado, que permite ejecutar secuencias de comandos en el
navegador de la víctima, para robar credenciales, secuestrar sesiones, o la instalación de software malicioso en el equipo de la víctima
 XSS Reflejado: la aplicación o API utiliza datos sin validar, suministrados Prevenir XSS requiere mantener los datos no confiables separados del contenido
por un usuario y codificados como parte del HTML o Javascript de salida. activo del navegador:
No existe una cabecera que establezca la Política de Seguridad de  Utilizar frameworks seguros que, por diseño, automáticamente codifican el
Contenido (CSP). Un ataque exitoso permite al atacante ejecutar comandos contenido para prevenir XSS
 arbitrarios (HTML y Javascript) en el navegador de la víctima
 XSS Almacenado: la aplicación o API almacena datos proporcionados por
el usuario sin validar ni sanear, los que posteriormente son visualizados o
utilizados por otro usuario o un administrador.
 XSS Basados en DOM: frameworks en JavaScript, aplicaciones de página
única o APIs incluyen datos dinámicamente, controlables por un atacante.
Idealmente, se debe evitar procesar datos controlables por el atacante en
APIs no seguras. Los ataques XSS incluyen el robo de la sesión,
apropiación de la cuenta, evasión de autentificación de múltiples pasos,
reemplazo de nodos DOM, inclusión de troyanos de autentificación,
ataques contra el navegador, descarga de software malicioso, keyloggers, y
otros tipos de ataques al lado cliente.
 Deserialización Insegura
No se debe desvalorizar el impacto de los errores de deserialización. Pueden llevar a la ejecución remota de código, uno de los ataques más serios posibles.
Aplicaciones y APIs serán vulnerables si deserializan objetos hostiles o
manipulados por un atacante. Esto da como resultado dos tipos primarios de
ataques:
 Ataques relacionados con la estructura de datos y objetos; donde el
atacante modifica la lógica de la aplicación o logra una ejecución remota
de código que puede cambiar el comportamiento de la aplicación durante o 
después de la deserialización
 Ataques típicos de manipulación de datos; como ataques relacionados con
el control de acceso, en los que se utilizan estructuras de datos existentes
pero se modifica su contenido.
 Uso de componentes con Vulnerabilidades Conocidas
No se debe desvalorizar el impacto de los errores de deserialización. Pueden llevar a la ejecución remota de código, uno de los ataques más serios posibles.
 No conoces las versiones de todos los componentes que utiliza
 El software es vulnerable, no posee soporte o se encuentra desactualizado
 No se analizan los componentes periódicamente ni se realiza seguimiento
de los boletines de seguridad de los componentes utilizados.
 No se parchea o actualiza la plataforma subyacente, frameworks y
dependencias, con un enfoque basado en riesgos
 No asegura la configuración de los componentes correctamente
 Registro y Monitorización Insuficiente
Los ataques más exitosos comienzan con la exploración de vulnerabilidades. Permitir que el sondeo de vulnerabilidades continúe puede aumentar la probabilidad de una
explotación exitosa
 Eventos auditables, tales como los inicios de sesión, fallos en el inicio de 
sesión, y transacciones de alto valor no son registrados.
 Advertencias y errores generan registros poco claros, inadecuados o
ninguno en absoluto.
 Registros en aplicaciones o APIs no son monitoreados para detectar
actividades sospechosas.
 Los registros son almacenados únicamente de forma local.
 Los umbrales de alerta y de escalamiento de respuesta no están
implementados o no son eficaces.
 Las pruebas de penetración y escaneos utilizando herramientas DAST
(como OWASP ZAP) no generan alertas.
 La aplicación no logra detectar, escalar o alertar sobre ataques en tiempo
real.
 Codificar los datos de requerimientos HTTP no confiables en los campos
de salida HTML resuelve los XSS Reflejado y XSS Almacenado
 Aplicar codificación sensitiva al contexto, cuando se modifica el
documento en el navegador del cliente, ayuda a prevenir DOM XSS
 Habilitar una Política de Seguridad de Contenido (CSP) es una defensa
profunda para la mitigación de vulnerabilidades XSS, asumiendo que no
hay otras vulnerabilidades que permitan colocar código malicioso vía
inclusión de archivos locales, bibliotecas vulnerables en fuentes conocidas
almacenadas en Redes de Distribución de Contenidos (CDN) o localmente.
El único patrón de arquitectura seguro es no aceptar objetos serializados de
fuentes no confiables:
 Implementa verificaciones de integridad tales como firmas digitales en
cualquier objeto serializado, con el fin de detectar modificaciones no
autorizadas
Durante la deserialización y antes de la creación del objeto, exige el
cumplimiento estricto de verificaciones de tipo de dato, ya que el código
normalmente espera un conjunto de clases definibles
 Aísla el código que realiza la deserialización, de modo que se ejecute en
un entorno con los mínimos privilegios posibles.
 Registra las excepciones y fallas en la deserialización, tales como cuando
el tipo recibido no es el esperado, o la deserialización produce algún tipo
de error.
 Restringe y monitoriza las conexiones (I/O) de red desde contenedores o
servidores que utilizan funcionalidades de deserialización.
 Monitoriza los procesos de deserialización, alertando si un usuario
deserializa constantemente.
Remover dependencias, funcionalidades, componentes, archivos y
documentación innecesaria y no utilizada:
 Utilizar una herramienta para mantener un inventario de versiones de
componentes
 Monitorizar continuamente fuentes como CVE y NVD en búsqueda de
vulnerabilidades en los componentes utilizados. Utilizar herramientas de
análisis automatizados. Suscribirse a alertas de seguridad de los
componentes utilizados.
 Obtener componentes únicamente de orígenes oficiales utilizando canales
seguros. Utilizar preferentemente paquetes firmados con el fin de reducir
las probabilidades de uso de versiones manipuladas maliciosamente.
 Supervisar bibliotecas y componentes que no poseen mantenimiento o no
liberan parches de seguridad para sus versiones obsoletas o sin soporte
Asegúrate de que todos los errores de inicio de sesión, de control de acceso
y de validación de entradas de datos del lado del servidor se pueden
registrar para identificar cuentas sospechosas. Mantenerlo durante el
tiempo suficiente para permitir un eventual análisis forense.
 segúrate de que las transacciones de alto impacto tengan una pista de
auditoría con controles de integridad para prevenir alteraciones o
eliminaciones.
 Asegúrate que todas las transacciones de alto valor poseen una traza de
auditoría con controles de integridad que permitan detectar su
modificación o borrado, tales como una base de datos con permisos de
inserción únicamente u similar.
 Establece una monitorización y alerta efectivos de tal manera que las
actividades sospechosas sean detectadas y respondidas dentro de períodos
de tiempo aceptables.
 Establece o adopta un plan de respuesta o recuperación de incidentes
