preparación para la era de la IA
12 artículos con esta etiqueta
Seguridad para la era de la IA: los fundamentos que blindar ya (lista de prioridades)
La IA sobre todo amplifica los ataques sobre debilidades EXISTENTES (CVE sin parchear, contraseñas reutilizadas, secretos expuestos) más que inventar nuevas — encontradas de forma automática, rápida y a escala. Así que la mejor preparación es blindar los fundamentos en el orden correcto: parcheo de CVE + monitoreo de dependencias, eliminar la reutilización + MFA, quitar secretos expuestos, mínimo privilegio, reducir la superficie pública, registros/IOC, copias de seguridad.
Qué funciona (y qué no) para la seguridad en la era de la IA — por qué también golpean a los sitios pequeños
Cuatro mitos de la era de la IA corregidos: (1) demasiado pequeño para ser objetivo → la automatización elimina «un humano te elige»; (2) necesita un control nuevo especial → los fundamentos siguen ganando; (3) un producto te hace seguro → diseño de prevención antes que detección; (4) el código de IA es rápido, así que es seguro → se despliega con vulnerabilidades, revisa antes de publicar. Lo que funciona son los aburridos fundamentos en el orden correcto.
¿Un correo de phishing falsificó tu propio dominio? Suplantación vs intrusión, y cómo detenerla
Un correo sospechoso que parece venir de tu propio dominio normalmente no es una intrusión — es un From falsificado, porque SMTP permite a cualquiera escribir la línea From. Leer las cabeceras (Authentication-Results, Received, Reply-To) distingue una intrusión de una falsificación. La razón principal de que llegue a tu bandeja de entrada es la falta de una política DMARC. Corrígelo con SPF → DKIM → DMARC (p=none → reject).
Elegir bien la MFA: qué significa «resistente al phishing» y por qué el SMS es débil
La MFA es una segunda cerradura para que una contraseña filtrada por sí sola no permita entrar — pero lo que actives cambia su fortaleza en tres niveles. Los códigos por SMS/correo caen ante el phishing por relay y el SIM-swap; las apps de autenticación (TOTP) están en medio; las passkeys/llaves de seguridad (FIDO2) no pueden presentarse a un sitio falso en absoluto — eso es resistencia al phishing. Máxima prioridad: pon MFA resistente al phishing en las llaves del reino (correo, dominio, pagos). Guardar los códigos de recuperación y tener un factor de respaldo completan la configuración.
Fundamentos de copias de seguridad: la regla 3-2-1 y un plan de recuperación que sobrevive al ransomware
«Tengo una copia de seguridad» no basta — solo es real una copia que has verificado que puedes restaurar. Los fundamentos: la regla 3-2-1 (tres copias, dos tipos de medio, una fuera del sitio). Para el ransomware además necesitas al menos una copia «offline o inmutable» — una copia siempre conectada se cifra junto con el original. La sincronización en la nube no es una copia de seguridad (también replica borrados y cifrado). El versionado y una prueba de restauración periódica completan la práctica.
¿Son seguros los gestores de contraseñas? Cómo funcionan, nube vs local y cómo elegir
Un gestor de contraseñas es más seguro que reutilizar o guardar en texto plano. La clave es el cifrado de conocimiento cero: tu contraseña maestra descifra la bóveda solo en tu dispositivo, el proveedor solo guarda texto cifrado, así que una brecha del proveedor no expone tus contraseñas. El verdadero punto único es tu contraseña maestra más el MFA de la bóveda. Elige nube (Bitwarden/1Password) o local (KeePass) según el uso.
La base de seguridad para desarrolladores independientes y pequeños operadores: el conjunto estándar completo
La base no es 'todo igual de importante'. El orden de prioridad de este sitio: 1) llaves del reino (MFA, dominio, correo), 2) secretos y código, 3) la propia app, 4) parchear, detectar, recuperar. Con tiempo finito, complétala de arriba abajo. La mayoría de las brechas graves no vienen de ataques novedosos sino de un hueco en esta base.
Corregir CVE de dependencias de verdad: escanear, corregir, aislar y seguir vigilando
El trabajo de vulnerabilidades no termina cuando «lo corriges». Hecho = 1) escanear, 2) corregir, 3) aislar/delegar, 4) monitorear. Hasta que el monitoreo (detección diaria de cambios) esté en marcha, está incompleto — las dependencias vuelven a ser vulnerables mañana. Una corrección perfecta que el siguiente despliegue sobrescribe vale cero. Los equipos pequeños se mantienen seguros con dos disciplinas: detección automatizada de cambios y «local→push→deploy».
Instalar y usar osv-scanner: encuentra CVE en tus dependencias
osv-scanner escanea lockfiles y contenedores para sacar a la luz CVE en tus dependencias, gratis. Esto recorre la instalación, la ejecución y la integración en CI, además de cuándo usarlo frente a npm/pnpm audit y Dependabot. La visión de este sitio: la herramienta correcta la decide TU configuración — recurre a osv-scanner en proyectos multiecosistema o sin GitHub, y al pnpm audit incluido para un único árbol npm.
¿Dejaste un archivo de secretos en un directorio público? Audita tu webroot
Cualquier cosa en tu webroot puede descargarse por URL por cualquiera. Un JSON de token/credenciales olvidado, un .env o una copia de seguridad significa exposición instantánea — y si vino de una plantilla compartida, todos los sitios tienen el mismo agujero. Solución: coloca en el directorio público solo cosas compartibles públicamente, mantén los secretos fuera del webroot con permisos 600, y una vez que encuentres uno, audita cada sitio y servidor.
No des claves de root a entornos que pueden ser comprometidos: privilegio mínimo en claves SSH
Registrar una clave de root en producción desde un entorno efímero y comprometible (pod de GPU, runner de CI, VM desechable) significa que en el momento en que ese entorno se compromete, se toma producción con root. Solución: sin claves de root en entornos efímeros; quita las claves cuando no se usen; si se necesita de nuevo, usa un usuario no-root más una clave restringida a un comando que limite la clave a una sola operación. Una clave reutilizada es tu activo más crítico — nunca construyas un montaje de 'una fuga, todo'.
Código escrito por IA filtró una clave de API y generó cargos fraudulentos — la causa real era un CVSS 10.0 sin parchear
El pico en la factura fue un síntoma. La causa real era un RCE público CVSS 10.0 sin parchear. Un caso anonimizado, destilado en lecciones defensivas.