OP.PL.3 Adquisición de nuevos componentes

Documentos de referencia

• Son de especial relevancia los siguientes principios básicos:
  • Artículo 9. Reevaluación periódica.
• ISO/IEC 27000
  • 27002:2013
    • 14.1.1 - Análisis de requisitos y especificaciones de seguridad de la información
• NIST 800-53 rev.4
  • [PL-1] Security Planning Policy and Procedures
  • [PL-2] System Security Plan
  • [PL-7] Security Concept of Operations
  • [PL-8] Information Security Architecture
  • [SA-1] System and Services Acquisition Policy and Procedures
  • [SA-3] System Development Life Cycle
  • [SA-4] Acquisition Process
  • [SA-8] Security Engineering Principles
  • [SA-12] Supply Chain Protection
• Otras referencias:
  • NIST SP 800-18 - Guide for Developing Security Plans for Federal Information Systems
  • NIST SP 800-65 - Integrating IT Security into the Capital Planning and Investment Control Process

Guía de implantación

78. La adquisición de nuevos componentes debe:

• tener en cuenta el análisis de riesgos [op.pl.1]
• ajustarse a la arquitectura de seguridad [op.pl.2]
• prever los recursos necesarios, esfuerzo y medios económicos para:
  • la implantación inicial.
  • el mantenimiento a lo largo de su vida útil.
  • atender a la evolución de la tecnología.
• en todo momento se atenderá tanto a las necesidades técnicas como a la necesaria concienciación y formación de las personas que van a trabajar con los componentes.

Implementación en Legit Health Plus

Marco de Adquisición Segura

Política de Adquisición de Componentes

Legit Health Plus implementa un proceso estructurado para la adquisición de nuevos componentes que garantiza:

• Evaluación de seguridad previa a la adquisición
• Análisis de riesgos específico según op.pl.1
• Conformidad con la arquitectura definida en op.pl.2
• Evaluación del ciclo de vida completo del componente
• Consideración de aspectos regulatorios (FDA, EU MDR, ENS)

Principios de Adquisición Segura

Principios Fundamentales:

• Security by Design: Componentes con seguridad integrada
• Supply Chain Security: Validación de la cadena de suministro
• Vendor Risk Management: Evaluación de proveedores
• Total Cost of Ownership: Coste completo del ciclo de vida
• Regulatory Compliance: Cumplimiento normativo desde el diseño
• Open Source Due Diligence: Evaluación rigurosa de componentes FOSS

Proceso de Evaluación y Selección

Fases del Proceso de Adquisición

Fases del proceso de adquisición:

El proceso de adquisición sigue un flujo secuencial de 11 fases con validaciones en cada etapa:

Fase	Actividad	Objetivo
1	Identificación de Necesidad	Determinar la necesidad de un nuevo componente
2	Evaluación Inicial	Valorar alternativas y viabilidad técnica
3	Análisis de Seguridad	Evaluar requisitos y riesgos de seguridad
4	Evaluación de Proveedores	Seleccionar y evaluar proveedores potenciales
5	Prueba de Concepto	Validar funcionalidad en entorno controlado
6	Análisis de Riesgos	Análisis detallado según op.pl.1 y R-TF-013-002
7	Evaluación Económica	Calcular TCO y ROI del componente
8	Decisión de Adquisición	Aprobación formal por comité de evaluación
9	Implementación Piloto	Despliegue controlado en entorno de prueba
10	Despliegue Producción	Puesta en producción gradual
11	Monitorización Continua	Seguimiento del rendimiento y seguridad post-despliegue

Flujo de proceso: Las fases son secuenciales y cada fase debe completarse exitosamente antes de avanzar a la siguiente. Cualquier hallazgo crítico en fases intermedias puede requerir volver a fases anteriores o cancelar la adquisición.

Criterios de Evaluación

Matriz de Evaluación por Categorías:

