Las cedulas

Uno de los perros se puso a ladrar a las 04:00 y ya mejor me levanté.

Ayer, regresando del trabajo, no escribí nada, pero es en muchos aspectos un campo minado. No la actitud de la gente, que es tolerable, sino cosas que internamente están mal.

Documento aqui por mi estrategia que también se parece a las cédulas. silencio, trabajo, registro, y paciencia.

Por otra cosa, obtuve el nombre completo de la programadora. Sus estudios son de Técnica en alimentos y bebidas. No licenciatura o ingeniería.

Voy a poner aqui un borrador de documentación de porqué debe tenerse cedula y no titulo solamente, sea la profesión que sea.

Puede decirse que la cédula no es necesaria. En parte es así en ciertas profesiones. En otras, si la gente es descuidada y no revisa, no hay problema; pero si haces bien tu trabajo, no debe haber problema más allá de limitar posibilidades laborales y dificultarte sacar visa de trabajo.

Pero cuando la persona hace estupideces del tamaño de un edificio… o alguien del área hace estupideces del tamaño de un edificio, se lleva a todos de corbata.

Python es un lenguaje de desarrollo que tiene varias «comodidades» y son para facilitarte «PRUEBAS». Pero tengo razones para pensar que no usaron ninguna de las puertas o salvaguardas.

• Parece que NO usan Gunicorn que Es un servidor multihilos real. Están desarrollando con lo integrado a Flask en producción, que no debe ser. Es como teniendo permiso de circulación trataras de pasar a otro estado, o que después de un curso de primeros auxilios te presentes como cirujano de trasplantes.
• CORS = False. Es el equivalente de decir: mi puerta cierra porque no le pongo llave, e ilumino atrás para que piensen que hay personas.
• El server de desarrollo solo tiene Python, no PHP, y es Debian 12 con una versión vulnerable de nginx. Todavía no tengo credenciales, pero con la pura dirección IP ya lo vi. Esto significa que de las vulnerabilidades CVE, o graves del año pasado acá, no están enterados.

Es mucho así.

Presentarse de la carrera que sea como licenciado o ingeniero sin tener cédula es una forma de autoengaño. Pero es descuido de todos los demás. No sé qué le pasó a mi antecesor. Creo que se fue por no usan GIT y sin eso no pueden muchos trabajar. Otra es el código porque Python al nivel que usan se ve avanzado, pero el nivel es bajo. Y no usan repositorios de ningún tipo.

Veo tres o cuatro opciones principales:

• Que la directiva no tiene idea de nada.

• Es posible que quieran quitar a mi jefe y ponerme a mí. Van como 7 trabajos que me ha pasado eso y acabo como jefe de área menos de dos meses de mi entrada.

• Quieren que yo lo arregle.

• Buscan un chivo expiatorio.

Pero aquí la pregunta no es si va a estallarles, sino cuándo.

Hay datos adicionales que no digo aquí.

De entrada: Esta combinación es muy peligrosa y básicamente constituye una vulnerabilidad de seguridad de alto riesgo. Un negocio de ese giro maneja datos de clientes (que incluyen información financiera) con computadoras sin antivirus, junto con los problemas de CORS y HTTP que mencioné anteriormente, significa que los datos financieros de la cartera de clientes están prácticamente «desnudos».

Y no expico el desastre de php de estandares 2011 al 2026 mezclados por acumulación.

Por qué el riesgo es extremadamente alto

1. Los datos que maneja la empresa son el «objetivo principal»

Lo que maneja esta empresa son datos financieros de millones de personas, y en México este tipo de datos ha sido objeto de ataques dirigidos específicamente. Según reportes de 2026, el gobierno mexicano investigó un caso en el que se vendían en plataformas de mensajería bases de datos de centros de llamadas con aproximadamente 12.9 millones de registros, que incluían nombres, contactos, RFC (registro federal de contribuyentes), domicilios e información bancaria. Estos datos provienen de filtraciones internas de centros de llamadas o robo por exempleados. El valor de los datos que maneja tu empresa es exactamente el que buscan los atacantes.

2. Las computadoras sin antivirus significan que ni siquiera existe la «línea de defensa más básica»

Las computadoras de un lugar de trabajo suelen estar conectadas a Internet y son operadas por múltiples empleados. Sin antivirus, las rutas de infección son muy directas:

• Keyloggers: registran silenciosamente todo lo que los empleados teclean en el sistema, incluyendo credenciales de inicio de sesión y consultas de datos de clientes.

• Ransomware: bloquea directamente las computadoras, paralizando el negocio de cobranza; en el peor caso, los datos son cifrados y extorsionados.

• Troyanos: convierten las computadoras en «zombis» dentro de la red interna, utilizándolas como trampolín para atacar servidores internos.

NTT Este de Japón enumera explícitamente estos riesgos: sin antivirus, la fuga de información personal, el secuestro de computadoras y la propagación a otros dispositivos ocurrirán tarde o temprano. Para un negocio con cientos de empleados, solo se necesita que una persona abra un correo de phishing o conecte una memoria USB infectada para que toda la red se vea comprometida.

