Hacking y ética, fuga de datos y exposición de vulnerabilidades.

Montevideo, 07 de julio de 2020.

¿Fuga de datos o Hacking? Diferencias.

En la fuga de datos tenemos un incidente donde la información confidencial queda expuesta o es filtrada (robada o copiada). La fuga puede ser producto de falta de controles de seguridad, gestión inadecuada de la información, negligencias administrativas, virus informáticos, entre otros. En el mundo físico esto se puede dar, por ejemplo, al momento de eliminar papelería confidencial de la oficina sin haberla destruido. Si la información sensible está en el basurero y es recuperable, alguien puede acceder a ella y fugar información.

Es por eso que las fugas de información son un diverso grupo de acciones dentro de los incidentes de seguridad que se puede generar por varios vectores o canales.

El caso del hacking suele ser diferente porque, si bien se puede recopilar información de forma pasiva a través de fuentes abiertas (OSINT), por lo general conlleva el compromiso de controles de seguridad.

En el vasto mundo del hacking tenemos categorías y diferentes nombres para quienes actúan en los umbrales de la ética. Por un lado, los llamados “Crackers” son hackers de “Sombrero Negro” (o simplemente ciberdelincuentes): aquellos que violan sistemas de seguridad sin permisos ni autorizaciones, actúan por malicia o beneficio personal. Los hacktivistas, por otra parte, son aquellos cuya motivación no es personal, sino que son movidos por una causa política o incluso altruista. Y finalmente, los Hackers de “Sombrero Blanco” que actúan sin malicia, para poner a prueba sistemas de seguridad movidos por la curiosidad intelectual y el desafío personal.

Esta categorización se basa en la motivación del individuo. Sin embargo, el elemento ético entra en discusión no solo a nivel de la motivación del agente, sino también a posteriori: ¿qué tipo de pruebas se realizan para encontrar una vulnerabilidad?, ¿se explotaron sistemas ajenos y/o cuentas de terceros o se usaron credenciales propias? Si se usaron credenciales propias, ¿se fue más allá del comportamiento “permitido”? Y una vez se encontró un fallo, ¿qué se hizo con dicha información? Evidentemente alguien podría estar motivado por buenas intenciones, pero seguir un comportamiento poco ético.

Tenemos entonces:

1) la intención del individuo,

2) las acciones realizadas para encontrar la vulnerabilidad,

3) la forma en que se divulga dicha información.

Ética Hacker

En el apartado anterior analizamos el aspecto 1) la intención del individuo. Detengámonos ahora en analizar los dos puntos restantes.

En el mundo del hacking es conocido como “Disclosure” el término que hace referencia a la exposición de un problema de seguridad por parte de quien lo encuentra. Hay varias formas de hacer un Disclosure, básicamente se subdividen en “Responsable” y “Total”.

El Full Disclosure o publicación total, conlleva exponer los detalles de la fuga o compromiso de datos sin avisar a las partes afectadas de antemano. Se informa a la comunidad y la misma dispone qué hará con dicha información.

La otra forma de divulgar una vulnerabilidad se conoce como “Responsible Disclosure” o “Limited Disclosure” que sugieren que el investigador informe los datos a la organización responsable del producto vulnerable y luego de un “tiempo prudencial” hacer pública la vulnerabilidad a la comunidad (por ejemplo, a través de un CVE).

La forma en dar a conocer una vulnerabilidad tiene implicaciones éticas: ¿es correcto no dar a conocer a la comunidad una vulnerabilidad si la misma expone datos de terceros y la empresa responsable es indiferente? Si publicamos la vulnerabilidad, ¿no estamos ayudando a que los ciberdelincuentes aprendan de ella y la exploten a su favor? Evidentemente se trata de un trade-off. ¿Y qué consecuencias podría acarrearnos personalmente a nosotros la divulgación de una vulnerabilidad, podríamos enfrentar acciones judiciales? Y si la vulnerabilidad es muy grave, ¿no estaríamos cayendo en una suerte de omisión de asistencia si no la divulgamos o denunciamos?

Si miramos la historia, lo cierto es que las mejoras en el terreno de la seguridad han ido al impulso en gran parte de una política de Full Disclosure, que ha tenido muchos episodios muy poco éticos, pero que ha impuesto costos relevantes a quienes no han valorado la seguridad de sus productos e infraestructura.

En la actualidad, la aparición de programas de “bug bounty” o caza recompensa de errores y vulnerabilidades, los servicios de escaneo de vulnerabilidades y hacking ético, la aplicación de marcos normativos, etc., muestran que el ecosistema empresarial ha ido madurado de modo de internalizar la seguridad como elemento trascendente. Esto implica que el criterio del Responsible Disclosure se impone como más adecuado.

Los hackers ven el mundo de manera diferente a desarrolladores e ingenieros. En lugar de centrarse en cómo funcionan los sistemas, se centran en cómo fallan, cómo se puede hacer que fallen y cómo se puede usar algo de una manera distinta a la que fue prevista. Se trata de una cierta mentalidad.

La mayoría de las vulnerabilidades de software nunca aparecen en las operaciones normales, solo cuando un atacante las explota deliberadamente. El problema se encuentra en que dichas pruebas, por mejor intencionadas, pueden estar infringiendo una ley o bien exponiendo información de terceros. A su vez, los proveedores del producto afectado pueden desestimar una vulnerabilidad (“no es un bug, es una característica”) o afirmar que se trata de algo meramente teórico. En ese caso, el investigador se encuentra con que, si no demuestra que el bug puede ser explotado, no es considerado relevante, pero al explotarlo, ha infringido condiciones de uso. El dilema evidentemente existe.

Parece claro que el comportamiento más recto a seguir es aquel del hacker de sombrero blanco que actúa además bajo autorización de las organizaciones y acuerdos contractuales establecidos. Fuera de ese marco, una actitud que tienda hacia el disclosure responsable parece la mejor opción. Solo si el fabricante o responsable no respondiera de ninguna manera, podría llegar a habilitarse la opción del full disclosure. Además, el investigador debería pensar muy bien qué tipo de pruebas y en qué condiciones está operando. Por mejores intenciones que tenga, puede llegar a afectar a terceros o incluso a sí mismo.

En definitiva, sobre los pilares de la Ética Hacker fundados en el valor de la creatividad, la combinación de la pasión por la libertad y la verdad debemos incorporar los aspectos que hacen al modo de encontrar los fallos y al modo de conducirnos al encontrarlos.

 

Contáctenos

Con gusto los profesionales certificados de Datasec atenderán sus consultas.

Contacto >

Somos una firma presente en el mercado internacional desde 1987, pionera en el área del buen gobierno, aseguramiento, gestión de riesgos, calidad y seguridad en sistemas de la información (TI).

   

Miembro de