Segunda entrega de proyecto

En esta entrega expandes el informe que comenzaste en la primera entrega incorporando los conceptos del Bloque 2. Entregas una nueva versión del mismo documento PDF, ahora con cuatro capítulos adicionales que cubren cómo protegerás técnicamente tu sistema.


Qué entregas

Un documento PDF actualizado que contiene:

  • Los capítulos de la primera entrega, revisados si recibiste retroalimentación
  • Cuatro capítulos nuevos correspondientes al Bloque 2

No es un documento nuevo ni un resumen de lo anterior: es el mismo informe, ampliado.


Estructura del documento

Capítulos que ya existen (de la primera entrega)

Revísalos e incorpora la retroalimentación recibida. Si algo cambió en tu comprensión del proyecto, actualízalo.

  • Capítulo 1: Descripción del proyecto
  • Capítulo 2: Contexto de ciberseguridad (activos, amenazas, actores, principios CIAAN)
  • Capítulo 3: Riesgos identificados y consecuencias

Capítulos nuevos (Bloque 2)

Capítulo 4: Criptografía y protección de datos

Aplica los conceptos de la clase 08.

  • ¿Qué datos de tu sistema son sensibles y requieren protección?
  • ¿Qué se cifra en tránsito (TLS/HTTPS), qué en reposo (AES) y qué mediante hash (contraseñas)?
  • ¿Cómo se almacenarán las contraseñas de los usuarios? Especifica el algoritmo.
  • ¿Qué otros mecanismos criptográficos aplican a tu sistema (firmas, tokens, certificados)?

Capítulo 5: Seguridad en la aplicación

Aplica los conceptos de la clase 05.

  • ¿Qué vulnerabilidades del OWASP Top 10 son relevantes para tu proyecto? Justifica cuáles y por qué.
  • ¿Cómo aplicas validación de entradas, autenticación segura y autorización correcta?
  • ¿Cómo integras la seguridad en el ciclo de desarrollo (DevSecOps)?
  • ¿Qué tipo de pruebas de seguridad realizarías antes de lanzar el sistema?

Capítulo 6: Control de acceso

Aplica los conceptos de la clase 06.

  • ¿Qué roles existen en tu sistema y qué puede hacer cada uno?
  • ¿Qué modelo de control de acceso elegiste (DAC, MAC, RBAC)? Justifica la elección.
  • Presenta la matriz de permisos completa (roles × recursos con operaciones CRUD).
  • ¿Cómo aplicas el principio de privilegio mínimo? Da ejemplos concretos.
  • ¿Qué riesgos introduce una configuración incorrecta de permisos en tu caso específico?

Capítulo 7: Arquitectura e infraestructura

Aplica los conceptos de la clase 07.

  • Incluye un diagrama de arquitectura de tu sistema con todos los componentes y capas.
  • Identifica las superficies de ataque: ¿dónde puede intentar entrar un atacante?
  • ¿Qué controles de seguridad aplican a cada capa (cliente, red, servidor, base de datos)?
  • Si tu sistema usa servicios en la nube, ¿qué responsabilidades de seguridad son tuyas y cuáles del proveedor?

Criterios de evaluación

1. Revisión y evolución desde la primera entrega (10 puntos)

NivelDescripciónPuntos
ExcelenteLos capítulos anteriores fueron revisados incorporando retroalimentación con evidencia de mejora9–10
BuenoSe incorporaron algunos ajustes; la evolución es visible7–8
SuficienteLos capítulos anteriores no cambiaron, sin justificación5–6
InsuficienteSe ignoran los capítulos anteriores o el documento parece empezar de cero0–4

2. Criptografía y protección de datos (20 puntos)

NivelDescripciónPuntos
ExcelenteIdentifica todos los datos sensibles, especifica mecanismo concreto para cada caso (algoritmo, dónde aplica) y justifica las decisiones18–20
BuenoCubre la mayoría de los datos sensibles con mecanismos apropiados; alguna decisión podría estar más justificada14–17
SuficienteMenciona cifrado o hashing de forma genérica sin especificar cómo ni dónde9–13
InsuficienteNo considera protección criptográfica o propone mecanismos incorrectos para el contexto0–8

