CÓDIGO:

01
POLITICAS DE DESARROLLO
01
SEGURO SOFTENERGY VERSIÓN:

FECHA: 14/02/2024

Estándar de Desarrollo Seguro de Aplicaciones.

Principales modificaciones por versión

Historial de Versiones

Versión Autor Fecha Descripción de la

modificación
01 CRISTIAN DAVID GROSSO 14/02/2024 Documento inicial
YEFRY TOVAR MARTINEZ
02
03
04
05

Revisado por: Adan Beltran

 CÓDIGO:
01
POLITICAS DE DESARROLLO
01
SEGURO SOFTENERGY VERSIÓN:

FECHA: 14/02/2024

It. Nombre Fecha de Revisión

1
2
3
4
5
6
 CÓDIGO:
01
POLITICAS DE DESARROLLO
01
SEGURO SOFTENERGY VERSIÓN:

FECHA: 14/02/2024

CONTENIDO

1. OBJETIVO........................................................................................................ 4

2. ALCANCE.........................................................................................................4

3. DEFINICIÓN DE ROLES..................................................................................4

4. RECOMENDACIONES DE SEGURIDAD DEL CLICLO DE VIDA DE DESARROLLO 4

5. AMENAZAS DE SEGURIDAD.............¡ERROR! MARCADOR NO DEFINIDO.

6. ESTÁNDARES Y REQUERIMIENTOS DE SEGURIDAD................................6

7. ARQUITECTURA DE SEGURIDAD / REVISIÓN DE DISEÑO........................9

8. REVISIÓN DE CÓDIGO SEGURO / PRUEBAS DE SEGURIDAD / GESTIÓN

DE VULNERABILIDADES..............................................................................10

9. SEGURIDAD EN EL AMBIENTE....................................................................11

10. VULNERABILIDADES DE SEGURIDAD.......................................................13

11. ANEXOS......................................................................................................... 29
 CÓDIGO:
01
POLITICAS DE DESARROLLO
01
SEGURO SOFTENERGY VERSIÓN:

FECHA: 14/02/2024

1. OBJETIVO

Definir un estándar de desarrollo seguro que mitigue los riesgos más conocidos de las aplicaciones WEB/
Cliente - Servidor basado en las buenas prácticas definidas en Owasp Top 10 y Sans Top 25.

2. ALCANCE.

El documento estándar de desarrollo seguro cubre las recomendaciones de seguridad que se puede aplicar durante
el ciclo de vida de desarrollo, en el proceso revisión de código seguro y en la publicación a ambiente productivo
de las aplicaciones.

Igualmente presenta las vulnerabilidades más comunes en las aplicaciones, su mecanismo de explotación y
remediación.

3. DEFINICIÓN DE ROLES

Proveedor: Proveedores de servicios de Software o fábricas del ciclo de vida de software, contratado por
Softenergy para participar en creación o modificaciones de aplicaciones Web/Cliente – Servidor.

Administrador: funcionario de softenergy que soporta o administra la aplicación y es el responsable de recibir la

aplicación nueva o modificada por el proveedor. Además Funcionario sustenta el código y usabilidad de la
plataforma tecnológica

4. RECOMENDACIONES DE SEGURIDAD DEL CLICLO DE VIDA DE DESARROLLO

A partir de la siguiente sección, se presentan las recomendaciones de seguridad que se puede aplicar durante el
ciclo de vida de desarrollo de las aplicaciones de softenergy.

 Integración de Seguridad desde el Inicio: Integrar prácticas de seguridad desde las primeras etapas del
desarrollo, incluyendo la definición de requerimientos y diseño. Esto puede incluir la realización de análisis de
riesgos y amenazas, así como la especificación de controles de seguridad que se deben implementar.

 Revisión de Código y Pruebas de Seguridad: Realizar revisiones periódicas del código en busca de
vulnerabilidades y ejecutar pruebas de seguridad, tanto estáticas como dinámicas, para identificar y remediar
problemas de seguridad antes de que el software llegue a producción.

 Gestión de Dependencias: Mantener todas las bibliotecas y dependencias del proyecto actualizadas y aplicar
rápidamente los parches de seguridad necesarios. Esto también incluye revisar regularmente el código en
busca de cualquier componente obsoleto o inseguro.

 Formación y Conciencia de Seguridad: Capacitar continuamente al equipo de desarrollo en prácticas de

seguridad actualizadas, y fomentar una cultura de seguridad que priorice la protección de los datos y la
 CÓDIGO:
01
POLITICAS DE DESARROLLO
01
SEGURO SOFTENERGY VERSIÓN:

FECHA: 14/02/2024

infraestructura de la aplicación.

5. AMENAZAS DE SEGURIDAD.

Las amenazas que se pueden presentar durante cualquier proyecto de software pueden ser los siguientes:

 Inyección de código: como SQL injecion, permite a los atacantes manipular las consultas de la base de
datos

 Cross-Site Scripting (xss): donde los atacantes inyectan scripts maliciosos en el contenido de
páginas web vistas por otros usuarios.

 Fuga de información y exposición de datos sensibles: donde datos confidenciales son accesibles debido a falta
de cifrado o políticas de seguridad inadecuadas.

 Ruptura de autenticación y gestión de sesiones: que permite a los atacantes secuestrar sesiones de usuario o
robar credenciales de identidad.

 Configuración de seguridad inadecuada: que deja sistemas vulnerables debido a configuraciones

predeterminadas o inseguras.

 Cross-Site Request Forgery (CSRF): que engaña a un navegador de un usuario para ejecutar acciones no
deseadas en una aplicación web en la que están autenticados.

 Componentes vulnerables: como bibliotecas y frameworks desactualizados que pueden ser explotados por
atacantes.

 Riesgos asociados al almacenamiento inseguro de contraseñas: lo que facilita ataques de fuerza bruta o
adivinación de contraseñas.
 CÓDIGO:
01
POLITICAS DE DESARROLLO
01
SEGURO SOFTENERGY VERSIÓN:

FECHA: 14/02/2024

fácilmente puede identificar y registrar los riegos en la matriz de riesgos de la metodología definida por Softenergy
6. ESTÁNDARES Y REQUERIMIENTOS DE SEGURIDAD.

a) Autenticación y contraseñas

- Políticas de Contraseñas Fuertes:

Requerir contraseñas complejas que incluyan una mezcla de letras mayúsculas y minúsculas, números y
caracteres especiales. Establecer una longitud mínima de contraseña (por ejemplo, 8 caracteres).

- Rotación y Caducidad de Contraseñas:

Imponer políticas de caducidad de contraseñas para que los usuarios cambien sus contraseñas regularmente (por ejemplo,
cada 90 días).

- Almacenamiento Seguro de Contraseñas:

Utilizar algoritmos de hashing seguros (como bcrypt, Argon2) para almacenar contraseñas. Evitar el almacenamiento de
contraseñas en texto plano.

- Autenticación de Múltiples Factores (MFA):

Implementar MFA para proporcionar una capa adicional de seguridad, utilizando combinaciones de algo que el usuario
sabe (contraseña), algo que el usuario tiene (token o código de SMS), o algo que el usuario es (biometría).

- Limitación de Intentos de Inicio de Sesión:

Limitar el número de intentos de inicio de sesión fallidos para proteger contra ataques de fuerza bruta.

- Verificación de Seguridad en el Cambio de Contraseñas:

Solicitar la contraseña actual del usuario antes de permitir cambios de contraseña y validar la identidad del usuario
durante el proceso de recuperación de contraseña.

b) Autorización
 CÓDIGO:
01
POLITICAS DE DESARROLLO
01
SEGURO SOFTENERGY VERSIÓN:

FECHA: 14/02/2024

- Control de Acceso Basado en Roles (RBAC):

Definir roles de usuario y permisos asociados a esos roles, asegurando que los usuarios tengan acceso solo
a las funcionalidades y datos necesarios para sus roles.

- Principio de Menor Privilegio:

Asignar a los usuarios y sistemas el mínimo nivel de acceso necesario para realizar sus funciones.

- Gestión Segura de Sesiones:

Asegurar que las sesiones de usuario sean únicas y estén protegidas contra la usurpación, implementando
Utilizar algoritmos criptográficamente seguros para generar identificadores de sesión únicos.
tokens de sesión seguros y mecanismos de renovación de sesión.

- Validación de Acceso en Cada Petición:

Verificar los derechos de acceso del usuario en cada petición al sistema para prevenir la elevación de
privilegios.

c) Manejo de sesiones

-Generación Segura de Tokens de Sesión:

Utilizar algoritmos criptográficamente seguros para generar identificadores de sesión únicos.

-Protección contra Fijación de Sesión:

Cambiar el identificador de sesión después de un inicio de sesión exitoso para evitar ataques de fijación de sesión.

-Configuración de Cookies de Sesión:

Marcar las cookies de sesión con atributos Secure, HttpOnly, y preferiblemente SameSite, para protegerlas contra
interceptación y ataques de scripting entre sitios.

-Tiempo de Expiración de Sesiones:

Establecer un tiempo de expiración adecuado para las sesiones y tokens de sesión, cerrando automáticamente las
sesiones inactivas.

- Cierre de Sesión Seguro:

Proporcionar una funcionalidad de cierre de sesión que termine y limpie correctamente la sesión del lado del servidor
y del cliente.
 CÓDIGO:
01
POLITICAS DE DESARROLLO
01
SEGURO SOFTENERGY VERSIÓN:

FECHA: 14/02/2024

d) Logs y Auditoría

- Generación de Logs:
Generar logs de eventos significativos de seguridad, errores, y transacciones críticas del sistema,
incluyendo intentos de acceso, cambios de configuración, y acciones de usuarios administrativos.

- Protección de Logs:
Asegurar la integridad y confidencialidad de los logs mediante mecanismos de control de acceso, cifrado
en reposo y durante la transmisión, y almacenamiento seguro.

- Políticas de Retención de Logs:

Definir y adherir a políticas de retención que especifiquen cuánto tiempo se deben guardar los logs,
basándose en requisitos legales y operacionales.

- Revisión y Monitoreo de Logs:

Implementar herramientas de monitoreo y análisis de logs en tiempo real para detectar y responder a
actividades sospechosas o maliciosas rápidamente.

- Auditoría Regular:
Realizar auditorías regulares de los logs para identificar patrones inusuales o indicadores de compromiso,
así como para verificar el cumplimiento de políticas de seguridad.

e) Manejo de Errores y Excepciones

- Gestión Segura de Errores:

Implementar un manejo de errores que no revele información sensible del sistema, como
detalles internos de la implementación, información de configuración o datos de usuario.
Mostrar mensajes de error genéricos a los usuarios finales.

- Registro de Errores:
Registrar los detalles técnicos de los errores en archivos o sistemas de logs seguros,
accesibles solo para personal autorizado, para facilitar el análisis y la resolución de problemas
sin comprometer la seguridad.

- Notificación de Errores:
En caso de errores críticos o vulnerabilidades detectadas, establecer procedimientos para
notificar a los administradores o a equipos de seguridad de manera inmediata.
 CÓDIGO:
01
POLITICAS DE DESARROLLO
01
SEGURO SOFTENERGY VERSIÓN:

FECHA: 14/02/2024

- Validación de Entrada:
Prevenir errores y vulnerabilidades relacionadas con el manejo incorrecto de las entradas de
usuario mediante la validación estricta de datos en todos los puntos de entrada.

- Pruebas de Excepciones:
Incluir pruebas específicas para manejo de excepciones en el ciclo de desarrollo de software,
asegurando que las aplicaciones manejen de manera adecuada situaciones inesperadas o
entradas inválidas.

- Análisis de Causa Raíz:

Tras la detección de errores o incidentes de seguridad, realizar un análisis de causa raíz para
identificar y abordar el origen del problema, previniendo así su recurrencia.

f) Tablas de trabajo

-Definición de Procesos y Flujos de Trabajo:

Establecer procesos claros para la gestión de tareas de seguridad, incluyendo la identificación,
evaluación, asignación, resolución y verificación de vulnerabilidades y problemas de seguridad.

-Integración con Herramientas de Seguridad:

Conectar las Tablas de Trabajo con herramientas de análisis de seguridad, sistemas de gestión
de incidencias y otras plataformas para automatizar la captura y asignación de tareas
relacionadas con la seguridad.

-Segmentación y Priorización:
Organizar las tareas en categorías o niveles de prioridad basados en la severidad, impacto y
urgencia de las vulnerabilidades o problemas de seguridad identificados.

-Roles y Responsabilidades:
Definir claramente los roles y responsabilidades dentro del equipo de desarrollo y seguridad para
cada tipo de tarea en la Tabla de Trabajo, asegurando una asignación y seguimiento efectivos.

-Seguimiento y Actualización de Tareas:

Implementar mecanismos para el seguimiento continuo y la actualización del estado de las
tareas, facilitando la visibilidad del progreso y fomentando la responsabilidad del equipo.

-Revisión y Aprendizaje:
Incorporar procesos de revisión periódica de las Tablas de Trabajo para identificar lecciones
aprendidas, optimizar flujos de trabajo y mejorar las prácticas de seguridad continuamente.
 CÓDIGO:
01
POLITICAS DE DESARROLLO
01
SEGURO SOFTENERGY VERSIÓN:

FECHA: 14/02/2024

7. ARQUITECTURA DE SEGURIDAD / REVISIÓN DE DISEÑO.

7.1 Objetivos
Garantizar que la seguridad esté integrada desde el inicio del proceso de diseño de sistemas y aplicaciones.
Identificar y mitigar riesgos de seguridad potenciales en las fases tempranas de diseño para minimiza
vulnerabilidades.

7.2 Principios de Diseño Seguro

Principio de Menor Privilegio: Asegurar que los sistemas y aplicaciones operen con los mínimos privilegios
necesarios para su funcionamiento.

Defensa en Profundidad: Implementar múltiples capas de defensa para proteger los sistemas y datos contra
ataques.

Segregación de Entornos: Diferenciar entre entornos de desarrollo, prueba y producción para reducir riesgos.

Seguridad por Diseño: Incorporar consideraciones de seguridad en el proceso de diseño y desarrollo desde el
principio.

7.3 Componentes Críticos

Control de Acceso y Autenticación:

Establecer mecanismos robustos para verificar la identidad de los usuarios y controlar su acceso a recursos y datos.

Manejo de Sesiones:
Implementar prácticas seguras para la creación, gestión y terminación de sesiones de usuario.

Encriptación de Datos:
Utilizar estándares de encriptación para proteger datos sensibles en tránsito y en reposo.

Gestión de Configuraciones:
Asegurar que las configuraciones de sistemas y aplicaciones sean seguras y estén alineadas con las mejores
prácticas de seguridad.

Auditoría y Monitoreo:
Desarrollar capacidades para registrar y monitorear eventos de seguridad relevantes.
 CÓDIGO:
01
POLITICAS DE DESARROLLO
01
SEGURO SOFTENERGY VERSIÓN:

FECHA: 14/02/2024

7.4 Revisión de Diseño

Evaluación de Riesgos:
Realizar análisis de riesgos para identificar y evaluar amenazas potenciales a la seguridad en la arquitectura
propuesta.

Revisión de Código:
Incluir revisiones de código enfocadas en seguridad para identificar vulnerabilidades y malas prácticas en el
desarrollo.

Pruebas de Seguridad:
Ejecutar pruebas de penetración y otras pruebas de seguridad para validar la eficacia de las medidas de seguridad
implementadas.

7.5 Estrategias de Implementación

Integración Continua de Seguridad:

Incorporar herramientas y prácticas de seguridad en el proceso de integración y despliegue continuos.

Formación y Conciencia:
Educar al equipo de desarrollo sobre principios y prácticas de seguridad a través de formación continua.

Respuesta a Incidentes:
Establecer un plan de respuesta ante incidentes de seguridad que permita actuar de manera rápida y eficaz ante
posibles brechas.

7.6 Consideraciones Finales

La arquitectura de seguridad y la revisión de diseño deben ser procesos iterativos que se adapten a los cambios en
los requisitos del proyecto y al panorama de amenazas emergentes.

Es esencial mantener una colaboración estrecha entre los equipos de desarrollo, seguridad y operaciones para
asegurar que las prácticas de seguridad se implementen de manera efectiva y coherente a lo largo del ciclo de
vida del desarrollo de software.
 CÓDIGO:
01
POLITICAS DE DESARROLLO
01
SEGURO SOFTENERGY VERSIÓN:

FECHA: 14/02/2024

8. REVISIÓN DE CÓDIGO SEGURO / PRUEBAS DE SEGURIDAD / GESTIÓN DE

VULNERABILIDADES.

8.1 Revisión de Código Seguro

Objetivos:
Asegurar que el código desarrollado no contenga vulnerabilidades de seguridad mediante la revisión sistemática del mismo.

Metodologías:

Revisiones Manuales:
Realización de inspecciones de código por parte de expertos en seguridad que buscan patrones de diseño inseguros y prácticas de
codificación vulnerables.

Herramientas de Análisis Estático de Código (SAST):

Uso de herramientas automatizadas para escanear el código en busca de vulnerabilidades comunes y errores de programación sin
ejecutar el programa.

Prácticas Recomendadas:
Integrar la revisión de seguridad del código en el ciclo de desarrollo de software desde las etapas iniciales.
Capacitar a los desarrolladores en principios de codificación segura y revisión de código.

8.2 Pruebas de Seguridad

Objetivos:
Verificar la efectividad de las medidas de seguridad implementadas y la resistencia del software ante ataques maliciosos.

Tipos de Pruebas:

Pruebas de Penetración (Pen Testing):

Simulaciones de ataques en entornos controlados para identificar vulnerabilidades explotables.

Análisis Dinámico de Aplicaciones (DAST):

Evaluación de aplicaciones en ejecución para identificar vulnerabilidades que se manifiestan durante la ejecución.

Pruebas de Seguridad de Aplicaciones Interactivas (IAST):

Combinación de SAST y DAST para analizar el código en tiempo de ejecución y detectar vulnerabilidades.

Prácticas Recomendadas:
Realizar pruebas de seguridad en todas las fases del ciclo de vida del desarrollo de software.
 CÓDIGO:
01
POLITICAS DE DESARROLLO
01
SEGURO SOFTENERGY VERSIÓN:

FECHA: 14/02/2024

Utilizar un enfoque de pruebas múltiples para cubrir diferentes aspectos de seguridad.

8.3 Gestión de Vulnerabilidades

Objetivos:
Identificar, clasificar, remediar y mitigar vulnerabilidades de seguridad de manera eficaz.

Proceso:

Identificación de Vulnerabilidades:
Uso de herramientas de escaneo de vulnerabilidades y servicios de inteligencia de amenazas para detectar riesgos potenciales.

Evaluación y Priorización:
Clasificación de vulnerabilidades basada en su gravedad, impacto y la probabilidad de explotación.

Remediación:
Implementación de correcciones o mitigaciones para las vulnerabilidades identificadas, incluyendo parches, actualizaciones o
cambios en la configuración.

Verificación:
Realización de pruebas posteriores a la remediación para asegurar que las vulnerabilidades han sido efectivamente corregidas.

Prácticas Recomendadas:
Establecer un proceso de gestión de vulnerabilidades continuo y proactivo.

Mantener una comunicación efectiva entre los equipos de seguridad, desarrollo y operaciones para garantizar una rápida
respuesta ante vulnerabilidades.

8.4 Consideraciones Finales

La seguridad del software es un proceso continuo que requiere atención constante y esfuerzos coordinados a lo largo de todo el
ciclo de vida del desarrollo.

La implementación de prácticas rigurosas de revisión de código seguro, pruebas de seguridad y gestión de vulnerabilidades es
fundamental para minimizar los riesgos de seguridad y proteger los activos de información contra amenazas emergentes.
 CÓDIGO:
01
POLITICAS DE DESARROLLO
01
SEGURO SOFTENERGY VERSIÓN:

FECHA: 14/02/2024

9. SEGURIDAD EN EL AMBIENTE.

8.1 Objetivo

Establecer medidas de seguridad robustas para proteger los entornos de desarrollo, prueba y producción, asegurando que los
sistemas y datos estén resguardados contra accesos no autorizados, pérdida o daño.

8.2 Seguridad en el Desarrollo y Pruebas

Control de Acceso:
Restringir el acceso a los entornos de desarrollo y prueba solo al personal autorizado para reducir el riesgo de exposición
accidental o malintencionada.

Gestión de Configuración Segura:

Aplicar prácticas de configuración segura en servidores, aplicaciones y bases de datos para minimizar vulnerabilidades.

Segregación de Entornos:
Mantener una clara separación entre los entornos de desarrollo, prueba y producción para evitar la contaminación de datos y la
propagación de vulnerabilidades.

Datos de Prueba:
Utilizar datos anónimos o sintéticos para las pruebas, evitando el uso de información real que pueda ser sensible o regulada.

8.3 Seguridad en Producción

Hardening de Sistemas:
Aplicar técnicas de hardening para fortalecer los sistemas contra ataques, eliminando servicios innecesarios, cerrando puertos no
utilizados y aplicando las últimas actualizaciones de seguridad.

Monitoreo y Respuesta a Incidentes:

Implementar sistemas de monitoreo en tiempo real para detectar actividades sospechosas o maliciosas, junto con un plan de
respuesta a incidentes para actuar rápidamente ante cualquier amenaza detectada.

Cifrado de Datos:
Asegurar que los datos sensibles estén cifrados en tránsito y en reposo para proteger contra el acceso no autorizado y las brechas
de datos.

Respaldo y Recuperación:
Establecer políticas y procedimientos de respaldo y recuperación para asegurar la disponibilidad y la integridad de los datos en
caso de un incidente de seguridad o fallo del sistema.

8.4 Gestión de Parches y Vulnerabilidades

 CÓDIGO:
01
POLITICAS DE DESARROLLO
01
SEGURO SOFTENERGY VERSIÓN:

FECHA: 14/02/2024

Evaluación Continua:
Realizar evaluaciones periódicas de vulnerabilidades en los entornos de producción para identificar y remediar riesgos de
seguridad de manera oportuna.

Aplicación de Parches:
Mantener un programa de gestión de parches para aplicar actualizaciones de seguridad a sistemas operativos, aplicaciones y otros
componentes críticos de la infraestructura.

8.5 Formación y Concienciación

Educación Continua:
Fomentar programas de formación y concienciación en seguridad para el personal de TI y usuarios finales, promoviendo buenas
prácticas y una cultura de seguridad.

8.6 Consideraciones Finales

La seguridad en el ambiente es un aspecto fundamental de la seguridad informática general de una organización.

Requiere un enfoque holístico que abarque tanto las medidas técnicas como las prácticas organizativas para proteger contra una
amplia gama de amenazas.

La implementación efectiva de las directrices mencionadas ayudará a asegurar la integridad, confidencialidad y disponibilidad de
los sistemas y datos en todos los entornos operativos.
 CÓDIGO:
01
POLITICAS DE DESARROLLO
01
SEGURO SOFTENERGY VERSIÓN:

FECHA: 14/02/2024

10. VULNERABILIDADES DE SEGURIDAD

10.1 EXPOSICIÓN DE DATOS SENSIBLES

SANS TOP 25:

CWE-79: Cross-site Scripting (XSS)

para evitar ataques de Cross-site Scripting (XSS). Esta función convierte caracteres especiales en
entidades HTML, lo que impide que los atacantes inyecten código HTML o JavaScript malicioso en tu
página web.

10.2 DENEGACIÓN DE SERVICIO

Para prevenir ataques de denegación de servicio (DoS), puedes limitar el número de solicitudes que un
usuario puede hacer en un período de tiempo determinado. PHP no tiene una funcionalidad incorporada
para esto, pero puedes implementarlo a nivel de servidor (por ejemplo, con iptables o fail2ban en un
servidor Linux) o utilizando un servicio de protección contra DDoS.

10.3 SQL INJECTION

 CÓDIGO:
01
POLITICAS DE DESARROLLO
01
SEGURO SOFTENERGY VERSIÓN:

FECHA: 14/02/2024

(CWE-89 / OWASP A1)

En PHP se pueden utilizar consultas preparadas para evitar la inyección SQL. Las consultas preparadas
separan la consulta SQL de los datos, lo que impide que los atacantes manipulen la consulta para acceder
o modificar datos no autorizados.

10.4 XSS (CROSS SITE SCRIPTING)

(CWE-79 / OWASP A7)

la función htmlspecialchars se usa para evitar ataques de Cross-site Scripting (XSS). Esta función
convierte caracteres especiales en entidades HTML, lo que impide que los atacantes inyecten código
HTML o JavaScript malicioso en tu página web.

10.5 PATH TRANSVERSAL

 CÓDIGO:
01
POLITICAS DE DESARROLLO
01
SEGURO SOFTENERGY VERSIÓN:

FECHA: 14/02/2024

(CWE-22 / OWASP A5)

utilizar la función realpath es necesario para resolver rutas relativas y evitar ataques de Path Traversal.
Esta función devuelve la ruta absoluta, lo que impide que los atacantes accedan a archivos o directorios
fuera del directorio previsto.

10.6 PÉRDIDA DE AUTENTICACIÓN Y GESTIÓN DE SESIONES.

(CWE-287 / OWASP A2)

para este punto necesitaremos utilizar sesiones para manejar la autenticación y la gestión de sesiones.
Asegúrando de regenerar el ID de la sesión después de que un usuario inicie sesión para prevenir ataques
de fijación de sesión
 CÓDIGO:
01
POLITICAS DE DESARROLLO
01
SEGURO SOFTENERGY VERSIÓN:

FECHA: 14/02/2024

10.7 FALSIFICACIÓN DE PETICIONES EN SITIOS CRUZADOS (CSRF)

(CSRF) (CWE-352 / OWASP A6)

se pueden utilizar tokens CSRF para prevenir ataques de Cross-Site Request Forgery. Un token CSRF es
un valor único y aleatorio que se genera para cada formulario y se verifica cuando se envía el formulario.
 CÓDIGO:
01
POLITICAS DE DESARROLLO
01
SEGURO SOFTENERGY VERSIÓN:

FECHA: 14/02/2024

10.8 REDIRECCIONES Y REENVÍOS NO VALIDADOS.

(OWASP A10)

En este tipo de norma se deben validar todas las redirecciones y reenvíos para asegurarte de que solo se
permiten URLS seguras y confiables. Nunca debes permitir que los usuarios proporcionen la URL de
redirección directamente.

11. ANEXOS

ANEXO 1. MODELAMIENTO DE AMENAZAS

Modelamiento de amenazas es una técnica de la ingeniería cuyo objetivo es identificar y planificar la mejora con
el fin de mitigar la amenaza en un sistema informático o una aplicación.

Es un escenario que debería iniciarse desde la primera etapa de desarrollo y planificación de un sistema.

Es un proceso que nos facilita el entendimiento de las amenazas a las que esta expuestas las aplicaciones.
 CÓDIGO:
01
POLITICAS DE DESARROLLO
01
SEGURO SOFTENERGY VERSIÓN:

FECHA: 14/02/2024

Su finalidad es preparar las defensas adecuadas durante las fases de diseño, implementación y también durante
su posterior revisión y testeo.

Para realizar el modelamiento de amenazas y aplicar la metodología de clasificación STRIDE y metodología de

puntuación DREAD, se recomienda seguir las siguientes fases:

INICIO

FASE 1 Identificar los activos de la aplicación

FASE 2 Descomponer la aplicación

FASE 3 Categorizar las amenazas

FASE 4 Asignar un valor a cada de amenaza

FASE 5 Decidir cómo responder a las amenazas

FASE 6 Mitigar los riesgos identificados.

 Identificar los activos de la aplicación

Un activo es información valiosa de la empresa que contiene la aplicación a analizar. El proveedor debe
identificar los activos información que contiene la aplicación como por ejemplo: Datos personales, datos de los
clientes, datos de los usuarios, venta de los clientes, compra de los proveedores, información del afiliado, entre
otros.
 CÓDIGO:
01
POLITICAS DE DESARROLLO
01
SEGURO SOFTENERGY VERSIÓN:

FECHA: 14/02/2024

 Descomponer la aplicación.

Identificar los puntos de entrada y puntos de salida por cada uno de los activos de información identificados de la
aplicación, como por ejemplo: Los datos del cliente tiene como punto entrada el formulario de registro del cliente
y como salida un reporte de la información registrada del cliente.

 Categorizar las amenazas.

Para la categorización amenazas se debe primero identificar las amenazas que puede ocurrir con estos datos
(Recomendación ver OWASP Top 10 para aplicaciones web) y después se categoriza cada una de las amenazas
con la metodología STRIDE en la cual su acrónimo se resume en seis categorías que son las siguientes:

Un ataque de suplantación se produce cuando un atacante se hace pasar

S - Suplantación (Spoofing)
T-Manipulación (Tampering)
R - Repudio (Repudiation)
I - Revelación de información
(Information Disclosure)
D - Denegación de servicio
(Denial of Service)
E Elevación de privilegios
(Elevation of Privilege)
por alguien que no es
La manipulación ataques se producen cuando el atacante modifica los
datos en tránsito.
Negar la autoría de una acción o evento en los sistemas de información.
Cuando la aplicación revela información sensible de forma no
controlada debido a un error en la programación o un fallo en la
configuración del servicio o aplicación.
Introducción de información maliciosa que logre la saturación o el
bloqueo de la aplicación y de los servicios que esta proporciona
generando como consecuencia la caída de la aplicación o el
sistema informático.
Una elevación de privilegios se produce cuando un atacante tiene la
capacidad para obtener privilegios que normalmente no tendrían. Esto
se logra mediante la alteración o ataque a la aplicación obteniendo unos
niveles de acceso mayores de los inicialmente otorgados, saltándose así
la política de control de
acceso predefinida.

Se debe categorizar cada amenaza en una o varias categorías dependen de la aplicación a analizar de metodología
STRIDE, como por ejemplo si tiene una amenaza de inyección de comandos de SQL se puede categorizar en
suplantación, manipulación, repudio, elevación información y elevación de privilegios. A continuación se muestra
otro ejemplo con varias amenazas categorizadas.
 CÓDIGO:
01
POLITICAS DE DESARROLLO
01
SEGURO SOFTENERGY VERSIÓN:

FECHA: 14/02/2024

AMENAZAS S T R I D E
Inyección de Comandos SQL x x x
Robar las Credenciales de los Usuarios x x x x
Ataques de cross-site Scripting(Xss) x x x x x
Ataques de objetos inseguros x x x x
Exposición de Datos Sensibles x x x x x
Crear peticiones de HTTP Falsificadas x x x x x
Escaneo de Componentes Vulnerables x x x x x
Redirecciones no validas x x x x x

 Asignar un valor a cada amenaza.

Para asignar un valor a cada amenaza se puede utilizar la metodología Dread con la siguiente puntación:
Puntuación Alto(3) Medio(2) Bajo(1)
D Daño potencial El atacante podría ejecutar Divulgación de información Divulgación de
aplicaciones con sensible información
permiso de administrador; trivial
subir contenido.
R Reproducibilidad El ataque es fácilmente El ataque se podría Ataque difícil de
reproducible reproducir, pero sólo en reproducir, incluso
condiciones muy concretas, conociendo la naturaleza
ejemplo: condición de del Fallo.
Carrera.

E Explotabilidad Un programador novel Un programador Se requieren ciertas

podría
implementar el ataque en
poco
Tiempo.
A Usuarios Todos los usuarios,
afectados configuración por
defecto …
D Descubrimiento Existe información pública
que Explica el ataque
Vulnerabilidad presente en
una
parte de la aplicación muy
Utilizada.
experimentado podría
implementar el ataque
Algunos usuarios, no es la
configuración por
defecto
La vulnerabilidad afecta a
una parte de la aplicación
que casi no se Utiliza. No es
muy probable que sea
Descubierta.
habilidades y
conocimientos para
explotar la
Vulnerabilidad.
Pocos usuarios afectados.
El fallo no es trivial, no
es muy probable que
los usuarios puedan
utilizarlo para
causar un daño Potencial.
 CÓDIGO:
01
POLITICAS DE DESARROLLO
01
SEGURO SOFTENERGY VERSIÓN:

FECHA: 14/02/2024

Para el uso metodología Dread se muestra siguiente ejemplo: se tiene amenaza de inyección de comandos de SQL
con la siguiente puntación:

Amenaza D R E A D Total Puntuación

Inyección de comandos 3 3 3 2 3 14
SQL

La metodología también dice que la sumatoria de la puntación se considera en un riesgo alto cuando da 12 a 15,
riesgo medio cuando da entre rango de 8 a 11 y riesgo bajo cuando da entre rango de 5 a
7. Por ejemplo en el cuadro anterior se muestra que la amenaza de Inyección de comandos de SQL contiene
puntuación de 14 lo cual es un riesgo alto para la aplicación.

Después de realizar la puntación de la amenaza con la metodología Dread, para identificar como remediar el
riesgo alto se utiliza el siguiente cuadro, lo cual se representa con un ejemplo:

Descripción Inyección de Comandos de SQL

Objetivo de la amenaza
Nivel de Riesgo
Técnicas de Ataque
Contramedidas
Componente acceso de Base de Datos
Alto
El atacante introduce comandos SQL en el campo Usuario
utilizado para formar una sentencia SQL.
Filtrar el contenido del campo usuario, utilizar un
procedimiento almacenado que utilice parámetros para
Acceder a la base de datos.

 Decidir cómo responder con las amenazas.

Después de aplicar la metodología de puntación Dread, el equipo de desarrollo realiza una reunión para decidir
que contramedidas debe realizar para prevenir que ocurran estas amenazas en la aplicación.

 Mitigar los riegos identificados.

Identificar las técnicas y tecnologías necesarias para mitigar los riesgos identificados. (Se recomienda ver las
contramedidas que da el Owasp Top 10 para aplicaciones web o las que presenta en este documento de Estándar
de desarrollo Seguro).
 CÓDIGO:
01
POLITICAS DE DESARROLLO
01
SEGURO SOFTENERGY VERSIÓN:

FECHA: 14/02/2024

ANEXO 2. LISTA DE CHEQUEO.

Lista de chequeo SI No Observaciones

CICLO DE VIDA DE DESARROLLO EN LAS APLICACIONES

En el contrato se incluyó una cláusula que asegura el cumplimiento sobre los estándares
OWASP TOP 10
En el contrato se incluyó una cláusula de confidencialidad.
Los riesgos identificados durante el ciclo de vida de desarrollo de la aplicación están
registrados en la matriz de riesgos definida por EMPRESA.
El código fuente desarrollado o modificado transfiere la propiedad intelectual y
derechos de autor a EMPRESA
El proveedor al entregar el código fuente a EMPRESA, aplicó el procedimiento
definido en el documento estándar de desarrollo seguro en el ítem 4.
RECOMENDACIONES DE SEGURIDAD EN EL CICLO DE VIDA DE
DESARROLLO DE APLICACIONES

AMENAZAS DE SEGURIDAD
El proveedor aplicó y entregó a EMPRESA toda la documentación sobre el
modelamiento de amenazas definido en el documento de Estándar Desarrollo
Seguro.

ESTÁNDARES Y REQUERIMIENTOS DE SEGURIDAD.

La aplicación está integrada con el directorio activo LDAP de EMPRESA.
La aplicación tiene definido los permisos para cada recurso requerido por el perfil del
usuario.
Los mensajes de error que se utilizan en la aplicación son personalizados, tipificados y
despliega mensajes útiles para el usuario sin revelar información
sensible de la aplicación y base de datos.
Las credenciales de los usuarios son capturadas por Método Post.
Cuando son procesos críticos, la aplicación pide nuevamente autenticación por
usuarios.
Los datos sensibles de la aplicación viajan cifrados (identificar que datos sensibles
tienen la aplicación, cuales viajan cifrados y cuáles no, igualmente
identificar el tipo cifrado que utilizó el proveedor para los datos sensibles).
La opción de Cerrar Sesión esta visible en todos los formularios de la aplicación.

Si la memoria cache utiliza datos sensibles de la aplicación debe esta deshabilitada.

La aplicación maneja la propiedad HTTPOnly para la seguridad en los

 CÓDIGO:
01
POLITICAS DE DESARROLLO
01
SEGURO SOFTENERGY VERSIÓN:

FECHA: 14/02/2024

Lista de chequeo SI No Observaciones

Cookies.
La aplicación contiene la imagen “captcha” después de dos intentos fallidos de
autenticación como medida aseguramiento.
La aplicación solo permite acceso a usuarios autorizados por EMPRESA.
La aplicación no permite excesivas peticiones de un usuario.
Los usuarios finales tienen mínimos privilegios contra la base de datos.
(Validar que los usuarios que acceden a la aplicación no sean los súper- usuarios o
propietarios de la base de datos).
Los privilegios de administración están asignados a un usuario diferente a los asignados
para su operación o uso. El usuario administrador no debe tener acceso a tareas
operativas
Utiliza procedimientos almacenados y consultas parametrizadas para realizar las
operaciones de las base de datos, los procedimientos almacenados debe
tener permisos asignados por cada rol o perfil.
La aplicación permite configurar diferentes roles donde se definan permisos o
autorización de consulta, inserción, modificación o borrado de recursos o información
en cada uno de los módulos, servicios o secciones de la
aplicación
La aplicación tiene implementada la matriz RACI o RBAC. Cada usuario solo podrá ver
sus directorios y accesos a módulos asignados.
La aplicación no maneja datos sensibles en los Cookies, si los manejan,
deben viajar de forma cifrada y se debe borrar los datos de los Cookies cada vez que se
cierre sesión.
La aplicación no tiene el tipo de autenticación “Recordar Contraseña”.
La aplicación tiene un límite de inactividad para el usuario. Ejemplo: puede ser de 5
minutos o parametrizable.
La aplicación permite destruir el ID de sesión del usuario cada vez que éste salga del
sistema o cierre el navegador.
La aplicación valida que un usuario solamente este logueado en un solo escritorio
virtual, si se realiza la prueba de autenticar el mismo usuario en dos
máquinas, la aplicación debe desplegar un mensaje donde indique que su usuario ya
está activo en otra máquina.
Todos los datos de entrada de los formularios tienen validación de tipo de dato,
tamaño de caracteres, filtro de caracteres especiales, entre otras
validaciones.
La aplicación no tiene sentencias directas de SQL.
La aplicación entregada contiene la capa de base de datos y presentación independiente

La aplicación debe registrar en logs lo siguiente: los fallos, intentos de

autenticación exitosos y no exitosos, accesos a recursos no permitidos o con
 CÓDIGO:
01
POLITICAS DE DESARROLLO
01
SEGURO SOFTENERGY VERSIÓN:

FECHA: 14/02/2024

Lista de chequeo SI No Observaciones

privilegios. Estos logs deben ser exportados y/o enviados de manera automática a un
syslog, snmtp o una base de datos externa tipo (SIEM), Igualmente en logs debe
quedar registrado la aplicación, versión, fecha, hora,
dirección IP y el usuario logueado.
Los logs de la aplicación registran todos los eventos de intento de evasión de controles
que se detecten en la aplicación, los eventos inesperados y todas las excepciones
producidas por el sistema, todos los eventos o cambios
realizados por los usuarios con mayor privilegio sobre la aplicación.
Los logs del sistema no registran datos sensibles de la aplicación.
La aplicación web, tiene filtros de escape XSS (Cross site Scripting).
La aplicación web utiliza etiquetas javascript. Estas etiquetas están filtradas de escape
XSS o cifradas por un algoritmo fuerte.
La aplicación web, tiene cifrados las peticiones de los links e imágenes.
La aplicación no utiliza direcciones de URL cuando realiza funciones de cambio de
estado u operaciones en las base de datos.
Las peticiones de HTTP tienen solicitudes a páginas esperadas y existentes en la
aplicación.
Las URLs no se pueden fácilmente modificar y no es visible.
Los parámetros de las Urls son validados adecuadamente (Revisar tipo de dato,
tamaño y filtros caracteres especiales)
La aplicación no tiene redirecciones ni reenvíos a Urls quemadas en el código.

ARQUITECTURA DE SEGURIDAD / REVISIÓN DE DISEÑO.

