Per segnalare una vulnerabilità di sicurezza, è necessario attenersi alla seguente procedura:

• Compilare il modulo di invio della segnalazione messo a disposizione sui canali digitali;
• Fornire una descrizione dettagliata della vulnerabilità, compresi i passaggi per riprodurla;
• Allega eventuali screenshot, video o codici di prova pertinenti;
• Inviare la relazione.

Il modulo di invio della segnalazione è presente su una pagina dedicata alla gestione della segnalazione. Occorrerà quindi compilare un form con le seguenti informazioni:

• Titolo vulnerabilità
• Tipologia bug
• Livello di gravità
• Replicabilità
• Descrizione step by step (inclusa l’indicazione del servizio, degli URL o degli IP interessati)
• Risultato previsto
• Risultato ottenuto
• Data e ora in cui è stata trovata la vulnerabilità
• Altri commenti
• Immagini/video dimostrativi

Sisal chiede a tutti i ricercatori di seguire con attenzione le seguenti linee guida e di operare in conformità alle normative vigenti e applicabili per non incorrere in violazioni o possibili reati informatici sanzionati dall’ordinamento giuridico (anche con la detenzione) e quindi a titolo esemplificativo e non esaustivo:

• Non sfruttare la vulnerabilità o la problematica scoperta;
• Non eseguire alcuna attività che possa:
  o   danneggiare Sisal
  o   i suoi utenti;
  o   bloccare un sistema o un servizio di Sisal;
  o   causare la perdita di dati.
• Mantenere riservate tutte le informazioni sulle vulnerabilità scoperte, salvo diverso accordo reciproco;
• Evitare violazioni della privacy. Interagire solo con gli account di cui si è proprietari;
• Esercitare cautela e moderazione per quanto riguarda i dati personali e non intraprendere intenzionalmente attacchi contro terzi, social engineering, attacchi denial-of-service, attacchi fisici a qualsiasi proprietà di Sisal o spamming;
• Non causare fastidi ad altri utenti;
• Non utilizzare i comuni scanner di vulnerabilità. La ricerca delle vulnerabilità deve essere manuale, anche se sono consentiti strumenti con richieste automatiche se limitate a 5 richieste al secondo.

Inoltre i ricercatori dovranno:

• Presentare documentazione in inglese;
• Utilizzare identificatori che aiutino a determinare che siano ricercatori di sicurezza (es.: nei log, nelle richieste, nei dettagli dell'account);
• Avere almeno 18 anni;
• Rispettare tutte le leggi locali e nazionali applicabili.

Sisal a fronte del rispetto di queste regole si impegna a:

• Effettuare una prima risposta di presa in carico della segnalazione entro pochi giorni lavorativi;
• Non intraprendere alcuna azione legale nei confronti dei ricercatori di sicurezza che segnalano vulnerabilità seguendo questa policy;
• Non trasmettere i dati personali a terzi a meno di adempimenti di natura legale;
• Informare i ricercatori circa i progressi e la risoluzione delle vulnerabilità rilevate;
• In caso di duplicati Sisal considererà il primo report ricevuto (a condizione che possa essere riprodotto integralmente).

Sisal è particolarmente interessata alle vulnerabilità che potrebbero compromettere la riservatezza, l'integrità o la disponibilità dei dati degli utenti o interrompere il normale funzionamento delle piattaforme

È probabile che qualsiasi problema di progettazione o implementazione che influisca in modo sostanziale sulla riservatezza o l'integrità dei dati dell'utente rientri nell'ambito del programma. Esempi comuni includono:

• Cross-Site Scripting (XSS);
• Cross-Site Request Forgery (CSRF);
• Authentication or Authorization Flaws;
• Server-Side Request Forgery (SSRF);
• Server-Side Template Injection (SSTI);
• SQL injection (SQLI);
• XML External Entity (XXE);
• Remote Code Execution (RCE);
• Local or Remote File Inclusions. 

• Email/SMS Spam o tecniche di social engineering su dipendenti, collaboratori ed esercenti;
• Attacchi DoS or DDoS;
• Eventuali vulnerabilità su applicazioni/servizi di terze parti integrati con piattaforme Sisal
• Content injection. La pubblicazione di contenuti su un portale è una funzione fondamentale, pertanto la content injection (nota anche come "content spoofing" o "HTML injection") non rientra ;nell'ambito di applicazione, a meno che non sia dimostrato chiaramente un evidente rischio;
• Segnalazioni di interruzioni improvvise su app mobile non riproducibili su versioni aggiornate del sistema operativo o su dispositivi mobili rilasciati negli ultimi 24 mesi;
• Clickjacking su pagine senza azioni/dati sensibili;
• Cross-Site Request Forgery (CSRF) su moduli non autenticati o su moduli senza azioni/dati sensibili;
• Attacchi che richiedono MITM (Man in The Middle) o accesso fisico al dispositivo dell'utente;
• Misconfiguration su SSL/TLS;
• Password, email e account policy (ad esempio: email id verification, password complexity);
• Rate limiting o bruteforce su endpoint senza autenticazione;
• Missing HttpOnly o Missing Secure flags sui cookies;
• Software version disclosure / problematiche di Banner identification / Messaggi di errore o headers verbosi (ad esempio, stack trace, errori dell'applicazione o del server);
• Inserimento di backdoor;
• Command injection (quando si verifica una vulnerabilità di Command injection, è sufficiente mostrare l'output dei comandi id o hostname e interrompere lo sfruttamento a questo punto).

Attenzione: quando si analizzano applicazioni ospitate da fornitori di servizi cloud (CSP), leggere attentamente e rispettare sempre le regole di ingaggio (ROE) del CSP. Ad esempio:

• ROE per AWS: https://aws.amazon.com/security/penetration-testing/
• ROE per Azure: https://www.microsoft.com/en-us/msrc/pentest-rules-of-engagement
• ROE per Google Cloud: https://cloud.google.com/security/overview/

(questi sono solo esempi, identificate sempre il CSP e seguite le sue regole di ingaggio).

L'Agenzia dell'Unione europea per la sicurezza informatica (ENISA) ha pubblicato una mappa delle politiche nazionali di Vulnerability Disclosure (CVD) negli Stati membri dell'UE. All’interno di questo link è possibile trovare le loro raccomandazioni.

Sisal non prevede un meccanismo di rewarding, ma in base alla gravità e all’impatto della vulnerabilità potrebbe concedere una ricompensa. In tale senso quindi, l’eventuale rewarding viene concesso ad esclusiva discrezione dell’azienda e viene influenzato da fattori quali il potenziale impatto della vulnerabilità, l'unicità del risultato e la qualità del report.

Sisal si riserva inoltre il diritto di aggiornare la presente Politica di divulgazione responsabile in qualsiasi momento.