La guía del "grey hat" de la EFF [traduccion]

Encontre un_documento_de_la_EFF hasta el que llegue a través de el de "derechos_del_programador" (muy recomendable, por cierto) que puede resultar interesante para quién sin querer se pudo meter en problemas o simplemente tiene dudas sobre como avisar sobre vulnerabilidades y supuse que a alguien le puede parecer interesante, así que aquí va la traducción. Por cierto, esto gira en torno a las leyes en los EEUU, pero al fin y al cabo hoy en día en este mundillo son las que se acaban imponiendo, sin más...
Un/a investigador/a de seguridad informática que ha violado la ley
durante su investigación se enfrenta a un dilema al pensar si debe
notificar a la compañía del problema que descubrió en uno de los
productos de esa compañía. Al reportar el fallo de seguridad, el/la
investigador/a revela que puede haberr cometido una actividad ilegal,
lo que puede invitar a la denuncia o investigación criminal. Por
otro lado, ocultar la informacion significa que un fallo de seguridad
potencial puede que no se arregle.

No hay respuestas fáciles para el/la hacker ético que se alejo  
demasiado hacia el arbusto legal (legal thicket) de las leyes de  
delitos informaticos. Entre las opciones poco deseables, el/la hacker  
ético puede escojer reconstruir su investigación usando software,  
dispositivos y redes a las que tiene acceso autorizado y avisar una  
vez teniendo las manos lavadas con la reconstrucción del  
descubrimiento. Además puede escojer avisar del fallo en términos  
generales que identifican el problema, sin revelar el camino  
comprometido de la investigación que usó para descubrirlo. Ninguna  
opción protege perfectamente al/a la investigador a la vez que  
asegura que el problema se arreglará. Sin embargo uno u otro pueden  
ser mejores que malas elecciones.

A pesar del valor que los/las profesionales de seguridad informática  
proveen probando software y redes en busca de vulnerabilidades, las  
actividades de investigación pueden violar cierto número de  
complicadas u obscuras regulaciones y estatutos. Esas leyes incluyen:

* Computer Fraud and Abuse Act  
* Anti-Circumvention Provisions of the DMCA  
* Copyright law  
* Otras leyes estatales e internacionales

El Acta de fraudes y abuso de computadores (Computer Fraud and Abuse  
Act) prohibe el acceso sin autorización a ordenadores. Los/las  
investigadores/as que realizan pruebas en sistemas que no les  
pertenecen están reñidos con esta ley. Por otra parte, la ley se ha  
utilizado mal al perseguir el uso de servicios de ordenadores con la  
violación de los términos de servicio1 e incluso el acto del aviso  
de vulnerabilidades en si.2

Las previsiones contra la circumvención del Digital Millennium  
Copyright Act crean un potencial obstáctulo legal para un/  
a investigador que estudie los mecanismos que controlan la forma en  
el que se puede acceder a software o otros materiales con copyright o  
usarlos, o software protegido con eso mecanismo. Litigantes  
potenciales han invocado las previsiones contra la circunvención no  
solo donde concierne a los tradicionales “digital rights  
management” (DRM), si no tambien en casos que involucran la  
ingeniería inversa de un protocolo sin documentar.

La ley de copyright de los U.S. regula las copias hechas durante la  
ingeniería inversa. Algunos estados y otros países tienen sus  
propias leyes de crimen con ordenadores, y los/las investigadores/as  
dificilmente pueden esperar conocerlas todas. Por ejemplo, los  
Estados Unidos persiguieron a Dmitry Sklyarov y a la compañía rusa  
Elcomsoft bajo el DMCA por crear un lector para los eBooks de Adobe.  
El producto no viola ninguna ley rusa.

Como el régimen regulatorio es complicado y no-intuitivo, los/las  
investigadores/as de seguridad pueden tener más razones para  
preocuparse por retos legales que otros cientificos/as.  
Potencialmente, un/a investigador/a puede violar desintencionadamente  
la ley a través de la ignorancia o el entusiasmo mal enfocado, o una  
parte afectada puede estirar o malusar la ley para desafiar a la  
investigación que presentan sus productos o servicios bajo un  
enfoque negativo.

Por eso recomendamos que los/as investigadores/as de seguridad  
consulten a un avogado antes de una investigación potencialmente  
arriesgada. Un buen avogado puede ayudarle a evitar las trampas  
legales comunes y si identifica los riesgos legales por adelantado,  
puede que sea capaz de ajustar su plan de investigación para mitigar  
o evitar completamente los problemas.

