OP.EXP.1 Inventario de activos
Documentos de referencia
- ISO/IEC 27000
- 27002:2013:
- 8.1.1 - Inventario de activos
- 8.1.2 - Propiedad de los activos
- 27002:2013:
- NIST SP 800-53 rev4:
- [CM-8] Information System Component Inventory
- [PM-5] Information System Inventory
- Otras referencias:
- SANS - CIS Critical Security Controls - Version 6.1
- CSC.1 - Inventory of Authorized and Unauthorized Devices
- CSC.2 - Inventory of Authorized and Unauthorized Software
Guía de implantación
- El inventario debe cubrir todo el dominio de seguridad del responsable de la seguridad del sistema de información, hasta alcanzar los puntos de interconexión y los servicios prestados por terceros. La granularidad debe ser suficiente para cubrir las necesidades de reporte de incidentes y para hacer un seguimiento, tanto formal (auditorías) como reactivo en el proceso de gestión de incidentes.
- Identificación del activo: fabricante, modelo, número de serie
- Configuración del activo: perfil, política, software instalado
- Software instalado: fabricante, producto, versión y parches aplicados
- Equipamiento de red: MAC, IP asignada (o rango)
- Ubicación del activo: ¿dónde está?
- Propiedad del activo: persona responsable del mismo
Implementación en Legit Health Plus
Alcance del inventario
El inventario de activos de Legit Health Plus como dispositivo médico de Clase IIa incluye:
1.1 Activos de información
- Datos clínicos: Imágenes dermatológicas, historiales médicos, informes diagnósticos
- Algoritmos de IA: Modelos de aprendizaje automático para diagnóstico dermatológico
- Datos de configuración: Parámetros del sistema, configuraciones de usuarios
- Registros de auditoría: Logs de acceso, uso clínico, cambios en el sistema
- Documentación regulatoria: DHF (Design History File), certificaciones CE, FDA submissions
1.2 Activos de software
- Aplicación principal: Legit Health Plus v1.1.0.0
- Componentes de IA: TensorFlow, PyTorch, modelos propietarios
- Servicios backend: APIs REST, microservicios de procesamiento
- Bases de datos: PostgreSQL, MongoDB para almacenamiento de imágenes
- Librerías médicas: DICOM handlers, HL7 FHIR connectors
1.3 Activos de infraestructura
- Servidores cloud: AWS EC2, Azure Virtual Machines
- Contenedores: Docker, Kubernetes clusters
- Redes: VPCs, subredes, security groups
- Almacenamiento: S3 buckets, Azure Blob Storage
- CDN: CloudFront para distribución de contenido estático
Estructura del inventario
Asset_ID: LHP-[TIPO]-[NUMERO]
Tipo_Activo: [Información|Software|Infraestructura|Servicio]
Nombre: [Nombre descriptivo]
Descripción: [Descripción detallada]
Clasificación_Seguridad: [Público|Interno|Confidencial|Crítico]
Propietario: [Responsable del activo]
Custodio: [Responsable técnico]
Ubicación: [Física o lógica]
Versión: [Si aplica]
Fecha_Alta: [YYYY-MM-DD]
Estado: [Activo|Deprecado|En_Mantenimiento]
Criticidad_Médica: [Alta|Media|Baja]
Impacto_Clínico: [Directo|Indirecto|Sin_Impacto]
Categorización de activos por criticidad
Nivel 1 - Críticos (Impacto directo en diagnóstico)
- Modelos de IA para diagnóstico
- Base de datos de imágenes clínicas
- Algoritmos de scoring de severidad (ALEGI, DLQI)
- Interfaz de visualización diagnóstica
Nivel 2 - Importantes (Soporte al diagnóstico)
- Sistema de autenticación y autorización
- Logs de auditoría clínica
- APIs de integración con HIS/EMR
- Sistema de backup y recuperación
Nivel 3 - Estándar (Operación general)
- Documentación de usuario
- Herramientas administrativas
- Sistemas de monitorización
Responsabilidades
Chief Technology Officer (CTO)
- Aprobación del inventario maestro
- Revisión trimestral de activos críticos
- Autorización de nuevos activos de Nivel 1
Information Security Officer (ISO)
- Mantenimiento del inventario
- Clasificación de seguridad de activos
- Auditorías semestrales del inventario
DevOps Team Lead
- Actualización de activos de infraestructura
- Gestión de versiones de software
- Documentación de cambios técnicos
Clinical Safety Officer
- Validación de criticidad médica
- Evaluación de impacto clínico
- Revisión de activos relacionados con algoritmos diagnósticos
Procedimientos de gestión
5.1 Alta de nuevos activos
- Solicitud: Formulario T-024-001 con justificación clínica/técnica
- Evaluación: Análisis de riesgos según R-TF-013-002
- Clasificación: Asignación de nivel de criticidad y seguridad
- Registro: Entrada en base de datos CMDB
- Notificación: Comunicación a stakeholders relevantes
5.2 Actualización del inventario
- Frecuencia: Mensual para activos críticos, trimestral para el resto
- Triggers de actualización:
- Cambios en versiones de software
- Modificaciones en infraestructura
- Incidentes de seguridad
- Auditorías regulatorias
- Cambios en algoritmos de IA
5.3 Baja de activos
- Evaluación de impacto: Análisis de dependencias
- Plan de migración: Si aplica
- Sanitización: Borrado seguro según NIST SP 800-88
- Documentación: Registro en R-024-003
- Archivo: Mantener registro por 10 años (requisito MDR)
Herramientas y automatización
Sistema CMDB (Configuration Management Database)
- Herramienta: ServiceNow CMDB
- Integración: APIs con AWS Config, Azure Resource Graph
- Escaneo automático: Discovery semanal de nuevos activos
- Alertas: Notificaciones de activos no autorizados
Descubrimiento automático
# Script de descubrimiento de activos cloud
import boto3
import azure.mgmt.resource
class AssetDiscovery:
def scan_aws_resources(self):
# Escaneo de EC2, S3, RDS, Lambda
pass
def scan_azure_resources(self):
# Escaneo de VMs, Storage, SQL Database
pass
def validate_against_inventory(self):
# Comparación con inventario autorizado
pass
Métricas e indicadores
KPIs del inventario
- Completitud: % de activos documentados vs. descubiertos
- Actualización: Tiempo medio de registro de nuevos activos
- Conformidad: % de activos con clasificación completa
- Riesgos: Número de activos críticos sin propietario asignado
Reporting
- Dashboard ejecutivo: Mensual para el Board
- Informe técnico: Semanal para el equipo de seguridad
- Reporte regulatorio: Anual para auditorías MDR/FDA
Integración con otros controles ENS
- OP.EXP.2: Configuración de seguridad basada en criticidad de activos
- OP.EXP.5: Gestión de cambios vinculada al inventario
- OP.EXP.7: Priorización de incidentes según activos afectados
- MP.SI.2: Cifrado aplicado según clasificación de activos
Consideraciones específicas para dispositivo médico
Trazabilidad regulatoria
- Vinculación de cada activo software con requisitos de PRS (Product Requirements Specification)
- Mapeo con controles de ciberseguridad según FDA Cybersecurity Guidance
- Cumplimiento con IEC 62304 para activos de software médico
Gestión de algoritmos de IA
- Versionado específico de modelos de machine learning
- Registro de datasets de entrenamiento y validación
- Documentación de métricas de performance clínica
Plantilla de registro de activo
## Registro de Activo: LHP-SW-001
**Nombre**: Modelo de Diagnóstico Dermatológico v2.3
**Tipo**: Software - Algoritmo de IA
**Descripción**: Red neuronal convolucional para clasificación de lesiones cutáneas
### Información técnica
- **Framework**: TensorFlow 2.12
- **Arquitectura**: EfficientNet-B4
- **Tamaño**: 245 MB
- **Precisión diagnóstica**: 94.7% (validación clínica)
### Clasificación
- **Seguridad**: Crítico
- **Impacto clínico**: Directo - Diagnóstico
- **Requisito regulatorio**: MDR Anexo I, Requisito 17
### Gestión
- **Propietario**: Dr. Alfonso Medina (Chief Medical Officer)
- **Custodio técnico**: Taig Mac Carthy (CTO)
- **Última revisión**: 2024-01-15
- **Próxima auditoría**: 2024-07-15
### Dependencias
- Base de datos de imágenes clínicas (LHP-DAT-002)
- Servicio de preprocesamiento (LHP-SVC-003)
- API de inferencia (LHP-API-001)
### Controles de seguridad aplicados
- Cifrado en reposo: AES-256
- Control de acceso: RBAC con MFA
- Integridad: Firma digital del modelo
- Auditoría: Logging completo de inferencias
Referencias cruzadas
- T-024-001: Procedimiento de gestión de activos
- T-024-002: Clasificación de información
- R-TF-013-002: Registro de gestión de riesgos
- GP-013: Gestión de la ciberseguridad
- GP-001: Control de documentos y registros
Signature meaning
The signatures for the approval process of this document can be found in the verified commits at the repository for the QMS. As a reference, the team members who are expected to participate in this document and their roles in the approval process, as defined in Annex I Responsibility Matrix
of the GP-001
, are:
- Author: Team members involved
- Reviewer: JD-003, JD-004
- Approver: JD-001