Cuatro hallazgos, dieciséis horas: priorizar el portal de una cadena de ferreterías
Un equipo de tres desarrolladores construye el portal de clientes de una cadena de ferreterías dominicana. El código ya está en producción y hay una auditoría el viernes. Hallazgos de la revisión: las contraseñas se guardan con SHA-256 sin sal; las consultas se arman concatenando el correo del usuario en la cláusula WHERE; el token de sesión vive en localStorage y dura 30 días; y los registros de la aplicación envían a un SIEM en el extranjero el número de cédula, el correo y los últimos cuatro dígitos de la tarjeta. El gerente pide «arreglar todo» antes de la auditoría. El equipo calcula que cada corrección toma entre 2 horas y 3 días, y solo hay 16 horas de desarrollo disponibles. La empresa no tiene oficial de protección de datos ni política de retención, y el contrato con el proveedor del SIEM no menciona el tratamiento de datos personales.
1. Ordene los hallazgos por prioridad de remediación y justifique con criterios de explotabilidad, impacto y esfuerzo.
Read the worked answer
Criterios explícitos: explotable remotamente sin autenticación, datos alcanzables, tiempo que lleva expuesto y esfuerzo de corrección. Con 16 horas, el orden importa tanto como la lista.
- Inyección SQL (4-8 h, consultas parametrizadas). Es la única vulnerabilidad explotable hoy por cualquiera desde Internet, sin credenciales, con herramientas automáticas, y da acceso a toda la base. Máximo impacto con mínimo esfuerzo: va primero sin discusión.
- Enmascarar datos en los registros (≈2 h). El esfuerzo es trivial, pero el daño es continuo: cada evento crea una copia de cédulas y datos de tarjeta en un tercero en el extranjero. Es exposición legal acumulativa, no solo técnica; puede hacerse en paralelo con el punto 1.
- Hash de contraseñas con sal única y algoritmo lento (Argon2id, bcrypt o PBKDF2) (≈4 h). SHA-256 sin sal permite tablas precalculadas y cracking masivo. Aun así, explotarlo exige haber comprometido antes la base, algo que la inyección SQL facilita: por eso va después. Se migra en el siguiente inicio de sesión válido.
- Token en localStorage con 30 días de vigencia (1-3 días). Requiere un XSS previo y toca frontend y backend (cookie HttpOnly/Secure, expiración corta, rotación). No cabe antes del viernes; mitigante parcial: reducir la vigencia y validar la sesión en servidor.
Conclusión: SQLi + enmascarado + hashing caben en 16 horas. «Arreglar todo» es la instrucción que garantiza no arreglar lo urgente. Si el orden difiere, debe defenderse con los mismos criterios de forma explícita.
2. Analice el envío de datos personales al SIEM en el extranjero y proponga la corrección.
Read the worked answer
Hay tres problemas superpuestos: técnico, contractual y legal.
Técnico: minimización El monitoreo no necesita la cédula completa ni datos de tarjeta para correlacionar eventos. Se requiere un identificador de usuario, IP, marca de tiempo y tipo de evento. Enviar el resto es acumular riesgo sin valor operativo. Además, registrar datos de tarjeta, aunque sean los últimos cuatro dígitos, debe revisarse contra los requisitos de la industria de tarjetas: los datos de tarjeta no pertenecen a un registro de aplicación.
Contractual El proveedor del SIEM trata datos personales por cuenta de la empresa: falta un acuerdo que fije finalidad, medidas de seguridad, subencargados, plazo de conservación, ubicación y devolución o borrado al terminar. Sin eso, la empresa no puede demostrar que el tratamiento es lícito ni controlar a su encargado.
Legal Aplican los principios habituales de protección de datos: finalidad determinada, proporcionalidad, calidad, seguridad y consentimiento informado del titular. Una brecha en el SIEM es una brecha de la empresa, no del proveedor.
Corrección propuesta (orden)
- Filtrar en origen: tokenizar la cédula, eliminar cualquier dato de tarjeta, conservar solo lo necesario.
- Firmar el acuerdo de tratamiento con el proveedor y definir retención.
- Cifrado en tránsito y en reposo, y revisión de accesos al SIEM.
- Documentar la decisión y designar un responsable de protección de datos, aunque sea parcial.
El enmascarado es un cambio de dos horas que reduce el impacto de forma inmediata mientras se resuelve lo contractual.
3. El gerente quiere publicar en la auditoría que el portal «cumple con protección de datos». ¿Qué respondería?
Read the worked answer
Respondería que hoy no se puede sostener esa afirmación, y explicaría por qué con hechos verificables, no con opiniones.
Lo que falta para poder afirmarlo
- Base legal y finalidad: no hay registro de qué datos se tratan, para qué y con qué consentimiento.
- Política de retención: nadie definió cuánto tiempo se conservan los datos ni cuándo se eliminan.
- Encargados: el proveedor del SIEM trata datos sin contrato que lo regule.
- Seguridad del tratamiento: hay inyección SQL abierta en producción, lo que significa que la medida de seguridad más básica no está garantizada.
- Derechos de los titulares: no existe procedimiento para atender acceso, rectificación u oposición.
Por qué no debe declararse Una declaración de cumplimiento sin evidencia es peor que el silencio: si ocurre una brecha, la auditoría mostrará que la organización afirmó algo que sabía falso, y eso agrava la posición institucional y la confianza del cliente.
Alternativa constructiva Proponer una redacción honesta y verificable: «se identificaron brechas en materia de protección de datos; existe un plan de remediación con responsables y fechas, en ejecución». Adjuntar el plan con los cuatro hitos (parametrizar consultas, enmascarar registros, firmar acuerdo con el proveedor, designar responsable). El área de TI gana credibilidad cuando su informe mide el avance real, no cuando maquilla el estado.