De la Teoría a la Práctica

02 · Certificación

eJPT v2 (Junior Penetration Tester)

Certificación de INE Security, enfocada en pentesting práctico con 20 horas de contenido.

• Examen 100% Práctico: Laboratorio en navegador simulando auditoría/pentest real.
• Duración: 48 horas continuas.
• Aprobación: Mínimo 80%.

Áreas cubiertas:

• Metodología PTES
• Reconocimiento pasivo y activa
• Scanning y enumeración
• Vulnerability assessment
• Ataques a sistemas web
• Post-explotación

03 · Fundamentos

¿Qué es Ciberseguridad?

Ciberseguridad es el conjunto de prácticas, tecnologías y procesos diseñados para proteger sistemas, redes y datos contra ataques digitales, acceso no autorizado, daño e interrupción.

Objetivos principales:

• Previene robos de datos sensibles
• Protege contra interrupciones operativas
• Safeguarda la privacidad de usuarios
• Garantiza continuidad operativa

04 · Casos Reales

Los números no mienten

América Latina en cifras (2025):

Sectores más golpeados:

• ● Gobierno
• ● Salud
• ● Telecomunicaciones
• ● Educación

Fuentes: Check Point Q1 2025, Banco Mundial

05 · Caso Real

El ransomware no distingue fronteras

Más casos que azotaron a LATAM:

06 · Caso Real

El caso que nos toca más cerca

Datos comprometidos:

• Nombres, DNI, cumpleaños
• Números de tarjeta, CVV
• Contraseñas de bases de datos Azure
• Transacciones, saldos Tunki

Fuentes: WeLiveSecurity, ESET

07 · Caso Real

Cuando un país declaró la guerra a un ransomware

08 · Normativas

¿Qué dice la ley en Perú?

09 · Normativas

Las cifras duelen más que las palabras

Empresas más sancionadas:

• Financieras
• Telecomunicaciones
• Retail

Fuentes: EY Perú, AmCham News, ANPD

10 · Gobernanza

La seguridad no es solo del área de TI

La ISO 27001 hace incapie en:

• Compromiso de la alta dirección
• Asignación de presupuesto
• Definición de roles y responsabilidades
• Revisión y mejora continua

NIST 2.0 (2024) incorporó:

• Govern (Gobernar) como pilar central
• Gerencia debe establecer políticas
• Gerencia debe asignar recursos
• Gerencia debe medir y supervisar riesgos

11 · Paradigma IA

Ya no son hackers solitarios

"Open-source code is basically like handing out the blueprint to a bank vault. And now there are 100x more hackers studying the blueprint."

"El código open source es básicamente como entregar los planos de la bóveda de un banco. Y ahora hay 100 veces más hackers estudiando esos planos."

12 · Caso Concreto

De open source a código cerrado

"We made this decision long before Claude Mythos and the OpenBSD vulnerability was announced, but the timing is frightening."

13 · Amenaza IA

Cuando la IA encuentra bugs de 27 años

Project Glasswing:

• $100 millones en créditos para defensa
• Partners: Apple, Microsoft, Google, CrowdStrike, Palo Alto...

"Security through obscurity is a losing bet against automation."

14 · Concepto Clave

Security Through Obscurity

(Seguridad por Oscuridad)

POR QUÉ FALLA:

• Los atacantes pueden descubrir vulnerabilidades por su cuenta
• La IA no necesita ver el código para encontrar fallas (black-box testing)
• Solo oculta la información a los defensores, no a los atacantes

16 · Parte Técnica

Ahora ensuciémonos las manos

Lo que viene a continuación está orientado a desarrolladores:

• Conceptos fundamentales de seguridad
• Secure SDLC — El ciclo de desarrollo seguro
• OWASP Top 10 — Los riesgos más comunes en web
• DevSecOps — Integrar seguridad en CI/CD
• Herramientas de defensa
• Arquitectura y hardening

17 · Fundamentos Técnicos

Las palabras del vocabulario

