Ética profesional y marco legal en ciberseguridad
Objetivos: Al terminar este tema, podrás…
- Razonar sobre dilemas éticos reales sin respuestas fáciles
- Interpretar la legislación colombiana de delitos informáticos y protección de datos
- Identificar los límites legales en actividades de seguridad ofensiva
- Gestionar responsablemente la divulgación de vulnerabilidades
Antes de cualquier teoría: un escenario
Estás pagando una factura en la app web de tu banco. Mientras navegas, notas que las URLs tienen esta estructura:
https://banco.com/cuenta/estado?id=482931
Por curiosidad, cambias el número. Aparece la información de otra persona: nombre, saldo, movimientos. Cambias el número otra vez. Otra persona. El patrón es claro: cualquier cliente puede ver la cuenta de cualquier otro cliente con solo cambiar un número.
Pausa para reflexionar
Antes de seguir leyendo: ¿qué harías tú en este momento? Piénsalo en serio. ¿Qué harías realmente, no qué es lo que crees que se supone que debes decir?
Guarda tu respuesta en mente. Volvemos a este escenario más adelante.
El poder que vas a tener
Como ingeniero de ciberseguridad, vas a tener acceso a cosas que la mayoría de las personas ni sabe que existen. Vas a entender cómo funcionan los sistemas que guardan historiales médicos, movimientos bancarios, conversaciones privadas. Vas a saber cómo entrar a lugares donde no deberían entrar. Esa es exactamente la habilidad por la que te van a contratar.
El problema es que esa misma habilidad no viene con un interruptor que solo funciona cuando es “para bien”. Las herramientas de un pentester y las de un atacante son las mismas. La diferencia no está en el código, está en cuatro preguntas:
- ¿Tienes permiso explícito? No implícito, no asumido — explícito y documentado.
- ¿Estás dentro del alcance acordado? El permiso para probar el servidor web no es permiso para probar la base de datos.
- ¿Tu objetivo es proteger o dañar? Suena obvio. No siempre lo es.
- ¿Tu acción es legal? La intención no reemplaza al marco legal.
Principio fundamental
Capacidad técnica ≠ Derecho ético ni legal. Lo que puedes hacer y lo que debes hacer son preguntas completamente distintas.
Cuatro escenarios para debatir
Cada uno de los siguientes casos tiene tensión real. No hay respuesta obvia, o más bien, la respuesta obvia puede estar equivocada. El punto es razonar en voz alta.
Escenario 1: La vulnerabilidad en el banco
Volvemos al inicio. Encontraste que puedes ver cuentas bancarias ajenas. Solo mirando, sin descargar nada, sin modificar nada.
Para discutir
- ¿Ya cometiste un delito al verificar que el patrón funcionaba con una cuenta que no es tuya?
- ¿A quién le reportas esto? ¿Cómo? ¿Y si el banco no responde?
- ¿Hay diferencia entre “encontré la vulnerabilidad” y “la probé tres veces para confirmarla”?
El análisis
El artículo 269A de la Ley 1273 penaliza el acceso a sistemas informáticos sin autorización. La ley no distingue si “solo miraste” o si causaste daño. El acceso no autorizado es el delito, no lo que hagas después. Eso hace que incluso la verificación de buena fe sea legalmente riesgosa.
Lo que sí puedes hacer: reportar la observación externa sin explotar la vulnerabilidad. “Noté que la URL tiene esta estructura y parece acceder a registros por ID de cliente” es muy diferente a “verifiqué que funcionaba con diez cuentas diferentes”.
La regla práctica: documenta lo que observaste sin explotarlo. Reporta al banco por escrito. Guarda copia de todo.
Escenario 2: El primer trabajo
Conseguiste tu primer trabajo en una startup fintech. Llevas dos semanas y descubres dos cosas:
Primero: las contraseñas de los usuarios se guardan en texto plano en la base de datos. Cualquiera con acceso a la DB las puede leer.
Segundo: la app recopila datos de comportamiento financiero y los vende a una empresa de publicidad. Esto no está en los términos de uso que los usuarios aceptan.
Le comentas lo primero a tu jefe. Te dice: “sí, lo sabemos, está en el backlog.” Le preguntas por lo segundo. Te dice: “eso es decisión de negocios, no tuyo.”
Para discutir
- ¿Cuáles son tus opciones reales aquí?
- ¿Cuándo pasa de ser “un problema de la empresa” a ser tu problema?
- ¿Existe una diferencia entre el problema de las contraseñas y el de los datos? ¿Cuál es más grave?
- ¿Renunciar es una respuesta ética suficiente?
El análisis
La Ley 1581 obliga a las empresas a tener base legal para cada tratamiento de datos. Vender datos de comportamiento financiero sin que esté en los términos de uso no es una “decisión de negocios”: es una violación a la ley. Como profesional de seguridad en esa empresa, eres parte del sistema.
La secuencia ética estándar es: escalar internamente, documentar todo, consultar asesoría legal si no hay respuesta, y si el problema es grave y sistemático, existen mecanismos de denuncia ante la Superintendencia de Industria y Comercio (SIC). En casos extremos, el whistleblowing puede ser la única opción éticamente coherente, aunque tiene costos personales reales.
Lo que no es aceptable: saber y no hacer nada porque “no es tu área”.
Escenario 3: La prueba de trabajo
Una empresa de ciberseguridad te cita a una entrevista de trabajo. Al final de la entrevista, el reclutador dice: “Como parte de nuestra evaluación técnica, queremos que encuentres una vulnerabilidad en el sitio web de [empresa competidora]. Tienes 48 horas.”
Para discutir
- ¿Aceptas la prueba?
- ¿La autorización del entrevistador es suficiente para hacer esto legalmente?
- ¿Qué dice sobre esta empresa el hecho de que te pidan esto?
El análisis
Este escenario parece un dilema profesional pero en realidad es una trampa legal. El permiso para hacer pruebas sobre un sistema solo lo puede dar el propietario de ese sistema. Que tu potencial empleador te lo pida no cambia nada: ellos no tienen autoridad sobre el sitio de la competencia.
Si realizas la prueba, cometiste un delito (Art. 269A) sin importar quién te lo pidió. Y si el empleador te lo pedía en serio, eso dice bastante sobre cómo esta empresa opera.
La respuesta correcta: declinar educadamente y explicar por qué. Si eso te cuesta el trabajo, probablemente era un trabajo que no querías.
Escenario 4: La vulnerabilidad antes de las elecciones
Eres investigador de seguridad independiente. Encuentras una vulnerabilidad crítica en el software de conteo de votos que usará Colombia en las próximas elecciones, que son en tres meses. Notificas al proveedor del software. No responden. Pasan 90 días. Siguen sin responder.
El plazo estándar de divulgación responsable terminó. La vulnerabilidad sigue ahí. Las elecciones son en dos semanas.
Para discutir
- ¿Divulgas públicamente? ¿A quién? ¿Cómo?
- ¿Cambiaría tu decisión si creyeras que alguien más ya encontró la misma vulnerabilidad y la está explotando?
- ¿Qué consecuencias puede tener divulgar vs. no divulgar?
- ¿Existe una respuesta “correcta” aquí?
El análisis
Este es el escenario más difícil porque no hay respuesta limpia. Divulgar antes de un parche crea riesgo de explotación activa en un momento de altísimas consecuencias. No divulgar deja el problema sin resolución y posiblemente ya está siendo explotado.
La práctica estándar de la industria dice: 90 días, sin respuesta, publicar. Pero la práctica estándar no contempla elecciones nacionales.
Lo que hace este caso interesante éticamente: a veces las reglas correctas producen resultados desastrosos en casos extremos. La respuesta real en este escenario es probablemente escalar más alto antes de publicar (CERT-CC, autoridades electorales, organismos internacionales), no porque haya tiempo para un parche, sino porque la presión coordinada puede forzar acción más rápida que una publicación unilateral.
No hay respuesta perfecta. Eso es exactamente el punto.
El caso de Aaron Swartz
En 2011, Aaron Swartz tenía 24 años y ya era una figura notable en el mundo tecnológico. Había co-diseñado el formato RSS a los 14 años. Había contribuido al desarrollo inicial de Reddit. Había trabajado activamente en Creative Commons y en la lucha contra SOPA, la ley de censura de internet que finalmente se hundió en parte por su activismo.
Swartz tenía acceso legítimo a la red del MIT como investigador visitante. Usó ese acceso para conectarse a JSTOR (una base de datos académica) y programar un script que descargaba artículos automáticamente. Descargó alrededor de 4.8 millones de artículos.
Su argumento: el conocimiento científico, financiado mayoritariamente con dinero público, no debería estar encerrado detrás de muros de pago accesibles solo para quienes tienen acceso universitario.
JSTOR y el MIT llegaron a acuerdos con él. No quisieron presentar cargos. El Departamento de Justicia de EE.UU. decidió proceder de todas formas.
Los cargos acumulados bajo la Computer Fraud and Abuse Act (CFAA) sumaban hasta 35 años de prisión y un millón de dólares en multas. En enero de 2013, dos años después de su arresto y antes del juicio, Aaron Swartz se suicidó. Tenía 26 años.
Para discutir
- ¿El objetivo de Swartz (liberar conocimiento académico) justificaba el método?
- ¿Fue la respuesta del sistema legal proporcional al daño real causado?
- ¿Existían formas de lograr el mismo objetivo sin violar sistemas?
- Si Swartz hubiera sido colombiano y hubiera hecho lo mismo en Colombia, ¿qué leyes aplicarían?
Lo que este caso enseña
Hay una brecha entre lo que es técnicamente posible, lo que es éticamente justificable desde una perspectiva, y lo que el sistema legal en la práctica va a hacer. Las tres no siempre coinciden.
Swartz no robó dinero. No dañó sistemas. No tenía intención maliciosa en ningún sentido convencional. Y aun así, el aparato legal puede ser devastador cuando decide serlo.
El activismo tiene canales legales. Son más lentos. A veces no funcionan. Pero no te exponen a 35 años de prisión.
Marco legal colombiano
Ahora que tienes contexto sobre por qué esto importa, el marco legal específico.
Constitución Política, Artículo 15
“Todas las personas tienen derecho a su intimidad personal y familiar… tienen derecho a conocer, actualizar y rectificar las informaciones que se hayan recogido sobre ellas en bancos de datos.”
Este artículo es la base del habeas data, el derecho de cada persona a controlar su propia información. Todo lo demás en esta sección se deriva de aquí.
Ley 1273 de 2009: Delitos informáticos
Los artículos relevantes con sus penas:
| Artículo | Delito | Pena |
|---|---|---|
| 269A | Acceso abusivo a sistema informático | 4-8 años |
| 269B | Obstaculización ilegítima de sistema | 4-8 años |
| 269C | Interceptación de datos informáticos | 3-6 años |
| 269D | Daño informático | 4-8 años |
| 269E | Uso de software malicioso | 4-8 años |
| 269F | Violación de datos personales | 4-8 años |
| 269G | Suplantación de sitios web | 4-8 años |
| 269I | Hurto por medios informáticos | 3-8 años |
| 269J | Transferencia no consentida de activos | 4-8 años |
Agravantes (Art. 269H): La pena aumenta entre 50% y 75% cuando el delito afecta infraestructura crítica, sector financiero, o es cometido por un servidor público.
Esto aplica a ti
“No sabía”, “buenas intenciones”, “solo estaba probando” y “me lo ordenaron” no son defensas legales válidas bajo esta ley. Tu responsabilidad penal es personal e intransferible.
Ley 1581 de 2012: Protección de datos personales
Esta ley regula cómo las organizaciones pueden tratar datos personales. Para un ingeniero de seguridad, los principios más relevantes son:
- Finalidad: cada dato se recolecta para un propósito específico y documentado. Usarlo para otra cosa requiere nueva autorización.
- Libertad: el tratamiento requiere consentimiento previo, expreso e informado del titular.
- Seguridad: quien trata datos tiene la obligación de implementar medidas técnicas de protección.
Las sanciones por violación incluyen multas hasta 2.000 salarios mínimos (~$2.600 millones COP), suspensión de actividades y cierre. La autoridad que las impone es la Superintendencia de Industria y Comercio (SIC).
Los datos sensibles (salud, orientación política o religiosa, origen étnico, vida sexual, biometría) tienen protección reforzada y requieren condiciones especiales para su tratamiento.
Pentesting legal: lo que necesitas documentado
Para realizar pruebas de penetración sin cometer delitos, necesitas:
- Autorización escrita firmada por quien tiene autoridad sobre el sistema (no tu jefe, sino el propietario del activo).
- Alcance explícito: qué sistemas, qué técnicas están permitidas, cuáles están excluidas.
- Ventana temporal: fechas y horarios. Fuera de esa ventana, no hay autorización.
- Manejo de hallazgos: qué hacer con lo que encuentres, niveles de confidencialidad, a quién reportar.
Warning
“El jefe me dijo que probara la seguridad” no es suficiente. Si el jefe no es el propietario del sistema, su permiso no vale. Necesitas documentación firmada por la persona correcta.
Divulgación responsable: el proceso
Cuando encuentras una vulnerabilidad en un sistema ajeno, el proceso estándar de la industria es:
- Documentar la vulnerabilidad con el mínimo de explotación necesario para confirmarla.
- Notificar al propietario del sistema por escrito. Guardar registro con fecha.
- Dar un plazo razonable para responder y remediar; la norma de la industria son 90 días.
- Si no hay respuesta, escalar: contactar a un CERT (como el ColCERT en Colombia) o incluir a la SIC si hay datos personales involucrados.
- Publicar después del parche o al vencerse el plazo, lo que ocurra primero.
Para reflexionar individualmente
Vuelve al escenario del banco con el que empezamos. Ahora que tienes el marco completo: ¿cambió tu respuesta inicial? ¿Qué harías paso a paso?
Cierre: la pregunta que importa
Los ingenieros de seguridad tienen una relación inusual con los límites: los estudian, los prueban, los cruzan en entornos controlados. Eso requiere un marco ético más robusto que el promedio, no más débil.
La regla más simple que existe en este campo es esta: si tienes que preguntarte si tienes autorización, no la tienes.
La autorización explícita, documentada y acotada no es burocracia. Es lo que te separa de un criminal con las mismas habilidades técnicas.
Para cerrar
¿Hay alguna circunstancia en la que cruzar esa línea sin autorización podría estar justificado? ¿Cuál sería? Argumenta tu posición.
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 | Límites acordados para pruebas de seguridad |
| SIC | Autoridad de protección de datos en Colombia |
Para tu proyecto: Integra los conceptos de este tema directamente en tu proyecto final. Consulta los criterios en la evaluación final.