En el desarrollo de software, uno de los puntos que normalmente menos se toman en cuenta pero que es probablemente el más importante de todo son las medidas que se toman durante el ciclo de vida del desarrollo de las aplicaciones para que éstas sean lo más seguras posibles.
Todos nuestros procesos de desarrollo tienen una orientación DevSecOps, donde las tres partes tienen una importancia similar dentro de los procesos de nuestra Software Factory.
En BLMovil la seguridad de las aplicaciones que desarrollamos es uno de los puntos más importantes de nuestra factoría de software, y para llevarlo a cabo, nos fijamos en los siguientes 5 puntos:
1.- Identificar los requisitos de seguridad que debe garantizar el sistema. Identificar y clasificar los niveles de criticidad en integridad y confidencialidad durante el análisis de la solución.
En el proceso de identificación de los requisitos de seguridad, BLMovil funciona de dos formas diferentes dependiendo del tipo de proyecto.
Si el proyecto viene completamente definido por parte del cliente, el proceso que realizamos, consiste en revisar todos los requisitos de seguridad solicitados por el cliente y si encontramos alguna inconsistencia o la falta de algún requisito de seguridad bajo nuestra experiencia, se lo notificamos al cliente para tenerlo en cuenta y poderlo agregar al desarrollo.
Si el cliente nos solicita a nosotros que gestionemos totalmente el proyecto con la gestión de los requisitos, nosotros tomamos los requisitos de seguridad que solicite el usuario final, y sobre esos requisitos, aplicamos nuestros estándares de seguridad dependiendo del tipo de aplicación y de la criticidad de los datos que se van a tratar en la aplicación.
BLMovil, sigue las especificaciones Application Security Verification Standard de OWASP para las pruebas a verificar según el tipo de aplicación y la sensibilidad de los datos a gestionar.
2.- La seguridad debe estar presente desde el comienzo del proyecto, empezando por la definición de una arquitectura segura. Se deben identificar los componentes tanto de negocio como de infraestructura registrando las interfaces de E/S y los datos involucrados.
BLMovil, como en el punto anterior, trabaja de forma diferente dependiendo de si es el cliente quien le proporciona la arquitectura o no.
Si el cliente proporciona la arquitectura, antes de utilizarla, realizamos las pruebas correspondientes a la misma para identificar los posibles problemas de seguridad y comunicárselos al cliente.
Si no la proporciona, nosotros utilizamos alguna de las arquitecturas que ya tenemos probadas y validadas en cuanto a la seguridad de las mismas
En cuanto a los interfaces de E/S y los datos involucrados siempre buscamos el uso de procesos de encriptación y desencriptación de los datos tratando de usar estándares de al menos 256 bits unidireccoinales o simétricos dependiendo del tipo de datos como SHA-256, TLS1.3, etc, para que los datos viajen seguros.
Asimismo, establecemos procesos de seguridad en el acceso de los datos dependiendo de los perfiles, de forma que cumplimos las normativas GDPR, PCI, etc., según necesidad del cliente y de la normativa que tenga que cumplir la aplicación, ocultando o enmascarando los datos sensibles para usuarios que no deban tener acceso a los mismos, permitiendo o prohibiendo el acceso a datos sensibles a perfiles específicos, haciendo todo esto desde el propio aplicativo.
3.- Durante el desarrollo se deben incluir auditorias de código estático y dinámico. Así como controles de seguridad relativos a:
-
-
Proceso de autenticación y autorización basada en roles y permisos
-
Uno de los puntos importantes dependiendo del tipo de aplicación, es asegurar que la persona que accede al sistema es exactamente la persona que dice ser.
El proceso de autenticación y autorización, lo realizamos basado en el sistema que tenga el cliente, y como en los casos anteriores, si vemos problemas de seguridad en los mismos, avisamos al cliente de los posibles problemas.
En el caso de que el cliente, no disponga de su sistema de autentificación, y autorización nosotros proponemos el uso de uno de los que ya tenemos definidos dependiendo del tipo de aplicativo a desarrollar, y siempe cumpliendo los apartados de Requisitos de Verificación de seguridad definidos en el estándar de verificación de seguridad de aplicaciones de OWASP.
-
-
Gestión de secretos y de la sesión
-
La gestión de los secretos en nuestros desarrollos propios la realizamos normalmente mediante el uso de almacenes de claves centralizados de la aplicación. Tenemos por un lado almacenes de claves optimizados para la gestión de usuario y clave para el acceso a sistemas externos y por otro lado sistemas de almacenamiento para los archivos y claves de encriptación.
Para el caso de que el cliente tenga sus propios almacenes, utilizamos los que nos proporciones
Para la gestión de la sesión, seguimos asimismo las recomendaciones de OWASP, como no mantener la sesión en parámetros de la URL, definir tokens de sesión con al menos 64 bits, almacenamiento de los tokens de sesión en cookies securizadas, definición de la duración de la sesión.
Asimismo, donde el cliente lo permita, utilizamos sistemas de doble autentificación como OAuth,o JWT, dependiendo de las necesidades del cliente.
-
-
Validación de entradas y codificación de salidas
-
En BLMovil utilizamos unos frameworks de desarrollo que hacen la validación de los datos introducidos en las entradas, de forma que no se puedan introducir datos distintos a los que admita el campo, así como la validación de los mismos.
Para las salidas de datos siempre se codifican con una codificación de 256 bits, con un sistema de clave pública y clave privada.
-
-
Diseño de codificación y uso de criptografía
-
Para la codificación de los datos utilizamos los estándares de codificación de la industria.
En cuanto a la criptografía dependiendo de las necesidades y/o solicitudes de nuestros clientes, solemos utilizar los sistemas criptográficos que vienen definidos en los propios lenguajes de programación, siempre usando una encriptación con un mínimo de 128 bits, aunque preferentemente de 256 bits.
-
-
Uso de memoria y ficheros
-
Si no son desarrollos muy específicos por ejemplo en C donde tengamos que acceder a posiciones de memoria específicas, en los desarrollos que hacemos no utilizamos referencias específicas a posiciones de memoria. En el caso del uso de direcciones de memoria específicas, siempre controlamos por un lado que no se utilicen espacios de memoria reservados, y por otro, que la longitud de los datos a almacenar sea siempre menor o igual al espacio de memoria reservado.
Para el uso de ficheros, el funcionamiento que se realiza en nuestros desarrollos es no almacenarlos en la base de datos, sino en un directorio del sistema que se tiene protegido por un sistema antivirus. A este directorio sólo tiene acceso el usuario de la aplicación, y se controlan los permisos de acceso por usuario a los mismos.
-
-
Manejo de logs y errores
-
Los desarrollos que realizamos disponen habitualmente de un sistema de niveles de log de información, de forma que dependiendo del nivel de log solicitado muestran la información en el log.
Para la gestión de errores, los sistemas desarrollados por BLMovil, disponen de gestión de excepciones, que evitan que el error de la aplicación el llegue al usuario final, pero que quede almacenado en el log de errores para que los equipos de desarrollo tengan acceso a los mismos. Dependiendo de la solicitud del cliente, estos logs se pueden enviar a una base de datos en vez de a un archivo para poder dar acceso a los desarrolladores a los errores sin necesidad de que accedan a los servidores productivos.
Asimismo, la mayoría de nuestros desarrollos tienen una bitácora de operaciones en las que se registran las operaciones sensibles que pueda realizar cualquier usuario, almacenando el usuario, timestamp, y la información relacionada de la operación.
-
-
Interfaces seguras
-
En los desarrollos que realizamos, siempre intentamos que las interfaces con terceros sistemas sean seguras. Si nosotros tenemos el control de ambos puntos de conexión, las interfaces siempre las realizamos con los datos encriptados, y con un token de autentificación, que valide la solicitud. Si el servicio al que nos conectamos es de un tercero, intentamos que la comunicación sea lo más segura posible, avisando al cliente de los posibles riesgos que puede tener en el uso de esos interfaces en el caso de que no sean 100% seguros.
-
-
Seguridad aplicada a recursos: FS, docs…
-
La seguridad aplicada a los recursos, desde la aplicación, cada vez que se crea un FS, o u documento, o cualquier otro recurso, lo realizamos asignando los permisos mínimos al perfil de usuario que deba tener al mismo a nivel sistema operativo, para que no pueda ser accedido desde el propio sistema operativo si no se dispone el usuario correspondiente.
-
-
Protección y aislamiento de datos
-
Todos los datos sensibles que se crean desde los sistemas que desarrollamos, se encuentran convenientemente cifrados, y las claves de encriptación se encuentran separadas del sistema en los almacenes de claves de seguridad.
Asimismo, en el caso de datos muy sensibles, separamos en bases de datos diferentes dependiendo de la sensibilidad de los datos, para hacer más complicado el acceso a los mismos en el caso de ataques de fuerza bruta.
4.- Pruebas:
-
-
Testing automatizado de seguridad
-
Por un lado, todos nuestros desarrollos tienen validación mediante SonarQube de los problemas estándares de seguridad de los desarrollos. Dentro del proceso de integración continua de BLMovil, basado en Jenkins, a diario se hace una validación del código subido a los repositorios de control de versiones de todas las aplicaciones en desarrollo que tengan alguna modificación en el día.
Las reglas aplicadas, pueden ser los estándares, o las que se definan con el cliente.
Asimismo, si tenemos acceso a los sistemas productivos, realizamos una batería de pruebas de seguridad contra los sistemas productivos.
-
-
Pentesting
-
Contamos con una empresa externa y dos consultores freelance especialistas externos todos dedicados a la ciberseguridad que utilizamos alternándolos para hacer procesos de pentesting. De esta manera, algunas pruebas las repetimos si es necesario pero con diferentes actores.
Internamente estamos empezando a utilizar Kali Linux para la realización de pentesting.
-
-
Owasp
-
Todos nuestros desarrollos se hacen teniendo en cuenta las especificaciones OWASP. Asimismo, SonarQuBe realiza ciertas validaciones de las recomendaciones OWASP que revisamos y solucionamos.
-
-
Detección de riesgos
-
Podemos realizar con la empresa asociada análisis de detección de riesgos de seguridad.
5.- Mantenimiento
-
-
Monitorización continua
-
Dentro del grupo tenemos una empresa Hova IT que está orientada a la distribución de soluciones para hacer que las áreas de IT de las empresas sean más productivas. Dentro de las soluciones que distribuimos, tenemos una solución SecuPi, que está orientada a la monitorización de los accesos a los datos, quién accede a qué datos, y qué mostrar a cada usuario.
-
-
Protocolos preventivos y reactivos de seguridad
-
Los protocolos preventivos y reactivos de seguridad van a depender de si nosotros publicamos la aplicación, o lo realiza el cliente o un tercero, donde el acceso a la monitorización y resolución de problemas puede estar más restringida.
En los desarrollos a solicitud del cliente podemos generar un documento definiendo los protocolos a aplicar, si nosotros no somos los encargados de la publicación de la aplicación o no tenemos acceso al mismo.
-
-
Documentación asociada
-
La documentación asociada va a depender de la solicitada por el cliente. Como mínimo para el área de seguridad, se van a tener el documento de gestión de requisitos de seguridad del sistema, el documento de pruebas de seguridad a realizar, los resultados de cada ejecución de pruebas de seguridad ejecutados, la definición de la arquitectura de seguridad.
Notas adicionales: Aparte de el uso del Kali Linux, estamos evaluando el uso de soluciones con IAST para la detección de vulnerabilidades y RASP para la protección de aplicaciones web, APIs y microservicios
Si tienes una idea, nosotros te la desarrollamos