El objetivo final de un proceso de Ethical Hacking es el de evaluar la seguridad de los sistemas, comunicaciones, infraestructuras de las que dispone la organización o empresa. En toda actividad que se realice en el proceso, ya sea una auditoria interna, un APT o una auditoria perimetral, es necesario, no sólo planificar y llevar a cabo las actividades sino efectuar procedimientos de control y de contramedida.
En otras palabras, hay que llevar a cabo la parte de intrusión y pruebas de seguridad, y por otro lado preparar las contramedidas y procedimientos que serán llevados a cabo en caso de detectar y explotar vulnerabilidades. La suma de ambas partes constituye una evaluación de seguridad global, que es realmente la que el cliente contrata y espera.
Vulnerabilidades
Un proceso de Ethical Hacking está compuesto, como se ha podido entender ya con anterioridad. por diversas pruebas con distintos enfoques, roles y ámbitos. Cualquier de estas pruebas tienen como objetivo común encontrar las vulnerabilidades que puedan afectar en mayor o menor medida a los bienes y activos de la empresa u organización. Se puede determinar por lo tanto que un proceso de Ethical Hacking está guiado por la búsqueda de las vulnerabilidades, las cuales provoquen la ejecución de las acciones correctoras, con el fin de detectar y solucionar los agujeros de seguridad.
Todas las vulnerabilidades no son iguales, este hecho es obvio. Existen ciertas vulnerabilidades que afectan directamente a los activos o bienes de la empresa, por lo que su detección y explotación puede suponer a la empresa una gran pérdida económica. Por otro lado existen las vulnerabilidades importantes, las cuales pueden afectar a los activos de la empresa, pero no de manera directa. También existen las vulnerabilidades meramente informativas, las cuales pueden proporcionar información a un atacante, la cual puede no interesar que se conozca por varios motivos. Este tipo de clasificación que se realiza de manera orientativa puede provocar que el auditor caiga en un error conceptual. Generalmente, en los informes que se realizan en el mundo profesional de la seguridad informática, no se clasifican de manera adecuada las vulnerabilidades encontradas.
Es importante recalcar que una vulnerabilidad que provoque una denegación de servicio puede ser critica si realmente el servicio que se deniega es importante para la empresa. Esta carencia no permite realizar una comparativa entre diferentes evaluaciones, sobre todo cuando estas evaluaciones han sido llevadas a cabo por distintos proveedores de seguridad, utilizando distintas técnicas, herramientas, pruebas y criterios. Es fundamental dentro de cualquier modelo de seguridad que los trabajos sean medibles de igual manera y que puedan ser comparados, de manera contraria no se podrá estudiar el grado de evolución real.
Una de las vías de resolver esta problemática es la que propuso MITRE quien desarrolló una serie de estándares que permiten homogeneizar las diferentes debilidades que pueden existir. Por un lado existe la Common Weakness Enumeration, CWE, y la Common Vulnerabilities Exposures, CVE. Este estándar se comentará más en detalle en el siguiente apartado.
Por lo general hay que analizar con el máximo detalle cómo afecta cada una de las vulnerabilidades a las funcionalidades del servicio. Una vez que se haya determinado el número de vulnerabilidades y cuáles son las implicaciones, si se detecta alguna crítica, se debería notificar a la mayor brevedad posible, para proceder a su corrección.
La descripción anterior se encuentra estandarizado por el FIRST, cuyo estándar se puede encontrar en la siguiente URL https://www.first.org/cvss/user-guide