• AMENAZA (Threat) Actor que puede explotar una vulnerabilidad (hacker, malware, etc.)
• VULNERABILIDAD (Vulnerability) Debilidad en el sistema que puede ser explotada
• INCIDENTE (Security Incident) Cuando una amenaza explota una vulnerabilidad
• CVE Common Vulnerabilities and Exposures — Identificador único de vulnerabilidad
• CVSS Common Vulnerability Scoring System — Puntuación de severidad (0-10)
• Zero-day Vulnerabilidad desconocida, sin parche disponible

18 · Ciclo de Desarrollo

Seguridad desde el día cero

19 · OWASP Top 10

Los 10 riesgos más críticos en 2025

OWASP Top 10 (2025):

20 · OWASP A01

Broken Access Control

Control de Acceso Roto

Los usuarios pueden actuar fuera de sus permisos previstos. Incluye: acceder a cuentas de otros, cambiar permisos, leer archivos no autorizados.

Ejemplo vulnerable:

// ❌ MAL: Confía en el ID del usuario
app.get('/api/user/:id', (req, res) => {
  const user = db.find(req.params.id);
  res.json(user);  // Cualquiera puede pedir cualquier usuario
});

¿Por qué es peligroso?

• Horizontal: User A ve datos de User B
• Vertical: Usuario regular accede a admin
• IDOR: Insecure Direct Object Reference

21 · OWASP A02

Security Misconfiguration

Configuración de Seguridad Incorrecta

Configuraciones incorrectas, incompletas o adaptadas de forma insegura. Incluye: permisos excesivos, features innecesarias, errores default.

Ejemplos comunes:

• Debug mode en producción — Información expuesta
• Credenciales default — admin:admin en routers
• Permisos excesivos — chmod 777
• SSL/TLS mal configurado — TLS 1.0 habilitado

Caso real:

• Interbank 2024: Credenciales mal configuradas en Azure
• 3 millones de usuarios afectados, 3.7 TB filtrados

22 · OWASP A03 ⚡NUEVO

Software Supply Chain Failures

Fallos en la Cadena de Suministro de Software

⭐ NUEVO en 2025 — Reemplaza "Vulnerable Components". Se enfoca en TODO el pipeline: dependencias, builds, distribución.

Tipos de ataques:

• Typosquatting: request vs requesł (L polaca)
• Dependency confusion: Paquete interno con mismo nombre que público
• Malicious packages: 1,000+ paquetes maliciosos en npm/pypi (2024)

Caso crítico:

• XZ Utils (2024): Backdoor en util-linux —险些成为全球灾害
• Una dependencia comprometida = toda la app comprometida

23 · OWASP A04

Cryptographic Failures

Fallos Criptográficos

Exposición de datos sensibles debido a criptografía débil o inexistente. Anteriormente "Sensitive Data Exposure".

Ejemplos comunes:

• Datos en texto plano: Contraseñas, tarjetas sin cifrar
• Hashing débil: MD5/SHA1 para contraseñas
• SSL obsoleto: TLS 1.0/1.1 habilitado
• Keys hardcodeadas: API keys en código

Caso real:

• Interbank: 3.7 TB de datos sensibles filtrados
• Tarjetas de crédito, CVV, contraseñas expuestos

24 · OWASP A05

Injection

Inyección

Datos no confiables enviados a un intérprete como parte de un comando. SQL Injection, NoSQL Injection, OS Command Injection.

Ejemplo SQL Injection:

// ❌ MAL: Concatenación directa
const query = "SELECT * FROM users WHERE name = '" + req.body.name + "'";
// Input: ' OR '1'='1
// Resultado: TODOS los usuarios expuestos

¿Por qué es peligroso?

• Exfiltración: Toda la DB expuesta
• Auth bypass: Login sin credenciales
• RCE: Shell en el servidor

25 · OWASP A06

Insecure Design

Diseño Inseguro

Fallas en la arquitectura y diseño de la aplicación. Diferente de "Implementation" — el problema es el diseño faltante o deficiente.

Ejemplos:

• Sin threat modeling: No se consideran ataques al diseñar
• Missing rate limiting: APIs sin límites
• Broken auth flow: Recovery sin verificación
• No MFA: Solo password para acciones sensibles

¿Por qué es peligroso?

• Un design flaw no se arregla con código — requiere refactorizar

26 · OWASP A07

Authentication Failures

Fallos de Autenticación

Autenticación o session management mal implementada. Permite a atacantes comprometer passwords, keys, tokens, o la lógica de auth.

Ejemplos:

• Credenciales por default: admin:admin en producción
• Weak passwords: "123456", sin políticas
• Session fixation: ID de sesión predecible
• No MFA: 2FA opcional/no existe

Estadística:

• 81% de breaches usan credenciales robadas (Verizon DBIR)

27 · OWASP A08

Software or Data Integrity Failures

Fallos de Integridad de Software o Datos

Code e infraestructura que no protege contra violaciones de integridad. CI/CD sin validación, serialización insegura.

Ejemplos:

• CI/CD inseguro: Builds desde forks no auditadas
• Auto-updates sin verificación:
• Insecure deserialization: Code de fuentes no confiables
• SolarWinds (2020): 18,000 empresas via CI/CD comprometido

¿Por qué es peligroso?

• Code en producción que nadie revisó manualmente

28 · OWASP A09

Security Logging and Alerting Failures

Fallos en Registro de Seguridad y Alertas

Insuficiente logging, monitoreo y respuesta. Cuando pasa algo malo, no hay forma de detectar, investigar o responder.

Ejemplos:

• Sin logs de auditoría: No se registra quién accedió
• Logs sin contexto: IP, timestamp ausentes
• Alertas no configuradas: SIEM sin rules

Caso real:

• Interbank: Breach tomó meses en descubrirse
• No hay forensics = no se sabe cómo entró

29 · OWASP A10 ⚡NUEVO

Mishandling of Exceptional Conditions

Manejo Incorrecto de Condiciones Excepcionales

⭐ NUEVO en 2025 — Reemplaza SSRF. Cómo la app maneja errores, excepciones y edge cases inesperados.

Ejemplos:

• Error messages leak: Stack traces en producción
• Race conditions: Concurrencia mal manejada
• Resource exhaustion: Sin límites en requests
• Type confusion: Esperando int, recibe array

¿Por qué es peligroso?

• DoS: App cae con input inesperado
• SSRF: Manipular requests internos via error handling

30 · DevSecOps

Integrar seguridad en el pipeline

GitHub Actions:

Pipeline:

code → test → security-scan → deploy

Política de dependencias:

• No agregar packages sin revisar
• Actualizar dependencias regularmente
• Usar lock files

31 · Herramientas

Las herramientas que defienden

• FIREWALL Controla tráfico de red. Reglas de entrada/salida. Ej: OPNsense, pfSense, Fortinet
• WAF (Web Application Firewall) Protege apps web específicamente. Filtra HTTP/S. Ej: ModSecurity, Cloudflare WAF, Fortinet FortiWeb
• IDS (Intrusion Detection System) Detecta amenazas en la red. Solo alertas, no bloquea automáticamente.
• EDR (Endpoint Detection & Response) Monitorea endpoints (laptops, servers). Detecta y responde a nivel de host. Ej: CrowdStrike, SentinelOne, Wazuh

32 · Opciones

Opciones para todos los presupuestos

33 · Hardening

Endurecer el entorno

Hardening de servidores:

• Parches actualizados siempre
• Puertos mínimos abiertos
• SSH con key-based auth, no passwords
• Fail2ban contra brute force
• Firewall zones (dmz, internal)

☁️ En nube:

• Security Groups / NACLs
• IAM roles con mínimo privilegio
• Secrets Manager para credenciales
• No exposure de puertos sensibles

🔄 Proxy reverso:

• Nginx/Apache como reverse proxy
• Oculta infraestructura real
• TLS/SSL termination

34 · Demo

Demo Práctica

35 · Cierre

¡Gracias!