3. Seguridad en la aplicación (25 puntos)

NivelDescripciónPuntos
ExcelenteIdentifica vulnerabilidades OWASP relevantes al proyecto, propone controles técnicos específicos y muestra comprensión del ciclo DevSecOps23–25
BuenoCubre las principales vulnerabilidades con controles pertinentes; profundidad mejorable en algunos puntos18–22
SuficienteVulnerabilidades mencionadas de forma genérica; controles vagos o no aplicados al contexto12–17
InsuficienteAnálisis superficial o vulnerabilidades irrelevantes para el sistema0–11

4. Control de acceso (25 puntos)

NivelDescripciónPuntos
ExcelenteModelo justificado, roles completos, matriz de permisos detallada, privilegio mínimo aplicado consistentemente, riesgos de mala configuración analizados23–25
BuenoModelo aplicado, roles definidos, matriz presente, privilegio mínimo en la mayoría de casos18–22
SuficienteRoles básicos, matriz incompleta, aplicación inconsistente del privilegio mínimo12–17
InsuficienteSin modelo coherente o sin matriz0–11

5. Arquitectura e infraestructura (20 puntos)

NivelDescripciónPuntos
ExcelenteDiagrama claro con todos los componentes, superficies de ataque identificadas, controles por capa especificados18–20
BuenoDiagrama presente, la mayoría de superficies de ataque cubiertas, controles pertinentes14–17
SuficienteDescripción textual de la arquitectura, superficies de ataque generales, pocos controles9–13
InsuficienteSin diagrama o sin análisis de superficies de ataque0–8

Formato sugerido para la matriz de permisos

Recurso / RolAdministradorUsuario registradoUsuario invitadoSistema externo
Base de datos de usuariosCRUDR (solo sus datos)
API principalCRUDCRRR
Panel de administraciónCRUD
Logs del sistemaR

C = Crear, R = Leer, U = Actualizar, D = Eliminar


Checklist antes de entregar

  • Los capítulos 1–3 de la primera entrega están revisados e incorporan retroalimentación
  • El capítulo 4 especifica qué datos se cifran, con qué algoritmo y en qué momento (tránsito, reposo)
  • Las contraseñas de usuarios se almacenan con bcrypt o Argon2 (no SHA-256 directo)
  • El capítulo 5 menciona al menos 3 vulnerabilidades OWASP relevantes con controles concretos
  • El capítulo 6 incluye una matriz de permisos completa con todos los roles y recursos del sistema
  • El capítulo 6 justifica el modelo de control de acceso elegido
  • El capítulo 7 incluye un diagrama de arquitectura real (no genérico)
  • El capítulo 7 identifica al menos 3 superficies de ataque con sus controles
  • Todos los capítulos nuevos hacen referencia al proyecto específico, no a sistemas genéricos

Errores comunes a evitar

  1. Proponer cifrado sin especificarlo: “Cifraremos los datos sensibles” no es suficiente. ¿Cuáles datos? ¿Con qué algoritmo? ¿Dónde se guarda la clave?

  2. Copiar la matriz de permisos del ejemplo: La matriz debe reflejar los roles reales de tu proyecto. Un sistema de salud tiene roles distintos a un e-commerce.

  3. Diagrama de arquitectura genérico: “Cliente → Servidor → BD” describe cualquier sistema web. El tuyo debe mostrar sus componentes específicos, integraciones externas y capas de seguridad.

  4. Ignorar la primera entrega: Esta entrega la incluye y mejora. Si los capítulos 1–3 tienen los mismos errores que antes, ese criterio se evaluará negativamente.

  5. Tratar los capítulos como secciones independientes: El análisis de riesgos del capítulo 3 debe conectarse con los controles del capítulo 5. La arquitectura del capítulo 7 debe verse reflejada en la matriz de acceso del capítulo 6.


Extensión recomendada

10–14 páginas en total (sin contar portada y referencias). Los capítulos nuevos deberían sumar aproximadamente 6–8 páginas.


Recursos útiles


Navegación:Anterior | Inicio | Siguiente: Ética y legislación