3. La combinación con CORS=False y HTTP es «peor aún»

Ya sabemos que CORS=False significa que las barreras del navegador no tienen candado, y que HTTP significa que los datos se transmiten en texto plano. Ahora añadimos «computadoras sin antivirus»:

• El HTTP sin cifrar permite que cualquier persona en la misma red interna (incluyendo dispositivos infectados) intercepte directamente las credenciales de inicio de sesión y las transmisiones de datos de los empleados.

• La configuración laxa de CORS permite que páginas maliciosas lean directamente las respuestas de la aplicación.

• Sin antivirus, una vez que una computadora es infectada, el atacante puede moverse lateralmente dentro de la red interna, encontrando servidores y bases de datos.

• Datos financieros en float y varchar es un error clásico y peligroso.

En resumen: el atacante no necesita ser un hacker de alto nivel, solo necesita poder conectarse a su red interna, o hacer que un empleado haga clic en un enlace.

Desde la perspectiva de cumplimiento normativo, esto también es un problema

La Ley Federal de Protección de Datos Personales en Posesión de los Particulares (LFPDPPP) de México, así como el sentido común requieren que los responsables del tratamiento de datos  implementen medidas de seguridad administrativas, técnicas y físicas para proteger los datos personales. Las medidas técnicas incluyen firewalls, antivirus, cifrado, etc. El INAI (autoridad de protección de datos de México) puede imponer multas de hasta 320,000 UMAs (Unidad de Medida y Actualización, aproximadamente decenas de millones de pesos).

Si los datos de clientes se filtran, los clientes  será considerada «responsable» y el lugar donde trabajo será considerado «encargado». El encargado está obligado a implementar medidas de seguridad según las instrucciones del responsable. Las computadoras sin antivirus son una negligencia evidente en las medidas de seguridad técnicas. Una vez que ocurra un incidente, tanto el responsable como el encargado no podrán evadir su responsabilidad.

En lo estructural:

• No estoy en la cadena de mando por lo que veo no se tiene acceso como programador o consultor a  configuración a producción ni a desarrollo. Sin poder de cambio, no puedo ser responsable de lo que no controlas. Eso es principio básico de gobernanza de TI: la responsabilidad sigue al control.

• La separación de funciones es real: el programador escribe código; quien administra el servidor (hardening, TLS, antivirus, parches, CORS a nivel de infraestructura) es el área de sistemas/infra. Si esa área no existe o no hace su trabajo, el fallo es de ellos, no de quien programa.

• La chica técnica tiene su parte: si su código asume que el servidor es seguro cuando no lo es, o si ella configuró Flask de desarrollo en producción, eso sí es su responsabilidad técnica. Pero la ausencia de antivirus, HTTP sin TLS en la intranet y un nginx vulnerable son decisiones de infraestructura, no de código.

• Esperar es prudente: Documentar mentalmente y observar es lo razonable.

Combinado con lo anterior (CORS=False, HTTP sin TLS, PCs sin antivirus, nginx vulnerable, Flask de desarrollo en producción), el cuadro es el de un sistema construido sin disciplina de ingeniería:

• Datos financieros en float → integridad de datos comprometida (no es solo seguridad, es corrección del negocio).

• Datos financieros en varchar (si es el caso de montos) → sin validación ni operabilidad.

• Eso, en un sistema financiero, significa que los números del negocio no son confiables, independientemente de si hay o no un ataque.

Mi posición de «no es mi responsabilidad, pero lo veo»:

1. No es mi código (la programadora lo hizo), no es mi server (infra lo controla), no estoy en la cadena de mando. Correcto.

2. Pero el float para dinero es un error tan básico que cualquier auditoría o revisión de código lo detecta en minutos. Cuando explote (por un ataque, por una auditoría, por una disputa con un cliente, o porque el banco no cuadra), la pregunta será «¿quién revisó esto?». Yo ya lo documenté.

3. Ya lo Documenté en un word: fecha, qué tabla/columna, qué tipo, por qué es incorrecto, qué riesgo implica (redondeo, conciliación, auditoría). Sin acción, sin confrontación, sin avisar. Solo como respaldo.

Pero ….  float para dinero es un error de diseño objetivo, no una opinión. varchar para montos es igual de malo. Es la prueba de que el sistema se construyó sin estándares. Yo lo veo, no puedo arreglarlo, no me corresponde, pero queda registrado como un mapa de l oque hay que arreglar.

Todo lo mencionado es evidencia de prácticas deficientes, no necesariamente de «no saber nada». Puede saber algo de Python y aun así no tener bases de ingeniería de software, bases de datos o seguridad. Es una aclaración importante: el problema no es que no sepa nada, es que no tiene las bases específicas que este sistema requiere, y nadie lo verificó.

