En primer lugar para sacar esto del camino: recuerde que el OWASP Top 10 no es el principio y el fin de la seguridad del software. Por definición, está enfocado en la web, si está construyendo algo más, por ejemplo, un proyecto de infraestructura, un proyecto móvil que puede necesitar más y diferente. Además, si no se trata de una operación de campos verdes, es posible que desee requisitos que centren la atención en la integración con sus controles de seguridad en lugar de construir desde cero, por ejemplo, detallo mi pensamiento al respecto aquí: Mitigar los 10 principales de OWASP sin ningún código
Por lo tanto, desea proporcionar el OWASP Top 10 como un requisito para un desarrollador / vendedor (externo) en un lenguaje que se pueda probar y hacer cumplir en un contrato. Para la última parte, le sugiero que se asegure de que la redacción sea revisada por un abogado de su jurisdicción, solo estoy brindando asesoramiento como profesional de seguridad.
A un nivel alto, puede ser tan simple como esto:
- Cómo proteger mi computadora PC y laptop de las botnets
- ¿Qué determina si una conexión segura se cifra con cifrado de 128 o 256 bits?
- ¿Cómo puedo resolver esto: acceso denegado para el usuario 'nagpursp_ns' @ 'localhost' (usando la contraseña: SÍ)?
- ¿Cómo sabemos que las aplicaciones 'seguras' como Confide en realidad no son lanzadas por el (a) gobierno? ¿Se puede verificar su encriptación de forma independiente?
- ¿Qué es el malware de Doxware?
1) La solución no será vulnerable a ninguna de las vulnerabilidades de los 10 principales de OWASP, como lo demuestran las pruebas de seguridad independientes.
Glosario OWASP Top 10: Categoría: Proyecto OWASP Top Ten
MOSCÚ: debe
Lo anterior es probablemente suficiente para un contrato.
Para conocer los requisitos detallados, puede seguir el estándar significa que mitiga los 10 principales:
Validación / codificación de entrada y salida (que abordan la mayoría de las vulnerabilidades y específicamente)
1) La aplicación asumirá que todas las entradas son maliciosas y realizará la validación utilizando la siguiente estrategia (en orden de preferencia):
Restringir: acepta solo entradas conocidas, válidas y seguras (enfoque de lista blanca solamente)
Rechazar: los datos que no se ajustan al formato esperado se rechazan de plano
Desinfectar: los datos se examinarán por entradas “peligrosas” o maliciosas, que se codificarán para que sean inofensivas para el contexto en el que se utilizarán los datos (por ejemplo, se citarán comillas simples para los datos que se enviarán a la base de datos) .
2) La implementación de validación de entrada de aplicación (rutinas y lógica) verificará si se espera:
Tipo
Longitud
Formato
Distancia
La entrada está en su forma canónica
Conjuntos de caracteres e idiomas aceptados
3) Todas las fallas de validación de entrada darán como resultado un rechazo de entrada o desinfección de entrada.
4) Se debe especificar un conjunto de caracteres, como UTF-8, para todas las fuentes de entrada
5) La aplicación no se basará únicamente en la validación de entrada del lado del cliente. La validación de entrada se realiza en el lado del servidor por la aplicación para todas las entradas
6) La validación de todos los campos obligatorios (por ejemplo, aceptación de términos y condiciones) se realizará en el sitio del servidor
7) Todos los puntos de entrada de la aplicación y los límites de confianza se identificarán y documentarán. El diseño de la aplicación minimiza activamente el volumen y la frecuencia de los datos aceptados de fuentes remotas, por ejemplo, utilizando una estrategia de “aceptar una vez, validar una vez y reutilizar el valor limpio”
8) La validación de entrada se aplicará de manera consistente cada vez que se reciba una entrada
9) Los controles de validación de entrada de la aplicación deben ser modulares, consistentes y fácilmente verificables (auditables)
10) La aplicación utilizará un único control de validación de entrada centralizado para cada tipo de datos que se acepte
11) Todos los datos no confiables que se envían a HTML (incluidos los elementos HTML, los atributos HTML, los valores de datos de JavaScript, los bloques CSS y los atributos URI) XML, LDAP, etc. se deben escapar / codificar correctamente para el contexto aplicable.
12) Todos los controles de salida de codificación / escape se implementarán en el lado del servidor
13) La aplicación utilizará un único control de escape / codificación de salida centralizada para cada tipo de salida
14) Las declaraciones preparadas o los procedimientos almacenados parametrizados se utilizarán para almacenar o proporcionar la entrada del usuario a la base de datos
15) Para aplicaciones web, se utilizará un entorno de tiempo de ejecución que no sea susceptible a desbordamientos del búfer
Autenticación y autorización (vulnerabilidad A3)
1) El acceso a la solución solo se otorgará después de la autenticación contra una identidad central y un repositorio de control de acceso (si desea integrarse con una solución existente o eliminar central si desea desarrollar / proporcionar esto)
2) Todas las cuentas de usuario serán identificables individualmente (no genéricas o compartidas)
3) Todas las cuentas del sistema tendrán un propietario identificable individualmente y se les negará la capacidad de inicio de sesión local. Los administradores deberán exigir una forma responsable de obtener la contraseña de una cuenta del sistema (por ejemplo, registrar / retirar el depósito de contraseñas)
4) Las contraseñas (donde se usen) serán:
Mínimo 8 caracteres
Complejo (aplicar caracteres alfanuméricos y especiales)
Bloqueo después de 10 intentos de inicio de sesión no válidos
Desbloqueo por rol autorizado, incluido el restablecimiento de autoservicio y automáticamente después de 30 minutos
Forzar cambio en el primer inicio de sesión después de reiniciar
Requerir la contraseña actual antes de permitir el cambio de contraseña
Caducidad 60 días
Las últimas 12 contraseñas del historial no pueden reutilizarse
(Ajuste a su política, por ejemplo, eliminaría el vencimiento y el historial de la mayoría de los sistemas)
5) Los usuarios deberán poder cerrar sesión en su sesión. Cerrar sesión terminará la sesión del lado del servidor.
6) Las cuentas de preproducción y no producción no podrán acceder a entornos de producción con las mismas credenciales
7) La autenticación de dos factores (2FA) debe estar en su lugar para todo el acceso a la solución
(ajuste según su modelo de amenaza, apetito de riesgo, política, etc.)
8) Para los que se mueven y abandonan, el acceso a la solución se eliminará en 24 horas.
9) Todos los sistemas mostrarán un mensaje de advertencia apropiado a los usuarios antes de intentar iniciar sesión con respecto al uso no autorizado del sistema
10) CAPTCHA o equivalente se utilizará cuando exista la posibilidad de que un bot o script simule usuarios reales, incluidos:
Registros
Activación de cuenta
Restablecimiento de contraseña
Desbloqueo de cuenta
Cambie el nombre de usuario
Atención al cliente e interacción: comentarios o contáctenos, funcionalidad, foros del centro de contacto, etc.
11) La funcionalidad para realizar un desbloqueo masivo de todas las cuentas bloqueadas estará en su lugar en respuesta a un ataque de Denegación de Servicio (DOS)
12) Cuando se usen preguntas de seguridad, serán:
No se puede adivinar o investigar fácilmente (seguro, por ejemplo, sin código postal, fecha de nacimiento, apellido de soltera de la madre),
No cambia con el tiempo (estable),
Memorable
13) Las preguntas de seguridad o un código de restablecimiento de contraseña por sí solo no se utilizarán para realizar una función de seguridad clave (por ejemplo, restablecimiento de contraseña, validación de Contact Center). En su lugar, se utilizarán preguntas de seguridad, además del factor “algo que tienen”, por ejemplo, el código enviado a una dirección de correo electrónico o teléfono móvil verificado
(igual que 2FA)
14) Las cuentas que no se hayan utilizado en más de 180 días se bloquearán y requerirán un restablecimiento de contraseña para desbloquear
15) Los códigos de restablecimiento de contraseña solo serán válidos durante 15 minutos
(depende de los requisitos comerciales, mecanismo de entrega aceptable, etc.)
16) Todo el acceso de los usuarios se gestionará mediante roles y el sistema central de gestión de identidades y accesos (IDM)
(según la autenticación)
17) Se definirán los roles comerciales y técnicos de menor privilegio y se asignará al personal interno a puestos dentro de la estructura organizativa
18) Se requerirá autorización para realizar todas las funciones, incluidas la actualización de las reglas comerciales, los datos estáticos, los cambios en el contenido público, el acceso a URL y archivos de datos no públicos protegidos, leer o modificar registros
19) Cualquier referencia directa a objetos debe estar protegida de modo que solo los objetos autorizados sean accesibles para cada usuario
20) Cualquier separación de conflictos de deberes y otras combinaciones tóxicas se definirán para garantizar que se eviten o marquen para un proceso de excepción
21) Ningún usuario individual o cuenta del sistema tendrá la autoridad para aumentar su propia autoridad o privilegios de acceso en un sistema.
22) No habrá acceso privilegiado permanente en el entorno de producción. Cuando se requiera acceso privilegiado, será a través de un mecanismo de bombero que esté vinculado a un boleto de cambio o soporte aprobado y acciones completamente registradas
23) El acceso administrativo se limitará a la cantidad mínima de personal que lo requiera para fines comerciales
24) Será posible crear múltiples cuentas con permisos específicamente y solo para realizar la administración de usuarios.
25) Las aplicaciones no se configurarán para ejecutarse bajo cuentas de servicio o sistema operativo genérico. Las cuentas personalizadas y con privilegios mínimos deben crearse específicamente para el uso de la aplicación. Esta configuración permitirá el aprovisionamiento granular de permisos y la facilidad de registro y la capacidad de auditoría de los eventos de la aplicación.
26) Cuando los códigos de activación se utilizan para confirmar la dirección de correo electrónico o el móvil, se generarán de forma aleatoria y se aplicarán bloqueos en caso de entrada fallida:
Mínimo 8 caracteres
Alfanumérico y mínimo 1 carácter especial
Bloqueo después de 3 intentos fallidos de entrada
Gestión de sesiones (A3 y A5)
1) Se utilizará un marco de gestión de sesión aceptado por la industria. El identificador de sesión utilizado deberá contener al menos 128 bits de datos aleatorios (de una fuente confiable de entropía).
2) Cada formulario donde los usuarios puedan proporcionar información (incluida la selección de un menú desplegable) incluirá un token impredecible como parte de cada transacción. Dichos tokens deben, como mínimo, ser únicos por sesión de usuario e incluirse en un campo oculto enviado como parte de la solicitud http. El envío del formulario solo se aceptará si este token está validado. Los métodos aceptados por la industria, como la protección CSRF, se pueden utilizar para proporcionar esto
3) Las sesiones deberán tener un tiempo de espera configurable tanto para inactividad como absoluta (independientemente de la actividad). El tiempo de espera predeterminado para inactividad será de 15 minutos. El tiempo de espera absoluto predeterminado será de 24 horas.
4) El número de sesiones concurrentes que acceden a una cuenta será configurable y predeterminado a 1. La creación de una nueva sesión (es decir, iniciar sesión) terminará cualquier sesión previa
5) Una sesión autenticada permanecerá segura durante toda la sesión. Si por alguna razón la sesión se interrumpe, debe realizarse una nueva autenticación para reanudar la sesión.
6) Cualquier dato cargado o creado en las instalaciones del usuario final (es decir, navegador, computadora de escritorio, teléfono inteligente) será transitorio, es decir, se borrará de la memoria después de que finalice la sesión, o cuando haya cesado el requisito de residencia de memoria, lo que ocurra antes.
7) Las identificaciones de sesión nunca se revelarán excepto en los encabezados de cookies; particularmente en URL, mensajes de error o registros. Esto incluye verificar que la aplicación no admite la reescritura de URL de las cookies de sesión.
8) Solo los identificadores de sesión generados por la aplicación serán reconocidos como válidos por la aplicación.
9) Los tokens de sesión emitidos para usuarios no autenticados serán destruidos y reeditados por la aplicación web después de una autenticación de usuario exitosa y en cualquier reautenticación
10) Las cookies que contienen tokens / identificadores de sesión autenticados deben tener su dominio y ruta configurados en un valor restrictivo apropiado para el sitio
11) Las cookies que contienen tokens / identificadores de sesión autenticados solo se establecerán a través de transporte cifrado (por ejemplo, HTTPS)
Criptografía (A7) (estas fechas están mal, así que verifique qué está actualizado o su política)
1) RSA 4096 y superior se utilizarán para certificados TLS / SSL y cifrado asimétrico. AES 512 y superior se utilizarán para el cifrado simétrico. SHA 512 o superior se utilizará para el hash
2) Solo se admitirán cifrados TLS 1.0 y superiores
3) Las contraseñas se deben cifrar con SHA512 o superior y se salan
4) Todas las claves privadas y las claves de cifrado simétrico se almacenarán en un dispositivo certificado FIPS-140-2 (por ejemplo, HSM). Todos los demás módulos criptográficos se validarán con FIPS-140-2
5) Deben existir herramientas y procesos seguros y centralizados de administración de claves para generar, distribuir, proteger, cambiar, almacenar y retirar / reemplazar de manera segura las claves de cifrado
6) Todas las funciones criptográficas utilizadas para proteger los secretos del usuario de la aplicación se implementarán en el lado del servidor
Configuración, parches y pruebas (A6 y todo realmente)
1) Se definirán e implementarán estándares de configuración de seguridad (por ejemplo, plataforma, base de datos, aplicación, hipervisor de virtualización, middleware, estándares de dispositivos de red). Esto garantizará que todas las contraseñas predeterminadas se cambien y las cuentas predeterminadas se bloqueen donde no se usen. Los componentes y servicios de software que no son necesarios se eliminarán y se aplicarán los permisos con menos privilegios. Solo se utilizarán servicios seguros, por ejemplo, no TFTP o SNMP v2
2) Se debe implementar una herramienta y un proceso de cumplimiento de la configuración para garantizar que todos los componentes cumplan con los estándares de configuración reforzados
3) Se establecerá un proceso para identificar, priorizar en función del riesgo, verificar la integridad de, probar y aplicar parches de seguridad en al menos un ciclo de 1 mes con la capacidad de aplicar un parche de seguridad de emergencia dentro de los 5 días a toda la producción accesible por Internet ambientes
(los tiempos dependen del modelo de amenaza, apetito de riesgo, política)
4) Para cualquier desarrollo o personalización a medida, se seguirán los estándares de codificación segura y las convenciones de nomenclatura
5) Todas las plataformas deben ejecutar productos antimalware aprobados y una verificación de una firma actualizada y la definición del motor con el proveedor antimalware realizado al menos cada 3 horas. Cuando haya una actualización disponible, se implementará por completo dentro de las 24 horas.
6) Se realizarán pruebas de penetración de seguridad y se corregirán las vulnerabilidades de calificación alta y media antes de la puesta en marcha a partir de entonces al menos seis veces al mes
7) El análisis del código fuente de seguridad se realizará en todo el código y en cualquier vulnerabilidad de calificación alta y media remediada antes de la puesta en marcha a partir de entonces en cada cambio de código
8) El escaneo de vulnerabilidades de seguridad se realizará en todos los componentes del sistema y cualquier vulnerabilidad de calificación alta y media remediada antes de la puesta en marcha de allí en adelante al menos semanalmente.
9) Se proporcionará un paquete de prueba de regresión de seguridad automatizado dedicado para permitir a los evaluadores verificar fácilmente qué cambios en el código de impacto en la seguridad pueden haber tenido para la operación del sistema en su conjunto.
