I sistemi SAP sono il cuore pulsante di migliaia di organizzazioni nel mondo: gestiscono processi finanziari, catene di fornitura, dati HR e molto altro. Proprio per questo rappresentano un obiettivo ad altissimo valore per gli attaccanti. Eppure, la sicurezza SAP è spesso trattata come un argomento di nicchia, separato dalle pratiche di cybersecurity tradizionale.
Il threat detection modeling per SAP colma questo gap: fornisce un framework strutturato per identificare, classificare e monitorare le minacce specifiche dell’ecosistema SAP, integrando queste informazioni con i processi SOC (Security Operations Center) aziendali.
I sistemi SAP presentano caratteristiche che li rendono unici dal punto di vista della threat detection. A differenza di una normale applicazione web, SAP gestisce transazioni business-critical con un proprio linguaggio (ABAP), protocolli di rete proprietari (RFC, DIAG), e un modello di autorizzazione estremamente granulare.
Le principali superfici di attacco includono ad esempio:
Layer RFC/ABAP: chiamate Remote Function Call non autorizzate, esecuzione di codice ABAP malevolo, backdoor nei programmi custom
Gestione delle identità: uso improprio di utenze di sistema (es quelle speciali e note DDIC, SAP*), privilege escalation, account condivisi non tracciati
Interfacce esterne: attacchi tramite SAP Web Dispatcher, ICM (Internet Communication Manager), endpoint HTTP/S non protetti
Transport & Change: importazione di trasporti malevoli, modifiche non autorizzate in produzione, bypass dei processi di change management
Un modello di threat detection efficace per SAP si struttura in quattro fasi principali. L’obiettivo non è solo rilevare gli attacchi, ma costruire una mappa completa delle minacce che permetta di prioritizzare gli investimenti in sicurezza.
Prima di modellare le minacce, è necessario avere una visione chiara degli asset SAP: sistemi (ECC, S/4HANA, BW, PI/PO, Solution Manager, BTP, Cloud/OnPremise), mandanti, interfacce. Si mappano i flussi di dati tra i sistemi per identificare i punti di ingresso e i percorsi che un attaccante potrebbe seguire.
Il modello STRIDE (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) viene esteso con categorie SAP-specifiche.
Ogni minaccia viene mappata alle transazioni, ai log e agli indicatori di compromissione (IoC) rilevanti. Ad esempio Security Audit Log (SM20 - RSAU_READ_LOG ), System Log (SM21), table trace Log (SCU3), Gateway Log e, per i sistemi HANA, Security Audit log a livello di database.
La verifica ed attivazione dei log è il presupposto indispensabile per qualsiasi attività di detection.
Per ogni minaccia identificata si progettano le regole di rilevamento.
Una regola è composta da: sorgente del log, condizione di trigger, parametri di correlazione, soglia di alerting e severity.
Le regole vengono potenzialmente implementate nel SIEM aziendale (es. Splunk, Microsoft Sentinel, IBM QRadar) o in soluzioni specifiche come ad esempio SAP Enterprise Threat Detection (ETD), SecurityBridge, redrays, Pathlock (CAC), Onapsis.
Il risultato finale è una matrice che associa ciascuna minaccia alla sua probabilità, all’impatto potenziale e alla copertura di detection disponibile. Questo strumento guida le decisioni del SOC (Security Operation Center) e degli audit di sicurezza.
| Minaccia | Vettore | Log sorgente | Severity |
| Login con utenza SAP* o DDIC | Spoofing / Privilege Escalation | SM20-RSAU_READ_LOG (Audit Log) | CRITICA |
| Esecuzione RFC remota non autorizzata | Lateral Movement | SAP Security Audit Log | CRITICA |
| Modifica diretta in tabelle di sistema | Tampering | SCU3 (Table Trace) | ALTA |
| Accesso a dati sensibili fuori orario | Information Disclosure | Workload analysis / Security Audit Log / Read Access Log | ALTA |
| Importazione trasporto in produzione | Tampering | STMS / Change Document / Table Trace | MEDIA |
Scenario: un attaccante ottiene le credenziali di un utente tecnico SAP con autorizzazioni RFC ampie. Inizia a interrogare moduli funzione sensibili (RFC_READ_TABLE, SUSR_USER_AUTH_FOR_OBJ_GET) per estrarre dati e mappare le autorizzazioni.
Lo scenario passo per passo:
L’attaccante esegue login RFC dall’IP 192.168.10.45 con l’utenza RFC_BATCH, orario inusuale (02:17)
Viene chiamato il modulo RFC_READ_TABLE su tabella USR02 (questa tabella contiene l'elenco delle utenze, gli stati attive o meno, gli hash delle password)
Seguono 34 chiamate a moduli SUSR* in meno di 90 secondi
Il SIEM correla: IP anomalo + orario notturno + tabelle sensibili alert severity CRITICA
La logica della regola è volutamente semplice ma efficace. Il risk score combina tre segnali: volume di chiamate, orario notturno (che pesa molto) e diversità di moduli interrogati.
Il secondo scenario riguarda una delle minacce insider più insidiose nell’ecosistema SAP: un utente con accesso alla transazione SU01 (gestione utenti) che crea o modifica account per ottenere privilegi elevati, combinando l’azione con accessi diretti alle tabelle tramite SE16N per cancellare le tracce o manipolare dati.
Questo attacco è particolarmente pericoloso perché sfrutta funzionalità legittime del sistema infatti, la transazione SU01 è una transazione di amministrazione "ordinaria" per la gestione delle utenze, e la SE16/SE16N è uno strumento di visualizzazione tabelle comunemente usato dai team IT.
La deviazione malevola si individua solo analizzando il comportamento nel contesto e nella correlazione degli eventi.
Vediamo l'esempio:
L’utente ADMBASIS esegue la transazione SU01 e crea il nuovo utente SVCTMP01 (senza seguire il processo di provisioning standard, nessun ticket collegato o strumento di provisioning)
Al nuovo utente viene assegnato il profilo SAP_ALL tramite la transazione SU01, conferendo accesso illimitato a tutti i moduli SAP
SVCTMP01 una volta entrato a sistema avvia la transazione SE16N sulla tabella BSEG (partite contabili, ACDOCA nel contesto S/4HANA) e modifica direttamente valori di importo su transazioni già contabilizzate, sta utilizzando una funzione di DEBUG senza controllo e senza potenziali tracce
Infine, ADMBASIS torna su SU01 e disabilita l’utente SVCTMP01 nel tentativo di eliminare la traccia dell’account temporaneo
La strategia di detection si articola in due regole correlate: la prima rileva la creazione di utenti con profili critici senza processo autorizzativo; la seconda individua le scritture dirette su tabelle sensibili tramite SE16N, transazione che per default non dovrebbe avere capacità di modifica in produzione.
Il punto di attenzione di questo scenario emerge dalla correlazione delle due regole. Un alert su Regola A seguito ad esempio entro 30 minuti da un alert su Regola B. Con lo stesso utente creatore come denominatore comune. Eleva automaticamente la priorità dell’incidente e deve innescare una risposta immediata del SOC con potenziale blocco preventivo dell’account coinvolto.
Non sempre semplice da attuale il tutto, per arrivare qui servono strumenti, regole e maturità aziendale sul tema.
Un threat model SAP non vive in isolamento. Per essere efficace, deve integrarsi con il processo SOC aziendale. Alcuni principi chiave:
contesto business-aware: gli analisti SOC devono conoscere il significato business delle transazioni SAP. Un accesso a SE16N da un utente IT a fine trimestre è probabilmente legittimo; lo stesso accesso da un utente IT alle 3 di notte è sospetto
Playbook di risposta dedicati: per ogni categoria di minaccia SAP deve esistere un playbook di incident response specifico, che include i passi di triage e le parti da coinvolgere (team Basis, CISO, compliance)
Revisione continua: il modello va aggiornato ad ogni patch SAP importante, ad ogni nuovo sistema introdotto e almeno semestralmente. Ad esempio l’introduzione di sistemi cloud SAP BTP, SAP Fiori o integrazioni ulteriori introducono nuove superfici che richiedono nuove regole