El problema no es saber hacer algo, sino decidir qué debe hacerse
Un mismo conocimiento puede servir para corregir una vulnerabilidad, validar una frontera de aislamiento o facilitar una intrusión. La capacidad técnica no trae incorporada una finalidad moral. Tampoco la etiqueta dual use —uso dual— decide por sí sola si una actividad es admisible: describe que una capacidad puede producir beneficios y daños según quién la use, sobre qué sistema, con qué autorización y con qué controles.
La dificultad profesional aparece cuando el objetivo parece legítimo, pero el camino elegido expone a terceros; cuando una demostración convincente exige tocar datos reales; cuando un responsable pide ocultar una limitación; o cuando divulgar un detalle puede acelerar una corrección y, a la vez, facilitar abuso. En esos casos, «tener buenas intenciones» no sustituye autorización, análisis de impacto ni trazabilidad.
Este capítulo propone un modelo operativo para decidir bajo esas tensiones. La ética profesional no es una colección de gestos personales separados de la ingeniería. Es una práctica de razonamiento: identificar quién puede verse afectado, separar hechos de inferencias, comparar cursos de acción, reducir daño previsible, documentar la decisión y mantener un canal de revisión. El resultado no es certeza moral absoluta; es una actuación defendible y corregible.
Capacidad, uso y daño no son la misma cosa
Una capacidad es una técnica o conocimiento que permite producir un efecto: enumerar una interfaz, modificar una entrada, recuperar un estado, generar una prueba o automatizar una decisión. Un uso es la aplicación concreta de esa capacidad a un objetivo y un entorno. Daño es la pérdida o afectación adversa que recae sobre personas, activos, servicios, derechos, reputación o capacidad de decidir. Confundir los tres lleva a errores opuestos: prohibir todo conocimiento potencialmente riesgoso o aceptar cualquier actividad porque su herramienta también tiene usos defensivos.
El mecanismo importa. Una prueba de límites sobre un entorno sintético puede revelar una condición sin contactar producción. La misma lógica aplicada a registros de clientes puede revelar información privada y alterar disponibilidad. La diferencia no está en que una técnica sea «buena» o «mala», sino en el alcance, los efectos y las salvaguardas del uso.
Un error frecuente consiste en llamar «investigación» a cualquier acción exploratoria. La palabra describe una intención, no una autorización. Otro consiste en asumir que una prueba de bajo volumen no puede causar daño: una consulta que no modifica filas puede activar alertas, exponer nombres o cargar un servicio. En la práctica profesional, antes de ejecutar se declara el objetivo, la frontera, los datos que podrían aparecer, la condición de parada y la persona con autoridad para ampliar o detener la actividad.
El Código de Ética y Conducta Profesional de la Association for Computing Machinery (ACM) sitúa evitar daño, ser honesto y evaluar los riesgos de los sistemas dentro de las obligaciones profesionales; no presenta la ética como una propiedad de una herramienta. ACM Code of Ethics and Professional Conduct, 2018
Un criterio mínimo: autorización, necesidad y proporcionalidad
La autorización es el permiso verificable para realizar una actividad concreta, sobre activos definidos, durante un periodo y con límites. No equivale a que una persona diga «adelante» en una conversación informal. Debe poder responder quién autoriza, qué autoridad posee, qué acciones incluye, qué queda excluido y cómo se revoca. Una autorización para revisar una aplicación no cubre automáticamente al proveedor de identidad, a un cliente real ni a un vecino de red.
La necesidad pregunta qué parte de la actividad hace falta para responder la pregunta técnica. La minimización reduce datos, privilegios, duración y alcance a lo necesario. La proporcionalidad compara el beneficio esperado con el daño probable y las alternativas menos intrusivas. No son sinónimos: una actividad puede estar autorizada y ser innecesaria; puede ser necesaria pero requerir una técnica menos invasiva; puede ser proporcional en un entorno de prueba y no en producción.
Antes de actuar, conviene registrar una matriz breve:
- objetivo técnico y decisión que debe informar;
- activo, entorno, identidad del operador y autoridad que consiente;
- datos o personas potencialmente expuestos;
- efecto esperado, efecto peor razonablemente previsible y señales de alarma;
- alternativa de menor impacto y condición inequívoca de parada;
- evidencia que se conservará, quién la custodiará y cuándo se eliminará;
- responsable que revisa el resultado y acepta el riesgo restante.
La matriz no convierte una decisión en correcta por rellenar casillas. Su función es hacer visibles supuestos y desacuerdos antes de que la acción produzca un hecho difícil de revertir. El límite profesional aparece cuando falta autoridad, el impacto no puede acotarse o la evidencia no permite estimar las consecuencias: entonces se detiene la escalada y se solicita una decisión competente.
Autorización, necesidad y proporcionalidad son preguntas distintas; una acción autorizada puede ser innecesaria.
Consentimiento, alcance y terceros afectados
El consentimiento expresa que una parte acepta una acción dentro de un ámbito que comprende. En ciberseguridad, quien administra un servicio puede autorizar una evaluación, pero no necesariamente puede consentir por todas las personas cuyos datos aparecerán. La autoridad técnica y la legitimidad sobre los intereses afectados pueden separarse.
El mecanismo de alcance debe incluir las dependencias. Una prueba contra una API puede alcanzar colas, almacenamiento, proveedor de autenticación, redes de terceros o dispositivos de usuarios. Un permiso que sólo nombra el dominio visible deja ambigüedad sobre rutas de administración, subdominios y datos replicados. Las reglas de divulgación de vulnerabilidades necesitan un canal y un alcance explícitos; RFC 9116 define un formato security.txt para que una organización publique cómo contactar y reportar vulnerabilidades, pero aclara que ese archivo no sustituye una política completa ni autoriza pruebas ilimitadas. RFC 9116, §§1.1, 2 y 3
Un error común es leer la existencia de un programa de bug bounty como permiso para hacer cualquier cosa. El programa puede excluir denegación de servicio, ingeniería social, datos personales o sistemas de terceros. También puede imponer límites de automatización, cuentas de prueba y reglas de divulgación. El uso profesional es leer la política vigente, conservar su versión y preguntar cuando el lenguaje no permita determinar el límite. Si la respuesta no llega, se espera o se trabaja únicamente con evidencia ya disponible y cuyo uso esté permitido. Llamar «pasiva» a una observación no resuelve por sí solo su autorización ni sus efectos sobre la privacidad; la incertidumbre no se transforma en permiso tácito.
Responsabilidad individual y responsabilidad distribuida
Responsabilidad describe quién debe responder por una decisión, una omisión o un resultado dentro de una autoridad. Accountability añade la posibilidad de reconstruir la decisión: identidad, motivo, aprobación, ejecución, evidencia y revisión. Una organización puede asignar una tarea, pero el operador sigue teniendo deber de competencia, honestidad y detención ante un riesgo no contemplado. A la inversa, culpar a una persona no corrige un diseño que ocultaba el entorno, un proceso que premiaba el silencio o una autoridad que no podía pedir ayuda.
La atribución debe respetar la evidencia. Un log puede mostrar que una cuenta ejecutó una acción; no demuestra por sí solo quién la controlaba, si la acción estaba aprobada o qué información tenía la persona. Un equipo puede ser responsable de un proceso sin que todos sus miembros tengan la misma decisión. Separar sujeto técnico, aprobador, dueño del activo y afectado evita tanto la acusación automática como la dilución de responsabilidad.
La competencia también es una obligación de seguridad. Aceptar una tarea fuera de la formación disponible no se resuelve con confianza personal. Se declara la limitación, se busca supervisión, se reduce alcance o se rechaza la actividad. El IEEE Code of Ethics vincula responsabilidad pública, honestidad de las afirmaciones, competencia, reconocimiento de errores y rechazo de daños maliciosos; funciona como pauta profesional, no como sustituto de una evaluación de riesgo concreta. IEEE Code of Ethics, edición junio de 2020, reproducida en el manual institucional de 2021, p. 21
La cuenta técnica, la acción y el contexto deben contrastarse con evidencia; una cuenta no identifica por sí sola persona ni intención.
Dual use: decidir sobre una capacidad concreta
Una revisión ética de uso dual debe describir la capacidad al nivel en que cambia la decisión. «Herramienta ofensiva» es demasiado amplio. Es más útil preguntar: ¿permite leer un dato, cambiar un estado, aumentar privilegios, persistir, evadir una detección o afectar disponibilidad? ¿Requiere credenciales? ¿Puede limitarse a un fixture sintético? ¿Qué control evita que una salida se reutilice contra un tercero?
El análisis puede organizarse en cuatro preguntas conectadas:
- Beneficio esperado: ¿qué propiedad se verifica o qué daño se reduce, y cómo sabremos si la acción aporta evidencia?
- Rutas de abuso: ¿qué pasos adicionales permitirían convertir el resultado en acceso, vigilancia, fraude o interrupción? ¿Quién podría obtenerlo?
- Barreras: ¿el entorno está aislado?, ¿las identidades son sintéticas?, ¿hay aprobación, registro, límites de tasa, revisión por pares y destrucción de datos?
- Alternativas: ¿una simulación, prueba unitaria, dataset fabricado, análisis de código o medición pasiva respondería la misma pregunta con menos exposición?
El error de «dual use» como excusa aparece cuando se enuncia el beneficio, pero no se analiza la ruta de abuso. El error contrario es tratar toda divulgación técnica como daño inevitable y privar a defensores de información necesaria. El criterio profesional no es ocultar por defecto ni publicar por defecto: es ajustar resolución, momento, audiencia y controles al riesgo y al beneficio demostrables.
El beneficio, los afectados y el daño permiten comparar alternativas; la falta de autoridad o salvaguardas exige detener y escalar.
Investigación y desarrollo responsable
La investigación de seguridad debe comenzar con una pregunta, no con una demostración vistosa. La pregunta define qué observación sería suficiente y qué acción sería excesiva. Si se pretende saber si dos cuentas están aisladas, una lectura de un registro sintético puede ser suficiente; descargar toda una tabla real añade daño sin mejorar la inferencia. Si se pretende conocer si una política permite modificar un objeto, un control positivo y otro negativo en un entorno autorizado pueden separar comportamiento permitido y fallo sin tocar datos ajenos.
El diseño de pruebas debe considerar reversibilidad. Una operación que sólo lee puede causar exposición; una operación que modifica puede dejar persistencia; una operación que envía tráfico puede afectar terceros. Antes de ejecutar se definen estado inicial, cambio mínimo, señal esperada, rollback y criterio de parada. Las muestras y tokens deben ser sintéticos. Las capturas se minimizan y se cifran con control de acceso; no se conserva un secreto «para demostrar» que se encontró.
La documentación debe distinguir observación, interpretación e impacto. «La respuesta incluyó el identificador de otra cuenta» es observación. «La consulta no aplica correctamente el ámbito» es inferencia que necesita mecanismo. «Podría exponer información personal» es impacto potencial; «se accedió a datos de una persona concreta» exige evidencia adicional. Esta separación evita que una probabilidad se publique como hecho y permite que otra persona revise la decisión.
La presión por reproducibilidad puede entrar en tensión con la minimización. Una reproducción segura debe conservar los pasos necesarios para validar el mecanismo, no necesariamente cada dato original. Se puede sustituir un identificador por un valor sintético, registrar un hash o entregar un fixture que mantiene la condición relevante. Si la publicación requiere un detalle que aumentaría la explotación antes de existir una mitigación, se difiere o se entrega a una audiencia que pueda protegerlo.
Divulgación coordinada como proceso de responsabilidad
La divulgación coordinada es un proceso para informar una vulnerabilidad, permitir análisis y remediación y comunicar a usuarios la información necesaria con un riesgo controlado. El abstract público de ISO/IEC 29147:2018 describe requisitos y recomendaciones a proveedores sobre divulgación y declara como objetivo reducir el riesgo asociado a la explotación. Aquí se usa únicamente ese alcance público: no se atribuyen plazos ni procedimientos al texto completo, que no se ha consultado para este capítulo. Tampoco se deduce de su objetivo una autorización para investigar. ISO/IEC 29147:2018, abstract
Un reporte profesional identifica versión, alcance, precondiciones, impacto observado frente a potencial, pasos mínimos, evidencia reducida y una propuesta de contacto. No exagera la severidad ni oculta incertidumbre. Si hay múltiples proveedores o una cadena de suministro, el investigador debe intentar identificar a las partes necesarias sin enviar datos sensibles a un destinatario no verificado. El proveedor, por su parte, necesita confirmar recepción, asignar responsables, evaluar el riesgo y comunicar mitigaciones de forma verificable.
El divulgador no puede prometer que la otra parte actuará bien; sí puede controlar qué comparte, cuándo y por qué canal. El proveedor no puede tratar el silencio del investigador como prueba de ausencia de riesgo; debe analizar la vulnerabilidad. El desacuerdo sobre crédito, plazos o severidad no justifica destruir evidencia, amenazar, publicar credenciales o expandir pruebas. Si la coordinación falla, se documentan intentos y se busca asesoría institucional o legal antes de cambiar de canal.
Conflictos de interés y presión organizacional
Un conflicto de interés existe cuando una relación, incentivo o interés puede influir —o parecer influir— en el juicio profesional. Cobrar según el número de hallazgos, evaluar un control que se diseñó, competir por publicidad o tener acciones de un proveedor no vuelve automáticamente inválida una conclusión, pero exige declaración y, cuando sea posible, revisión independiente.
El error frecuente es reducir el conflicto a corrupción explícita. La presión por cumplir una fecha puede sesgar la selección de evidencia: se cierran pruebas que no terminaron, se omiten negativos o se presenta una mitigación como remediación. Otro error es declarar el conflicto y seguir como si la declaración resolviera todo. La respuesta puede ser separar funciones, cambiar el criterio de éxito, añadir un revisor o limitar la conclusión.
Cuando una autoridad ordena una acción incompatible con el alcance o pide falsear un resultado, el profesional debe explicar el riesgo específico, proponer una alternativa segura y registrar la decisión. Si persiste la instrucción, se escala al responsable adecuado y se detiene la acción no autorizada. «El jefe lo pidió» explica una presión; no demuestra autorización del activo ni elimina el deber de no engañar. Un registro contemporáneo protege al equipo y permite que una revisión posterior distinga error, desacuerdo y negligencia.
Interés público, privacidad y comunicación
El interés público no es una palabra que permita ignorar a una persona concreta. Requiere explicar qué bien colectivo se protege, qué daño se evita, a quién se expone y por qué no existe una alternativa menos intrusiva. La publicación de un hallazgo puede ayudar a corregir muchos despliegues, pero también identificar objetivos vulnerables. Un aviso técnicamente exacto puede ser éticamente defectuoso si revela datos, sugiere una explotación trivial o no distingue versiones afectadas.
La privacidad afecta el proceso entero: recolección, análisis, transferencia, almacenamiento, publicación y eliminación. Minimizar no significa borrar todo hasta perder el mecanismo; significa conservar sólo lo que hace falta, con acceso limitado y periodo definido. Si una muestra contiene información incidental de un tercero, se redacta antes de compartirla y se evalúa si la transformación preserva la inferencia. No se usa un dato real cuando un fixture reproduce la propiedad relevante.
La comunicación debe ser comprensible para la audiencia. Un equipo técnico necesita precondiciones y regresión; una persona afectada necesita saber qué decisión tomar; una dirección necesita impacto, incertidumbre y dueño; un proveedor necesita una reproducción mínima. Un único texto para todas las audiencias suele inflar o esconder aspectos. La honestidad exige decir qué se observó, qué no se pudo probar y cuándo debe reevaluarse.
Decidir ante incertidumbre y urgencia
La urgencia cambia el coste de esperar, no convierte lo desconocido en conocido. En un incidente, la contención puede ser prioritaria, pero debe conservarse la distinción entre alerta, hipótesis e incidente confirmado. NIST SP 800-61 Rev. 3 integra la respuesta a incidentes en la gestión del riesgo y recalca preparar, detectar, responder y recuperar con información y responsabilidades definidas; no autoriza a cualquier operador a intervenir en un activo ajeno. NIST SP 800-61 Rev. 3
Una decisión urgente puede usar un umbral temporal: seleccionar la acción reversible que reduzca el peor daño plausible mientras se busca confirmación. Deshabilitar una credencial de prueba, aislar un workload autorizado o activar un contacto de emergencia son acciones distintas de borrar logs, modificar evidencia o escanear redes de terceros. Para cada acción se registra predicción, autoridad, duración, efecto colateral y reversión.
El resultado puede ser «no determinado». Esta conclusión es profesional cuando la telemetría está incompleta, el alcance es ambiguo o varias explicaciones siguen siendo compatibles. «No determinado» no significa «no pasó» ni «todos son culpables». Indica que la decisión debe limitarse, que falta una observación y que el nivel de confianza no soporta una afirmación mayor.
Un procedimiento de seis pasos para casos difíciles
Ante una tarea ambigua, use un procedimiento breve y repetible:
- Describir la pregunta. Escriba qué propiedad o decisión se quiere informar; elimine objetivos vagos como «probar todo».
- Congelar la autoridad y el alcance. Identifique activo, entorno, datos, periodo, operador, aprobador y dependencias; si falta alguno, detenga la escalada.
- Mapear daño y alternativas. Enumere afectados directos e indirectos, efectos reversibles e irreversibles y la opción de menor intrusión que pueda separar las hipótesis.
- Definir salvaguardas. Use cuentas sintéticas, aislamiento, límites de tasa, supervisión, registro, custodia, rollback y condición de parada.
- Ejecutar y comunicar por capas. Cambie una variable relevante, conserve evidencia mínima y entregue a cada audiencia sólo lo necesario para actuar.
- Revisar y asumir responsabilidad. Compare predicción con resultado, declare incertidumbre, documente incidentes o desviaciones y asigne dueño a la siguiente decisión.
El procedimiento no reemplaza ley, contrato, política interna o asesoría especializada. Sirve para detectar temprano cuándo esas fuentes son necesarias. Tampoco ofrece una puntuación que resuelva dilemas: obliga a mostrar quién soporta el riesgo y qué se hizo para reducirlo.
Casos de transferencia
Caso A: prueba de aislamiento. Un analista recibe permiso para evaluar un servicio multiinquilino. La primera respuesta sugiere que un identificador sintético de un tenant podría devolver metadatos de otro. La acción defendible es detener la enumeración, conservar una respuesta mínima, confirmar que ambos tenants son de prueba y pedir al dueño una reproducción controlada. Descargar objetos reales para «probar impacto» violaría minimización y no añade necesariamente evidencia.
Caso B: reporte con presión comercial. Una consultora descubre una condición de autorización en la versión que un cliente planea anunciar. El cliente pide eliminar el hallazgo del informe. La respuesta profesional separa observación, impacto y confianza, registra el conflicto, solicita revisión independiente y no presenta una conclusión falsa. Si el cliente decide aceptar el riesgo, esa aceptación debe quedar atribuida y no transformar la evidencia.
Caso C: herramienta de doble uso. Un equipo desarrolla un emulador que permite reproducir una clase de fallo en dispositivos. Para investigación interna se limita a firmware propio, sin funciones de propagación, con muestras sintéticas y revisión de acceso. Publicar el componente que automatiza el contacto con dispositivos reales exigiría un nuevo análisis: el beneficio educativo puede lograrse con un fixture, mientras la automatización ampliaría capacidad de abuso. El nombre «emulador defensivo» no sustituye esa comparación.
Síntesis
La ética profesional en ciberseguridad se vuelve técnica cuando conecta capacidad, uso, autoridad, daño, evidencia y responsabilidad. El uso dual explica una tensión; no otorga permiso ni obliga a prohibir. Autorización delimita quién puede pedir una acción, pero necesidad y proporcionalidad determinan si esa acción es adecuada. Minimización reduce exposición; accountability permite reconstruir y corregir; competencia obliga a declarar límites; divulgación coordinada organiza el paso de una observación a una mitigación.
Una decisión defendible no promete que nadie sufrirá daño. Declara qué se intentó proteger, qué podía salir mal, qué alternativa se descartó, quién aprobó, qué ocurrió y qué permanece desconocido. Cuando el alcance cambia, la evidencia cambia o aparece un tercero afectado, se reabre la decisión. La responsabilidad profesional no consiste en actuar siempre ni en abstenerse siempre: consiste en hacer que la próxima acción sea necesaria, autorizada, proporcional, revisable y honesta.
Comprobación de comprensión
Uso dual. Una herramienta puede enumerar interfaces para defender un servicio o preparar una intrusión. ¿Por qué «es dual use» no basta para decidir si la actividad es admisible? Respuesta modelo: separa capacidad, objetivo, activo, entorno, autoridad, afectados, rutas de abuso, salvaguardas, parada y alternativa menos intrusiva; por ejemplo, un fixture sintético puede responder la pregunta sin contactar producción. Contraejemplo: que exista un uso defensivo no autoriza usar la herramienta contra producción.
Alcance y consentimiento. Una administradora autoriza probar una API que replica datos en un proveedor externo. ¿Qué debes confirmar antes de una prueba que podría leer registros? Respuesta modelo: autoridad sobre la API y consentimiento o base legítima sobre datos de terceros; activos, acciones, periodo, entornos, dependencias, réplicas, subcontratistas, retención, evidencia mínima y parada. Si el alcance del tercero no está resuelto, se pide autorización adicional o se elige una verificación pasiva/sintética. Contraejemplo: autorizar el dominio no autoriza automáticamente todas sus copias.
Verificación sintética. Evalúa una decisión defensiva sintética para comprobar aislamiento entre dos tenants sin leer datos reales. ¿Qué precondiciones, observación, controles y rollback deben constar? Respuesta modelo: autorización explícita, tenants y objetos señuelo, pregunta acotada y parada; el camino legítimo es control positivo y el caso cruzado, control negativo. Registra sólo decisión, tenant efectivo, objeto señuelo y telemetría mínima; incluye aislamiento, duración, custodia y restauración. Contraejemplo: leer un objeto real «para demostrar impacto» añade exposición sin necesidad.
Cuenta compartida y responsabilidad. Un log muestra que una cuenta compartida ejecutó un cambio fuera de ventana. ¿Qué puedes afirmar y qué no puedes atribuir? Respuesta modelo: si la procedencia es válida, cuenta, acción, ventana y resultado registrado; no una persona, intención, aprobación, legitimidad o causa. Se necesita trazabilidad complementaria —sesión, aprobador, ticket, contexto y controles— y una declaración de lo desconocido. Contraejemplo: atribuir el cambio a todo un equipo porque la cuenta lleva su nombre.
Conflicto de interés. Una consultora descubre una vulnerabilidad y el cliente pide quitarla del informe antes de anunciarla. ¿Cómo preservar honestidad y responsabilidad? Respuesta modelo: separar hecho, inferencia, impacto confirmado y potencial; conservar evidencia y versiones; declarar la presión; solicitar una segunda comprobación documentada por alguien no implicado; y acordar comunicación coordinada sin secretos ni exageración. La aceptación de riesgo queda atribuida, pero no cambia el hecho. Contraejemplo: quien paga el trabajo no puede convertir un sistema vulnerable en «limpio» por edición.
Contención reversible. En una urgencia puedes aislar un workload de prueba o borrar registros. ¿Qué favorece la primera opción y qué documentas? Respuesta modelo: autorización, reversibilidad, reducción del peor daño plausible y preservación de evidencia; documenta motivo, predicción, activo, alcance, duración, efectos colaterales, custodia, responsable de revisión y rollback. Si falta autoridad o hay terceros, se detiene y escala. Contraejemplo: borrar logs confunde detener actividad con destruir evidencia.
Comunicación coordinada. Redacta la estructura no operativa de un aviso sobre una condición de autorización con versión y precondiciones conocidas, pero impacto en producción aún no confirmado. ¿Qué incluir y qué omitir? Respuesta modelo: contacto verificado, versión, alcance, precondiciones, condición conceptual, impacto observado frente a potencial, evidencia redactada, confianza, medidas temporales, responsables y revisión. Omite payloads, reproducción contra objetivos, datos personales, secretos y automatización reutilizable; declara que el impacto no está confirmado y que coordinar no autoriza probar. Contraejemplo: enviar una reproducción completa al primer contacto puede habilitar abuso antes de verificar destinatario.
Publicación acotada. Un equipo quiere publicar documentación sobre un fallo reproducido sólo con fixtures sintéticos y firmware propio. ¿Qué análisis justifica limitarla, sin desarrollar un emulador operativo? Respuesta modelo: compara beneficio incremental con audiencia, precondiciones, facilidad de reutilización y daño plausible; publica descripción conceptual, condiciones de seguridad, evidencia reducida y mitigación, reservando detalles sensibles para partes autorizadas. Registra autoridad editorial, afectados, salvaguardas y reevaluación. Contraejemplo: «publicar todo mejora transparencia» ignora capacidad de abuso adicional sin evidencia proporcional.