Gestión de los 10 principales riesgos OWASP

Todo acceso es autorizado por nuestro sistema backend basándose en los datos necesarios, como la identidad de la persona que llama, el punto final llamado y los parámetros de la solicitud, para evitar la escalada de privilegios tanto vertical como horizontal. Las soluciones de control de acceso se reutilizan siempre que es posible. Las llamadas a la API relacionadas con la autenticación tienen un índice limitado para reducir el riesgo de ataques de denegación de servicio y de recopilación automática de datos.

Cualquier conexión entre clientes web o dispositivos recientes y nuestros servidores siempre admite TLS. Esto incluye las conexiones desde los navegadores de los clientes a nuestros servidores web, pero también las conexiones desde los dispositivos a nuestros servicios. Los protocolos de texto plano no se utilizan para la comunicación de dispositivos que transmiten datos sensibles, a menos que sea un requisito específico del cliente para la comunicación de dispositivos.

Los algoritmos criptográficos y la solidez de las claves se revisan y actualizan periódicamente según sea necesario.

Los datos en reposo de nuestras bases de datos SQL se almacenan en volúmenes cifrados.

Como primera línea de defensa contra las vulnerabilidades de tipo inyección, nuestras aplicaciones web implementan la validación de entrada. Cuando es posible, se valida el tipo y el formato de la entrada del usuario.

Los frameworks modernos también proporcionan la codificación adecuada para evitar inyecciones al crear ciertos objetos, incluidos documentos XML, lo que reduce el riesgo de tales vulnerabilidades.

El riesgo de inyección SQL se reduce significativamente mediante el uso correcto de un ORM.

El riesgo de inyección de comandos del sistema operativo también se reduce en gran medida por la pila tecnológica subyacente basada en Java, en la que los comandos del sistema operativo nunca se ejecutan desde el código.

En cuanto al XSS, revisamos manualmente nuestro código y nuestros entornos de prueba para detectar scripts entre sitios. Algunas tecnologías y frameworks que utilizamos nos ayudan a prevenir XSS aplicando la codificación adecuada por defecto.

Nuestras normas internas de seguridad de la codificación y nuestros principios de diseño seguro sirven como lista de requisitos de seguridad y proporcionan una lista de reglas que todo el código y la arquitectura deben seguir. A la hora de tomar decisiones sobre posibles mejoras, tenemos en cuenta fuentes como BSIMM y SAMM. Nuestro Consejo de Seguridad gobierna y supervisa el diseño de la seguridad.

Nuestro objetivo es aplicar el principio del mínimo privilegio en todos los niveles de nuestra pila tecnológica. La superficie de ataque también se reduce instalando únicamente los componentes necesarios. La configuración del servidor se gestiona mediante soluciones automatizadas para garantizar el cumplimiento de las políticas internas. Las configuraciones a nivel de aplicación también se gestionan automáticamente y se comprueban mediante la revisión del código de seguridad y el análisis estático.

Para el procesamiento XML, el procesamiento DTD en línea se desactiva siempre que es posible, o se aplican mitigaciones adecuadas cuando es necesario.

Revisamos los componentes de terceros y sus vulnerabilidades. Los componentes con vulnerabilidades se evalúan y, si la vulnerabilidad afecta a nuestros servicios, se programa una actualización o corrección en función del riesgo. En el caso de los componentes de código abierto, esto también se apoya en las notificaciones de GitHub sobre componentes vulnerables. Además, realizamos análisis periódicos de la red para encontrar servicios vulnerables en todos nuestros entornos.

Nuestras aplicaciones web requieren contraseñas seguras según las recomendaciones del NIST (NIST 800-63-3).

Las cuentas se bloquean durante periodos de tiempo exponencialmente crecientes tras un número de intentos de inicio de sesión fallidos. Se registran tanto los intentos de inicio de sesión exitosos como los fallidos. La recuperación de contraseñas se realiza a través del correo electrónico, donde sólo se envían tokens. Las contraseñas nunca se envían por correo electrónico. Las contraseñas de la base de datos se cifran con una función de derivación de clave apropiada (no un hash criptográfico simple), utilizando implementaciones estándar bien conocidas. Esto evita los ataques de fuerza bruta incluso en una lista conocida de hashes de contraseñas.

Nuestros servicios web se actualizan a través de una canalización CI revisada y de confianza. Las vulnerabilidades de los módulos de terceros se comprueban mediante la automatización proporcionada parcialmente por GitHub. Los dispositivos utilizan actualizaciones de firmware firmadas y no cargan imágenes no firmadas o no fiables. El firmware sólo puede firmarse mediante un proceso riguroso y cuidadosamente diseñado que protege adecuadamente las claves de firma.

Los eventos auditables se registran, y los registros se recopilan en un repositorio central en tiempo real. Se dispone de registros de auditoría. Disponemos de supervisión de aplicaciones para detectar anomalías. Los registros nunca incluyen secretos y cumplen la normativa GDPR.

Los desarrolladores son conscientes de la existencia de SSRF, las revisiones de código y los análisis estáticos ayudan a prevenir estos problemas. La entrada del usuario se desinfecta cuando es necesario para mitigar SSRF. También forma parte de nuestras pruebas de penetración comprobar específicamente problemas similares.