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

1. Marco de Adquisición Segura

1.1 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)

1.2 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

2. Proceso de Evaluación y Selección

2.1 Fases del Proceso de Adquisición

2.2 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

3. Evaluación de Componentes por Tipo

3.1 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
   npm audit                    # Node.js dependencies
   pip-audit                    # Python packages
   safety check                 # Python security
   snyk test                    # Multi-language scanning
   trivy fs --security-checks vuln,config .  # Container scanning

2. Generación de SBOM

   # Software Bill of Materials
   syft packages dir:. -o json > sbom.json
   grype sbom.json              # Vulnerability analysis

3. Validación de Integridad

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

3.2 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

3.3 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

4. Gestión de Proveedores

4.1 Evaluación de Proveedores

Cuestionario de Evaluación de Proveedores:

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

Development Practices:
  - 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:
  - 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

4.2 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

5. Análisis de Riesgos de Componentes

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

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

Cada nuevo componente genera automáticamente:

{
  "id": "R-NEW",
  "types": ["Product", "Cybersecurity"],
  "hazardOrUseError": "Introducción de vulnerabilidades por nuevo componente",
  "securityProperty": ["Confidentiality", "Integrity", "Availability"],
  "threatModelRefs": ["T-024-006"],
  "newComponentRefs": ["COMP-XXX"],
  "severity": {
    "initial": "TBD",
    "controlled": "TBD"
  },
  "mitigationRequirements": ["Evaluación previa", "Monitorización continua"]
}

5.2 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

6. Proceso de Implementación

6.1 Implementación Gradual

Fases de Implementación:

6.2 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

7. Gestión del Ciclo de Vida

7.1 Monitorización Continua

Indicadores de Salud del Componente:

Security Metrics:
  - CVE count (last 12 months): < 5 critical
  - Patch deployment time: < 7 days
  - Security alert response: < 24 hours
  - Vulnerability scan results: No critical/high

Performance Metrics:
  - Availability: > 99.9%
  - Response time: < 200ms p95
  - Error rate: < 0.1%
  - Resource utilization: < 80%

Compliance Metrics:
  - Audit findings: 0 critical
  - Policy violations: 0
  - License compliance: 100%
  - Documentation currency: < 30 days old

7.2 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

8. Consideraciones Específicas para Dispositivos Médicos

8.1 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

8.2 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

9. Documentación y Trazabilidad

9.1 Registro de Componentes

Component Configuration Management Database (CCMDB):

Component Record:
  id: COMP-XXX
  name: "Component Name"
  version: "x.y.z"
  vendor: "Vendor Name"
  category: "SOUP|Cloud|Internal"
  criticality: "Critical|High|Medium|Low"

  security_assessment:
    completed_date: "YYYY-MM-DD"
    assessor: "Name"
    findings: [...]
    recommendations: [...]

  risk_analysis:
    risk_id: "R-XXX"
    residual_risk: "Acceptable"

  lifecycle:
    acquisition_date: "YYYY-MM-DD"
    eol_date: "YYYY-MM-DD"
    replacement_plan: "..."

9.2 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

10. Roles y Responsabilidades

10.1 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

10.2 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

11. Métricas y KPIs

11.1 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

11.2 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%

12. Herramientas y Automatización

12.1 Pipeline de Evaluación Automatizada

# .github/workflows/component-assessment.yml
name: Component Security Assessment
on:
  pull_request:
    paths:
      - "requirements.txt"
      - "package.json"
      - "Dockerfile"

jobs:
  security-scan:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Run Trivy scan
        uses: aquasecurity/trivy-action@master

      - name: Generate SBOM
        run: syft packages dir:. -o json

      - name: Vulnerability assessment
        run: grype sbom.json -o json

      - name: License compliance check
        run: license-checker --production --summary

      - name: Upload results
        uses: github/codeql-action/upload-sarif@v2

12.2 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

{
  "component_risk_assessment": {
    "component_id": "COMP-XXX",
    "assessment_date": "YYYY-MM-DD",
    "assessor": "Name",
    "risks_identified": [
      {
        "id": "R-XXX",
        "description": "Risk description",
        "category": "Security|Operational|Compliance",
        "probability": 1-5,
        "impact": 1-5,
        "risk_level": "Low|Medium|High|Critical",
        "mitigation_measures": ["..."],
        "residual_risk": "Acceptable|AFAP|Not Acceptable"
      }
    ],
    "overall_assessment": "Approved|Conditional|Rejected",
    "conditions": ["..."],
    "review_date": "YYYY-MM-DD"
  }
}

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