• El problema no es solo que la persona no tenga formación formal en el área. El problema es que la empresa, siendo una empresa que maneja datos financieros, no verificó sus competencias técnicas antes de contratarla ni antes de poner su código en producción. El giro del negocio exige esa verificación. No se hizo. Eso es un fallo de proceso, no solo de una persona.
• La ausencia de verificación técnica no es un caso aislado: la programadora no tiene formación formal en el área, el sistema tiene errores objetivos de diseño, el ViciDial lo maneja un estudiante de electrónica sin experiencia verificada en telefonía IP, y no sé si mi jefe tenga formación verificable. Para una empresa que maneja datos financieros, esto es un fallo de proceso de contratación y supervisión, no de una sola persona.
• Me consta que hay por lo menos cuatro servidores deseactualizados con stacks diferentes, y versiones diferentes

La cédula como «prueba de saber» es un indicador. Hay gente con cédula que programa mal, y gente sin cédula que programa bien. Pero en su caso, la combinación de «sin formación formal en el área» + «sin repositorios» + «errores objetivos en el código» + «sin certificaciones» hace que no haya ninguna evidencia de que sepa lo que hace. Eso es lo que me preocupa.

No hay forma de defender a nadie si algo estalla.

Por qué no hay defensa posible:

1. La programadora no puede defender su código: float para dinero, varchar para montos, CORS=False, Flask de desarrollo en producción, sin Gunicorn, sin repositorios. Son errores objetivos, documentables, que cualquier revisión técnica detecta. No hay interpretación que los salve.

2. El estudiante de electrónica no puede defender la administración de ViciDial: si no tiene formación en telefonía IP, Linux, Asterisk, seguridad de VoIP ni bases de datos, y el sistema falla o se compromete, no hay argumento de «hice lo que pude» que lo cubra.

3. Supervisión no puede defender la supervisión: si no verificó competencias, no revisó código, no exigió repositorios, no hizo hardening, no instaló antivirus, no configuró TLS, permitió Flask de desarrollo en producción. Si sabía, es negligencia; si no sabía, es incompetencia. Ninguna de las dos defiende.

4. La empresa no puede defender el proceso: contrató sin verificar, puso en producción sin revisar, no tiene antivirus, no tiene TLS, no tiene repositorios, no tiene separación de funciones, no tiene auditoría. Para una empresa que por su giro maneja datos financieros, eso es un fallo sistémico de diligencia.

5. Yo si puedo defenderme: cuatro días, sin poder formal, sin acceso a servidores, sin cadena de mando, sin responsabilidad sobre el código ni la infraestructura. Y con un registro documentado de lo que vi, cuándo lo vi y por qué no actué (porque no ne correspondía y no tengo poder para hacerlo).

Pero de infra es igual o peor :

Servidores Debian 12 con vulnerabilidades sin parchear

• Debian 12 (Bookworm) es una base sólida, pero sin actualizaciones de seguridad acumula CVEs. Un servidor con nginx vulnerable y sin parches es una puerta abierta, y ya lo vi con la pura IP.

• Si no parchean el sistema operativo, tampoco parchean nginx, ni Python, ni las dependencias de Flask, ni MySQL/MariaDB, ni Asterisk/ViciDial. La superficie de ataque se acumula capa por capa.

• Y si el servidor es vulnerable, el respaldo que vive en ese servidor (o en la misma red) también lo es. Un atacante que entra al servidor puede borrar, cifrar o exfiltrar los respaldos antes de que nadie se dé cuenta.

Respaldos:

1. Respaldos en el mismo servidor o en la misma red sin segmentar: si el servidor cae o es comprometido, el respaldo cae con él. Eso no es un respaldo, es una copia.

2. Sin verificación de restauración: nadie ha probado restaurar. El respaldo existe en teoría, pero nadie sabe si sirve. Es el error más común: «tenemos respaldos» <> «¿los han restaurado alguna vez?» = silencio.

3. Sin cifrado: si los respaldos contienen datos financieros y de clientes, y están en HTTP o en un servidor vulnerable, están expuestos. La LFPDPPP exige medidas de seguridad para datos personales, y un respaldo sin cifrar es una fuga esperando ocurrir.

4. Sin retención definida ni rotación: o se acumulan hasta llenar el disco (y el servidor se cae por espacio), o se borran sin criterio (y no hay histórico para auditoría).

5. Sin respaldo offsite / air-gapped: si todo está en la misma infraestructura, un ransomware cifra producción y respaldos a la vez. Sin copia offline o en otra ubicación, no hay recuperación.

6. Sin documentación ni responsable: nadie sabe dónde están, cómo se restauran, quién tiene las credenciales. Si la persona que «sabía» se va (o es la que se fue: tu antecesor), el respaldo se vuelve un misterio.

7. Sin monitoreo: nadie sabe si el respaldo corrió bien anoche. Se enteran cuando necesitan restaurar y el archivo está corrupto o incompleto.

Prefiero quedarme callado de momento, hacer mi trabajo, sin problemas, ayudar en lo que pueda.

La lógica de responsabilidad: