1. Introducción

Este post es la resolución al ejercicio: https://github.com/breatheco-de/implement-isms-iso-27001-to-small-business.git

Para comenzar este proyecto, asumiremos el rol de consultor en ciberseguridad encargado de implementar un SGSI para una organización pública. El objetivo es desarrollar un SGSI básico para garantizar que la organización pueda gestionar y proteger adecuadamente su información. Este proyecto nos guiará a través de la definición del alcance, la realización de una evaluación de riesgos, la selección de controles y la documentación de políticas y procedimientos de seguridad. Utilizaremos las instrucciones y listas de verificación proporcionadas para organizar el trabajo.

1.1 Objetivo General

Desarrollar un SGSI fundamental para un escenario de organización pública, asegurando que la organización tenga una estructura formal para la gestión de la seguridad de la información que identifique riesgos, seleccione controles apropiados y mantenga políticas y procedimientos de seguridad efectivos.

2. Seleccionando la Organización Pública

Organización elegida: Sistema de la Universidad de California (UC).

2.1 Razones para elegir la Universidad de California:

1. Disponibilidad de información pública
   • La UC cuenta con documentación accesible y detallada sobre sus estándares de ciberseguridad, políticas de privacidad y gestión de riesgos. Aquí podemos ver toda la información pública (enlace), lo que facilita la recopilación de datos para el SGSI.
2. Relevancia en seguridad de la información
   • Como institución educativa, maneja datos sensibles (expedientes académicos, investigación confidencial, información financiera de estudiantes, etc.), lo que la convierte en un escenario realista para aplicar controles de seguridad técnicos, físicos y administrativos.
3. Complejidad adecuada
   • La UC es una red multicampus (10 universidades + laboratorios nacionales), lo que implica:
     • Diversos sistemas de TI interconectados.
     • Riesgos variados (desde ciberataques hasta acceso físico no autorizado).
     • Necesidad de cumplir con regulaciones como FERPA (protección de datos educativos) y HIPAA (en áreas médicas).
4. Alineación con el aprendizaje
   • Su estructura permite trabajar con marcos como ISO 27001 o NIST SP 800-53, útiles para practicar la selección de controles y la evaluación de riesgos en un entorno con múltiples stakeholders.

3. Definición del Alcance

3.1. Identificación de Activos de Información

Inventario y clasificación de activos según criticidad:

Categoría	Ejemplos de Activos	Nivel de Importancia
Infraestructura TI	Servidores, routers, firewalls, centros de datos.	Crítico
Datos Académicos	Expedientes estudiantiles (FERPA), calificaciones, matrículas.	Alto
Investigación	Proyectos confidenciales (ej. defensa, salud), patentes, datos sensibles.	Crítico
Finanzas	Datos de pago de estudiantes, becas, nóminas de empleados.	Alto
Comunicaciones	Correos electrónicos institucionales, sistemas de aprendizaje (Canvas).	Medio
Dispositivos	Computadoras, tablets, equipos de laboratorio.	Medio

• Los datos de investigación y la infraestructura TI son críticos por su impacto en la reputación y operación de la UC.
• Los datos académicos y financieros son altos debido a requisitos legales (FERPA, GLBA).

3.2. Límites Físicos

• Ubicaciones incluidas:
  • Campus principales (ej. UC Berkeley, UCLA).
  • Centros de datos universitarios.
  • Laboratorios de investigación (ej. Laboratorio Nacional Lawrence Berkeley).
  • Oficinas administrativas.
• Áreas con acceso restringido:
  • Salas de servidores (biometría/tarjetas de acceso).
  • Laboratorios con datos sensibles (ej. investigación médica).

3.3. Límites Virtuales

• Sistemas incluidos:
  • Redes universitarias (WiFi eduroam, VPNs).
  • Plataformas en la nube (Google Workspace, AWS para investigación).
  • Bases de datos (SIS – Student Information Systems).
• Exclusiones:
  • Dispositivos personales de estudiantes (BYOD) no gestionados por la UC.
  • Sistemas de terceros sin contrato de seguridad (ej. proveedores externos sin auditoría).

