Requisiti per la qualificazione di servizi SaaS: Sicurezza

Il Fornitore SaaS, prima della messa in esercizio della soluzione SaaS, deve garantire che il codice applicativo sia stato sviluppato seguendo i principi dello sviluppo sicuro. Il fornitore deve dichiarare se il software viene sottoposto a periodiche verifiche di sicurezza secondo il framework OWASP, in particolare a seguito di operazioni di manutenzione del servizio (aggiornamenti e modifiche).

Continua a leggere su: http://cloud-pa.readthedocs.io/it/latest/circolari/SaaS/allegato_docs/sicurezza.html

Relativamente al requisito RS2, Agid utilizzerà qualche standard o framework per effettuare la verifica in caso di qualificazione su PSN o SPC? Se si quale?

Relativamente al requisito RS13 si chiede conferma del fatto che non sia obbligatorio cifrare la comunicazione tra back-end e DB.

RS2: Il Cloud Provider effettua controlli di sicurezza in modo che il codice, una volta nella piattaforma, non venga attaccato da eventuali malware.
Il Cloud provider dispone inoltre di strumenti intelligenti per penetration testing, la scansione di vulnerabilità dei sistemi operativi e strumenti per la gestione e l’applicazione di patch. Si richiede se il Cloud Provider, nel caso in cui fornisca l’infrastruttura a supporto della soluzione SaaS soprastante, debba garantire anche controlli sul codice sorgente dell’eventuale fornitore SaaS prima che questo venga inserito nella piattaforma cloud.
RS3 e RS4: Si richiede se il Cloud Provider, nella veste di fornitore IaaS/PaaS, debba essere garante anche dei software (terze parti e non) utilizzati dal fornitore SaaS. Questi requisiti potrebbero essere modificati evidenziando le caratteristiche di sicurezza dei Public Cloud Provider in generale e non del codice software della soluzione SaaS sopra installata.
RS17: Il Cloud Provider, in qualità di fornitore di piattaforma IaaS/PaaS a supporto di una generica soluzione SaaS, non ha visibilità sull’implementazione della soluzione SaaS stessa. Il Cloud Provider fornisce una piattaforma scalabile, veloce e affidabile per permettere al fornitore SaaS di ottenere performance ottimali, così come strumenti per il monitoring e analisi dei tempi di latenza per troubleshooting del software stesso. Per quanto riguarda la gestione di incidenti e le tempistiche, sarebbe preferibile quantificare questi come valori di SLA offerti dal Public Cloud Provider e di servizi di supporto offerti.
RS21: Il Cloud Provider pubblica normalmente “Release Notes” relative ai suoi prodotti dopo aver effettuato qualsiasi modifica o miglioramento su di essi. Si richiede come sia possibile che il Public Cloud Provider possa fornire delle specifiche Release Notes in merito al software SaaS non direttamente controllato.

Riporto ed integro dal mio messaggio già pubblicato sul forum (Requisiti di sicurezza per la qualificazione dei servizi SaaS per il Cloud della PA) dubbi e questioni su alcuni requisiti relativi alla sicurezza.

RS7 - Il Fornitore SaaS deve mettere in atto misure di network e domain isolation (firewall, ACL, controller di dominio) per mantenere l’isolamento tra i diversi domini applicativi

Il fonitore SaaS per potersi occupare di elementi infrastrutturali come quelli citati in questo requisito ha bisogno di avere a disposizione i mezzi per farlo.
In altre parole, occorre che i requisiti a cui deve aderire il cloud della PA (Cloud SPC, PSN e CSP) esplicitino l’obbligo di mettere chi si occupa unicamente della parte applicativa in condizione di poter soddisfare questo punto e, se vogliamo, anche i requisiti RS6 e RS8.

RS9 - …devono essere inclusi meccanismi per bloccare il traffico di rete da e verso URL presenti in una blacklist…

Il traffico di rete non ha un URL di provenienza, casomai un indirizzo IP, e non ha necessariamente un URL di destinazione.
Ritengo debba essere chiarito cosa si intende esattamente con la dicitura “traffico di rete da URL”.
Per quanto riguarda il filtro su URL di destinazione, va chiarito se per il traffico di rete che non è associato a risorse identificabili tramite URL, siano necessarie blacklist e se sì, basate su cosa.

RS14 - Il Fornitore SaaS deve garantire che non si possano verificare abusi […] nell’accesso ai dati (eventualmente in grado di compromettere la sicurezza)

Dal momento che è a carico del fornitore SaaS occuparsi della sicurezza dell’intera supply chain relativa all’applicazione, e che purtroppo gli 0-day esistono (https://it.wikipedia.org/wiki/0-day2), la garanzia dell’assenza di qualunque possibilità, seppur remota, che un malintenzionato con sufficienti risorse e conoscenze possa effettuare degli abusi mi sembra, purtroppo, utopica.

Quello che si può realisticamente richiedere al fornitore SaaS potrebbe essere il corretto mantenimento del software in termini di patch di sicurezza, che devono essere tempestivamente applicate qualora vengano rese note vulnerabilità su uno degli elementi che fanno parte della soluzione.