El/la investigador/a se encuentra en un dilema cuando ha roto  
potencialmente la ley, pero nunca pensado robar información o  
invadir la privacidad y quiere ver el problema arreglado. Reportar la  
información levanta sospechas que pueden resultar en una  
investigación y demandas civiles o incluso cargos criminales.  
Mantenerse callado significa que el error quedará sin arreglar y  
será potencialmente explotado por alguien con intenciones  
criminales. ¿Que debe hacer el hacker de sobrero gris?

Algunas compañías han aclarado que generalmente no toman acciones  
legales si una persona no maliciosa les llama la atención sobre  
vulnerabilidades, sin tener en cuenta como se encontro el fallo.  
Compañías que tratan frecuentemenete con vulenerabilidades suelen  
ser las más abiertas y se toman mejor los tropiezos de los/as  
investigadores/as. Ya lo han visto antes, quieren mejorar sus  
productos, y no quieren la mala prensa que viene al demandar a  
hackers con buenas intenciones. Compañías que ganan su dinero de  
otras formas que no son la distribución de software suelen ser  
nuevos en el juego del aviso de vulnerabilidades. Son estas  
compañías las que entran en pánico con más facilidad,  
sobrereaccionar y sacar al avogado cuando se entfrentan con  
información sobre vulnerabilidades en el producto. Para el/la  
investigador/a, esto suele significar suponer sobre la reacción de  
la parte a la que va dirigida el aviso.

Para moderar el riesgo legal, los/as investigadores/as pueden  
considerar el usar un intermediario que se ponga en medio. En casos  
anteriores, un/a investigador/a le dió la información sobre la  
vulnerabilidad a un avogado o periodista y le pidió que le diese la  
información al vendedor. Otros/as investigadores/as que han  
considerado dar una charla en una conferencia de seguridad y pedir al  
comité de selección una aproximación al vendedor, o incluso vender  
la información de la vulnerabilidad a una compañía agente  
(brokering company) que desvelará la vulnerabilidad al vendedor, y  
entonces a sus clientes, y finalmente al público. Sin embargo,  
ninguna de estas posibilidades es una solución perfecta. Cada  
aproximación presenta el riesgo de que un vendedor enfadado intente  
descubrir la identidad del/la investigador/a a través del  
intermediario. Ni la conferencia, ni los agentes de vulnerabilidades  
tienen ningún privilegio legal para negarse a desvelar la identidad  
del/la investigador si un tribunal cree que es requerido para un  
proceso legal. Los/as periodistas no tienen ese privilegio bajo  
precedente en la Corte Suprema de los Estados Unidos aunque pueden  
tenerlas bajo las reglas de algunas cortes bajas o la lay estatal.  
Los avogados tienen el derecho más fuerte a negarse a proveer  
identificación de información bajo el privilegio avogado-cliente,  
pero no está claro si la identidad del cliente es información  
protegida para todos los propósitos.

El/la investigador/a puede considerar recurrir al cifrado para  
ocultar su identidad al avisar de detalles importantes a las partes  
afectadas. El anonimato puede exacerbar algunos de los problemas  
comunes para los/as que avisan de vulnerabilidades, como ser tomados/  
as en serio, pero el problema particular para el hacker de sombrero  
gris es dar demasiada información sobre la investigación sin  
señalar ningun rastro de evidencias que de información suficiente  
que revele el delito y la identidad real del/la investigador/a. Por  
esto los/as investigadores/as quizá quieran recrear el  
descubrimiento del fallo usando solo software, dispositivos y redes  
que le pertenezcan o que tenga permiso para usar, y reportar el  
"descubrimiento". Alternativamente, el/la investigador/a puede tener  
que dejarse detalles que podrían en efecto servir como un rastro de  
migas de pan que llevan a su puerta, y esperar que la información es  
suficiente para notificar, informar y asistir a las partes afectadas  
a arreglar el problema.

Cualquiera que sea el curso que tome el/la investigador/a, se expone  
en el interes de mejorar la seguridad para el público. Una solución  
más completa sería hacer más claras y más limitadas las leyes de  
crimen por ordenador. El objetivo es dejar margen para la  
investigación de seguridad legítima y darle a los/as investigadores  
que ayudan a proteger nuestra propiedad y privacidad digital unas  
guías claras para sus actividades científicas y innovadoras. Esto  
es mucho mejor permitir que la investigación de seguridad florezca  
en una atmósfera de regulación ligera, que intentar castigar  
ataques criminales después de que ocurran con leyes draconianas y  
confusas. Mientrastanto, sin embargo, las mejoras de seguridad  
dependerán a veces en la disposición de los/as investigadores/as a  
aceptar el riesgo a ser demandados/as.

Fuente: https://www.eff.org/issues/coders/grey-hat-guide

La traducción, como el documento original está bajo licencia CC-by_3.0, siendo el autor original la Electronic_Frontier_Foundation.

untagged

Pywc 0.4 » « Un bot para probarlos a todos (trampeando en RTB)