Esempi di "Autoprotezione dell'applicazione Runtime" (RASP) in azione?

5

Sto avendo difficoltà a capire cosa sia realmente "Runtime Application Self-Protection" (RASP), anche se lo vedo menzionato sulla stampa. La migliore descrizione che ho visto dei possibili benefici, insieme ad alcuni limiti, è in questo articolo L'auto-protezione dell'applicazione runtime è una scorciatoia per proteggere il software?

Ma questo ancora non fornisce esempi pratici.

C'è qualche software open source che fa questo? Qualche framework che lo fornisce? Qualcosa di simile alla protezione dei falsi con richiesta di cross site in Django sarà un esempio?

    
posta nealmcb 11.04.2015 - 17:06
fonte

3 risposte

3

RASP utilizza un'applicazione ingenua e consente di identificare gli attacchi e bloccarli. Esistono diversi approcci diversi tra cui filtri, sandbox e strumentazione completa. Ecco un buon articolo indipendente su RASP che descrive i casi d'uso e gli approcci: link .

Diamo un'occhiata a un semplice esempio di iniezione SQL. Un'applicazione ingenua semplicemente non ha difesa e viene sfruttata. Un'applicazione che utilizza PreparedStatements è sicura contro l'iniezione, ma non ha idea se sia stata attaccata o meno. Vediamo come funziona con RASP. Sto descrivendo l'approccio della strumentazione di Contrast qui.

In primo luogo, il RASP viene installato nell'applicazione. In questo caso, è sufficiente aggiungere semplicemente l'agente RASP all'ambiente. Quando il codice viene caricato, il RASP utilizza la strumentazione binaria dinamica per aggiungere nuovi sensori di sicurezza e funzionalità di analisi all'applicazione. Questo processo è molto simile a come NewRelic o AppDynamics funzionano per strumentare un'applicazione per le prestazioni.

Quando l'attacco arriva all'applicazione, RASP utilizza i dati relativi alla richiesta, all'utente, alla sessione e a qualsiasi altra informazione contestuale. I dati della richiesta dell'attacker vengono tracciati attraverso l'applicazione. Se sembra un attacco, ma non raggiunge mai una query SQL, viene segnalato come sonda. Questa è una grande differenza rispetto a ciò che può fare un WAF, poiché i WAF non sono in grado di vedere cosa succede all'interno dell'applicazione e devono essere sottoposti a overblock.

Se l'attacco raggiunge effettivamente una query SQL e modifica il significato di tale query, solo allora RASP blocca l'attacco. Questo essenzialmente sta rafforzando la definizione di SQL Injection, poiché sono bloccati solo gli attacchi che modificano con successo il significato delle query SQL. Questo è il motivo per cui l'implementazione RASP può essere implementata senza molta configurazione o formazione.

In definitiva, l'utente ottiene visibilità su chi sta attaccando le loro applicazioni, da dove provengono gli attacchi, le tecniche utilizzate, la riga esatta del codice che viene presa di mira e la query SQL completa contenente l'attacco. Il numero di attacchi vitali è solo una piccola parte delle sonde generali che non hanno mai colpito una vulnerabilità corrispondente. Quindi i risultati sono molto diversi da quelli che un WAF può fornire.

Il processo è più o meno lo stesso per altre vulnerabilità. Sebbene, RASP possa aggiungere protezioni specifiche per vulnerabilità conosciute in librerie e componenti. RASP può anche aggiungere registrazioni di sicurezza o altre funzionalità di sicurezza alle applicazioni.

    
risposta data 05.04.2017 - 18:42
fonte
3

lascia che ti dia una breve risposta per iniziare una discussione, potenzialmente con un pregiudizio, da qualcuno che lavora per un'azienda che vende RASP. Ho visto che nessuno ha risposto per un po '.

Comprendiamo RASP come qualcosa che diventa parte del binario dell'app. Utilizzando la scansione del codice si sviluppa un'app sicura, ma per mantenerla protetta è necessario rafforzare l'applicazione contro attacchi statici e dinamici come reverse engineering, patching, decompilazione, debug, swizzling, hook API, sollevamento chiave crittografica ecc. Vedere le contromisure dei principali rischi mobili OWASP, ad esempio.

Alcune contromisure rilevano il patching tramite il checksum, ad es. e quindi potresti conoscere alcune tecniche per offuscare il flusso di controllo, evitare stringhe letterali nell'app, rilevare swizzling, debug o hook API ecc. Ma potrebbero esserci più tecniche sconosciute in RASP che implementano prodotti come la riparazione del codice (per il codice che è stato patchato) e azioni personalizzate. Una volta che l'app stessa capisce che è stata manomessa, RASP dovrebbe darti dei modi per comportarti in modo intelligente, un'azione personalizzata. Con smart intendo non solo chiudere o arrestare un'app o far apparire un dialogo che qualcosa non è come previsto, ma limitare la funzionalità, distruggere le chiavi crittografiche o qualsiasi altra azione personalizzata intelligente per un'applicazione specifica.

Queste contromisure contro determinati attacchi fanno tutti parte dell'app e la sicurezza va dove va l'app e non si basa su nulla di più installato su un dispositivo. Un segreto importante di alcuni prodotti RASP è il modo in cui la sicurezza stessa difende da tutti questi attacchi.

Ha senso?

    
risposta data 11.05.2015 - 10:24
fonte
1

C'è qualcosa chiamato OWASP AppSensor. Hanno scritto che il loro concetto è molto simile al RASP di Gartner, con la differenza che Gartner è focalizzato su "vendors-offerings" e OWASP ha costruito un framework che può consentire "l'integrazione profonda del codice".

Sembra che il primo possa implementare un comportamento più specifico ma il concetto è in realtà abbastanza simile.

Un altro esempio simile che posso pensare è HDIV in Java , anche se non sono sicuro delle sue capacità di runtime.

    
risposta data 02.09.2015 - 12:38
fonte

Leggi altre domande sui tag