La aplicación desarrollado por el proveedor está divida por las capas o vistas definidas
en el documento de Estándar de desarrollo seguro.
REVISIÓN DE CÓDIGO SEGURO / PRUEBAS DE SEGURIDAD / GESTIÓN
DE VULNERABILIDADES.
El proveedor aplicó pruebas de caja blanca.
El proveedor aplicó pruebas de caja negra
El proveedor realizó el proceso de revisión de código seguro (si no lo aplicó,
EMPRESA puede decidir a realizar el proceso revisión de código seguro con otro
proveedor externo diferente al proveedor que desarrollo la aplicación).
El proveedor realizó pruebas y escaneo de vulnerabilidades de infraestructura (si no lo
aplico, EMPRESA puede decidir a realizar el proceso de Hacking
Ético con otro proveedor externo diferente al proveedor que desarrollo la
aplicación.
El proveedor entregó toda la documentación de las pruebas realizadas.

SEGURIDAD EN AMBIENTE.
 CÓDIGO:
01
POLITICAS DE DESARROLLO
01
SEGURO SOFTENERGY VERSIÓN:

FECHA: 14/02/2024

Lista de chequeo SI No Observaciones

En la Matriz RACI (ITIL) o RBAC están definidas las funciones que realizan los
usuarios en los ambientes de desarrollo, calidad y producción.
Se retiraron todos los datos de pruebas utilizados en los ambientes de calidad,
entrenamiento y desarrollo antes de pasar a producción
En el documento de arquitectura se registró todos los componentes que son requeridos
para que la aplicación funcione correctamente.
Se verificó cuáles son las últimas actualizaciones de: aplicación, sistema operativo,
base de datos, parches, máquina virtual de java, servidor de aplicaciones, entre otros.
Si no es la última versión justificar porque utiliza
versiones anteriores.
La aplicación web no permite a cualquier usuario, navegar dentro de los directorios
internos del código fuente.
En el servidor se verificó que no se encuentren instalados módulos, extensiones,
programas por defecto y que no serán usados por la aplicación.
La aplicación utiliza protocolos seguros como: SSH, SFTP, FTPS, VPN,
SSL\TLS v1.1-1.3, IPSec, etc. Para la comunicación y transferencia de archivos

La aplicación verifica que solo este permitido él cargue de documentos con extensiones
específicas, como por ejemplo: .pdf, .xls,.doc,.txt, etc.
La aplicación valida la cantidad de registros que se pueden cargar en un archivo.

La aplicación valida la cantidad de registros que lee la aplicación de un archivo

La aplicación guardar los archivos que son cargados en un servidor seguro que solo
tenga permisos de lectura.
La aplicación utiliza índices que internamente se asocien a directorios o rutas pre
definidas. Se recomienda no usar rutas específicas para subir o descargar archivos.

La aplicación omite cuentas tales como administrador, root, sa, sysman,

“Supervisor”, o cualquier otra con máximos privilegios para ejecutar la
aplicación o conectar al servidor Web, base de datos o middleware.

ANEXO 3. GLOSARIO.

Algoritmo AES: AES conocida como Estándar de ciframiento Avanzada (Advanced Encryption Standard). AES
es una técnica de cifrado de clave simétrica que remplazará el Estándar de Cifrado de Datos (DES) utilizado
habitualmente.
 CÓDIGO:
01
POLITICAS DE DESARROLLO
01
SEGURO SOFTENERGY VERSIÓN:

FECHA: 14/02/2024

El algoritmo ganador, Rijndael, fue desarrollado por dos criptologistas Belgas, Vincent Rijmen y Joan Daemen.

AES proporciona una ciframiento seguro y ha sido elegida por NIST como un Estándar de Proceso de Información
Federal en Noviembre del 2001 (FIPS-197), y en Junio del 2003 el Gobierno de EEUU (NSA) anunció que AES
es lo suficientemente seguro para proteger la información clasificada hasta el nivel ALTO SECRETO, que es el
nivel más alto de seguridad y que se definen como información que pudiera causar "daños excepcionalmente
graves" a la seguridad nacional en caso de ser divulgada al público.

El algoritmo AES utiliza longitudes de ciframiento de 128-, 192-, o 256- bits. Cada tamaño de la clave de cifrado
hace que el algoritmo se comporte ligeramente diferente, por lo que el aumento de tamaño de clave no sólo ofrece
un mayor número de bits con el que se pueden cifrar los datos, sino también aumentar la complejidad del
algoritmo de cifrado.

Algoritmos HASH: Los algoritmos HASH, parten de una información de entrada de longitud indeterminada y
obtienen como salida un código, que en cierto modo se puede considerar único para cada entrada. La función de
estos algoritmos es determinista, es decir que partiendo de una misma entrada siempre se obtiene la misma salida.
Sin embargo, el interés de estos algoritmos reside en que partiendo de entradas distintas se obtienen salidas
distintas.

Amenaza: Causa potencial de un incidente no deseado, que puede provocar daños a un sistema o a la
organización. [ISO 27001:2013]

Bcrypt: Es un hash que puede ser utilizado para guardar contraseñas utilizando el algoritmo BlowFish de una
sola vía. Las razones por utilizar el Bcrypt es que es muy lento para descifrar, lo cual evita los ataques de fuerza
bruta y su longitud es de 64 bits.

BlowFish: Es un codificador de bloque simétricos, diseñado por Bruce Schneider en 1993 e incluido en un gran
número de conjuntos de codificadores y productos de cifrado. No se han encontrado técnicas de criptoanálisis
efectivas contra el BlowFish. BlowFish usa bloques de 64 bits y claves que van desde los 32 bits hasta 448 bits.

Ciframiento: El ciframiento es el proceso de cambiar los datos de forma que solo puedan ser leídos por el
receptor al que va destinado. Para descifrar el mensaje, el destinatario debe tener la clave para descifrar el mensaje

Ciframiento con clave simétrica: Se incluyen en esta familia el conjunto de algoritmos diseñados para cifrar
un mensaje utilizando una única clave conocida por los dos interlocutores, de manera que el documento cifrado
sólo pueda descifrarse conociendo dicha clave secreta. Algunas de las características más destacadas de este tipo
de algoritmos son las siguientes:
 CÓDIGO:
01
POLITICAS DE DESARROLLO
01
SEGURO SOFTENERGY VERSIÓN:

FECHA: 14/02/2024

 A partir del mensaje cifrado no se puede obtener el mensaje original ni la clave que se ha utilizado,
aunque se conozcan todos los detalles del algoritmo cifrado utilizado.
 Se utiliza la misma clave para cifrar el mensaje original que para descifrar el mensaje codificado.

 Emisor y receptor deben haber acordado una clave común por medio de un canal de comunicación
confidencial antes de poder intercambiar información confidencial por un canal de comunicación
inseguro.

Los algoritmos simétricos más conocidos son: DES, 3DES, RC2, RC4, RC5, IDEA, BlowFish y AE

Confidencialidad: La propiedad de la información, por la que se garantiza que está accesible únicamente a
personal autorizado a acceder a dicha información.

Disponibilidad: Característica, cualidad o condición de la información de encontrarse a disposición de quienes

deben acceder a ella, ya sean personas, procesos o aplicaciones.

FIPS 140-2: Es un estándar de seguridad de ordenadores del gobierno de los Estados Unidos para la acreditación
de módulos criptográficos, su título original son requerimientos de seguridad para módulos criptográficos. Se
referencia el siguiente link: http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf

Integridad: Es la propiedad el mantener con exactitud la información tal cual fue generada, sin ser manipulada o
alterada por personas o procesos no autorizado.

Metodología DREAD: Una vez que tenemos identificada la lista de amenazas, el siguiente paso consiste en
puntuarlas de acuerdo al riesgo que suponen. Esto nos permitirá priorizar las actuaciones a efectuar para mitigar el
riesgo. Recordemos que, el riesgo se puede cuantificar como el resultado de multiplicar la probabilidad de que la
amenaza se produzca, por el daño potencial de esta.

El método DREAD, trata de facilitar el uso de un criterio común respondiendo a las siguientes cuestiones:

Damage potential (Daño potencial): ¿Cuál es el daño que puede originar la vulnerabilidad si llega a ser explotada?
Reproducibility (Reproducibilidad): ¿Es fácil reproducir las condiciones que proporciona el ataque?
Exploitability (Explotabilidad): ¿Es sencillo llevar a cabo el ataque?
Affected users (Usuarios afectados): ¿Cuantos usuarios se verían afectados? Discoverability
(Descubrimiento): ¿Es fácil encontrar la vulnerabilidad?

Modelado de Amenazas: El modelado de amenazas es una técnica de ingeniería cuyo objetivo es ayudar a
identificar y planificar de forma correcta la mejor manera de mitigar las amenazas de una aplicación o sistema
informático.
 CÓDIGO:
01
POLITICAS DE DESARROLLO
01
SEGURO SOFTENERGY VERSIÓN:

FECHA: 14/02/2024

Ocurrencia: El número de líneas de código fuente donde se identificaron diferentes tipos de vulnerabilidades.

OWASP: OWASP (acrónimo de Open Web Application Security Project, en inglés ‘Proyecto abierto de
seguridad de aplicaciones web’) es un proyecto de código abierto dedicado a determinar y combatir las causas que
hacen que el software sea inseguro. La Fundación OWASP es un organismo sin ánimo de lucro que apoya y
gestiona los proyectos e infraestructura de OWASP. OWASP está formada por empresas, organizaciones
educativas y particulares de todo el mundo. Juntos constituyen una comunidad de seguridad informática que
trabaja para crear artículos, metodologías, documentación, herramientas y tecnologías que se liberan y pueden ser
usadas gratuitamente por cualquiera.

OWASP TO 10: 2013: El objetivo principal del Top 10 es educar a los desarrolladores, diseñadores, arquitectos,
gerentes, y organizaciones; sobre las consecuencias de las vulnerabilidades de seguridad más importantes en
aplicaciones web. El Top 10 provee técnicas básicas sobre cómo protegerse en estas áreas de alto riesgo y también
provee orientación sobre los pasos a seguir.

PBKDF2: Consiste en generar una nueva contraseña a partir de una contraseña existente. Para ello se parte de una
contraseña inicial y de una semilla, a esta contraseña inicial se le aplica una función de tipo Hash y se repite este
proceso muchas veces. El resultado final es una clave simétrica representada en una secuencia de bytes que puede
ser guardada como un fichero binario, se pude convertir en diferentes formatos como puede ser hexadecimal y
guardarla como texto u otro formato que resulte más cómodo.

Riesgo: Posibilidad de que una amenaza concreta pueda explotar una vulnerabilidad para causar una pérdida o
daño en un activo de información. Suele considerarse como una combinación de la probabilidad de un evento y
sus consecuencias. [ISO 27001:2013]

SANS TOP 25: Es una lista de los errores más comunes y críticos que puede conducir a graves vulnerabilidades
de software. A menudo son fáciles de encontrar y fácil de explotar. Estos errores con frecuencia permiten a los
atacantes tomar completamente el software, robar datos o impedir que software funcione correctamente.

Es una herramienta que ayuda a que los programadores tengan conciencia para prevenir todo tipo de
vulnerabilidades de software, identificando y mitigando los errores comunes que se puede producir antes del
software sea publicado.

STRIDE: Es un acrónimo que resume 6 categorías de Amenazas como suplantación, Manipulación, Repudio,
Revelación de información, Denegación de Servicio, Elevación de Privilegios.
 CÓDIGO:
01
POLITICAS DE DESARROLLO
01
SEGURO SOFTENERGY VERSIÓN:

FECHA: 14/02/2024

Vulnerabilidad: Debilidad de un activo o control que puede ser explotada por una o más amenazas [ISO
27001:2013]. Un error, falla, debilidad o la exposición de una aplicación, sistema o dispositivo o servicio que
podría dar lugar a un incumplimiento de la confidencialidad integridad o disponibilidad.