Categoría	Peso	Criterios de Evaluación
Seguridad (40%)
- Certificaciones	15%	Common Criteria, FIPS 140-2, ISO 27001
- Historial CVEs	10%	Número y severidad de vulnerabilidades
- Security Response	10%	Tiempo respuesta a vulnerabilidades
- Documentación	5%	Calidad documentación de seguridad
Cumplimiento (25%)
- Regulatory Alignment	15%	FDA, EU MDR, GDPR, ENS
- Standards Compliance	10%	ISO, IEC, HL7, FHIR
Técnico (20%)
- Funcionalidad	10%	Cobertura de requisitos
- Performance	5%	Rendimiento y escalabilidad
- Integración	5%	Facilidad de integración
Económico (15%)
- Coste Inicial	5%	Licencias, implementación
- Coste Operacional	10%	Mantenimiento, soporte, actualizaciones

Evaluación de Componentes por Tipo

Software de Terceros (SOUP - Software of Unknown Provenance)

Componentes SOUP Críticos en Legit Health Plus:

Componente	Categoría	Evaluación de Seguridad
FastAPI	Web Framework	✓ Análisis de vulnerabilidades
		✓ Revisión de dependencias
		✓ SBOM (Software Bill of Materials)
PyTorch	ML Framework	✓ Model security assessment
		✓ Supply chain verification
		✓ Vulnerability monitoring
OpenCV	Image Processing	✓ Buffer overflow analysis
		✓ Input validation review
		✓ Memory safety assessment

Proceso de Evaluación SOUP:

1. Análisis de Dependencias

   Herramientas utilizadas para análisis de dependencias:

Herramienta	Ámbito	Función
npm audit	Node.js dependencies	Auditoría de vulnerabilidades en dependencias npm
pip-audit	Python packages	Auditoría de seguridad de paquetes Python
safety check	Python security	Verificación de vulnerabilidades conocidas en Python
snyk test	Multi-language scanning	Escaneo de vulnerabilidades en múltiples lenguajes
trivy fs	Container scanning	Escaneo de vulnerabilidades y configuraciones

Estas herramientas se ejecutan de forma automatizada en cada cambio de dependencias para identificar vulnerabilidades conocidas antes de la integración del componente.

2. Generación de SBOM (Software Bill of Materials)

   Herramientas para generación y análisis de SBOM:

Herramienta	Función
syft	Genera SBOM completo en formato JSON de todos los paquetes
grype	Analiza el SBOM generado para identificar vulnerabilidades

El proceso genera un inventario completo de todos los componentes de software (SBOM) y posteriormente lo analiza para detectar vulnerabilidades conocidas. El SBOM se almacena como parte de la documentación del componente para trazabilidad y auditoría.

3. Validación de Integridad
   • Verificación de checksums/hashes
   • Validación de firmas digitales
   • Comprobación de fuentes oficiales

Servicios Cloud (AWS)

Evaluación de Servicios AWS:

Servicio	Función	Controles Evaluados
ECS/Fargate	Container Runtime	IAM roles, network isolation, logging
DocumentDB	Database	Encryption, backup, access controls
S3	Object Storage	Bucket policies, versioning, encryption
KMS	Key Management	HSM level, key rotation, access logging
CloudWatch	Monitoring	Log retention, access controls, alerting

Criterios de Selección AWS:

• Certificaciones de cumplimiento (SOC 2, ISO 27001, HIPAA)
• Disponibilidad de controles de seguridad granulares
• Capacidades de auditoría y logging
• Soporte para cifrado en reposo y en tránsito
• Integración con herramientas de security

Bibliotecas de Machine Learning

Evaluación Específica para ML:

Aspecto	Criterio	Implementación
Model Security	Model tampering protection	Digital signatures, checksums
Data Privacy	Training data protection	Differential privacy, federated learning
Bias Assessment	Algorithmic fairness	Bias testing frameworks
Explainability	Model interpretability	SHAP, LIME integration
Adversarial Robustness	Attack resistance	Adversarial testing

Gestión de Proveedores

Evaluación de Proveedores

Cuestionario de Evaluación de Proveedores:

Cuestionario de evaluación de proveedores:

Security Assessment (Evaluación de Seguridad):

Criterio	Opciones de respuesta
ISO 27001 certification	Yes / No
Vulnerability disclosure program	Yes / No
Security incident response	< 24h / < 1 week / > 1 week
Penetration testing frequency	Quarterly / Annual / Ad-hoc
Employee security training	Mandatory / Optional / None

