Ética profesional y marco legal en ciberseguridad
Objetivos: Al terminar este tema, podrás…
- Defender una posición en un dilema ético real de la profesión y formular el mejor argumento de la posición contraria
- Explicar qué castiga el artículo 269A de la Ley 1273 y reconocer cuándo una conducta cae en él
- Reconocer qué es un dato personal y un dato sensible según la Ley 1581, y qué obligaciones tiene quien los trata
- Identificar los cuatro elementos de una autorización expresa para hacer pruebas de seguridad
- Describir los pasos de la divulgación responsable y el papel de los programas de bug bounty
Apertura: cuatro semanas antes de las elecciones
Eres investigadora de seguridad independiente. Revisando por tu cuenta una copia pública del programa que se usará para transmitir los resultados preliminares de las próximas elecciones en Colombia, encuentras una falla grave: bajo ciertas condiciones, alguien con acceso a la red de transmisión podría alterar las cifras que se publican la noche de las elecciones. Faltan cuatro meses para la votación.
Le escribes a la empresa que desarrolla el programa, describes la falla y le das el plazo de 90 días que usa el equipo Project Zero de Google en su política de divulgación (política de Project Zero). Guardas copia del correo con su fecha. Nadie te responde. Insistes al mes, y a los dos meses, sin respuesta todavía, llevas el caso a ColCERT, el equipo nacional de respuesta a incidentes. ColCERT acusa recibo, te dice que contactará a la empresa y a la organización electoral, y no vuelve a escribirte. Los 90 días se cumplen sin una sola respuesta de la empresa ni noticias de ColCERT, y ahora faltan cuatro semanas para las elecciones.
Tienes dos caminos sobre la mesa, y gente seria defiende cada uno. El primero es publicar ya lo suficiente para que medios, partidos y ciudadanía presionen a la empresa y a las autoridades a corregir la falla antes de la votación, aceptando que alguien podría usar esa información para atacar. El segundo es no publicar nada todavía, aunque el plazo ya se venció: seguir insistiendo en reserva ante ColCERT y la organización electoral, y publicar solo cuando la falla esté corregida o las elecciones hayan pasado, aceptando que el problema podría seguir ahí el día de la votación.
(Escenario ficticio. No describe ninguna falla real ni ningún programa electoral real.)
Debate: publicar ahora o esperar
Ninguna de las dos posiciones del dilema es una caricatura. Publicar pone el riesgo frente a todos y obliga a actuar a quien hasta ahora no ha querido; esperar le da tiempo a quien puede corregir la falla sin entregarle el mapa al atacante. En clase, cuatro grupos defendieron una de las dos sin haberla elegido, y un quinto grupo, como jurado, decidió. El análisis completo de ambas posiciones está en la lectura «Los casos, resueltos», al final de esta página.
Explicación: divulgación responsable y bug bounty
Lo que acabas de defender en el debate tiene nombre. La posición del bando A se conoce como divulgación completa: publicar los detalles de una falla para que la presión pública obligue a corregirla. La del bando B se conoce como divulgación coordinada: trabajar en reserva con quien puede corregir la falla y con quien coordina la respuesta, y publicar cuando ya existe la corrección o cuando el plazo se vence.
Entre las dos se ha formado una práctica que hoy se llama divulgación responsable, y que puedes leer como una secuencia de cinco pasos. Primero documentas la falla con la mínima prueba necesaria para confirmarla, porque cada prueba adicional sobre un sistema ajeno es un acceso más. Después notificas al propietario por escrito y guardas el registro con su fecha, porque ese registro es tu evidencia de buena fe. Luego le das un plazo para corregir. Ese plazo no lo fija ninguna ley: lo fija quien coordina la divulgación. Project Zero, el equipo de Google, da 90 días y publica los detalles 30 días después de que la corrección esté disponible (política de Project Zero); el CERT/CC, el centro de coordinación de la Universidad Carnegie Mellon que conociste en la clase 01, publica por defecto a los 45 días del reporte (política del CERT/CC). Si el propietario no responde, escalas: en Colombia, a ColCERT, el equipo nacional de respuesta a incidentes, y a la SIC si hay datos personales de por medio. Y publicas cuando la falla está corregida o cuando el plazo se venció, lo que ocurra primero. Fíjate en dónde empezó el dilema: la investigadora ya había cumplido los cuatro primeros pasos, y el quinto le decía publicar. Lo que discutieron los dos bandos es si una elección a cuatro semanas justifica apartarse de ese último paso, y esa pregunta no la responde ninguna lista de pasos. Por qué esos dos plazos son distintos, y qué pasa cuando la corrección está a punto de salir, lo encuentras en la lectura «El marco legal en detalle»; el análisis completo del dilema electoral, en «Los casos, resueltos».
Un programa de bug bounty (en español, recompensa por fallas) resuelve desde el otro lado el problema de quien encuentra por su cuenta una falla en un sistema ajeno. En vez de que tú decidas si te arriesgas a probar un sistema ajeno, el propietario publica de antemano qué sistemas se pueden probar, con qué técnicas, cómo se reporta lo que encuentres y cuánto paga por cada falla confirmada. En plataformas como HackerOne las empresas publican sus programas y reciben los reportes. Lo que el programa te da es una autorización por escrito, con alcance, y eso es justamente lo que vas a ver en la ley en unos minutos: fuera del alcance del programa, la autorización desaparece.
Explicación: lo que dice la ley colombiana
Habeas data: el punto de partida
El artículo 15 de la Constitución Política dice que todas las personas tienen derecho «a conocer, actualizar y rectificar las informaciones que se hayan recogido sobre ellas en bancos de datos». Ese derecho tiene nombre propio, habeas data, y la Ley 1581 de 2012 lo convirtió en reglas concretas: puedes pedirle a cualquier empresa o entidad que te muestre qué datos tuyos tiene, que los corrija, que te diga para qué los usa, que te muestre la autorización que le diste y, en ciertos casos, que los borre. Cuando diseñes un sistema que guarda datos de personas, cada uno de esos derechos se vuelve una función que el sistema tiene que poder cumplir.
Ley 1581 de 2012: datos personales
Para la Ley 1581 de 2012, un dato personal es cualquier información que se pueda asociar a una persona concreta, aunque no lleve su nombre: tu cédula, tu dirección, tu número de celular, tu historial de compras o la ubicación de tu teléfono a las ocho de la noche. Dentro de esos datos, la ley separa los datos sensibles, aquellos cuyo mal uso puede llevar a que te discriminen, como tu salud, tu orientación política, tus creencias religiosas o tu huella dactilar, y les exige condiciones más estrictas. Los registros de salud de los pacientes de un grupo como Keralty, cuyo ataque viste en la clase 01, son datos sensibles de manual.
La ley llama titular a la persona a quien pertenecen los datos, responsable a quien decide para qué se usan y encargado a quien los procesa por cuenta del responsable, y se aplica por igual a empresas privadas y a entidades públicas. Tres de sus principios te van a acompañar en cualquier trabajo de seguridad. El de finalidad dice que los datos solo se pueden usar para el propósito que se le informó al titular. El de libertad, que el tratamiento necesita su consentimiento previo, expreso e informado. Y el de seguridad, que quien trata los datos debe protegerlos con medidas técnicas, humanas y administrativas contra la consulta, el uso o el acceso no autorizados.
Cuando esa protección falla y los datos quedan en riesgo, la ley obliga al responsable a informarlo a la Superintendencia de Industria y Comercio (SIC), que es además la autoridad que puede multar hasta con 2.000 salarios mínimos mensuales legales vigentes, suspender el tratamiento o cerrarlo. El salario mínimo mensual legal vigente es el sueldo mínimo que fija el Gobierno cada año, y la ley lo usa como unidad para que las multas suban solas con él: una multa de 2.000 salarios mínimos equivale a lo que ganaría en 2.000 meses una persona con ese sueldo. Los otros cinco principios de la ley, la lista completa de tus derechos y los casos en que no hace falta tu autorización están en la lectura «El marco legal en detalle».
Ley 1273 de 2009: el acceso abusivo
El artículo 269A de la Ley 1273 de 2009 castiga el acceso abusivo a un sistema informático, y vale la pena leerlo despacio porque cada palabra hace trabajo. Comete el delito quien, «sin autorización o por fuera de lo acordado», accede «en todo o en parte» a un sistema informático «protegido o no con una medida de seguridad», o quien «se mantenga dentro del mismo en contra de la voluntad de quien tenga el legítimo derecho a excluirlo». La pena es de 48 a 96 meses de prisión, es decir, de cuatro a ocho años.
Fíjate en tres cosas. La primera es que la ley castiga el acceso y no lo que hagas después: no hace falta robar, borrar ni dañar nada, y por eso «solo miré» no te pone a salvo. La segunda es que el sistema no tiene que estar protegido; que la puerta estuviera abierta no te da permiso de entrar. La tercera es la frase «por fuera de lo acordado», que alcanza también a quien sí tenía permiso pero se salió de él, por ejemplo un profesional que prueba un servidor que no estaba en su contrato o que sigue probando un día después de que venció el plazo.
En la clase 06 usaste la palabra autorización para la tercera pregunta del control de acceso, qué te deja hacer el sistema una vez sabe quién eres. Aquí la misma palabra tiene un sentido legal: el permiso de quien tiene derecho sobre el sistema. Los dos sentidos se separan justo donde aparece el delito, porque un sistema mal configurado puede dejarte hacer algo para lo que nadie te dio permiso.
Esto aplica a ti
Tener la intención de reportar una falla no convierte en autorizado un acceso que no lo estaba. Frases como «solo estaba probando» o «me lo pidió mi jefe» no te protegen de forma confiable ante una investigación, y la responsabilidad penal es personal: no se traslada a quien te pidió hacerlo. Si dudas de si tienes autorización, trata la duda como un no.
Aaron Swartz, leído con el 269A
Entre 2010 y 2011, Aaron Swartz, programador y activista estadounidense del acceso abierto al conocimiento, usó la red abierta para invitados del MIT para descargar de forma automática millones de artículos académicos de JSTOR, una base de datos de pago. Cuando el MIT y JSTOR detectaron el volumen y bloquearon su equipo, Swartz cambió la identificación de su computador en la red para seguir conectado, y más tarde dejó un portátil descargando dentro de un cuarto de red en el sótano de uno de los edificios del MIT. Aunque JSTOR llegó a un acuerdo con él y no lo demandó, y el MIT se declaró neutral, la fiscalía federal de Estados Unidos lo acusó de todos modos, con cargos que sumaban hasta 35 años de prisión. Swartz se quitó la vida en enero de 2013, antes del juicio. Tenía 26 años. (Fuentes: informe del MIT, «MIT and the Prosecution of Aaron Swartz»; Aaron Swartz (Wikipedia).)
Lee el caso con el 269A en la mano. Swartz tenía acceso a la red: cualquier invitado lo tenía. Lo que no tenía era permiso para descargar la base de datos entera, y menos aún para volver a entrar después de que lo bloquearon. Esa segunda parte se parece mucho a lo que el artículo describe como mantenerse dentro de un sistema «en contra de la voluntad de quien tenga el legítimo derecho a excluirlo». Que una conducta así fuera delito en Colombia lo decidiría un juez, pero la pregunta que te deja el caso es exacta: tener acceso a un sistema no es lo mismo que estar autorizado para lo que haces en él. La historia completa del caso está en la lectura «Los casos, resueltos».
Para pensar
Separa la conducta de Swartz en tres momentos: conectarse a la red de invitados, descargar millones de artículos y volver a conectarse con otra identificación después del bloqueo. ¿Cuál de las frases del 269A le correspondería a cada momento, si alguna? ¿En cuál de los tres te parece más difícil sostener que había autorización?
La autorización expresa
Las herramientas que usa un profesional para probar la seguridad de un sistema son las mismas que usa un atacante, y lo único que separa una prueba de un delito es la autorización. Por eso, antes de tocar un sistema ajeno, el profesional firma con el cliente un documento que fija las reglas de la prueba, conocido en el oficio por su nombre en inglés, Rules of Engagement (reglas de enfrentamiento). Ese documento tiene que resolver cuatro cosas. La primera es quién autoriza: la firma debe ser de quien tiene derecho sobre el sistema, y si tu jefe o tu contacto no es el propietario, su permiso no basta. La segunda es el alcance: qué sistemas y qué técnicas se pueden usar y cuáles quedan excluidos, porque probar algo fuera de esa lista es actuar «por fuera de lo acordado». La tercera es la ventana de tiempo: fechas y horas, porque una prueba un día después del plazo ya no tiene permiso. La cuarta es el manejo de hallazgos: qué haces con lo que encuentres, quién lo puede ver y a quién se lo reportas, que importa todavía más cuando el sistema guarda datos sensibles.
Los otros delitos de la Ley 1273
El 269A es el delito que más te importa como profesional, pero la Ley 1273 define otros, entre ellos el daño informático (269D), el uso de software malicioso (269E) y la violación de datos personales (269F). En 2015, Andrés Sepúlveda, conocido en los medios como «el hacker», fue condenado a diez años de cárcel tras un preacuerdo con la Fiscalía (un acuerdo en el que el acusado acepta los cargos a cambio de una pena menor) en el que aceptó, entre otros, los delitos de acceso abusivo a un sistema informático, uso de software malicioso agravado y violación de datos personales agravado (agravado quiere decir con la pena aumentada por alguna de las circunstancias que la ley enumera y que encontrarás en la lectura), por las interceptaciones ilegales contra los negociadores del proceso de paz (El Colombiano, 10 de abril de 2015). La tabla completa de delitos y penas, y los agravantes, están en la lectura «El marco legal en detalle».
Aplicación: cinco casos, cinco veredictos
Los cinco casos que siguen ponen a prueba lo que acabas de ver sobre el artículo 269A, la Ley 1581 y la autorización expresa. Todos son ficticios. En clase cada grupo trabajó uno; el razonamiento completo de cada caso está en la lectura «Los casos, resueltos».
Caso 1 — El número en la dirección
Entras a la app web de tu banco para pagar una factura y, al copiar la dirección, te equivocas en un dígito del número que va después de id=. Aparece la cuenta de otra persona, con nombre, saldo y movimientos. Ya sabes, por la clase 05, que eso es control de acceso roto. Para confirmar que no fue casualidad, cambias el número dos veces más y ves dos cuentas más. Ahora quieres avisarle al banco. (Caso ficticio.)
Caso 2 — Dos semanas en la empresa
Llevas dos semanas en tu primer trabajo, en una empresa de pagos por celular. Descubres dos cosas. La primera: las contraseñas de los usuarios están guardadas tal cual las escribieron, sin ningún hash, y cualquiera con acceso a la base de datos puede leerlas (en la clase 08 viste por qué eso es grave). La segunda: la empresa vende a una agencia de publicidad el historial de compras de sus usuarios, y eso no aparece en lo que los usuarios aceptaron al registrarse. Tu jefe te dice que lo primero «está pendiente» y que lo segundo «es decisión del negocio». (Caso ficticio.)
Caso 3 — La prueba de la entrevista
Al final de una entrevista de trabajo en una empresa de ciberseguridad, el reclutador te dice: «Como prueba técnica, encuentra una vulnerabilidad en el sitio web de nuestra competencia. Tienes 48 horas. Nosotros te autorizamos.» (Caso ficticio.)
Caso 4 — El correo de la clínica
Tu empresa recibe este correo del jefe de sistemas de una clínica: «Hola, prueben lo que quieran de nuestra página esta semana. Cualquier cosa me avisan por WhatsApp.» Tu compañero quiere empezar hoy mismo. (Caso ficticio.)
Caso 5 — Fuera del programa
Una tienda en línea tiene un programa de bug bounty que dice: «Alcance: app.tienda.co. Todo lo demás está excluido.» Mientras pruebas app.tienda.co, encuentras un enlace a admin.tienda.co, que muestra una pantalla de acceso. Pruebas el usuario admin con la contraseña admin «solo para confirmar» y entras. (Caso ficticio.)
Cierre: la autorización como frontera
Al principio de la clase, cuatro grupos defendieron una posición que no eligieron, y el jurado decidió. Ahora tienes el lenguaje para leer esa decisión. Si el jurado ordenó publicar ya, optó por una divulgación completa con un plazo ya vencido. Si ordenó mantener la reserva hasta que la falla se corrija o pasen las elecciones, optó por una coordinada que se extiende más allá del plazo mientras ColCERT y la organización electoral actúan. Y si decidió algo intermedio, como esperar solo hasta una nueva fecha cercana o publicar ya el riesgo sin el paso a paso del ataque, combinó las dos: siguió coordinando, pero con una fecha límite y con la publicación como presión. En ninguno de esos casos nadie tuvo que entrar a un sistema sin permiso, y esa es la frontera que atraviesa toda la clase. Una regla sencilla te sirve para no cruzarla: si tienes que preguntarte si tienes autorización, trata la respuesta como un no hasta tenerla por escrito. Los términos de la clase, con su definición corta, quedan reunidos en «Conceptos clave», al final de la página.
Principio fundamental
Capacidad técnica ≠ Derecho ético ni legal. Saber cómo entrar a un sistema no te da permiso de entrar, y la diferencia entre las dos cosas es exactamente lo que vas a firmar en cada trabajo.
Para cerrar
Vuelve al veredicto del jurado de tu clase. Si en vez de cuatro semanas faltaran cuatro días para las elecciones, ¿qué parte del veredicto cambiaría y cuál se mantendría? Usa al menos uno de los cinco pasos de la divulgación responsable en tu respuesta.
Lectura disponible — El marco legal en detalle
El artículo 15 completo
En clase leíste solo la frase del artículo 15 que funda el habeas data. El texto completo del artículo de la Constitución Política dice:
«Todas las personas tienen derecho a su intimidad personal y familiar y a su buen nombre, y el Estado debe respetarlos y hacerlos respetar. De igual modo, tienen derecho a conocer, actualizar y rectificar las informaciones que se hayan recogido sobre ellas en bancos de datos y en archivos de entidades públicas y privadas. En la recolección, tratamiento y circulación de datos se respetarán la libertad y demás garantías consagradas en la Constitución. La correspondencia y demás formas de comunicación privada son inviolables. Sólo pueden ser interceptadas o registradas mediante orden judicial, en los casos y con las formalidades que establezca la ley. Para efectos tributarios o judiciales y para los casos de inspección, vigilancia e intervención del Estado podrá exigirse la presentación de libros de contabilidad y demás documentos privados, en los términos que señale la ley.»
Fíjate en que el mismo artículo protege la información guardada en bases de datos y la comunicación privada. Por eso interceptar una conversación sin orden judicial, como en el caso Sepúlveda, toca a la vez la Constitución y la Ley 1273.
Los delitos de la Ley 1273 y sus penas
La tabla que sigue no está pensada para que la memorices, sino para que sepas que el acceso abusivo rara vez viene solo: un ataque real suele encajar en más de uno de estos delitos, como pasó con Sepúlveda, que aceptó tres de ellos en su preacuerdo, y la pena de cada uno puede subir hasta en tres cuartas partes cuando el sistema es del Estado o de un banco, o cuando quien lo comete es el empleado en quien la empresa confiaba. Las penas están tomadas del texto oficial de la Ley 1273 de 2009.
| Artículo | Delito | Pena de prisión |
|---|---|---|
| 269A | Acceso abusivo a un sistema informático | 48 a 96 meses |
| 269B | Obstaculización ilegítima de sistema informático o red de telecomunicación | 48 a 96 meses |
| 269C | Interceptación de datos informáticos | 36 a 72 meses |
| 269D | Daño informático | 48 a 96 meses |
| 269E | Uso de software malicioso | 48 a 96 meses |
| 269F | Violación de datos personales | 48 a 96 meses |
| 269G | Suplantación de sitios web para capturar datos personales | 48 a 96 meses |
| 269I | Hurto por medios informáticos y semejantes | Las del hurto calificado (Art. 240 del Código Penal) |
| 269J | Transferencia no consentida de activos | 48 a 120 meses |
Además de la prisión, casi todos estos artículos imponen una multa expresada en salarios mínimos mensuales legales vigentes.
El artículo 269H enumera las circunstancias que agravan cualquiera de estos delitos, y en ellas la pena aumenta «de la mitad a las tres cuartas partes». Ocurre cuando la conducta se comete sobre sistemas estatales u oficiales o del sector financiero, nacionales o extranjeros; cuando la comete un servidor público en ejercicio de sus funciones; cuando se aprovecha la confianza que depositó en el autor el poseedor de la información o alguien con quien tenía un vínculo contractual; cuando se revela o da a conocer la información en perjuicio de otro; cuando el autor obtiene provecho para sí o para un tercero; cuando se hace con fines terroristas o generando riesgo para la seguridad o la defensa nacional; cuando se usa como instrumento a un tercero de buena fe; y cuando la comete quien es responsable de administrar, manejar o controlar esa información, a quien además se le puede prohibir hasta por tres años ejercer profesiones relacionadas con sistemas de información. Observa que la lista no habla de «infraestructura crítica» en general: nombra sistemas del Estado y del sector financiero, y pone mucho peso en la confianza. El empleado que abusa de su acceso, el insider que viste en la clase 03, cae de lleno en ella.
Por qué «no sabía» no es una defensa confiable
Los delitos de la Ley 1273 exigen intención: la ley castiga a quien accede sabiendo que no tiene permiso, no a quien cae en una página por un error de dedo. El Código Penal reconoce además situaciones en las que una persona actuó equivocada sobre los hechos o cumpliendo una orden, y en ciertos casos eso puede excluir o reducir su responsabilidad. El problema práctico es que esas situaciones hay que probarlas ante un juez, y difícilmente cubren a quien siguió adelante después de darse cuenta de que estaba en un sistema ajeno. Quien cambia el número de la dirección una segunda vez ya no se equivocó, y quien prueba el sitio de la competencia porque se lo pidió un reclutador sabía que el reclutador no era el dueño. Por eso el consejo de la clase sigue en pie: la intención de ayudar no reemplaza a la autorización, y la duda se trata como un no.
La Ley 1581 en detalle
La Ley 1581 de 2012 tiene ocho principios en su artículo 4. Además de los de finalidad, libertad y seguridad que viste en clase, está el de legalidad, según el cual el tratamiento de datos es una actividad regulada que debe seguir la ley; el de veracidad o calidad, que exige que los datos sean ciertos, completos y actualizados, y prohíbe tratar datos parciales que lleven a error; el de transparencia, que le garantiza al titular saber en cualquier momento qué datos suyos existen; el de acceso y circulación restringida, según el cual los datos solo pueden llegar a las personas autorizadas y no pueden quedar publicados en internet sin control; y el de confidencialidad, que obliga a guardar reserva a todas las personas que intervienen en el tratamiento, incluso cuando ya terminó su relación con él.
Tus derechos como titular, en el artículo 8, van más allá de conocer, actualizar y rectificar. Puedes pedir prueba de la autorización que diste, ser informado del uso que se les da a tus datos, presentar quejas ante la SIC, revocar la autorización o pedir que se borren tus datos cuando no se respetan los principios de la ley, y consultar gratis tus datos.
La autorización del titular es la regla, pero el artículo 10 enumera los casos en que no hace falta: cuando una entidad pública o administrativa pide la información en ejercicio de sus funciones legales o por orden judicial; cuando se trata de datos de naturaleza pública; en casos de urgencia médica o sanitaria; cuando la ley autoriza el tratamiento para fines históricos, estadísticos o científicos; y cuando los datos tienen que ver con el registro civil de las personas. Fuera de esas excepciones, vender el historial de compras de un usuario sin que él lo haya aceptado no tiene ningún respaldo.
Las sanciones del artículo 23, que impone la SIC, son cuatro: multas hasta por 2.000 salarios mínimos mensuales legales vigentes, suspensión de las actividades de tratamiento hasta por seis meses, cierre temporal de las operaciones relacionadas con el tratamiento y, cuando se trata de datos sensibles, cierre inmediato y definitivo de la operación.
Los plazos de divulgación en detalle
Los dos plazos que viste en clase responden a filosofías distintas. Project Zero da 90 días para corregir y espera 30 días más después de que la corrección esté disponible antes de publicar los detalles técnicos, para que los usuarios alcancen a instalarla; si el fabricante avisa que la corrección está a punto de salir, concede un periodo adicional de 14 días (política de Project Zero). El CERT/CC, que coordina entre muchos fabricantes a la vez, publica por defecto a los 45 días del reporte, y puede ajustar ese plazo según el caso (política del CERT/CC). Que existan plazos distintos confirma lo que mostró el debate: el plazo no es una regla moral fija, sino un instrumento para que la falla se corrija sin dejar indefinidamente expuestas a las personas que dependen del sistema.
Lectura disponible — Los casos, resueltos
El dilema electoral, desde las dos posiciones
El dilema no tiene una respuesta limpia porque los dos caminos exponen a las mismas personas a dos daños distintos. Publicar antes de que exista una corrección abre la posibilidad de que alguien use la falla justo en el momento de mayores consecuencias, y además puede sembrar una sospecha de fraude que dañe la confianza en la elección aunque nadie llegue a atacar. No publicar deja la falla donde está y, si alguien más ya la encontró, la deja en manos de quien no va a avisar a nadie.
El plazo de 90 días existe para obligar al fabricante a corregir, y en este caso ya se cumplió sin respuesta, después de que la investigadora escalara a ColCERT. Siguiendo los pasos al pie de la letra, tocaría publicar. Lo que el plazo no contempla es que el sistema afectado sea una elección nacional a cuatro semanas de distancia. El silencio de ColCERT admite dos lecturas: que nadie está actuando, o que está coordinando con la empresa y la organización electoral sin informar a quien reportó, algo frecuente cuando la respuesta involucra a varias entidades. Por eso una salida razonable es no publicar todavía, insistir ante ColCERT y escribir directamente a la organización electoral, que tiene sobre la empresa una autoridad que la investigadora no tiene, pero fijando una nueva fecha límite cercana y comunicándola, para no esperar en silencio indefinidamente. La ventaja de ese camino no es que deje más tiempo para corregir, porque el tiempo es el mismo, sino que la presión coordinada de quien puede exigir puede mover más rápido a una empresa que una publicación unilateral. El giro del foro cambia el cálculo solo en la medida en que el mensaje sea creíble, y nadie puede verificarlo: puede ser la misma falla, otra o una estafa. Si fuera real, el argumento de no entregar la idea al atacante perdería fuerza, porque alguien ya la tendría, y ganaría la urgencia de avisar a quienes podrían protegerse. Real o no, el mensaje es un dato que ColCERT y la organización electoral deberían conocer. Y si se llega a publicar, qué se publica pesa tanto como cuándo: describir el riesgo y las medidas de protección no es lo mismo que publicar el paso a paso del ataque.
El razonamiento de cada caso
Caso 1, el número en la dirección. Al copiar la dirección del banco te equivocaste en un dígito y luego cambiaste el número dos veces más.
Caso 1: el razonamiento
La primera consulta fue un error tuyo al copiar la dirección, y por eso es la más difícil de reprochar: no la buscaste. La segunda y la tercera ya fueron decisiones. Entraste a dos cuentas ajenas sabiendo que no eran tuyas, y el 269A castiga justamente el acceso «sin autorización», aunque no te lleves nada y aunque tu intención sea avisar. Lo que puedes hacer ahora es escribirle al banco por su canal oficial describiendo lo que observaste, que el número de la dirección parece dar acceso a cuentas de otros clientes, sin adjuntar los datos que viste y sin volver a probar. Guarda copia del mensaje con su fecha. Si el banco no responde, el siguiente paso es ColCERT, y como hay datos personales de por medio, la SIC.
Caso 2, dos semanas en la empresa. Contraseñas guardadas sin hash y venta del historial de compras sin autorización de los usuarios.
Caso 2: el razonamiento
Los dos problemas son violaciones de la Ley 1581, pero de principios distintos. Guardar las contraseñas tal cual las escribió el usuario incumple el principio de seguridad, porque cualquiera con acceso a la base de datos puede leerlas; en la clase 08 viste que lo correcto es guardar un hash lento y con salt. Vender el historial de compras sin que los usuarios lo hayan aceptado incumple los principios de finalidad y de libertad: los datos se recogieron para otra cosa y nadie dio su consentimiento para esa venta. Ninguno de los dos es una simple «decisión del negocio».
Conviene separar lo que obliga a la empresa de lo que puedes hacer tú. La empresa, como responsable del tratamiento, debe corregir las dos cosas y, si los datos llegan a quedar en riesgo, informarlo a la SIC. Tú no eres el responsable, pero estás en la posición de quien decide si es cómplice o no. Lo razonable es dejar por escrito lo que viste y lo que dijo tu jefe, escalar a quien en la empresa responda por la protección de datos, buscar asesoría legal si nadie actúa y, si el problema sigue, acudir a la SIC, que es la autoridad que vigila el cumplimiento de la ley y recibe quejas. Renunciar puede ser una decisión personal legítima, pero no corrige nada para los usuarios cuyos datos siguen expuestos.
Caso 3, la prueba de la entrevista. Un reclutador te autoriza a atacar el sitio de su competencia.
Caso 3: el razonamiento
El permiso para probar un sistema solo lo puede dar quien tiene derecho sobre ese sistema. La empresa del reclutador no tiene ningún derecho sobre el sitio de su competencia, así que su «nosotros te autorizamos» no vale nada ante el 269A: si haces la prueba, accedes «sin autorización», sin importar quién te lo pidió, y la responsabilidad es tuya. Lo correcto es declinar con educación y explicar por qué. El pedido, además, te dice mucho sobre cómo opera esa empresa.
Caso 4, el correo de la clínica. Un jefe de sistemas autoriza por correo «lo que quieran» durante una semana.
Caso 4: el razonamiento
El correo sí expresa una intención de permitir pruebas, pero no resuelve casi ninguno de los cuatro elementos de una autorización expresa. No se sabe si el jefe de sistemas tiene derecho a autorizar en nombre de la clínica o si esa decisión le corresponde a la dirección. «Lo que quieran de nuestra página» no es un alcance: no dice qué sistemas, qué técnicas ni qué queda excluido. «Esta semana» es una ventana vaga, sin fechas ni horas. Y «me avisan por WhatsApp» no es un manejo de hallazgos: no dice quién puede ver lo que encuentren, cómo se guarda ni a quién se reporta.
Ese último vacío es el más grave, porque una clínica guarda datos de salud, que son datos sensibles. Antes de empezar, tu empresa necesita un documento de Rules of Engagement firmado por quien tenga autoridad sobre los sistemas de la clínica, con los sistemas y técnicas permitidos, las fechas y horas exactas, y un procedimiento escrito para tratar cualquier dato de pacientes que aparezca durante la prueba.
Caso 5, fuera del programa. Un programa de bug bounty que solo cubre app.tienda.co y un acceso a admin.tienda.co.
Caso 5: el razonamiento
El programa de bug bounty es una autorización por escrito, pero con alcance: cubre
app.tienda.coy excluye todo lo demás. Encontrar el enlace aadmin.tienda.cono es un problema; entrar conadmin/adminsí lo es, porque ese sistema está fuera del alcance y probarlo es actuar «por fuera de lo acordado», que el 269A castiga igual que no tener permiso. Que la intención fuera «solo confirmar» no cambia nada, como en el caso 1. Lo correcto era reportar al programa la existencia del panel y que parecía aceptar contraseñas débiles, sin entrar, o preguntar antes si ese sistema estaba dentro del alcance.
El caso Aaron Swartz completo
Este caso termina con la muerte de su protagonista. Si el tema te toca de cerca, habla con alguien de confianza o con el área de bienestar de la universidad.
Aaron Swartz era, antes del caso JSTOR, una figura conocida en el mundo del software. A los 14 años participó en el diseño de RSS, un formato que permite a un programa recibir automáticamente las novedades de un sitio web sin tener que visitarlo. Contribuyó en los inicios de Reddit, trabajó con Creative Commons, una organización que creó licencias para que los autores compartan su obra con permisos más abiertos que los del derecho de autor tradicional, y fue una de las voces de la campaña contra SOPA, un proyecto de ley estadounidense de 2011 que buscaba combatir la piratería y que sus críticos consideraban una forma de censura en internet. En el momento de los hechos era investigador asociado de un centro de ética de la Universidad de Harvard, no del MIT.
Swartz fue arrestado el 6 de enero de 2011. En 2012, la fiscalía amplió la acusación con nuevos cargos bajo la ley federal estadounidense de fraude y abuso informático, y el máximo teórico de prisión subió a unos 50 años. JSTOR había llegado a un acuerdo con él y no tenía interés en que el proceso siguiera. El MIT, en cambio, se mantuvo neutral: no pidió que lo acusaran, pero tampoco pidió que retiraran los cargos. Swartz murió el 11 de enero de 2013, antes del juicio.
Después de su muerte, el MIT encargó un informe sobre su propio papel en el caso. El informe concluyó que la universidad no había buscado el castigo de Swartz, pero reconoció que su postura neutral no tuvo en cuenta todo lo que estaba en juego para una institución que defiende el conocimiento abierto (informe del MIT). El caso abrió un debate que sigue vivo sobre la proporcionalidad: si las penas de las leyes de delitos informáticos, pensadas para atacantes que roban o destruyen, son razonables para alguien que descargó artículos académicos con fines de acceso abierto (Aaron Swartz (Wikipedia)). En la taxonomía de la clase 03, su caso suele leerse como hacktivismo, y muestra que la motivación no cambia la pregunta legal de fondo: si había autorización para lo que hizo.
El caso Sepúlveda
En abril de 2015, Andrés Sepúlveda fue condenado a diez años de cárcel tras un preacuerdo con la Fiscalía, en el que aceptó, entre otros, los delitos de acceso abusivo a un sistema informático, uso de software malicioso agravado y violación de datos personales agravado. Los hechos estaban relacionados con interceptaciones ilegales contra los negociadores del proceso de paz entre el Gobierno y las FARC (El Colombiano, 10 de abril de 2015). Es un ejemplo de cómo un solo caso real encaja a la vez en varios artículos de la Ley 1273, y de cómo los agravantes del artículo 269H se aplican en la práctica.
Lectura disponible — Conceptos clave
| Término | Definición |
|---|---|
| Habeas data | Derecho constitucional a controlar información personal |
| 2009 | Ley colombiana de delitos informáticos |
| 2012 | Ley colombiana de protección de datos personales |
| Divulgación responsable | Proceso de reportar vulnerabilidades dando tiempo para corrección |
| Rules of Engagement | Documento que fija quién autoriza, qué se puede probar, cuándo y qué se hace con los hallazgos |
| SIC | Autoridad de protección de datos en Colombia |
| Art. 269A (acceso abusivo) | Delito de acceder a un sistema informático sin autorización o por fuera de lo acordado, o de mantenerse en él contra la voluntad de quien puede excluirte |
| Dato personal | Cualquier información que se pueda asociar a una persona determinada o determinable |
| Dato sensible | Dato personal cuyo mal uso puede generar discriminación, como la salud, la orientación política o los datos biométricos |
| Autorización expresa | Permiso escrito de quien tiene derecho sobre un sistema, con alcance, ventana de tiempo y manejo de hallazgos definidos |
| Bug bounty | Programa en el que el propietario de un sistema autoriza de antemano pruebas con alcance definido y paga por las fallas confirmadas |
| Divulgación completa / coordinada | Publicar los detalles de una falla para forzar su corrección, frente a trabajar en reserva con quien puede corregirla y publicar después |
Los criterios de la entrega final del semestre están en la evaluación final.