Controllare la sicurezza di un'app? Ecco 8 cose da non dimenticare

1) Abbiamo preparato una lista di controllo?

"Quando cerchiamo di determinare se un'app o un servizio è sicuro, di solito seguiamo una lista di controllo preparata", spiega Chromek. Chromek consiglia di avere due liste di controllo: una incentrata su ciò che è necessario cercare nel contratto di licenza dell'app o nei termini di servizio dell'applicazione, e una relativa all'applicazione stessa e al suo utilizzo. La prima lista di controllo può essere basata sullo standard ISO 27002 e la seconda sullo standard OWASP (mobile) per la verifica della sicurezza delle applicazioni, oltre che sulle vostre esperienze precedenti. Cosa dovrebbero includere? Le seguenti domande forniranno una guida.

2) Il contratto prevede un accordo di non divulgazione?

Per qualsiasi applicazione, gli specialisti IT devono assicurarsi che il contratto includa un accordo di non divulgazione (NDA). "In termini di servizio, un NDA è spesso definito solo in modo vago. Di solito possiamo trovare una frase generica sulla protezione dei dati, ma se vogliamo essere sicuri che l'app sia sicura, potremmo dover cercare ulteriori informazioni. Ulteriori dati possono essere inclusi, ad esempio, nella descrizione della sicurezza di un'app o nei rapporti di audit sulla sicurezza (ad esempio, il rapporto SOC2). Questi possono dare agli specialisti IT un indizio su cosa succede ai dati nell'app, se sono crittografati o meno, e così via", dice Chromek. Un altro aspetto da tenere in considerazione quando si parla di NDA è cosa succede ai dati dopo la fine dell'utilizzo dell'app. "Continueranno a essere protetti? Verranno cancellati? Sono domande importanti a cui bisogna rispondere prima di determinare la sicurezza di un'app", aggiunge il CIO di ESET.

3) Cosa succede quando l'app si guasta o subisce un'interruzione?

"Dobbiamo ricordare che un'app può fare affidamento su un servizio che può fallire. Quindi, dobbiamo chiederci: cosa succede ai nostri dati quando il servizio non funziona?". dice Chromek. Uno specialista IT dovrebbe verificare come il contratto affronta i possibili guasti del servizio e cercare eventuali rapporti o pagine di stato che forniscano statistiche che mostrino la frequenza delle interruzioni dell'app e la loro durata. Un contratto di servizio dovrebbe anche specificare il tipo di risarcimento che i clienti devono aspettarsi quando il servizio fallisce o quando il rapporto tra funzionalità e guasti si discosta dai numeri previsti. Esistono diversi tipi di guasti che l'applicazione può subire: da un piccolo problema interno a grandi guasti di continuità aziendale (come l'incendio del data center OVHcloud) e persino "guasti di potenza superiore" (ad esempio, a causa di guerre o calamità naturali). Gli indennizzi previsti saranno solitamente diversi in ciascuno di questi casi e alcuni degli scenari sopra citati possono essere inclusi in paragrafi di limitazione di responsabilità o di forza maggiore.

4) Possiamo effettuare penetration test?

Anche se i termini di servizio sembrano buoni, lo stato tecnico effettivo della sicurezza del servizio potrebbe non esserlo. Molte applicazioni e servizi non forniscono informazioni sui test di sicurezza nei loro rapporti e, inoltre, i termini e le condizioni spesso vietano rigorosamente azioni che sono parte integrante dei test, come tentare un accesso non autorizzato o bypassare l'autenticazione. Tuttavia, i penetration possono essere essenziali per determinare se il servizio protegge i dati dei clienti in modo efficace o meno. Gli specialisti IT dovrebbero quindi cercare di comunicare con gli sviluppatori di un'applicazione e ottenere maggiori informazioni sui risultati dei test di penetrazione che l'applicazione ha superato in passato, oppure cercare di creare un accordo separato che consenta lo svolgimento dei penetration test.

5) L'app è sviluppata e gestita in modo sicuro?

Tornando al fatto che potreste utilizzare un servizio diverso solo installando un'app, gli specialisti IT non devono solo determinare se l'app stessa è sicura, ma anche assicurarsi che sia sviluppata e gestita in modo sicuro. Per ottenere queste informazioni, devono cercare i rapporti di audit già esistenti, come il rapporto SOC2 di tipo II, oppure far controllare il nuovo fornitore.

 6) Qual è il piano di risposta del fornitore agli incidenti di sicurezza?

Oltre ai problemi di interruzione occasionale, un'app può incorrere in altri incidenti gravi, tra cui le violazioni dei dati. "Quando ciò accade, dobbiamo assicurarci che il fornitore ci informi. Poiché le aziende hanno una responsabilità nei confronti dei loro clienti, partner e dipendenti, devono rispondere rapidamente a qualsiasi incidente", afferma Chromek. Se i servizi trattano dati personali, la necessità di notificare le violazioni può derivare da normative come il GDPR o il CCPA.

7) Come si comporta l'applicazione con la proprietà intellettuale?

Gli specialisti IT dovrebbero prestare molta attenzione a come l'app controllata tratta la proprietà intellettuale. "Il contratto può spesso affermare che l'app non è responsabile di alcun contenuto scaricato per proteggere i fornitori di servizi da azioni legali in materia di copyright (ad esempio, in base al DMCA). Può anche specificare che alcuni contenuti possono essere utilizzati dall'app per scopi specifici, come "miglioramenti del servizio", che possono portare allo sviluppo di prodotti competitivi. Tutti questi dettagli devono essere presi in considerazione", afferma Chromek.

8) Cosa può fare l'app?

Quando si tratta, ad esempio, di app di messaggistica, queste devono consentire molti tipi di azioni diverse: inviare messaggi e media, registrare chiamate, persino condividere la posizione, ecc. Tuttavia, alcune app non necessitano di altrettanti diritti: "Ad esempio, quando abbiamo un'app che si concentra sugli eventi online e richiede la vostra posizione, l'accesso alle vostre telefonate, l'invio di SMS e così via, non ha senso. Provate a pensare a cosa fa l'app e poi verificate se i requisiti dell'app non superano le esigenze ragionevoli", conclude Chromek.