Auditorías de seguridad informática ¿Tienes permiso?
Cuando hacemos auditorías de seguridad o test de intrusión contra una empresa deberiamos pedir permiso. Porque en caso contrario una de esas empresas podría tomar acciones legales contra nosotros. Algo a lo que muchos de vosotros no os queréis enfrentar.
Lo recomendables es siempre pedir permiso explícito. Lo importante es tener una prueba de ese permiso y un NDA (contrato de confidencialidad) con la persona a la que le quieres hacer la prueba de penetración. A continuación os vamos a hablar de los casos y situaciones más comunes que se nos pueden presentar.
1. Permiso del cliente
Uno de los casos más habituales es el solicitar un permiso explícito por parte del cliente. Este generalmente se incluye en un NDA (Contrato de confidencialidad), en el que se detalla las características de la auditoría y el ámbito de actuación.
Importante: En este contrato se deben establecer las direcciones IP, dominios, servicios, incluso horarios en los que podemos realizar nuestras auditorías.
El INCIBE pone a nuestra disposición de un modelo de NDA. Pero tener en cuenta que no contempla los detalles del trabajo.
2. Auditoría Reseller o contratista
Es una auditoría que la suelen solicitar personas que no son los propietarios de ese servicio. Principalmente son particulares que quieren realizar cosas poco éticas. Lo que suelen solicitar son servicios de auditoría que suelen ser ilegales.
Algunos ejemplos son:
- Este tío me debe pasta y quiero tumbarle la web
- Recuperar la clave de X servicio que supuestamente se perdió
Pero siempre existen otras situaciones, pongamos por ejemplo que la empresa Y subcontrata un servicio de auditoría: ¿Cómo sabes tú, como auditor, que la empresa final ha dado el consentimiento al contratista para realizar la auditoría?
Que el contratista aporte documentos que parecen ser firmados por el ceo no da mucha confianza. Muchas veces el entorno de auditoría es de pruebas y suelen dejar un txt en el que indican que autorizan el trabajo a X persona. Esto no ayudaría a verificar lo que el contratista los cuenta.
3. Auditoría BlackBoX
¿Qué es una auditoría Blackbox? Una auditoría Blackbox es aquella en la que el auditor realiza las pruebas/ataques desde el exterior de la organización a evaluar y sin ningún conocimiento previo de la infraestructura de ésta.
¿Qué pasa con las auditorías Blackbox? Pues en este caso la persona que realiza la auditoría debe reconocer los activos de la empresa por sí mismo.
Con esto entendemos que una auditoría del tipo BlackBox puede ser ilegal. Debido que al realizar un ataque hacia la empresa X sin darnos cuenta podemos estar también atacando a la empresa Y. Ya sea un simple escaneo de red o cualquier otro metodo.
4. Infraestructuras en la nube
Cuando vas a auditar a una web de una empresa que usa servidores y recursos externos en la nube de otra empresa debes contar con el consentimiento de esa empresa también.
Imagina que tienes una botnet muy grande y atacas a la web de X empresa alojada en Azure o en Amazon Web Services. ¿Qué tendría que hacer?
Tanto Azure como Amazon tienen unos formularios que has de rellenar para que ellos sean conscientes de que estás haciendo una auditoría de seguridad y no pongan sus abogados contra ti. Os dejo el documento para Amazon y para Azure.
En el caso de Google Cloud no es necesario avisar como ponen en el siguiente fragmento de su web:
Si planea evaluar la seguridad de su infraestructura de Cloud Platform con pruebas de penetración, no es necesario que se ponga en contacto con nosotros para comenzar las pruebas. Deberá cumplir con la Política de uso aceptable de Cloud Platform y los Términos del servicio y asegurarse de que sus pruebas solo afecten a sus proyectos (y no a las aplicaciones de otros clientes). Si se encuentra una vulnerabilidad, infórmenos a través del Programa de Recompensas de Vulnerabilidades.
Existen muchos hostings que no tienen este tipo de procedimientos definidos. En estos casos deberías evitar los ataques directos contra la infraestructura, como por ejemplo los ataques DDOS, DOS, DNS,... Realizar este tipo de ataques podrían afectar al hosting y ocasionarnos problemas de los cuales serías el responsable.