3.4. Partes Interesadas y Responsabilidades

Parte Interesada	Responsabilidad
Oficina de Seguridad de la Información (UC ISO)	Implementar controles, supervisar incidentes.
Departamento de TI	Mantener infraestructura, parches de seguridad.
Investigadores	Proteger datos confidenciales (ej. HIPAA en proyectos médicos).
Estudiantes/Empleados	Cumplir políticas de contraseñas y reportar phishing.
Proveedores	Garantizar seguridad en servicios contratados (ej. nube, SaaS).

3.5. Documentación del Alcance del SGSI

Propósito:
«Proteger la confidencialidad, integridad y disponibilidad de los activos de información de la UC, alineándose con estándares como NIST SP 800-171 (investigación federal) e ISO 27001».

Metas:

• Reducir brechas de seguridad en un 30% en 12 meses.
• Capacitar al 100% del personal en concienciación de seguridad.

Limitaciones:

• No cubre dispositivos personales no gestionados.
• Excluye sistemas heredados sin soporte (pendiente de migración).

4. Evaluación de Riesgos

4.1. Inventario de Activos (Clasificación Detallada)

Categorías y ejemplos:

Tipo de Activo	Ejemplos	Clasificación
Hardware	Servidores, routers, computadoras de laboratorio, dispositivos IoT.	Crítico/Alto
Software	Sistemas de gestión estudiantil (Banner), LMS (Canvas), ERP (PeopleSoft).	Alto
Datos	Expedientes académicos, investigación confidencial, datos de pago (PCI DSS).	Crítico
Personal	Administradores de TI, investigadores, personal con acceso privilegiado.	Medio

4.2. Identificación de Amenazas

Amenazas externas e internas:

Activo	Amenazas Potenciales	Origen
Bases de datos	Violaciones de datos (phishing, ransomware), acceso no autorizado por credenciales robadas.	Externo/Interno
Redes WiFi	Ataques Man-in-the-Middle (MITM), spoofing de redes.	Externo
Investigación	Robo de propiedad intelectual, espionaje por actores estatales.	Externo
Personal	Error humano (ej. correos mal enviados), insiders malintencionados.	Interno
Centros de datos	Desastres naturales (incendios, terremotos en CA), cortes de energía.	Externo

4.3. Identificación de Vulnerabilidades

Relación amenaza-vulnerabilidad:

Amenaza	Vulnerabilidad Asociada	Ejemplo de Explotación
Ransomware	Falta de backups automatizados, sistemas sin parches.	Cifrado de datos de investigación no respaldados.
Acceso no autorizado	Contraseñas débiles, falta de MFA.	Robo de credenciales de estudiante por fuerza bruta.
Fuga de datos	Cifrado ausente en dispositivos móviles.	Pérdida de un laptop con datos médicos sin cifrar.
Ataques DDoS	Ancho de banda limitado en redes académicas.	Interrupción de exámenes en línea.

4.4. Evaluación de Probabilidad e Impacto

Matriz de Riesgos (Ejemplos Prioritarios):

Riesgo	Probabilidad	Impacto	Nivel de Riesgo	Justificación
Violación de datos estudiantiles	Alta	Crítico	Alto	Frecuencia de ataques a universidades + multas por FERPA/GLBA.
Robo de investigación	Media	Crítico	Alto	Interés en proyectos militares/médicos; impacto reputacional.
Caída de servidores académicos	Baja	Alto	Medio	Redundancia en centros de datos, pero impacto operativo alto.
Phishing a empleados	Alta	Medio	Medio	Entrenamiento insuficiente; posible acceso a sistemas internos.

4.5. Priorización de Riesgos

Riesgos prioritarios para mitigación inmediata:

1. Violación de datos personales (FERPA/GLBA) → Implementar cifrado de datos + MFA.
2. Robo de investigación confidencial → Controles de acceso físico/lógico (ej. NIST 800-171).
3. Ataques ransomware a sistemas académicos → Backup automatizado + segmentación de redes.

