Carlos Andrés Gutiérrez

Carlos, gracias por la disponibilidad. Eres el desarrollador líder y, según entendemos, también el responsable técnico de seguridad. ¿Es así?

Sí, así es. Aunque oficialmente solo soy 'Desarrollador Fullstack'. La Gerencia me delegó el tema de seguridad porque era el que más sabía. Manejo desde el código hasta la infraestructura AWS y la respuesta a incidentes con clientes.

→ Acumulación de funciones en un solo rol — debilidad D5 del DOFA. Compromete la segregación de funciones (A.5.3 ISO 27002).

Hablemos de respuesta a incidentes. ¿Existe un Plan de Respuesta a Incidentes (IRP) escrito?

No, no como documento formal. Tenemos un grupo de WhatsApp con los clientes y ahí escalamos cualquier cosa. Si hay un problema técnico, yo lo atiendo directamente. Funciona, la verdad.

→ Sin IRP documentado. WhatsApp no es un canal apropiado: no hay registro estructurado, no hay clasificación de severidad, no permite cumplir Ley 1581 Art. 17 (notificación formal).

¿Han realizado alguna vez un simulacro tabletop de respuesta a una brecha de datos?

Honestamente, no. Nunca hemos ensayado un escenario así. Con suerte no nos ha tocado vivir uno real.

→ Cl. 8.1 y 8.2 de ISO 27001 implican la planificación operacional. Sin ensayos, el equipo no está preparado para una respuesta efectiva.

Si ocurriera una brecha hoy — por ejemplo, exposición pública de los manifiestos RNDC de varios clientes — ¿cuáles serían los pasos que tomarías?

Lo primero, contener el problema. Identificar qué se filtró, cerrar el agujero. Luego avisaría a los clientes uno por uno. La Gerente sería la cara visible. Pero no tenemos un timeline definido ni un mensaje preparado.

→ Sin protocolo de notificación. La Ley 1581 Art. 17 establece deber de informar a la SIC dentro de 15 días hábiles. OmniControl no tiene definidos plazos ni canales formales.

¿Tienen identificados los plazos legales que aplican? Por ejemplo, ¿cuánto tiempo tienen para notificar a la SIC tras detectar una brecha?

No te sabría decir el plazo exacto. Sé que hay obligación, pero no tengo el detalle. Es algo que tendríamos que consultar con un abogado en el momento.

→ Desconocimiento del marco legal por parte del responsable técnico. Plazo legal: 15 días hábiles (RNBD — Registro Nacional de Bases de Datos / Circular 02 de 2015 SIC).

¿Han recibido alguna vez un reporte de vulnerabilidad por parte de un investigador externo o cliente?

Hace como dos años, un cliente nos avisó por WhatsApp que veía datos raros en una pantalla. Resultó ser un bug de aislamiento entre clientes. Lo arreglé en dos días.

→ Indicio de incidente histórico de aislamiento multi-tenant — riesgo Catastrófico según Matriz de Partes Interesadas. Sin registro formal del evento ni RCA documentado.

¿Existe un canal formal donde un investigador de seguridad pueda reportar una vulnerabilidad de forma responsable?

No tenemos un email tipo security@. Si alguien quisiera reportar algo, supongo que llegaría al soporte general o me escribirían directamente a mí.

→ Sin política de Responsible Disclosure (control nuevo A.5.24). Riesgo de que vulnerabilidades reportadas se pierdan o lleguen tarde.

Una pregunta operativa: ¿Cómo registran ustedes los incidentes? ¿Hay un sistema de tickets, una hoja de Excel, algo?

Los técnicos los registramos en GitHub Issues como bugs. Pero los incidentes de cara a cliente quedan en WhatsApp. No hay un sistema unificado.

→ Sin trazabilidad entre incidente reportado por cliente y RCA técnico. Imposibilita análisis de tendencias, cumplimiento de SLA y reporte a Gerencia.

Última pregunta: ¿Cuál crees que es el incidente más probable que podría ocurrir en OmniControl en el próximo año?

Honestamente, una caída prolongada de la integración con DIAN o RNDC. O un infostealer en un equipo del equipo — todos trabajamos desde casa con nuestros propios computadores. Eso me quita el sueño a veces.

→ El responsable técnico identifica explícitamente los riesgos BYOD (debilidad D1) y dependencia de terceros — pero no hay controles formales para mitigarlos.