Development Practices (Prácticas de Desarrollo):

Criterio	Opciones de respuesta
Secure SDLC implementation	Yes / No
Code review requirements	All code / Critical only / Optional
Static analysis tools	Yes / No
Dependency scanning	Yes / No
Container security scanning	Yes / No

Compliance (Cumplimiento Normativo):

Criterio	Opciones de respuesta
GDPR compliance	Certified / Self-assessed / No
HIPAA compliance	Yes / No / N/A
SOC 2 Type II	Yes / No
Medical device experience	Yes / No
FDA QSR experience	Yes / No

Due Diligence de Proveedores

Proceso de Verificación:

1. Verificación Legal
   • Registro mercantil
   • Estados financieros
   • Referencias comerciales
   • Seguros de responsabilidad
2. Evaluación Técnica
   • Capacidades técnicas
   • Roadmap de producto
   • Soporte técnico
   • Documentación
3. Auditoría de Seguridad
   • Certificaciones vigentes
   • Políticas de seguridad
   • Gestión de vulnerabilidades
   • Respuesta a incidentes

Análisis de Riesgos de Componentes

Integración con el Sistema de Gestión de Riesgos

Vinculación con R-TF-013-002:

Cada nuevo componente genera automáticamente:

Estructura de registro de riesgo para nuevo componente:

Cada nuevo componente genera automáticamente un registro de riesgo en R-TF-013-002 con la siguiente estructura:

Campo	Valor para nuevo componente
ID	R-NEW (asignado automáticamente)
Tipos de riesgo	Product, Cybersecurity
Peligro o error de uso	Introducción de vulnerabilidades por nuevo componente
Propiedades de seguridad	Confidentiality, Integrity, Availability
Referencias modelo amenaza	T-024-006 (modelo de amenazas de ciberseguridad)
Referencias componente	COMP-XXX (identificador del componente nuevo)
Severidad inicial	TBD (a determinar durante evaluación)
Severidad controlada	TBD (a determinar tras implementación de controles)
Requisitos de mitigación	Evaluación previa obligatoria, Monitorización continua post-despliegue

Este registro se actualiza a lo largo del proceso de adquisición conforme se completan las fases de evaluación y se implementan controles de mitigación.

Análisis de Impacto

Matriz de Impacto por Componente:

Tipo de Componente	Impacto Potencial	Controles Requeridos
SOUP Critical	Alto	Análisis exhaustivo, sandbox testing
SOUP Non-Critical	Medio	Análisis estándar, monitoring
Cloud Services	Variable	Service-specific assessment
ML Libraries	Alto	Bias testing, adversarial testing
Crypto Libraries	Crítico	FIPS validation, expert review

Proceso de Implementación

Implementación Gradual

Fases de Implementación:

Fases de implementación gradual:

La implementación sigue un modelo de despliegue progresivo con testing específico en cada fase:

Fase	Testing asociado	Objetivo
Development	Unit Testing	Validación de funcionalidad básica del componente
Staging	Integration Testing	Pruebas de integración con sistemas existentes
Pre-Production	Security Testing	Validación de controles de seguridad
Production Pilot	User Acceptance	Validación con usuarios reales en entorno limitado
Full Deployment	Full Monitoring	Despliegue completo con monitorización exhaustiva

Flujo de implementación: Cada fase debe completarse exitosamente incluyendo su testing asociado antes de avanzar a la siguiente. El componente se despliega progresivamente desde entornos controlados (Development) hasta producción completa (Full Deployment), permitiendo detectar y corregir problemas en cada etapa.

Gates de Calidad

Security Gates obligatorios:

Gate	Fase	Criterios de Paso
Gate 1	Development	SAST sin críticos, dependencias actualizadas
Gate 2	Staging	DAST sin altos, configuración hardened
Gate 3	Pre-Prod	Penetration test OK, DR tested
Gate 4	Production	Security review completo, monitoring activo

Gestión del Ciclo de Vida

Monitorización Continua

Indicadores de Salud del Componente:

Indicadores de salud del componente:

Security Metrics (Métricas de Seguridad):

