Malas prácticas en la seguridad de productos
(cisa.gov)En el producto en sí
Lenguajes no seguros para la memoria (C, C++, etc.)
Siempre que sea posible, se deben usar lenguajes con seguridad de memoria, y los programas existentes que no la tengan deben reemplazarse gradualmente antes de finales de 2025.
Ejecución directa de sentencias SQL
Usa consultas parametrizadas, sentencias preparadas u ORM.
Ejecución directa de comandos del sistema operativo
La entrada del usuario no debe convertirse en el comando en sí. En lugar de ejecutar comandos directamente, se deben usar funciones de bibliotecas integradas o permitir en la entrada solo letras en inglés, números y guion bajo.
Uso de contraseñas demasiado conocidas
Debe evitarse en lo posible mediante métodos como los siguientes.
- Proporcionar una contraseña única desde el principio.
- Exigir que el usuario cree una contraseña fuerte durante la instalación.
- Establecer un límite de tiempo para la contraseña, como con MFA.
- Requerir acceso físico para obtener credenciales confiables.
- Realizar campañas o migrar a métodos de autenticación más seguros que los actuales.
Dejar sin atender vulnerabilidades conocidas
Las vulnerabilidades que aparecen en esa página deben prevenirse "todas". Cuando se reporten nuevas vulnerabilidades, deben resolverse oportunamente y se debe advertir a los usuarios que no actualicen a la versión corregida.
Bibliotecas de código abierto con vulnerabilidades
Se debe informar responsablemente de estos temas a las bibliotecas que se están usando y contribuir cuando corresponda. Esto también incluye las siguientes medidas.
- Elaborar un SBOM: muestra qué bibliotecas usa el software.
- Aspectos que deben aplicarse a las bibliotecas de código abierto de las que se depende
- Realizar revisiones de seguridad.
- Elegir proyectos de calidad que sean sostenidos, bien protegidos y bien mantenidos. También es buena idea seguir estos principios de seguridad.
- Investigar de forma continua si existen vulnerabilidades bien conocidas.
- El fabricante debe tener una copia por adelantado y no se debe actualizar desde lugares no verificados.
- Se debe considerar el costo de actualizar a nuevas versiones mayores o de aplicar parches de seguridad.
Si una vulnerabilidad no afecta al producto, se debe informar públicamente por qué no lo afecta.
Algoritmos criptográficos vulnerables o no reconocidos (TLS 1.0/1.1, DES, MD5, etc.)
Se deben usar algoritmos modernos. Además, también se debe preparar la adopción de algoritmos criptográficos poscuánticos estandarizados conforme a las directrices de NIST.
Claves secretas incluidas en el código fuente
Se debe usar un gestor de secretos (Secret Manager) para que el programa pueda recuperar claves secretas de forma segura. También se debe revisar si hay claves secretas en el código fuente.
En las funciones de seguridad
Sin soporte para MFA (incluye soportar solo passkeys)
Salvo en casos en los que un retraso sea peligroso, como equipos médicos de emergencia, por defecto se debe implementar MFA directamente o usar un autenticador externo. Debe exigirse a los administradores, y los administradores deben exigirlo a los usuarios dentro de la organización.
No proporcionar evidencia de intrusión
- Como función muy básica, se deben generar registros relacionados con cambios o consultas de configuración, historial de inicio de sesión y acceso a la información.
- En el caso de proveedores de nube, estos registros deben conservarse por al menos 6 meses sin costo adicional y deben ponerse a disposición del usuario.
En los procesos y políticas de la organización
No emitir CVE
Las vulnerabilidades críticas o con gran impacto deben divulgarse de inmediato.
No publicar una política de divulgación de vulnerabilidades (VDP)
Se deben publicar políticas como las siguientes.
- Aprobación de pruebas por parte del público en general
- Promesa de no emprender acciones legales contra quienes actúen de buena fe
- Un canal claro para realizar reportes
- Mejores prácticas de CVD (Coordinated Vulnerability Disclosure) y estándares internacionales
Las vulnerabilidades reportadas deben corregirse oportunamente y en orden de riesgo.
(En entornos on-premise) período de soporte poco claro
Se debe comunicar claramente el período de soporte y proporcionar actualizaciones de seguridad durante ese período.
- One-click exploit en KakaoTalk
- GN⁺: NIST (Instituto Nacional de Estándares y Tecnología de EE. UU.) prohíbe exigir una composición específica de caracteres en las contraseñas
- La Casa Blanca insta a los desarrolladores a evitar C y C++ y usar lenguajes con "seguridad de memoria"
- Hackear mi auto: Hyundai Ioniq: se encontró en el código fuente un cifrado RSA localizable con Google
7 comentarios
La seguridad es de esas cosas en las que, en un momento de descuido...! (creo que vi algo así en el ejército)
¡No te quiebres!
Parece que volvió a circular la idea de que no deberíamos usar ORM...
Solo hay que usar
Prepared Statementen lugar de ORM.zzz
Siempre hay principios para todo; lo difícil es cumplirlos...
Me gusta, estoy de acuerdo
Exigir que el usuario genere una contraseña fuerte != debe incluir obligatoriamente caracteres especiales, mayúsculas y minúsculas en inglés, y números
Con que tenga una longitud razonablemente larga, ya es una contraseña fuerte.