Riesgos secundarios:

• Phishing: Campañas de concienciación anual obligatoria.
• Caídas de red: Acuerdos con proveedores de energía redundante.

5. Selección de Controles

5.1. Revisión de Normativas Relevantes

Normas y marcos de referencia aplicables:

• ISO/IEC 27001: Para estructura general del SGSI.
• NIST SP 800-53: Controles para investigación financiada por el gobierno federal (ej. DoD, NIH).
• FERPA: Protección de datos estudiantiles.
• HIPAA: Para proyectos médicos en campus de salud (ej. UCSF).
• CIS Controls: Controles técnicos prioritarios (ej. hardening de sistemas).

5.2. Selección de Controles por Categoría de Riesgo

Riesgo Priorizado	Controles Seleccionados	Norma de Referencia
Violación de datos estudiantiles	– Cifrado AES-256 para datos en reposo/tránsito. – Autenticación MFA para todos los sistemas académicos. – Segmentación de redes (VLANS para departamentos).	NIST 800-171 (3.13.11, 3.5.3)
Robo de investigación	– Control de acceso físico (biometría en laboratorios). – DLPs (Data Loss Prevention) para monitorear transferencia de datos. – Acuerdos de confidencialidad obligatorios.	NIST 800-171 (3.1.1, 3.1.3)
Ransomware	– Backups automatizados (3-2-1 rule: 3 copias, 2 medios, 1 offsite). – Parches mensuales para sistemas críticos. – Ejercicios de recuperación anuales.	CIS Control 8, ISO 27001 A.12.3
Phishing	– Simulaciones de phishing trimestrales. – Filtros de correo avanzados (ej. DMARC, DKIM). – Capacitación obligatoria en concienciación.	CIS Control 14, ISO 27001 A.7.2.2
Caídas de red	– Acuerdos SLA con ISPs para redundancia. – UPS y generadores en centros de datos. – Monitoreo 24/7 con SIEM (ej. Splunk).	ISO 27001 A.17.1, A.17.2

5.3. Documentación de Controles

Ejemplo para un control específico:

• Control: Autenticación MFA para sistemas académicos.
  • Riesgo mitigado: Acceso no autorizado a datos estudiantiles (FERPA).
  • Implementación: Integración con Duo MFA + Azure AD.
  • Responsable: Equipo de IAM (Identity and Access Management).
  • Plazo: 6 meses (prioridad alta).

5.4. Planificación de Implementación

Cronograma y recursos:

Control	Fase	Recursos Necesarios	Dependencias	Plazo
Implementar MFA	Inicial	Licencias Duo MFA, capacitación a usuarios.	Integración con LDAP universitario.	0-6 meses
Backups automatizados	Intermedia	Solución Veeam/Bacula, almacenamiento AWS.	Auditoría previa de datos críticos.	3-9 meses
DLPs para investigación	Avanzada	Herramientas Symantec DLP, políticas de uso.	Clasificación de datos sensibles.	6-12 meses

Limitaciones:

• Presupuesto público: Priorizar controles de alto impacto/costo bajo (ej. MFA antes que SIEM).
• Resistencia al cambio: Campañas de comunicación para adopción de MFA.

6. Documentación de Políticas y Procedimientos de Seguridad

6.1. Política de Seguridad de la Información (Alto Nivel)

Objetivo:
Establecer el marco para proteger la confidencialidad, integridad y disponibilidad de los datos de la UC, alineado con ISO 27001, NIST y regulaciones aplicables (FERPA, HIPAA).

Principios Clave:

• Confidencialidad: Solo personal autorizado accede a datos sensibles.
• Integridad: Garantizar que la información no sea alterada sin autorización.
• Disponibilidad: Sistemas accesibles para operaciones críticas (ej. matrículas, investigación).

Compromiso de la Dirección:

• Asignar recursos para implementar el SGSI.
• Revisar anualmente la política.

Documento relacionado: [POL-001] Política de Seguridad de la Información.

6.2. Política de Control de Acceso

Procedimientos:

• Concesión de acceso:
  • Solicitud aprobada por supervisor + revisión de HR.
  • Principio de mínimo privilegio (PoLP).
• Revocación:
  • Automática al terminar contrato/rol.
  • Auditoría trimestral de accesos.
• Contraseñas:
  • Requisitos: 12 caracteres (mínimo), mayúsculas, números, símbolos.
  • Rotación: Cada 90 días.
  • Prohibido: Reutilizar las últimas 5 contraseñas.

Documento relacionado: [PRO-002] Procedimiento de Gestión de Identidades.

6.3. Plan de Respuesta a Incidentes

Definición de incidente:

• Cualquier evento que comprometa confidencialidad, integridad o disponibilidad (ej. ransomware, filtración de datos).

Procedimiento:

1. Detección: Monitoreo via SIEM + reporte de usuarios (portal dedicado).
2. Contención: Aislar sistemas afectados; activar equipo CERT de la UC.
3. Erradicación: Eliminar malware/causa raíz.
4. Recuperación: Restaurar desde backups limpios.
5. Lecciones aprendidas: Informe post-incidente.

Responsables:

• Equipo CERT de la UC: Investigación técnica.
• Comunicación Institucional: Notificar a afectados (si aplica).

Documento relacionado: [PRO-003] Plan de Respuesta a Incidentes.

6.4. Política de Copias de Seguridad y Recuperación

Procedimientos:

• Frecuencia:
  • Datos críticos: Backups diarios (incrementales) + semanales (completos).
  • No críticos: Semanales.
• Almacenamiento:
  • 3 copias (local, nube AWS GovCloud, cinta offsite).
• Pruebas:
  • Recuperación simulada cada 6 meses.

Responsables:

• Equipo de Infraestructura: Ejecución de backups.
• Auditoría Interna: Verificación de integridad.

Documento relacionado: [PRO-004] Procedimiento de Backup y DRP.

6.5. Plan de Concienciación y Capacitación

Estrategia:

• Capacitación anual obligatoria:
  • Módulos en línea (phishing, manejo de datos).
  • Simulaciones de phishing trimestrales.
• Materiales:
  • Guías rápidas de seguridad.
  • Carteles en áreas comunes (ej. «¡No deje dispositivos desbloqueados!»).

Público:

• Estudiantes, empleados, investigadores.

Documento relacionado: [PRO-005] Programa de Concienciación en Seguridad.

6.6. Aprobación y Revisión

Proceso:

• Aprobación inicial: Por el Comité de Seguridad de la UC y la Oficina del Rector.
• Revisiones:
  • Anuales (o ante cambios regulatorios).
  • Auditorías internas cada 6 meses.

Registro de versiones:

• Control de cambios en repositorio central (ej. SharePoint seguro).

Documento relacionado: [POL-006] Política de Gestión de Documentos.

7. Presentación Power Point

8. Conclusión Final

Este proyecto ha sido un ejercicio muy completo para comprender los fundamentos prácticos de un Sistema de Gestión de Seguridad de la Información (SGSI). A través de sus etapas—desde la definición del alcance hasta la documentación de políticas—se logró aplicar marcos normativos como ISO 27001 y NIST a un escenario realista, integrando metodologías clave como la evaluación de riesgos y la selección de controles. El proceso demostró cómo un SGSI no es solo un requisito técnico, sino un eje estratégico que equilibra seguridad, operatividad y cumplimiento.

Además, el ejercicio destacó la importancia de adaptar los controles a los recursos y necesidades específicas de una organización, priorizando riesgos críticos y fomentando una cultura de seguridad. La creación de un manual estructurado y una presentación ejecutiva reforzó la necesidad de comunicar claramente los hallazgos y acciones a todos los niveles, desde equipos técnicos hasta la alta dirección. Como aprendizaje clave, queda claro que la seguridad de la información es un proceso dinámico que requiere revisión constante, compromiso organizacional y flexibilidad ante nuevas amenazas. Este simulacro no solo fortaleció habilidades técnicas, sino también la visión holística necesaria para gestionar la seguridad en entornos complejos.