Métrica	Objetivo/Umbral
CVE count (last 12 months)	< 5 critical
Patch deployment time	< 7 días
Security alert response	< 24 horas
Vulnerability scan results	No critical/high

Performance Metrics (Métricas de Rendimiento):

Métrica	Objetivo/Umbral
Availability	> 99.9%
Response time	< 200ms p95
Error rate	< 0.1%
Resource utilization	< 80%

Compliance Metrics (Métricas de Cumplimiento):

Métrica	Objetivo/Umbral
Audit findings	0 critical
Policy violations	0
License compliance	100%
Documentation currency	< 30 días de antigüedad

Estos indicadores se monitorizan de forma continua y cualquier desviación de los umbrales establecidos genera alertas automáticas para investigación y remediación.

End-of-Life Management

Proceso de Decommissioning:

1. Identificación de EOL
   • Monitoring de vendor announcements
   • Tracking de support timelines
   • Assessment de replacement options
2. Planificación de Migración
   • Risk assessment de continuidad
   • Selection de replacement
   • Migration timeline
3. Ejecución Controlada
   • Parallel running period
   • Gradual cutover
   • Decommissioning seguro

Consideraciones Específicas para Dispositivos Médicos

Requisitos Regulatorios

FDA Requirements:

• Pre-market notification para cambios significativos
• Validación de SOUP según IEC 62304
• Documentación de análisis de riesgos
• Post-market surveillance de componentes

EU MDR Requirements:

• Clinical evaluation de cambios
• Technical documentation update
• Notified body notification si aplica
• UDI database update

Validación Clínica

Impacto en Eficacia Clínica:

Tipo de Cambio	Validación Requerida
Algoritmo ML	Clinical validation completa
UI Components	Usability testing
Infrastructure	Performance validation
Security Components	Security testing + risk analysis

Documentación y Trazabilidad

Registro de Componentes

Component Configuration Management Database (CCMDB):

Estructura de registro de componente en CCMDB:

Cada componente se registra en la Component Configuration Management Database con la siguiente estructura:

Información básica del componente:

Campo	Descripción
ID	COMP-XXX (identificador único)
Name	Nombre del componente
Version	x.y.z (versión semántica)
Vendor	Nombre del proveedor
Category	SOUP / Cloud / Internal
Criticality	Critical / High / Medium / Low

Security Assessment (Evaluación de seguridad):

Campo	Descripción
Completed date	YYYY-MM-DD (fecha de finalización de evaluación)
Assessor	Nombre del evaluador
Findings	Lista de hallazgos de seguridad
Recommendations	Recomendaciones de seguridad

Risk Analysis (Análisis de riesgos):

Campo	Descripción
Risk ID	R-XXX (referencia al registro en R-TF-013-002)
Residual risk	Acceptable / AFAP / Not Acceptable

Lifecycle (Ciclo de vida):

Campo	Descripción
Acquisition date	YYYY-MM-DD (fecha de adquisición)
EOL date	YYYY-MM-DD (fecha prevista de fin de vida)
Replacement plan	Plan de sustitución del componente

Auditoría y Compliance

Evidencias Requeridas:

• Justificación de selección
• Análisis comparativo de alternativas
• Assessment de seguridad completo
• Aprobaciones por comité de arquitectura
• Registros de testing y validación
• Documentación de deployment
• Métricas de performance post-deployment

Roles y Responsabilidades

Comité de Evaluación de Componentes

Miembros del Comité:

Rol	Responsabilidad
CTO	Decisión final, presupuesto
CISO	Evaluación de seguridad
QA/RA Manager	Cumplimiento regulatorio
Solution Architect	Impacto técnico
Procurement	Evaluación comercial

RACI Matrix

Actividad	CTO	CISO	QA/RA	Architect	Procurement
Identificación necesidad	C	C	C	R	I
Evaluación seguridad	A	R	C	C	I
Análisis riesgos	A	R	C	C	I
Selección proveedor	A	C	C	C	R
Aprobación adquisición	R	C	C	C	A
Implementación	A	C	C	R	I

Métricas y KPIs

Métricas de Proceso

