Desarrollo seguro en desarrollo de software

1. Exámen Desarrollo
Seguro Capítulo 1
Conceptos

2. Material
Material Principal: Desarrollo Seguro - Google Drive
Libro CSSLP: Official Guide to the CSSLP CBK 2E - Enlace Alternativo
Videos Curso GoNet: Curso Desarrollo Seguro
Exámenes: Base de datos preguntas
Simuladores BizMerlin: Login Bizmerlin
Presentaciones: Presentación 1 Presentación 2 Presentación 3 Presentación 4

3. Examen Desarrollo Seguro (CSSLP)
Alrededor de 42 preguntas
2 minutos por pregunta
Dividido en secciones
Basado en los 4 primeros capítulos de la Guía oficial CSSLP CBK ED 2 (2014)
Actualizado a 2022: Containers, Cómputo en la nube, OWASP Top 10 y CWE 25 actuales.
Banco de preguntas extenso

4. Examen Desarrollo Seguro (CSSLP)
Se recomienda leer las instrucciones detenidamente antes de iniciar el examen.

5. Examen CSSLP Desarrollo Seguro
No salir del recuadro del exámen durante la aplicación de este.

6. Conceptos Básicos

7. Conceptos Básicos
Confidencialidad
La confidencialidad es el concepto de seguridad que tiene que ver con la protección contra la divulgación de
información no autorizada. Tiene que ver con la visualización de datos. La confidencialidad no solo asegura
la discreción de los datos, sino que también puede ayudar a mantener la privacidad de los datos.
Integridad
En el software que es confiable o, en otras palabras, funciona según lo previsto, la protección contra la
alteración indebida de los datos también se conoce como software resistente. La integridad es la medida de
la resiliencia del software y tiene que ver con la alteración o modificación de datos y el funcionamiento
confiable del software.

8. Disponibilidad
La disponibilidad es el concepto de seguridad que se relaciona con el acceso del software o de los datos y que
estos no sean destruidos. Los datos no deben estar disponibles para las personas equivocadas o en el momento
equivocado.
Autenticación
La autenticación es un concepto de seguridad que responde a la pregunta: "¿Es usted quien dice ser?" No solo
garantiza que la identidad de una entidad (persona o recurso) se especifica de acuerdo con el formato que el
software lo espera, pero también valida o verifica la información de identidad que ha sido suministrada. En
otras palabras, asegura que quien dice ser una entidad o persona, realmente lo es.
La autenticación multifactor, que es el uso de más de un factor para autenticar, se considera más segura que la
autenticación de un solo factor, en la que solo se usa uno de los tres factores, conocimiento (Algo que se sabe),
propiedad (Algo que se tiene) o característica (Algo que se es) para validar las credenciales.

9. Autorización
El hecho de que las credenciales de una entidad se puedan validar no significa que la entidad deba tener acceso
a todos los recursos que solicita. La autorización es el concepto de seguridad en el que el acceso a los objetos
se controla en función de los derechos y privilegios que el propietario de los datos o el sistema otorga al
solicitante o de acuerdo con una política.
Las decisiones de autorización se superponen a la autenticación y nunca deben preceder a la autenticación, es
decir, no autoriza antes de autenticar, a menos que los requisitos de su negocio requieran que proporcione
acceso a usuarios anónimos (aquellos que no están autenticados), en cuyo caso la decisión de autorización
podrá ser uniformemente restrictiva a todos los usuarios anónimos.

10. Rendición de cuentas y no repudio
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. Por ejemplo, un usuario que cambió precios en una base de datos la cual crea registros
permanentes de todas las acciones, la hora, fecha y el usuario no puede negar el cambio que realizó.
La auditoría es un control de detección y también puede ser un control disuasorio. Dado que uno puede usar los
registros de auditoría para determinar el historial de acciones realizadas por un usuario o el propio software, la
auditoría o el registro es un control de detección pasivo. El conocimiento previo de ser auditado podría disuadir
a un usuario de realizar acciones no autorizadas, pero no necesariamente les impide hacerlo.

11. Conceptos de Diseño Seguro
Privilegio mínimo:
Un principio de seguridad en el que a una persona o proceso se le otorga solo el nivel mínimo de derechos
de acceso (privilegios) que es necesario para que esa persona o proceso complete una operación asignada.
Este derecho debe otorgarse solo por un tiempo mínimo que sea necesario para completar la operación.
El sandboxing o vistas en bases de datos son ejemplos de la aplicación de este concepto en la vida real. El
sandboxing solo permite acceder a un espacio aislado con limitaciones para no afectar el dispositivo en el que
se encuentra, mientras que las vistas solo permiten acceder a las tablas o datos necesarios para efectuar
nuestras tareas correctamente.

12. Principio de Separación de Funciones (o) Compartimentación:
También conocido como el principio de compartimentación o separación de privilegios, la separación de
funciones es un principio de seguridad que establece que la finalización exitosa de una sola tarea depende
de dos o más condiciones que deben cumplirse y sólo una de las condiciones será insuficiente para
completar la tarea por sí misma.
Un ejemplo de este principio es requerir dos o más autorizaciones diferentes para poder realizar algún
cambio que podría causar un posible impacto, como es la liberación de funcionalidades a producción o la
destrucción de información.

13. Defensa en profundidad (o) Defensa en capas:
También conocida como defensa en capas, la defensa en profundidad es un principio de seguridad en el que
los puntos únicos de compromiso total o las vulnerabilidades se eliminan o mitigan mediante la
incorporación de una serie o varias capas de salvaguardas de seguridad y contramedidas de mitigación de
riesgos.
Un ejemplo es implementar diferentes controles en distintos puntos, por ejemplo defendernos frente a
ataques de inyección implementando validación de entrada en el frontend y backend, cifrar nuestras
comunicaciones mediante SSL o TLS y aplicando vistas a la base de datos.

14. Fallo Seguro:
Un principio de seguridad que tiene como objetivo mantener la confidencialidad, la integridad y la
disponibilidad mediante la configuración predeterminada de un estado seguro, la recuperación rápida de la
resiliencia del software ante una falla en el diseño o la implementación. En el contexto de la seguridad del
software, a prueba de fallas se usa comúnmente de manera intercambiable con un sistema a prueba de
fallas, que proviene de la terminología de seguridad física. En otras palabras; no ignorar el error y continuar.
Mediación completa:
Un principio de seguridad que garantiza que la autoridad no se eluda en solicitudes posteriores de un objeto
por parte de un sujeto, al verificar la autorización (derechos y privilegios) en cada solicitud del objeto. En
otras palabras, las solicitudes de acceso de un sujeto a un objeto se completan mediatizadas cada vez, o bien,
se comprueba si el usuario está autorizado cada vez que intente acceder a algún recurso.
Aplicar una mediación completa total podría comprometer la aceptabilidad psicológica al autenticar y
autorizar a los usuarios constantemente en cada solicitud, por lo que es importante balancear estos dos
conceptos al diseñar los controles de nuestro software.

15. Economía de mecanismos:
Esto, en términos sencillos, es el principio “Keep It Simple” o “mantenerlo simple” porque la probabilidad de
un mayor número de vulnerabilidades aumenta con la complejidad del código y el diseño arquitectónico del
software. Al mantener el diseño del software y los detalles de implementación simples, se reduce la
capacidad de ataque o la superficie de ataque del software.
Mecanismos menos común:
El principio de seguridad de los mecanismos menos comunes no permite compartir mecanismos que son
comunes a más de un usuario o proceso si los usuarios y procesos tienen diferentes niveles de privilegio. Por
ejemplo, no se permitirá el uso de la misma función para recuperar el monto de la bonificación de un
empleado exento y un empleado no exento.
En este caso el cálculo de la bonificación es el mecanismo común. En otras palabras, al implementar
mecanismos o métodos, estos deben estar separados a nivel memoria o lógico si los usuarios y procesos
tienen diferentes niveles de privilegio.

16. Diseño abierto:
El principio de seguridad del diseño abierto establece que los detalles de implementación del diseño deben
ser independientes del diseño en sí, que puede permanecer abierto, a diferencia del caso de la seguridad por
oscuridad, en el que la seguridad del software depende del oscurecimiento del diseño en sí. Cuando el
software se diseña utilizando el concepto de diseño abierto, la revisión del diseño en sí no comprometerá las
salvaguardas del software. Que se conozca el diseño de nuestro desarrollo no implica que este sea
vulnerable.
Aceptabilidad psicológica:
Un principio de seguridad que apunta a 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. La facilidad de uso y la transparencia son requisitos esenciales para que este principio de
seguridad sea efectivo.

17. Eslabón más débil:
Este principio de seguridad establece que la resistencia de su software contra los intentos de piratas
informáticos dependerá en gran medida de la protección de sus componentes más débiles, ya sea el código,
el servicio o una interfaz.
Aprovechar los componentes existentes:
Este es un principio de seguridad que 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.

18. Gestión del Riesgo.
Objetivo
• Proteger a toda la organización de modo que haya una interrupción mínima o nula de las capacidades de la
organización para cumplir su misión.
• Implementando controles de seguridad
• Equilibrio entre la protección de los activos de la organización y el costo de la aplicación de los controles de
seguridad.

19. Activo
• 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.
• Los activos pueden ser de naturaleza tangible o intangible.
• La pérdida de reputación de marca para una organización puede ser desastrosa y la recuperación de tal
pérdida puede ser casi imposible. (Este es el activo más valioso para las organizaciones según el libro)

20. Vulnerabilidad
• Una debilidad o falla que podría ser provocada accidentalmente o explotada intencionalmente por un
atacante, dando como resultado la violación o falla de la política de seguridad.
Amenaza
• Es la posibilidad de que ocurra un evento no deseado, no intencionado o dañino.
• Cuando el evento ocurre tras la manifestación de la amenaza, resulta en un incidente.
• Estas amenazas se pueden clasificar en amenazas de divulgación, alteración o destrucción.

21. Fuentes / Agente de amenaza
• Cualquier persona o cosa que tenga el potencial de hacer que una amenaza se materialice .
• Pueden ser humanos o no humanos
Ataque
• Cuando un agente de amenaza provoca de forma activa e intencionada que se produzca una amenaza.
• A los agentes de amenaza se les denomina comúnmente "atacantes".

22. Impacto
• Es el resultado de una amenaza materializada.
Factor de Exposición
• Se define como la oportunidad de que una amenaza cause una pérdida.
Controles de seguridad
• Son mecanismos mediante los cuales se pueden mitigar las amenazas.
• Estos mecanismos pueden ser de naturaleza técnica, administrativa o física.
• Se pueden clasificar ampliamente en contramedidas y salvaguardas.

23. Riesgo total
• Es la probabilidad de que se produzca un evento no deseado.
• Es el riesgo global del sistema, antes de aplicar cualquier control de seguridad.
Riesgo residual
• Riesgo que permanece después de la implementación de controles de seguridad
Calculo del riesgo cuantitativo
Expectativa de pérdida única (SLE)
Se utiliza para estimar la pérdida potencial. Se calcula como el valor del activo (normalmente expresado monetariamente) por el factor de exposición, que se expresa como un porcentaje de pérdida
del activo cuando se materializa una amenaza.
SLE = Valor del activo ($) * Factor de exposición (%) Calculo del riesgo cuantitativo
Tasa anual de ocurrencia (ARO)
Numero de incidentes de una amenaza particular que se puede esperar en un año.
Calculo del riesgo cuantitativo
Expectativa de pérdida anual (ALE)
ALE = Expectativa de pérdida única (SLE) *
Tasa anual de ocurrencia (ARO)
Es un indicador de la magnitud del riesgo en un año.

24. PCI DSS
Es una normativa de protección de datos, el estándar de seguridad de datos de la industria de tarjetas de pago (PCI DSS)
tiene como propósito proteger los datos del titular de la tarjeta.
Esta normativa nos indica que si el almacenamiento de elementos de datos está permitido o prohibido y si cada elemento de
datos debe protegerse.
Los datos del medio de pago deben protegerse si se almacenan junto con el PAN.
Esta protección debe cumplir con los requisitos de PCI DSS para la protección general del entorno de datos del titular de la
tarjeta.
PCI DSS no se aplica si los PAN no se almacenan, procesan o transmiten.
Los datos confidenciales de autenticación no deben almacenarse después de la autorización (incluso si están encriptados)
Datos completos de la pista de la banda magnética, la imagen de la banda magnética en el chip o en cualquier otro lugar.