CSA-5: Onboarding SOC

Descrizione

L’integrazione con il Security Operations Centre (SOC) garantisce che i sistemi siano monitorati per minacce di sicurezza e che gli incidenti siano gestiti rapidamente. I team DEVONO (MUST) pianificare l’onboarding SOC presto nel ciclo di delivery.

Guida

Quando pianificare l’onboarding SOC

L’onboarding SOC DEVE (MUST) essere pianificato:

Early planning: Durante la fase di design dell’architettura
Before production: Completato prima del go-live in produzione
For all systems: Tutti i sistemi che gestiscono dati sensibili o servizi critici

Non aspettare fino alla fine del progetto - l’integrazione SOC richiede configurazione e testing che può richiedere settimane.

Requisiti per l’onboarding

Prima dell’onboarding, i team DEVONO (MUST) avere:

Logging centralizzato: CloudTrail, VPC Flow Logs, Application Logs configurati
Alert configurati: Security events che devono essere monitorati
Documentazione: Architettura, data flow, security controls
Runbook: Procedure per incident response
Contact list: Escalation path e on-call contacts

Processo di onboarding

Kickoff meeting: Presentare il sistema al team SOC
Log integration: Configurare forwarding dei log al SIEM del SOC
Alert tuning: Calibrare gli alert per ridurre false positives
Testing: Simulare security events per verificare detection e response
Go-live: Attivare il monitoraggio in produzione
Post-go-live review: Review dopo 30 giorni per ottimizzazioni

Dati da fornire al SOC

Il SOC DEVE (MUST) ricevere:

Security logs:
- Authentication events (login, logout, failed attempts)
- Authorization changes (IAM, permissions)
- Network traffic (VPC Flow Logs, NSG Flow Logs)
- Configuration changes (CloudTrail, Activity Logs)
- Data access (accesso a risorse sensibili)
Contextual information:
- Asset inventory (servizi, IP addresses, owners)
- Baseline behavior (traffico normale, pattern di utilizzo)
- Known vulnerabilities e mitigazioni
- Business impact per servizi critici

Alerting al SOC

Gli alert DEVONO (MUST) essere categorizzati per priorità:

Severity	Descrizione	Response time	Esempi
CRITICAL	Impatto immediato su sicurezza/disponibilità	< 15 minuti	Data breach, ransomware, complete outage
HIGH	Potenziale impatto significativo	< 1 ora	Brute force attacks, privilege escalation
MEDIUM	Richiede investigazione	< 4 ore	Unusual access patterns, policy violations
LOW	Informativo	< 24 ore	Minor config changes, non-critical errors

Incident response

Il team DEVE (MUST) collaborare con il SOC per:

Playbook: Procedure documentate per scenari comuni
Communication: Canali chiari per incident communication (Slack, MS Teams, email)
Escalation: Chi contattare e quando
Post-incident: Blameless post-mortem dopo ogni incident

Testing e esercitazioni

DOVREBBE (SHOULD) essere condotto:

Tabletop exercises: Simulazioni di scenari di security incident
Red team exercises: Penetration testing con detection testing
Alert testing: Verificare che gli alert arrivino al SOC
Runbook validation: Testare le procedure di incident response

Ongoing collaboration

Dopo l’onboarding, i team DOVREBBERO (SHOULD):

Monthly reviews: Review mensile con il SOC per ottimizzazioni
Threat intelligence sharing: Condividere informazioni su nuove minacce
Update documentation: Mantenere aggiornata la documentazione
Training: Formare il team su security awareness

Misurazione

Stato	Criteri
🟢 VERDE	SOC integrato con alerting live, testing completato, runbook validati
🟡 AMBRA	SOC engagement iniziato ma integrazione non completa
🔴 ROSSO	Nessun engagement con il SOC, sistemi non monitorati