KPI	Objetivo	Frecuencia
Tiempo medio de evaluación	< 30 días	Mensual
Tasa de rechazo en gates	< 10%	Mensual
Coste medio de evaluación	< 10% precio componente	Trimestral
Vulnerabilidades post-deployment	0 críticas	Continua

Métricas de Resultado

Indicador	Target	Estado Actual
Componentes sin vulnerabilidades críticas	100%	98%
Tiempo medio de patch deployment	< 7 días	5 días
Satisfacción con nuevos componentes	> 4/5	4.2/5
ROI de componentes adquiridos	> 150%	180%

Herramientas y Automatización

Pipeline de Evaluación Automatizada

PRO-COMP-ASSESS-001: Pipeline automatizado de evaluación de componentes

Objetivo: Ejecutar automáticamente evaluaciones de seguridad cuando se modifican dependencias del proyecto.

Triggers (Desencadenantes):

• Pull requests que modifican archivos de dependencias:
  • requirements.txt (Python)
  • package.json (Node.js)
  • Dockerfile (containers)

Pasos del proceso automatizado:

Paso	Actividad	Herramienta	Objetivo
1	Checkout code	GitHub Actions	Obtener código fuente del repositorio
2	Run Trivy scan	Trivy (aquasecurity)	Escanear vulnerabilidades en dependencias y configuración
3	Generate SBOM	syft	Generar Software Bill of Materials en formato JSON
4	Vulnerability assessment	grype	Analizar SBOM para identificar vulnerabilidades
5	License compliance check	license-checker	Verificar cumplimiento de licencias
6	Upload results	GitHub CodeQL	Subir resultados en formato SARIF para revisión

Resultado: El pipeline genera un informe completo de seguridad que debe ser revisado y aprobado antes de integrar los cambios de dependencias. Cualquier vulnerabilidad crítica o alta bloquea automáticamente la integración hasta su resolución.

Dashboard de Componentes

Métricas en Tiempo Real:

• Inventario de componentes por estado
• Vulnerabilidades pendientes de parcheo
• EOL timeline de componentes críticos
• Compliance status por framework
• Coste acumulado por componente

Anexo A: Checklist de Evaluación

Pre-Acquisition Checklist:

• Necesidad de negocio claramente definida
• Alternativas evaluadas (incluido desarrollo interno)
• Análisis de riesgos completado (referencia en R-TF-013-002)
• Arquitectura de seguridad revisada (alineación con T-024-009)
• Evaluación de proveedor completada
• POC exitosa con criterios de aceptación
• TCO calculado incluyendo ciclo de vida completo
• Plan de implementación definido
• Estrategia de monitorización establecida
• Plan de contingencia documentado
• Aprobaciones obtenidas según matriz RACI
• Documentación en CCMDB actualizada

Anexo B: Plantilla de Análisis de Riesgos

Plantilla de análisis de riesgos de componente:

Información general del assessment:

Campo	Descripción
Component ID	COMP-XXX (identificador del componente)
Assessment date	YYYY-MM-DD (fecha de evaluación)
Assessor	Nombre del evaluador

Riesgos identificados (para cada riesgo):

Campo	Descripción	Valores posibles
ID	R-XXX (identificador único del riesgo)	—
Description	Descripción del riesgo identificado	—
Category	Categoría del riesgo	Security / Operational / Compliance
Probability	Probabilidad de ocurrencia	1-5 (1=Muy baja, 5=Muy alta)
Impact	Impacto si ocurre	1-5 (1=Insignificante, 5=Catastrófico)
Risk level	Nivel de riesgo calculado	Low / Medium / High / Critical
Mitigation measures	Medidas de mitigación implementadas	Lista de medidas
Residual risk	Riesgo residual tras mitigación	Acceptable / AFAP / Not Acceptable

Evaluación global:

Campo	Descripción	Valores posibles
Overall assessment	Decisión final sobre el componente	Approved / Conditional / Rejected
Conditions	Condiciones si la aprobación es condicional	Lista de condiciones
Review date	Fecha de próxima revisión	YYYY-MM-DD

Esta plantilla se completa para cada componente nuevo y se actualiza periódicamente según el ciclo de reevaluación establecido.

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