FAQ: Sicurezza del Software

Lokad è, innanzitutto, uno specialista della supply chain e il nostro obiettivo primario è fornire decisioni superiori sulla supply chain attraverso l’ingegno tecnologico. Detto ciò, gestiamo quotidianamente dati finanziari importanti, perciò la sicurezza della nostra piattaforma software è una priorità che trattiamo con la massima serietà. Piuttosto che considerare la sicurezza come un ripensamento da gestire attraverso la burocrazia, crediamo fermamente in un approccio fondato su principi che enfatizza la pianificazione e la proattività – come dimostrato dalle nostre scelte specifiche di design software, personale e formazione.

Pubblico destinatario: Il reparto IT
Ultima modifica: 21 settembre 2023

Principi di sicurezza

Una delle illusioni più dannose nei circoli del software aziendale è l’idea che la sicurezza possa essere affrontata con liste di controllo di conformità, certificazioni e, più in generale, ogni sorta di burocrazia e compiti inutili. Sfortunatamente, i dettagli relativi alle preoccupazioni sulla sicurezza sono in costante evoluzione. I problemi sorgono quando attori malevoli sfruttano il software o le persone (o entrambi). Pertanto, la sicurezza può essere affrontata solo attraverso l’applicazione sensata di principi generali.

Più sicuri per design

Crediamo che il design sia uno degli aspetti della sicurezza del software meno apprezzati. Qui, il design copre le decisioni fondamentali prese per sviluppare il software. Le scelte progettuali che un’azienda adotta hanno enormi implicazioni per quanto riguarda la sicurezza, in particolare la superficie d’attacco. Grazie a un design software sensato, Lokad ha eliminato intere classi di problemi di sicurezza. Ad esempio, Lokad non utilizza un database SQL – ma un semplice blob storage – come strato di memorizzazione strettamente passivo. Questa scelta da sola previene interi gruppi di problemi di sicurezza, come gli attacchi di SQL injection, poiché non esiste un database SQL da attaccare. Analogamente, tutti i nostri livelli di persistenza sono solamente append-only. Questo è simile al version control, in cui le modifiche vengono aggiunte alla fine dei dati esistenti, anziché sovrascrivere l’intero contenuto. Tutte le modifiche sono tracciate e possono essere annullate. Questo passaggio complica notevolmente la cancellazione di qualsiasi dato (da parte di chiunque, compresi gli attaccanti), oltre a rendere più difficile la manomissione dei log di Lokad.

La maggior parte dei fornitori di software aziendale non riconosce il fatto che le scelte di design fondamentali sono la vera base dei loro prodotti. Di conseguenza, i loro problemi di sicurezza sono inesorabili. Ad esempio, se la configurabilità – quasi sempre un requisito per il software aziendale – viene fornita attraverso un linguaggio di programmazione di uso generale (come Python o JavaScript), inevitabilmente sorgono problemi di sicurezza. Questo perché è praticamente impossibile mettere in sicurezza completamente un linguaggio di programmazione di uso generale. Al contrario, Lokad ha fatto la scelta consapevole di concentrare tutta la configurabilità in un DSL (linguaggio di programmazione specifico per dominio) denominato Envision. Envision è molto più sicuro perché, per design, non possiede la capacità di interagire direttamente con il sistema operativo (OS) e con i suoi sottosistemi, come il file system.

Più sicuri per cultura

Nessuna tecnologia, e certamente nessun processo, può rendere il software sicuro se le persone semplicemente non se ne curano. Pertanto, facciamo del nostro meglio per fare in modo che Lokad – sia le sue tecnologie che i suoi processi – diventi qualcosa per cui valga davvero la pena interessarsi. Nel contesto del software aziendale, ciò è difficile poiché l’oggetto di interesse è astratto e disconnesso dalle prospettive e motivazioni individuali delle persone¹.

Per prima cosa, Lokad allinea, per quanto umanamente possibile, i suoi messaggi di marketing con la realtà del suo business. Lo facciamo che ci porti consenso o critiche. Questo contrasta nettamente con molti fornitori di software aziendale che fanno affermazioni pubbliche irragionevoli (e spesso fantasiose) ². Quando ciò accade, i dipendenti più brillanti – quelli capaci di identificare la disconnessione tra la realtà dell’azienda e ciò che viene comunicato all’esterno – smettono di interessarsi. Questa indifferenza genera compiacenza, e ne conseguono i problemi di sicurezza. Spesso, tali dipendenti lasciano l’azienda, lasciando dietro di sé quelli “creduloni” – quelli che non riescono a notare la disconnessione. La credulità, così come l’indifferenza, non è una caratteristica desiderabile in termini di sicurezza.

In secondo luogo, Lokad incentiva tra i suoi dipendenti una combinazione di curiosità e sano scetticismo su tutti gli aspetti del nostro business, sia tecnici che non tecnici, inclusa la sicurezza. Ciò crea flessibilità nel rivedere e aggiornare le pratiche, poiché i dipendenti sono formati ed esortati a contribuire. Tale plasticità è utile nell’anticipare attori malevoli, dato che sono noti per ideare modi sempre più creativi di attaccare. Fortunatamente per Lokad, questa mentalità risulta anche molto desiderabile per scopi di supply chain, poiché comportamenti avversi – sebbene non necessariamente criminali – sono comuni nella supply chain ³.

Più sicuri per formazione

Formiamo attivamente tutto il nostro personale per comprendere meglio le minacce informatiche e come mitigarle. A differenza del design e della cultura, la formazione in materia di sicurezza è in gran parte un processo dall’alto verso il basso. Sebbene il pensiero dal basso verso l’alto abbia il suo spazio, questo tipo di formazione è intrinsecamente debole contro la maggior parte dei rischi di sicurezza informatica. In altre parole, anche se le persone sono addestrate a non fare qualcosa, Lokad non può presumere che nessuno lo farà mai ⁴. Pertanto, adottiamo un approccio più rigoroso. Nell’ambito della nostra formazione, scoraggiamo l’uso di chiavette USB e di altri dispositivi USB che potrebbero compromettere le macchine. Ci assicuriamo che, ogni volta possibile, venga utilizzata l’autenticazione a due fattori. Formiamo il nostro personale ad operare con il minor numero possibile di privilegi sulle proprie postazioni di lavoro. Ci assicuriamo che tutti siano consapevoli di come funziona il social engineering, che può essere usato per ingannare anche le persone più intelligenti.

Più in generale, la formazione in materia di sicurezza si concentra sull’aumentare la consapevolezza su come il software e i processi possano essere riutilizzati e corrotti da attori malevoli. Considerando l’ampiezza della formazione, le competenze e il know-how necessari per prevenire attacchi così sofisticati, Lokad in genere ha pochissimi stagisti, rispetto alla maggior parte delle aziende di dimensioni comparabili nel settore. In breve, preferiamo puntare su un team stabile e altamente formato nel lungo termine.

Domande Frequenti (FAQ)

1. Pratiche

1.1 Avete l’Assicurazione sulla Sicurezza?

Si. L’assicurazione sulla sicurezza è un termine ombrello per una varietà di pratiche come il rafforzamento della sicurezza, i test di sicurezza e la gestione delle vulnerabilità. Il rafforzamento della sicurezza, in Lokad, viene affrontato innanzitutto attraverso il design. Grazie a scelte di design specifiche, eliminiamo intere classi di vulnerabilità che, a loro volta, eliminano la necessità stessa del rafforzamento. Ad esempio, Lokad non si basa su uno strato di memorizzazione “programmabile” – come un database relazionale – ma su un semplice key-value store. Ciò elimina tutti i vettori per SQL injection. Inoltre, i test di sicurezza vengono condotti mediante una serie di metodi diversificati; alcuni automatizzati e altri manuali, come i penetration test di terze parti. Per la gestione delle vulnerabilità, abbiamo un programma bug bounty e un processo di gestione delle release ampiamente automatizzato per garantire che le correzioni possano essere implementate rapidamente.

1.2 I vostri sistemi sono conformi a ISO 27001 (ISMS) e/o SOC 2?

No. Crediamo fermamente che queste certificazioni siano distrazioni che rendono le aziende software meno sicure. Questi processi di conformità enfatizzano una mentalità burocratica che è l’opposto di ciò che è necessario per rendere il software sicuro. Ad esempio, queste certificazioni richiedono la produzione di documentazione e l’istituzione di comitati. In maniera sincera, l’idea che la documentazione e i comitati possano fornire qualcosa di sostanziale per la sicurezza del software è altamente discutibile e non è affatto accettata da Lokad.

Nei circoli del software, la sicurezza si ottiene solitamente facendo di meno, non di più; sfruttando gli sforzi degli ingegneri specializzati nella sicurezza del software, invece di creare ulteriori team di non specialisti. A titolo esemplificativo, consideriamo alcune delle più gravi catastrofi informatiche, come Heartbleed o Log4Shell. Questi disastri probabilmente sarebbero stati evitati se le migliaia di aziende software “certificate” avessero scelto di dare priorità alla revisione del codice di terze parti – spesso la causa principale dei problemi – anziché cercare arbitrariamente sigilli commerciali di approvazione.

In generale, riteniamo che queste certificazioni siano stratagemmi di marketing che inducono le aziende in una falsa sensazione di sicurezza (sia in senso figurato che letterale).

1.3 Seguite le pratiche OWASP?

Sì. OWASP fornisce, attraverso le sue guide, una lista di controllo estesa contro le vulnerabilità comunemente riscontrate nel software. Si tratta di una compilazione ampia e di alta qualità che gli ingegneri di Lokad utilizzano per proteggere il nostro software da qualsiasi problema individuato da OWASP. Tuttavia, grazie alle sue scelte di design, Lokad elimina in gran parte intere classi di vulnerabilità comuni evidenziate da OWASP. Ad esempio:

Gestione delle password: Delegando l’autenticazione tramite funzionalità SSO (single sign-on, cosa raccomandata da Lokad), Lokad non deve più “gestire” le password, rendendo superflua l’intera lista di controllo relativa alle password.

Logging: Il design basato su event sourcing adottato da Lokad registra tutto per necessità. Se un’azione non viene registrata, per il sistema è come se non fosse mai accaduta. Questo annulla gran parte della lista di controllo relativa al logging.

Sicurezza del database: Lo strato di persistenza di Lokad non prevede un database relazionale, ma solo due componenti non programmabili; vale a dire una event source e un key-value store. Questa scelta di design annulla completamente la lista di controllo del database.

Più in generale, quando possibile, preferiamo evitare i modelli di design ingegneristico soggetti a errori che creano la necessità di tali liste di controllo fin dall’inizio.

1.4 Siete conformi al GDPR?

Sì. Tuttavia, l’ottimizzazione della supply chain – come fornita da Lokad – non richiede dati personali. Consideriamo i dati personali una passività piuttosto che un bene. Pertanto, raccomandiamo fortemente ai nostri clienti di non trasferirci dati personali. Questa raccomandazione fa solitamente parte dei nostri accordi contrattuali. Non avendo i dati personali in custodia, e quindi non trattandoli, eliminiamo in gran parte le preoccupazioni e i protocolli relativi alla loro protezione, come il GDPR o regolamenti simili.

1.5 Tutti i servizi/soluzioni di terze parti (che prevedono l’accesso a Informazioni di Identificazione Personale (PII)) nella soluzione di Lokad sono conformi ai requisiti del Data Protection Officer (DPO)?

Sì. Tuttavia, come affermato in Pratiche 1.4, l’ottimizzazione della supply chain – come fornita da Lokad – non richiede dati personali. Pertanto, raccomandiamo fortemente ai nostri clienti di non trasferirci dati personali.

Va notato che la soluzione di Lokad ha una lista molto breve di terze parti che hanno accesso ai dati PII. A partire da gennaio 2023, questa lista è limitata a Microsoft Azure.

1.6 Seguite le migliori pratiche di sicurezza?

Sì. In altre parole, facciamo scelte prudenti, poiché non esiste un accordo universale nell’industria su cosa costituisca “le migliori pratiche di sicurezza del software”. Per sua natura, la sicurezza del software è in uno stato di costante evoluzione, adattandosi a un ambiente segnato da nuove minacce e vettori di attacco. Pertanto, non ci affidiamo categoricamente a terze parti per definire quali siano le migliori pratiche di sicurezza del software. Invece, definiamo ciò che è meglio per i nostri clienti. Questo ci permette di assorbire le buone pratiche quando sono disponibili, senza seguire rigidamente quelle meno consigliabili solo perché sono popolari. Il tutto si traduce in pratiche di sicurezza del software attuali, applicabili ed efficaci.

1.7 Effettuate regolarmente test di penetrazione?

Sì. Effettuiamo sia test di penetrazione pianificati che non pianificati. Quelli pianificati sono tipicamente finanziati dai nostri grandi clienti, che, secondo l’accordo contrattuale sottoscritto, possono assumere aziende specializzate per condurre test di penetrazione sui loro principali fornitori di software, inclusa Lokad. Di solito esiste una certa coordinazione tra il team di ingegneria di Lokad e quegli specialisti in sicurezza. I test non pianificati fanno parte del nostro programma pubblico bug bounty, dove specialisti freelance di sicurezza possono tentare di individuare una debolezza nel nostro sistema suscettibile di un potenziale exploit.

1.8 Effettuate regolarmente audit esterni?

No. Detto ciò, siamo più che disposti a sottoporci a un audit esterno se l’operazione è finanziata dal cliente. Molti dei nostri grandi clienti prevedono tali audit nei nostri accordi contrattuali. Tuttavia, a partire da gennaio 2023, i test di penetrazione effettuati dai clienti non hanno rilevato problemi sufficienti a giustificare il ricorso a tali audit.

1.9 Avete un Piano di Continuità Operativa?

Sì. L’ipotesi più grande che Lokad ha affrontato è la possibile cessazione della società stessa. Lokad opera come una soluzione SaaS, tuttavia, alcuni dei nostri grandi clienti hanno clausole nei loro contratti per poter richiedere snapshot completi del nostro codice sorgente. Questi snapshot vengono messi in deposito presso una terza parte concordata in modo che, in caso di cessazione delle operazioni di Lokad, il cliente acquisisca automaticamente l’accesso al codice in deposito e una licenza permissiva per ricreare una propria istanza del servizio Lokad.

1.10 Avete un Piano di Comunicazione per le Crisi?

Sì. Per ogni cliente abbiamo un referente identificato all’interno della sua organizzazione. Dal nostro lato, ci sono almeno due dipendenti in Lokad - un titolare e un sostituto (tipicamente due dei nostri Supply Chain Scientist) - che si occupano di comunicare qualsiasi messaggio urgente al cliente. In pratica, la stragrande maggioranza delle crisi che affrontiamo non sono problemi di sicurezza software, ma riguardano la supply chain - emergenze che Lokad individua sulla base dei dati messi a disposizione dal cliente. In caso di evento di sicurezza, questo canale viene utilizzato per assicurare che i nostri clienti siano informati in maniera tempestiva.

1.11 Come garantite che i sistemi IT del cliente siano mantenuti sicuri?

Raccomandiamo fortemente che Lokad non abbia accesso ai sistemi IT del cliente; il sistema IT del cliente dovrebbe soltanto inviare e ricevere dati da Lokad. Questo approccio mira a mitigare la possibilità che un evento di sicurezza presso Lokad si propaghi al sistema IT del cliente. Inoltre, raccomandiamo fortemente l’utilizzo di un processo SSO (single sign-on), poiché elimina lo scenario ipotetico in cui una password usata per accedere a Lokad venga intercettata (in qualche modo) e successivamente utilizzata per compromettere uno dei sistemi IT del cliente.

1.12 Come proteggete la vostra rete?

Il nostro design adotta un’architettura Zero Trust, cioè consente l’accesso ai dati solo alle persone giuste in determinato momento. Essere semplicemente presenti sulla nostra rete non conferisce automaticamente uno status o dei privilegi (questo punto è approfondito in Authentication 2.1). Pertanto, pur essendo attenti alla sicurezza della rete, assicuriamo - come primo passo - che l’area di attacco associata alle nostre reti sia ridotta al minimo possibile.

Lokad utilizza due reti notevoli. La prima è Microsoft Azure, che viene impiegata per ospitare la nostra soluzione. La sicurezza della rete Microsoft Azure è interamente delegata a Microsoft. Non utilizziamo capacità di rete “avanzate” - come quelle offerte da Microsoft Azure - oltre ai normali bilanciatori di carico.

La seconda è la rete locale della nostra sede a Parigi. La sicurezza della rete locale è gestita internamente dal team di ingegneria di Lokad. La nostra rete locale non ospita alcun componente o sistema che contribuisca all’ambiente di produzione.

1.13 Garantite che tutti i componenti (inclusi quelli di terze parti) e gli strumenti (inclusi quelli open-source) integrati nella soluzione siano legalmente validi per l’uso in sviluppo e produzione?

Sì. Rispetto alla maggior parte dei fornitori di software enterprise, Lokad ha pochissime dipendenze. Tutte le nostre principali dipendenze sono progetti open-source credibili e ampiamente utilizzati (es: .NET di Microsoft, React di Facebook). Ciò rende il nostro processo di audit interno su questo specifico punto un’operazione semplice.

1.14 Come gestite i cambiamenti significativi nell’organizzazione e nei processi in termini di sicurezza?

Poiché Lokad ha adottato fin dall’inizio scelte e pratiche di sicurezza sensate, è raro che un cambiamento di qualsiasi portata (minore o maggiore) impatti la sicurezza (anche ipoteticamente). In tutta la storia di Lokad, ci sono stati solo 3 eventi che potrebbero essere considerati veramente significativi da un punto di vista della sicurezza: la migrazione a Microsoft Azure nel 2010; l’introduzione dell’autenticazione delegata nel 2012 (sia per i clienti che per i dipendenti); e, internamente in Lokad, la migrazione da Google Authentication a Microsoft Azure AD nel 2022.

Per ciascuno di questi eventi, la migrazione era stata preparata mesi in anticipo dal team di ingegneria del software di Lokad. Materiali formativi rilevanti e sessioni di formazione sono stati implementati prima del cambiamento programmato, per garantire la prontezza di tutti i dipendenti di Lokad. Infine, dopo ogni evento di migrazione, ci siamo assicurati che il precedente “path” venisse eliminato, come da prassi standard di Lokad.

A partire da gennaio 2023, non abbiamo in programma cambiamenti significativi. Qualora un tale cambiamento dovesse essere introdotto, quasi certamente procederemmo in maniera simile.

1.15 Come gestite la fine di un contratto?

I nostri accordi dettagliano il processo di terminazione alla fine di un contratto, come concordato con il cliente. Il processo di terminazione si conclude con la definitiva cancellazione dei dati del cliente. Poiché questo processo rappresenta un rischio di sicurezza in sé, tale punto viene discusso con ogni cliente e, pertanto, può variare leggermente a seconda del caso. Da un punto di vista della sicurezza, un attore male intenzionato potrebbe tentare di impersonare il cliente per innescare una terminazione anticipata del contratto (e interrompere le operazioni del cliente). Per prevenire ciò, Lokad e il cliente si impegnerebbero congiuntamente ad adottare un processo - previsto contrattualmente - che non sia banalmente vulnerabile ad un attacco di social engineering. Questo processo tipicamente prevede conferme scritte e un ritardo obbligatorio.

1.16 Qual è la strategia di licenza di Lokad, il modello di costo associato, e il modello di costo annuale di manutenzione?

Lokad in genere addebita una tariffa mensile fissa associata ai costi operativi della piattaforma, oltre a una tariffa mensile fissa relativa al servizio fornito dai Supply Chain Scientist dedicati al cliente (cioè, dagli ingegneri messi a disposizione da Lokad). I dettagli sono negoziati e specificati nel contratto di servizio tra il cliente e Lokad. Queste due tariffe rappresentano un pacchetto “all-inclusive” con Lokad. Non sono previste spese di manutenzione extra, costi di licenza, integratori di terze parti, consulenti esterni, ecc. Il pacchetto prevede limiti, sia in termini di portata che di scala, che sono negoziati congiuntamente come parte dell’accordo contrattuale per il servizio.

1.17 Potete fornire i termini e le condizioni di Lokad per le licenze, i servizi, il supporto, la manutenzione e i corsi di formazione?

Sì, su richiesta del cliente, possiamo fornire un modello contrattuale che rappresenta un accordo di “base”. Tuttavia, le situazioni variano sostanzialmente in base alla portata dell’iniziativa di supply chain, ai paesi applicabili e all’ambito dei servizi attesi da Lokad. Pertanto, se possibile, preferiamo avviare una discussione iniziale con un potenziale cliente, al fine di chiarire i dettagli specifici dell’iniziativa di supply chain in considerazione. Questo ci aiuta a creare il quadro contrattuale più pertinente per la situazione.

1.18 Fornite formazione (in sede/e-learning)?

Sì, Lokad fornisce sia sessioni di formazione in sede che in remoto. I dettagli di queste sessioni sono negoziati come parte dell’accordo contrattuale. Inoltre, Lokad dispone di una vasta documentazione tecnica pubblica e di una dettagliata serie di lezioni pubbliche di supply chain. Queste lezioni trattano la tecnologia di Lokad e la prospettiva sulla supply chain.

1.19 Il sistema di Lokad rispetta gli standard legali/locali rilevanti (ad es., ISO)?

Sì, Lokad opera in conformità con gli standard rilevanti. Tuttavia, Lokad offre l’ottimizzazione predittiva della supply chain e, in quanto tale, non controlla direttamente le operazioni. La nostra influenza è per lo più indiretta, tipicamente mediante l’ottimizzazione dell’allocazione delle risorse. Pertanto, gli standard ISO non sono pertinenti in questo caso (cioè, non applicabili a Lokad).

1.20 Esiste una protezione malware integrata a livello di rete, ad esempio su firewall, dispositivi proxy e/o sulla rete come soluzioni separate?

Vedi Practices 1.12

1.21 Il processo di sviluppo software include una valutazione integrata delle minacce?

Sì. Questa è la ragione principale per cui preferiamo affrontare le problematiche di sicurezza “by design”. Eliminando intere classi di minacce già in fase di progettazione, manteniamo la pratica complessiva di valutazione delle minacce più gestibile. La valutazione delle minacce copre anche gli “attacchi supply chain”. Questa è un’altra ragione per cui poniamo un forte accento sulla minimizzazione del numero di dipendenze di terze parti nel nostro stack software, poiché qualsiasi dipendenza aumenta intrinsecamente la superficie d’attacco.

1.22 Il processo di gestione degli incidenti è esercitato almeno una volta all’anno?

Sì. Esistono molti tipi di incidenti. Uno dei più frequenti è che l’azienda cliente stessa subisca una violazione. In caso di ransomware, ciò a volte porta al fatto che i dati di Lokad diventino accidentalmente l’unico dataset ancora accessibile. In casi di furto di identità, questo può condurre a tentativi di accesso all’account Lokad attraverso credenziali rubate. I dettagli dei vari processi di gestione degli incidenti vengono definiti congiuntamente con l’azienda cliente e, di solito, supervisionati dal Supply Chain Scientist di Lokad responsabile dell’account (per i clienti che optano per un account gestito).

1.23 La mappatura dei rischi e delle minacce viene revisionata almeno una volta all’anno?

Sì, sebbene queste revisioni vengano tipicamente effettuate regolarmente durante l’anno. Tali revisioni sono comunemente guidate da eventi significativi, come importanti violazioni della sicurezza nell’industria del software.

1.24 La valutazione del rischio viene eseguita anche sulle funzioni di supporto che potrebbero influire sulla disponibilità, la qualità e/o la sicurezza della soluzione?

Sì. Tuttavia, la piattaforma Lokad è essenzialmente un monolito che non si basa su alcuna “funzione di supporto” oltre a pochi fondamenti core, come il Blob Storage e le Linux VMs fornite da Microsoft Azure.

1.25 Vengono creati account di sistema dedicati - con solo i diritti di accesso necessari - per l’esecuzione dei processi di sistema?

Sì, vengono utilizzati account di sistema dedicati con i diritti di accesso appropriati per l’esecuzione dei processi di sistema. Lokad utilizza demoni sotto forma di servizi systemd, che operano sempre come utenti con il minor numero possibile di privilegi.

Sebbene Lokad non utilizzi un database SQL, la piattaforma impiega un sistema basato sui ruoli per determinare i diritti di accesso per i processi pianificati e attivati. Questi processi sono categorizzati come “userland” piuttosto che come processi “di sistema”.

1.26 Esiste un piano formale di governance del rischio approvato dal management che definisce i requisiti del programma di Enterprise Risk Management?

Sì, disponiamo di un piano formale di governance del rischio che è stato approvato dalla dirigenza.

Questo piano delinea i requisiti e le linee guida per il nostro programma di Enterprise Risk Management (ERM). È progettato per identificare, valutare, gestire e monitorare i rischi in tutta l’azienda in modo strutturato e coerente.

Il nostro piano di governance del rischio viene periodicamente rivisto e aggiornato per garantire che rimanga rilevante e in linea con gli obiettivi organizzativi e con l’evoluzione del panorama dei rischi. Inoltre, l’implementazione e l’efficacia del programma ERM sono regolarmente riportate alla dirigenza e agli stakeholder pertinenti per garantire una supervisione continua e il supporto necessario.

1.27 Esiste un programma di sicurezza fisica approvato dal management, comunicato ai soggetti interessati, e è stato assegnato un responsabile per la sua manutenzione e revisione?

Sì, disponiamo di un programma completo di sicurezza fisica che è stato approvato dalla dirigenza. Questo programma è stato comunicato in modo approfondito a tutti i soggetti interessati per garantire consapevolezza e conformità.

Inoltre, abbiamo designato un responsabile incaricato di mantenere, aggiornare e rivedere periodicamente il programma per garantirne l’efficacia e la pertinenza. Questo responsabile collabora con vari team e dipartimenti per affrontare eventuali nuove problematiche di sicurezza fisica e assicura che il programma sia in linea con le migliori pratiche e con gli obiettivi organizzativi.

1.28 Vengono condotte valutazioni dei rischi fisici e ambientali prima di stabilire la posizione o il sito di una struttura in cui risiedono i sistemi?

Sì, le valutazioni dei rischi fisici e ambientali sono parte integrante del nostro processo decisionale nella scelta della posizione o del sito di una struttura per i nostri sistemi. Dato che i nostri sistemi risiedono nei data center di Microsoft Azure, beneficiamo del rigoroso processo di selezione e valutazione dei siti messo in atto da Microsoft. Microsoft Azure effettua valutazioni approfondite dei rischi potenziali, inclusi quelli fisici e ambientali, prima di stabilire uno dei suoi data center. Il loro processo di selezione prevede l’analisi di fattori quali il potenziale di disastri naturali, l’accessibilità, la stabilità delle infrastrutture e altro ancora.

Sfruttando i data center di Azure, siamo certi che queste valutazioni siano state eseguite in modo completo per garantire i massimi livelli di sicurezza fisica e resilienza ambientale per i nostri sistemi.

1.29 Esiste un programma documentato di conformità interna ed etica?

Sì, anche se non crediamo che l’“etica” possa essere imposta in modo autoritario. Questo tipo di approccio produce invariabilmente risultati indesiderati che contraddicono gli obiettivi originari.

Famosamente, Enron aveva un codice etico scritto. Tale codice enfatizzava il rispetto, l’integrità, la comunicazione e l’eccellenza. Lo scandalo Enron, emerso nel 2001, ha rivelato che l’azienda era coinvolta in una massiccia frode contabile, che era - ovviamente - in contrasto con i principi enunciati nel loro codice etico. Vi era, quindi, una completa disconnessione tra l’etica dichiarata e scritta di Enron e le effettive pratiche commerciali e la cultura aziendale.

Pertanto, Lokad si concentra nel fare in modo che i dipendenti abbiano realmente a cuore i nostri clienti. “Stiamo facendo le cose giuste?” è uno dei nostri mantra. A nostro avviso, la conformità e l’etica sono il risultato di una cultura aziendale adeguata, non l’output di un programma in particolare.

1.30 Esiste un dipartimento interno di audit, gestione del rischio o conformità, o una funzione di supervisione simile, con la responsabilità di monitorare la risoluzione delle questioni regolatorie o di conformità in sospeso?

Sì. Anche se Lokad non è sufficientemente grande da avere un dipartimento autonomo dedicato alla conduzione di audit interni, alla gestione del rischio o alla conformità, diamo sicuramente priorità a queste aree. Abbiamo designato persone con competenze in questi settori, incaricate specificamente di gestire e supervisionare queste responsabilità critiche.

Questi individui riportano direttamente al vertice della direzione di Lokad, garantendo che la risoluzione di eventuali problemi normativi o di conformità in sospeso venga trattata con la massima priorità e riceva il necessario controllo a livello più alto della nostra organizzazione.

1.31 Esiste una politica o un programma wireless approvato dalla direzione, comunicato ai relativi soggetti interessati, e ad un responsabile designato per mantenerlo e rivederlo?

Sì, Lokad ha una politica wireless ben definita che è stata approvata dalla direzione e comunicata a tutti i soggetti interessati per garantire l’adesione. Questa politica distingue tra due reti Wi-Fi indipendenti e isolate: una dedicata ai dipendenti e un’altra specificamente per gli ospiti. La distinzione garantisce che le nostre operazioni primarie rimangano sicure, anche mentre offriamo connettività per ospiti o visitatori.

Tuttavia, è importante notare che la nostra modalità di connessione principale avviene tramite Ethernet, privilegiata per le sue prestazioni superiori e sicurezza migliorata. Le reti Wi-Fi sono principalmente implementate per ospitare riunioni e offrire flessibilità in determinati scenari.

Inoltre, abbiamo designato un responsabile per la politica che è incaricato della sua manutenzione e revisione periodica, assicurandosi che rimanga aggiornata ed efficace nell’affrontare le esigenze e le sfide in evoluzione.

2. Autenticazione

2.1 Forzate l’autenticazione per tutti gli accessi?

Sì. L’accesso ai dati dei clienti e/o a qualsiasi funzionalità sostanziale della soluzione richiede un’autenticazione preliminare. Tuttavia, per necessità, alcuni punti di contatto non sono soggetti ad autenticazione. Ad esempio, l’accesso alla pagina di login non richiede un’autenticazione preliminare (dato che autenticarsi è lo scopo principale di questa pagina di login).

Nel complesso, pochissimi endpoint tecnici non richiedono autenticazione, e di solito fanno parte dell’instrumentation della piattaforma (es.: un endpoint utilizzato solo per verificare che una macchina sia attiva). Va notato che gli endpoint non autenticati non espongono alcun tipo di dato sensibile, per non parlare dei dati effettivi dei clienti.

2.2 Richiedete che tutti gli accessi remoti siano protetti? Forzate l’HTTPS per le connessioni web?

Sì. Proteggere gli accessi remoti significa avere la corretta autenticazione, la corretta autorizzazione e la crittografia del canale di trasporto stesso - tutti elementi che applichiamo. Questa disposizione riguarda sia gli utenti client che i dipendenti di Lokad. Anche per il team di ingegneria di Lokad, non esiste alcun “accesso locale non sicuro” ai nostri sistemi di produzione. Non usiamo alcun tipo di “località” di rete come via di bypass per la sicurezza.

2.3 Offrite SSO (single sign-on)? Supportate Active Directory (AD)?

Sì. Offriamo SSO (single sign-on) tramite il protocollo SAML. Active Directory supporta SAML e può essere utilizzato per accedere a Lokad.

2.4 Supportate l’autenticazione a due fattori come EZToken, Google Authenticator o Microsoft Authenticator?

Sì. Il two-factor è realizzato tramite autenticazione delegata via SAML. Con SAML, Lokad non gestisce né il primo fattore di autenticazione né il secondo, poiché questo processo è delegato.

2.5 Supportate il protocollo di autenticazione OAuth2?

Di default, Lokad supporta il protocollo di autenticazione SAML. Questo protocollo è supportato dai principali sistemi di identità federata, come Microsoft Office 365 o Google Workspace. Il problema nel supportare OAuth2 è che OAuth2 non è in realtà un “protocollo di autenticazione”, ma un insieme di linee guida molto estese per ingegnerizzare “protocolli di autenticazione” che possono divergere in decine di modi.

Di conseguenza, osserviamo che le varie implementazioni di OAuth2 esistenti nel campo del software enterprise tendono a essere in gran parte incompatibili. Pertanto, se OAuth2 è un requisito assoluto, secondo accordo contrattuale, possiamo supportare una specifica variante di OAuth2. Tuttavia, questo accordo richiede risorse dedicate per garantire la compatibilità con la variante di OAuth2 così operata dalla società cliente.

2.6 Supportate l’integrazione LDAP?

Sì, attraverso un middleware che collega SAML sopra LDAP. Tuttavia, la maggior parte dei sistemi federati di identità che supportano LDAP supportano anche SAML. Pertanto, raccomandiamo di utilizzare direttamente SAML.

2.7 Forzate l’autenticazione a due fattori?

Per i dipendenti di Lokad, sì. Per i dipendenti dei clienti, la raccomandiamo fortemente ma in definitiva non possiamo forzarla (poiché l’autenticazione è solitamente delegata tramite SSO). Questa questione è gestita dal reparto IT dei nostri clienti, non dal nostro.

2.8 Potete imporre una complessità minima delle password?

Sì, ma in misura limitata. Per quanto riguarda la sicurezza del software, obbligare a una complessità minima della password è ormai riconosciuto come una cattiva pratica. Gli utenti finali rispondono male (e prevedibilmente) a richieste di password troppo rigide, causando una diminuzione complessiva del livello di sicurezza. Inoltre, consideriamo tali richieste di password come “bloatware” che aumentano la complessità di un software critico per la sicurezza (gestione delle password), esponendolo (e l’intera soluzione) a rischi indebiti. Vedi https://www.sans.org/blog/nist-has-spoken-death-to-complexity-long-live-the-passphrase/

Raccomandiamo fortemente l’uso di SSO al posto delle password/strategie tradizionali. Tramite SSO, non è necessario introdurre alcuna password dedicata a Lokad.

2.9 Potete imporre rotazioni programmate delle password?

Potremmo, ma non lo facciamo. Proprio come la complessità minima delle password (vedi Authentication 2.8), la rotazione programmata delle password è ormai riconosciuta come una cattiva pratica di sicurezza del software. Gli utenti finali rispondono male (e prevedibilmente) alle rotazioni programmate delle password. La sicurezza può addirittura indebolirsi poiché i dipendenti solitamente apportano solo lievi modifiche alle password (per ridurre il carico cognitivo associato a frequenti rotazioni). Come per la complessità minima delle password, vediamo la rotazione delle password come “bloatware” che aumenta la complessità di un software critico per la sicurezza (gestione delle password), esponendolo (e l’intera soluzione) a rischi indebiti. Vedi https://www.sans.org/blog/time-for-password-expiration-to-die/

2.10 Hashate e salate le password?

Sì. Usiamo scrypt come nostra funzione di hashing delle password. In linea generale, raccomandiamo fortemente l’uso del SSO al posto dell’utilizzo di password/strategie tradizionali. Tramite SSO, non è necessario introdurre alcuna password dedicata a Lokad.

2.11 La soluzione di Lokad abilita CAPTCHA dopo un determinato numero di fallimenti di autenticazione?

Sì, anche se tramite delega dell’autenticazione (tramite SSO). Sebbene i CAPTCHA siano un approccio utile per mitigare alcuni vettori di attacco, rientrano nella categoria dei componenti software che è meglio lasciare completamente al di fuori della portata di una soluzione di ottimizzazione della supply chain come quella di Lokad. Inoltre, il valore aggiunto dei CAPTCHA nel contesto del software enterprise è meno chiaro rispetto a quello del software B2C, specialmente freeware.

2.12 Avete una politica generale di sicurezza per le password? Avete un processo per farla rispettare?

Sì. La nostra politica generale di sicurezza per le password è “niente password”. Raccomandiamo fortemente l’uso di SSO, che elimina la necessità di introdurre password dedicate a Lokad.

2.13 Centralizzate la gestione degli utenti?

Sì. Lokad dispone di una gestione centralizzata degli utenti per la soluzione che operiamo. Questo sottosistema è stato implementato da Lokad e copre anche gli accessi dei dipendenti di Lokad - inclusi i nostri team di ingegneria.

2.14 Consentite account utente generici/condivisi?

No. Lokad impone una relazione uno-a-uno tra dipendenti e utenti (come rilevato dalla piattaforma Lokad). Sconsigliamo fortemente l’uso di account utente condivisi. In effetti, uno dei motivi per cui non addebitiamo per utente è evitare di dare ai nostri clienti un incentivo a condividere account utente tra i loro dipendenti. Tuttavia, ci sono alcuni casi in cui è accettabile avere un account utente che non ha un controparte dipendente. Questo accade tipicamente per il servizio “robot upload” sul lato cliente incaricato di inviare dati a Lokad. Nell’ambito del nostro controllo basato sui ruoli (RBAC), abbiamo un ruolo dedicato (chiamato “uploader”) che fornisce diritti minimi per questo caso d’uso unico.

2.15 Offrite connessioni VPN sicure?

No. Le connessioni degli utenti finali sono stabilite tramite canali crittografati (tipicamente TLS).

2.16 Consentite agli utenti di effettuare il login da più dispositivi?

Sì, entro certi limiti. In generale, il limite massimo è di 6 dispositivi per utente (non addebitiamo per permettere l’uso di più dispositivi). Ogni sessione è limitata a un singolo indirizzo IP. Tuttavia, Lokad si riserva il diritto di modificare questo limite al fine di contrastare alcune potenziali minacce e/o abusi.

2.17 La soluzione ha la capacità di bloccare forzatamente e/o disconnettere un utente (se ritenuto malizioso)?

Sì. Questa funzionalità richiede diritti di accesso “Owner” all’interno dell’account Lokad.

2.18 Il sistema disconnette automaticamente un utente inattivo dopo un determinato periodo di inattività?

Sì, sebbene “l’inattività” non sia il fattore saliente. Lokad disconnette automaticamente gli utenti dopo un determinato intervallo di tempo. Gli utenti non possono posticipare la disconnessione essendo “attivi”; una volta raggiunto l’intervallo di tempo specificato, gli utenti devono riautenticarsi.

2.19 È vietato l’uso di account condivisi e/o credenziali di accesso, e viene monitorata la conformità a queste politiche?

Sì. Vedi Authentication 2.14.

2.20 Gli ID utente e le password sono comunicati/distribuiti tramite mezzi separati (ad es. e-mail e telefono)?

Sì, diamo priorità alla sicurezza delle credenziali degli utenti e ci assicuriamo che vengano comunicate in un modo che rispetti le best practice. Internamente, i nostri sistemi utilizzano Azure Active Directory per l’autenticazione degli utenti. Quando vengono distribuiti gli ID utente e le password iniziali, Azure Active Directory segue i suoi schemi predefiniti, che sono progettati con la sicurezza in mente. Inoltre, applichiamo l’autenticazione a due fattori per il nostro Azure AD, aggiungendo un ulteriore livello di sicurezza al processo di autenticazione.

Esternamente, per i dipendenti dei clienti che si connettono ai nostri sistemi, raccomandiamo fortemente l’uso del Single Sign-On (SSO) e dei sistemi di identità federata. Questi sistemi, per loro natura, supportano le best practice nella gestione delle credenziali, assicurando che le credenziali vengano comunicate in modi sicuri, spesso con canali o metodi di comunicazione separati per gli ID utente e i meccanismi di autenticazione.

Vale la pena notare che non raccomandiamo l’autenticazione a singolo fattore, sia per gli utenti interni che per quelli esterni, se l’obiettivo è mantenere un alto standard di sicurezza.

2.21 Gli ID utente dei soggetti inattivi vengono disabilitati e cancellati dopo periodi di inattività definiti?

Sì, gestiamo e monitoriamo attivamente gli ID utente per garantire la sicurezza. Per i dipendenti di Lokad, la nostra politica prevede che tutti i diritti d’accesso vengano revocati il loro ultimo giorno di lavoro, assicurando che non vi sia accesso post-impiego per ex-dipendenti.

Per i nostri clienti, promuoviamo l’uso del Single Sign-On (SSO) e dei sistemi di identità federata. Questo approccio semplifica la gestione degli accessi. Ad esempio, quando un cliente rimuove un dipendente dal suo sistema di identità, l’accesso a Lokad viene simultaneamente terminato. Questo metodo non solo migliora la sicurezza, ma garantisce anche efficienza nella gestione degli utenti.

Nota: le specifiche riguardanti la cessazione dell’accesso degli utenti sono dettagliate nei nostri accordi contrattuali con ciascun cliente. Lokad riconosce fermamente il potenziale impatto operativo della disattivazione prematura di un account e adotta misure attive per evitare tali scenari. Per evitare interruzioni involontarie, i termini della cessazione dell’accesso degli utenti sono esplicitamente delineati, sia nel contratto che in una procedura concordata, garantendo che le misure di sicurezza di Lokad siano in linea con le esigenze operative del nostro cliente.

3. Autorizzazione

3.1 La soluzione fornisce diritti di accesso granulari?

Sì. La soluzione Lokad include un sottosistema RBAC (Role-Based Access Control) granulare. Ciò consente al cliente di controllare quali “Progetti” e “File” sono accessibili (e da chi) all’interno dell’account Lokad. Il RBAC ha la sua interfaccia utente web (dashboard). È disponibile per tutti gli utenti con designazione “Owner” all’interno dell’account Lokad. Vedi la nostra documentazione ruoli e permessi utente per ulteriori informazioni.

3.2 La soluzione permette al cliente di configurare gli accessi in conformità con il principio del minimo privilegio (PoLP)?

Sì. La soluzione Lokad include un sottosistema RBAC (Role-Based Access Control) granulare che può essere utilizzato per implementare il PoLP. Tuttavia, attraverso Envision (il DSL della soluzione), Lokad va ben oltre la maggior parte del software enterprise per quanto riguarda questo principio.

Attraverso Envision, Lokad ha eliminato interi gruppi di privilegi di sistema che sono semplicemente irrilevanti per l’ottimizzazione della supply chain. Ciò che rimane è semplificato pur rimanendo ampiamente configurabile. Analogamente, il file system su misura offerto da Lokad elimina anch’esso interi gruppi di privilegi di sistema non necessari.

3.3 Forzate i diritti di accesso con minimo privilegio?

Sì, anche se ciò che costituisce il “minimo accettabile” privilegio è infine deciso dai nostri clienti. Lokad non può determinare unilateralmente chi beneficia di una designazione “Owner” nello staff del cliente. Tuttavia, possiamo fornire indicazioni in tal senso. In pratica, per i nostri clienti “gestiti” - quelli supportati dal team di Supply Chain Scientists di Lokad - specifichiamo (per iscritto) l’organizzazione desiderata e i corrispondenti diritti di accesso.

3.4 La soluzione ha la capacità di nascondere una particolare entità nel sistema da utenti designati?

Sì. Questa è una forma di implementazione del PoLP ed è coperta dalle risposte 3.1, 3.2 e 3.3

3.5 Avete una classificazione in atto per i dati (livelli di sensibilità) e controlli adeguati a tale classificazione?

Sì. Come elemento integrato, Lokad limita, per default, tutti i dati amministrativi (come l’elenco degli utenti con un account) agli “Owner” dell’account. Questa designazione è la più alta e privilegiata dell’RBAC (Role-Based Access Control). Tutti gli altri dati all’interno dell’account Lokad possono essere segmentati secondo una classificazione di sensibilità definita dall’utente. Questa classificazione definita dall’utente può essere applicata sia ai dati originali (come caricati dal cliente) che ai dati trasformati (il risultato delle trasformazioni dei dati eseguite all’interno della piattaforma Lokad).

Per ulteriori informazioni sui controlli di accesso e sulle designazioni, si prega di consultare le risposte 3.1, 3.2 e 3.3.

3.6 La soluzione può autorizzare o bloccare utenti/ruoli/transazioni in tempo reale?

Sì, anche se “in tempo reale” necessita di chiarimenti nel contesto di un sistema informatico distribuito (come la soluzione Lokad). Gli aggiornamenti al RBAC (Controllo Accessi Basato sui Ruoli) avvengono in modo sincrono, il che significa che diventano attivi entro pochi secondi (tipicamente meno). Non ci sono ritardi percepibili (come ad esempio un periodo di attesa di un’ora o di un giorno).

Per quanto riguarda l’interruzione delle transazioni, questo non è rilevante poiché Lokad non dispone di un database transazionale. Detto questo, Lokad può interrompere operazioni asincrone di lunga durata (indicate in Lokad come “Project runs”). Quando viene attivata un’interruzione, essa garantisce immediatamente (in modo sincrono) che l’elaborazione non influisca sul sistema, ad esempio sovrascrivendo i file. Tuttavia, l’arresto dell’elaborazione è asincrono e tipicamente entra in vigore entro 20 secondi.

3.7 La soluzione limita l’accesso alle Personal Identifiable Information (PII) solo agli utenti con il giusto livello di autorizzazione?

Sì, anche se la soluzione non è progettata per contenere dati PII (oltre agli identificatori di autenticazione dei dipendenti con accesso alla soluzione). Questo vale sia per Lokad che per il cliente. All’interno della soluzione, solo i dipendenti con la designazione “Owner” hanno accesso all’elenco degli utenti. Per scopi di ottimizzazione della supply chain, Lokad non ha necessità (né trae benefici) dai dati PII, e abbiamo disposizioni contrattuali a tal fine (spiegate in Practices 1.4 & Practices 1.5).

Per ulteriori informazioni sui controlli di accesso e le designazioni, consulta le risposte 3.1, 3.2 e 3.3.

3.8 La soluzione consente ai filtri di ricerca dei dati PII di escludere ricerche con caratteri jolly?

Sì. Tuttavia, un utente con la designazione “Owner” all’interno di un account Lokad può accedere a tutti gli utenti (compreso il personale del cliente) autorizzati ad accedere all’account. Lokad non può limitare questa capacità, poiché i nostri clienti devono poter controllare, in maniera completa, l’elenco degli utenti che hanno accesso al loro account.

3.9 Il sistema è dotato della tecnologia WAF (Web Application Firewall)?

No. Il WAF è un design intrinsecamente pericoloso in quanto viola il principio di sicurezza del “minimo privilegio”: a un componente vengono concessi privilegi enormi per operare come un “man in the middle”. Ciò rende il WAF stesso un obiettivo principale per gli attaccanti e ne estende notevolmente la superficie d’attacco della piattaforma. Tuttavia, Lokad monitora attentamente il traffico web e i comportamenti anomali degli utenti sulla nostra piattaforma. Queste capacità, tuttavia, fanno parte della piattaforma stessa e, pertanto, non sono delegate a componenti software terze parti isolate con privilegi elevati.

Vedi anche Employees 6.6.

3.10 La rete è dotata della tecnologia IPS (Intrusion Prevention System)?

No. L’IPS è un design intrinsecamente pericoloso in quanto viola il principio di sicurezza del “minimo privilegio”: a un componente vengono concessi privilegi enormi per operare come un “man in the middle”. Questo rende l’IPS stesso un obiettivo principale per gli attaccanti e ne estende notevolmente la superficie d’attacco della piattaforma. Per rafforzare la piattaforma Lokad contro le intrusioni, il nostro design inizia minimizzando l’area della superficie d’attacco. Riteniamo che sia molto più sicuro eliminare fin dall’inizio i percorsi per le intrusioni, piuttosto che cercare di “prevenirle” come ripensamento.

Vedi anche Employees 6.6.

3.11 Il servizio utilizza tecnologia di protezione DoS (Denial-of-Service)?

Sì. Lokad sfrutta ReCaptcha, i limiti di velocità di nginx e componenti specifici propri (come l’arresto anticipato in caso di autenticazione non valida).

3.12 Tutti gli accessi amministrativi all’ambiente di produzione avvengono tramite jump host o bastion server?

Sì. Abbiamo un sistema essenzialmente simile a ‘Teleport’. Ciò offre non solo una completa tracciabilità di tutti gli accessi, ma facilita anche la revoca sicura dei diritti di accesso per i dipendenti.

3.13 Esiste un chiaro processo di autorizzazione per concedere l’accesso amministrativo (e che produca una traccia di audit affidabile)?

Sì. Vedi Logging and Monitoring 5.1 e 5.11.

3.14 Esiste un processo sistematico e regolare di revisione dei diritti di accesso (eseguito da una persona autorizzata), in cui i diritti di accesso amministrativo vengono confrontati con eventuali cambiamenti nei ruoli e nelle mansioni?

Sì. Esistono due livelli di diritti di accesso amministrativo.

Primo livello: i diritti amministrativi per supportare l’infrastruttura di Lokad. Tali diritti sono concessi e monitorati dalla divisione IT di Lokad.

Secondo livello: i diritti di accesso amministrativo all’interno di ogni account Lokad. Questi diritti sono concessi e monitorati dal Supply Chain Scientist responsabile dell’account – per i nostri account gestiti. In alternativa, tali diritti sono concessi e monitorati dalla stessa azienda cliente se l’account non è gestito direttamente da Lokad/da un Supply Chain Scientist.

3.15 La vostra politica di restrizione degli accessi segue il principio del “minimo privilegio”, dove è consentito solo il traffico necessario e approvato?

Sì. Applichiamo il principio del minimo privilegio (PoLP) a tutti i livelli di accesso della nostra infrastruttura, incluso il traffico di rete. La severità delle restrizioni di accesso varia a seconda del caso d’uso. Ad esempio, per alcuni accessi è consentito solo a un utente specifico e autenticato proveniente da un indirizzo IP specifico. In altri scenari, chiunque ovunque può accedere, come nel caso dei contenuti della nostra CDN (Content Delivery Network).

Vedi anche Authorization 3.3.

3.16 Le connessioni in uscita dall’ambiente di produzione sono limitate?

No, le connessioni in uscita dall’ambiente di produzione non sono limitate in maniera universale. Mentre alcuni server specializzati, come gli load balancer, hanno restrizioni in uscita, la maggior parte dei nostri server non le prevede.

Le nostre VM di produzione richiedono l’accesso a numerose API esterne. Una larga parte di queste API è ospitata da Microsoft Azure, con alcune eccezioni come letsencrypt.org. Abbiamo stabilito che mantenere una whitelist rigorosa di indirizzi IP introdurrebbe complessità che potrebbero annullare i benefici. Limitare le connessioni in uscita potrebbe offrire vantaggi limitati in termini di sicurezza, ma potrebbe anche introdurre complicazioni che potenzialmente compromettono la sicurezza del nostro ambiente di produzione.

3.17 Esiste un canale di comunicazione con personale (ad esempio, e-mail, modulo web, telefono, ecc.) disponibile per i clienti 24/7/365 per segnalare incidenti di sicurezza?

Sì, abbiamo implementato lo standard security.txt per facilitare la segnalazione di incidenti di sicurezza.

L’approccio security.txt è un modello ampiamente riconosciuto nella sicurezza web, in cui un file di testo specifico viene collocato sul sito. Questo file di testo spiega come segnalare le vulnerabilità di sicurezza.

Il nostro file security.txt può essere trovato all’indirizzo https://www.lokad.com/.well-known/security.txt e descrive il processo aggiornato per la segnalazione degli incidenti di sicurezza. Ciò garantisce che chiunque, sia un cliente, un utente o un ricercatore di sicurezza, possa facilmente trovare i dettagli di contatto rilevanti e le linee guida su come segnalare le problematiche di sicurezza.

Si prega di notare che, sebbene il processo descritto nel ‘security.txt’ possa essere rivisto, le informazioni più aggiornate e accurate saranno sempre disponibili a quell’indirizzo. Garantiamo che i canali di comunicazione menzionati nel file, siano essi e-mail, modulo web o altro mezzo, siano operativi e disponibili 24/7/365 per affrontare tempestivamente le segnalazioni di sicurezza.

4. Gestione dei Dati

4.1 Dove vengono ospitati ed elaborati i dati?

La nostra piattaforma SaaS (Software as a Service) è ospitata al 100% su Microsoft Azure; più precisamente, è situata nel data center Microsoft Azure Europe North (con sede a Dublino). I nostri backup sono conservati nel data center Microsoft Azure Europe West (con sede ad Amsterdam). In caso di un grave guasto del data center, abbiamo piani di contingenza per migrare la piattaforma a Dublino. Dal momento della nostra migrazione a Microsoft Azure nel 2010, non abbiamo mai affrontato tale situazione. Tutti i dati dei nostri clienti risiedono in Europa, dove rimarranno anche in caso di un grave guasto del data center.

4.2 Chi possiede i dati?

I nostri clienti rimangono i soli proprietari di tutti i dati che caricano su Lokad. I nostri clienti rimangono inoltre i soli proprietari di tutti i dati che generano, tramite il loro account Lokad, sulla piattaforma Lokad. Lokad non utilizza internamente i dati dei clienti per nessuno scopo, se non per quelli che contribuiscono direttamente ai compiti che i nostri clienti ci hanno affidato. Lokad non (ri)vende l’accesso ai dati dei clienti a terzi. Lokad non condivide l’accesso ai dati dei clienti, tranne che con i pochi provider di hosting che contribuiscono direttamente al compito in questione (es.: il noleggio di macchine virtuali da una piattaforma di cloud computing per eseguire le elaborazioni come richiesto dai nostri clienti).

4.3 La gestione del database è effettuata internamente o esternamente?

La gestione dello strato dati di Lokad è eseguita dai team di ingegneria di Lokad. Come già menzionato, la piattaforma core di Lokad non include un database transazionale (vedi Authorization 3.6), poiché Lokad utilizza invece un event store. Questo event store è implementato e gestito interamente da Lokad.

4.4 La soluzione ha la capacità di passare da un database RDBMS (PostgreSQL, Oracle, MySQL) a un database NoSQL (Cosmos)?

Teoricamente, sì, ma ciò è irrilevante in quanto la soluzione Lokad non utilizza RDBMS. Lo strato di persistenza dei dati della soluzione Lokad sfrutta un event store e un key-value store. Questo approccio differisce sostanzialmente dal design CRUD (Create-Read-Update-Delete) comunemente riscontrato nel software aziendale. Dato che Lokad è una soluzione SaaS, ci assumiamo la piena responsabilità per la persistenza dei dati e per la compatibilità futura (per garantire che i dati più vecchi rimangano accessibili).

4.5 Sono coinvolte terze parti nella gestione della soluzione?

Sì, in particolare la piattaforma di cloud computing sottostante che Lokad utilizza - Microsoft Azure. L’elenco delle terze parti coinvolte nella gestione della soluzione è molto breve e limitato all’hosting dell’infrastruttura di basso livello. Lokad non utilizza terze parti per sviluppare, amministrare o gestire la propria soluzione. In particolare, sia i nostri team di ingegneria che i nostri team di supporto tecnico sono interni.

4.6 Separate gli strati (reti, server e applicazioni)?

Sì, tuttavia la gestione a basso livello di reti e server è delegata alla piattaforma di cloud computing sottostante che Lokad utilizza - Microsoft Azure. Pertanto, la separazione degli strati di rete e server è in gran parte al di fuori del perimetro gestito da Lokad. All’interno della soluzione Lokad, limitiamo fortemente i privilegi concessi agli strati applicativi affinché non possano amministrare la propria infrastruttura (ad es.: gli strati applicativi non hanno alcun accesso in scrittura alla gestione del DNS).

4.7 Avete un processo per garantire l’eliminazione permanente dei dati?

Sì, anche se possono essere necessarie diverse settimane per completare tutti i passaggi. Il processo prevede la presentazione di una richiesta scritta formale - emessa da una parte autorizzata all’interno dell’organizzazione cliente - affinché i dati corrispondenti vengano eliminati in modo permanente. In pratica, disposizioni specifiche per tali richieste sono incluse nell’accordo contrattuale tra Lokad e i suoi clienti. I dati verranno prima eliminati dal nostro sistema di produzione principale e successivamente dal nostro sistema di backup. Quest’ultima fase è la causa della relativa “lentezza” dell’operazione. Questa è una scelta progettuale, poiché una volta che i dati sono eliminati dal nostro sistema principale, non possono più essere accessibili (eccetto tramite straordinari processi di disaster recovery).

Per impostazione predefinita, la soluzione Lokad garantisce che tutte le operazioni standard di cancellazione siano soft delete (cioè, cancellazioni non permanenti). Questo design è necessario per evitare intere classi di problemi di sicurezza, come la cancellazione accidentale dei dati da parte di un dipendente del cliente o la cancellazione maliziosa da parte di un attaccante. Inoltre, un processo di eliminazione permanente volutamente lento è necessario per mitigare attacchi di social engineering, come il caso in cui un attaccante si faccia passare per un dipendente di un cliente.

4.8 La soluzione ha la capacità di eseguire soft delete dei dati?

Sì. La soluzione Lokad adotta un design basato sull’event sourcing. In questo modo, tutto è versionato per impostazione predefinita, sia le voci degli utenti che le modifiche apportate al file system di Lokad. Di conseguenza, tutte le cancellazioni software sono soft delete, e possono essere tracciate e annullate, se necessario.

4.9 Offrite accesso diretto al database?

Sì, nel senso che il file system - parte della soluzione Lokad - può essere accessibile attraverso protocolli come FTPS e SFTP. Questo accesso è esteso, in quanto tutti i dati utilizzati come input o prodotti come output sono archiviati all’interno di questo file system.

Tuttavia, poiché Lokad non dispone di un database transazionale, non esiste un database sottostante che potrebbe essere reso “accessibile”. L’equivalente più vicino nell’architettura di Lokad è il nostro event store e non offriamo accesso diretto al flusso degli eventi. Tuttavia, potrebbero essere previste disposizioni contrattuali se un cliente richiedesse specifiche estrazioni da tale flusso (ammesso che vi sia un caso d’uso valido).

4.10. Come integra la soluzione i dati esterni?

La soluzione può utilizzare diversi protocolli per integrare dati esterni, in particolare FTPS e SFTP. È inoltre disponibile un’interfaccia utente web per caricare manualmente i file. La soluzione Lokad può integrare qualsiasi dato ragionevolmente tabellare. Per maggiori informazioni sulle capacità di integrazione dei dati esterni di Lokad, consulta Go to IT Perspective on Lokad 2.15.

4.11 Il sistema ha la capacità di gestire il change data capture (CDC) da flussi di dati in tempo reale?

Sì, a condizione che vi sia un accordo contrattuale specifico con il cliente. Il change data capture è un pattern di progettazione software - non uno standard di dati o un protocollo di trasferimento dati specifico - e le aspettative relative al “tempo reale” possono variare da latenze sub-millisecondo a sub-minute. Le funzionalità in questo ambito devono essere valutate da una prospettiva di supply chain. Nella nostra esperienza, i flussi di dati in tempo reale sono raramente rilevanti per affrontare i problemi di supply chain.

4.12 Tutti i dati presenti nella soluzione possono essere esportati?

Sì, tutti i dati accessibili attraverso il file system all’interno dell’account Lokad possono essere esportati tramite protocolli come FTPS o SFTP.

4.13 La soluzione offre strumenti per esportare i dati?

Sì, la soluzione Lokad offre un DSL (domain-specific language) chiamato Envision, pensato per supply chain analytics. Envision offre ampie capacità per riformattare i dati all’interno dell’account Lokad.

4.14 Quale sarà il formato dei dati esportati?

La piattaforma Lokad supporta tutti i formati tabellari comuni, inclusi CSV e XLS (Microsoft Excel). La piattaforma supporta numerose opzioni riguardanti il formato dei numeri, delle date, dei delimitatori, della codifica del testo, delle intestazioni, ecc.

4.15 La soluzione prevede la Transparent Data Encryption (TDE) per i dati contenenti Informazioni di Identificazione Personale (PII) sia nello storage mobile che in quello back-end?

La crittografia trasparente dei dati viene utilizzata sia nello storage back-end di Lokad (attraverso la crittografia Azure Storage per i dati a riposo) sia sui dispositivi forniti da Lokad (tramite BitLocker). Lokad non memorizza dati PII su dispositivi senza TDE abilitato.

4.16 Tutte le password e i segreti utilizzati all’interno dell’applicazione sono crittografati e non accessibili in formato testo semplice nel codice sorgente, nei file di configurazione, nei parametri di build, ecc.?

Sì. Tutti i segreti a livello di piattaforma sono memorizzati in Key Vault, un servizio offerto da Microsoft Azure. Le password degli utenti sono internamente salate e hashate con Scrypt secondo le pratiche standard.

4.17 La soluzione è in grado di limitare il caricamento dei file in base al tipo e alle dimensioni, e di scansionare eventuali contenuti malevoli?

Sì, in misura limitata. Per quanto riguarda la dimensione dei file, la supply chain optimization richiede frequentemente l’elaborazione di file di grandi dimensioni. Queste dimensioni dei file riflettono l’estrazione dei dati storici aziendali che alla fine elaboriamo (es: ordini di vendita storici). Data questa realtà, la piattaforma Lokad supporta file fino a 100GB.

Per quanto riguarda il tipo di file, disponiamo di una whitelist di estensioni note e formati attesi. In caso di un caso d’uso valido, questo parametro potrebbe essere modificato. Tale modifica verrebbe riflessa nel nostro accordo contrattuale.

Per quanto riguarda la capacità di scansionare contenuti malevoli, Lokad non dispone di questa funzionalità. La nostra soluzione enfatizza la condivisione di contenuti generati dalla piattaforma. Inoltre, il design stesso che abbiamo adottato garantisce che i file generati all’interno di Lokad siano sicuri, anche se i file di input non lo sono. Al contrario, grazie al suo design, la soluzione Lokad non privilegia la condivisione di contenuti caricati dagli utenti tramite Lokad.

4.18 Qual è il periodo di conservazione dei dati consigliato?

Lokad è SaaS, pertanto noi ci facciamo carico della responsabilità di scegliere il periodo di conservazione dei dati appropriato, e questa durata varia in base al tipo di dati. I dati storici transazionali, trasmessi a Lokad dal cliente attraverso la pipeline di estrazione dei dati, vengono tipicamente conservati per tutta la durata del servizio Lokad. In effetti, i dati storici solitamente valgono la pena di essere conservati per periodi arbitrariamente lunghi (al di fuori dei confini del servizio Lokad). All’altro estremo, vi sono i dati di strumentazione, che riflettono le prestazioni dettagliate della nostra piattaforma. Questi dati sono utili solo per risolvere problemi di rallentamenti inaspettati della piattaforma. Essendo estremamente dettagliati, solitamente non vengono conservati per più di poche settimane.

4.19 Fornite documentazione della struttura dei dati?

Sì, come parte del “Joint Procedure Manual”. Va notato che Lokad non utilizza un database relazionale, a differenza della maggior parte dei software per aziende. Invece, impieghiamo un paradigma di event sourcing. Tuttavia, le strutture dati di interesse (per la società cliente) non si trovano nella fonte degli eventi, ma nei file flat prodotti tramite script Envision all’interno della piattaforma Lokad. Questi file flat sono progettati per soddisfare i requisiti specifici della società cliente. La documentazione per questi file è inclusa nel “Joint Procedure Manual” - che è uno dei deliverables in una tipica iniziativa Lokad.

4.20 La segmentazione dei dati degli altri clienti fa parte del design del sistema?

Sì, sebbene Lokad sia un’app multi-tenant, i dati sono separati a livello di design tra i tenant, cioè gli account dei clienti. Questa partizione è un elemento di prima classe del nostro design back-end. Questo design previene errori di programmazione che potrebbero esporre i dati di un tenant a un altro, mentre si sviluppano ulteriori funzionalità ordinarie all’interno della piattaforma. Lo storage di base utilizzato da Lokad – Blob Storage di Microsoft Azure – facilita questo tipo di partizionamento rigoroso a livello di design.

4.21 Sono adottate misure efficaci per garantire che nessun dato cliente venga utilizzato negli ambienti di sviluppo e di test?

Sì, per impostazione predefinita, il team di ingegneria software non ha accesso diretto ai dati dei clienti. Abbiamo sviluppato ampi ambienti “mock” e dataset “mock” per consentire al team di ingegneria di operare senza problemi senza accedere ai dati dei clienti. Lokad utilizza internamente anche la propria piattaforma per l’elaborazione dei dati (ad es., analizzando il consumo dettagliato delle risorse di cloud computing ottenute da Microsoft Azure). Questa pratica di “dogfooding” garantisce che Lokad abbia a disposizione un’abbondante quantità di dati non critici da utilizzare per scopi di sviluppo e test.

Tuttavia, abbiamo progettato una pipeline speciale e ristretta per accedere a frammenti minimi (in sola lettura) dei dati dei clienti a scopi diagnostici. Questa pipeline garantisce automaticamente una minimizzazione rigorosa e completamente automatica dei dati recuperati. Inoltre, garantisce automaticamente la cancellazione dei dati al termine dell’operazione diagnostica. Vedi 4.22 per ulteriori dettagli su questa pipeline ristretta.

4.22 Se lo sviluppo o il test richiede un uso limitato dei dati dei clienti, esiste un processo definito per garantire la distruzione sicura e completa dei dati negli ambienti di sviluppo e test?

Sì, abbiamo progettato una pipeline dati speciale (in sola lettura) dedicata all’uso eccezionale dei dati dei clienti a scopi diagnostici - solitamente test di prestazioni. Questa pipeline dati è accessibile solo a una parte ristretta del team di ingegneria software.

Questa pipeline dati è stata progettata per minimizzare automaticamente il frammento dei dati del cliente recuperato per la diagnostica di interesse. Questa capacità ci permette di operare con quella che tipicamente corrisponde a una frazione molto piccola dei dati originali (come presenti nell’account del cliente). Inoltre, elimina la necessità per il team di ingegneria di selezionare manualmente quali dati recuperare.

Infine, questa pipeline dati elimina automaticamente i dati recuperati al termine dell’operazione diagnostica.

4.23 Tutte le sedi fisiche dei dati dei clienti sono note e documentate, inclusi i sistemi di backup e di alta disponibilità?

Sì. Tutti i dati dei clienti sono conservati nei data center fisicamente sicuri di Microsoft Azure, inclusi i backup. Non conserviamo i dati dei clienti localmente (cioè, presso le sedi di Lokad), né i dati dei clienti vengono memorizzati sui dispositivi dei dipendenti.

4.24 L’accesso alle sedi fisiche dei server è limitato ai dipendenti che ne hanno effettivamente bisogno per svolgere il loro lavoro?

Sì, sebbene i dati dei clienti di Lokad siano conservati nei data center sicuri di Microsoft Azure - una località alla quale Lokad non ha accesso fisico. La localizzazione fisica dei data center di Microsoft è di dominio pubblico, e la scelta dei data center da parte di Lokad è documentata pubblicamente.

4.25 Il Primary Account Number (PAN) viene memorizzato solo se assolutamente necessario per scopi aziendali legittimi?

Lokad non riceve, memorizza o gestisce alcun PAN dei clienti.

Il PAN (Primary Account Number) si riferisce solitamente al numero principale su una carta di credito o di debito. È la sequenza di numeri in rilievo o stampata sul fronte di una carta e utilizzata per identificare in modo univoco il conto bancario associato alla carta.

Per elaborare i pagamenti, ci affidiamo esclusivamente a terze parti che gestiscono i PAN per nostro conto. Tuttavia, va notato che la maggior parte delle transazioni ricevute da Lokad viene eseguita tramite bonifico bancario, eliminando del tutto il problema della gestione dei PAN.

Abbiamo alcuni PAN – per le carte di Lokad – che gestiamo in modo sicuro, seguendo le linee guida fornite dalle stesse banche.

4.26 I Primary Account Numbers (PAN) non crittografati vengono mai inviati tramite tecnologie di messaggistica per l’utente finale (ad esempio: email, messaggistica istantanea e chat)?

Sì, i PAN non crittografati (Primary Account Numbers) non vengono mai inviati tramite canali non sicuri come l’email. Lokad offre un canale di comunicazione sicuro integrato nella piattaforma, che rappresenta un’alternativa superiore per la trasmissione di materiali sensibili. Raccomandiamo questo canale ogniqualvolta l’uso di un canale non sicuro rappresenti un rischio aziendale significativo.

Nota: Per design, Lokad non riceve, memorizza o gestisce alcun PAN dei clienti. Pertanto, non vi sono trasferimenti di PAN non crittografati.

Vedi anche la memorizzazione dei PAN

4.27 Avete in essere un contratto con il vostro fornitore di servizi cloud e tale contratto contiene clausole relative agli accordi sulla sicurezza delle informazioni del fornitore di servizi cloud?

Sì, Lokad ha in essere un Enterprise Agreement (EA) con Microsoft per i servizi di cloud computing Azure. L’Enterprise Agreement generalmente include varie condizioni e clausole relative all’uso dei servizi, inclusi impegni sulla sicurezza dell’ambiente cloud.

Microsoft Azure, in quanto uno dei principali fornitori di servizi cloud, pone grande enfasi sulla sicurezza. Azure dispone di un insieme completo di funzionalità e pratiche di sicurezza per proteggere i dati nel cloud, e queste sono spesso riflesse nei loro accordi contrattuali con i clienti aziendali.

Sebbene non possiamo divulgare pubblicamente i dettagli specifici del nostro accordo contrattuale, dopo più di un decennio di collaborazione con Microsoft, siamo soddisfatti che tale accordo soddisfi i nostri requisiti e standard di sicurezza.

4.28 Sono coinvolti subappaltatori nell’elaborazione dei dettagli/dati del cliente?

No, Lokad non subappalta l’elaborazione dei dettagli o dati dei clienti. Per quanto riguarda la piattaforma Lokad, acquistiamo risorse di calcolo - principalmente macchine virtuali e blob storage - da Microsoft Azure, ma al di là di ciò nessun altro terzo è coinvolto per quanto riguarda i dati dei clienti.

Per quanto riguarda la fornitura dei servizi professionali di Lokad, solo i dipendenti a tempo pieno di Lokad (in questo caso, i supply chain scientists) hanno accesso ai dettagli o dati dei clienti. Lokad occasionalmente impiega alcuni tirocinanti (sebbene in numero inferiore rispetto ad altre aziende comparabili) per stage a lungo termine, ma operano sotto la supervisione diretta e rigorosa di senior supply chain scientist.

Nota: I tirocinanti sono soggetti agli stessi accordi di riservatezza dei full-time supply chain scientists.

5. Logging e monitoraggio

5.1 Offrite log di accesso (utente, data, data dell’ultimo accesso, ecc.)?

Sì. Lokad fornisce log di accesso formattati come file CSV. Al momento, questi log possono essere richiesti allo staff di supporto di Lokad. L’estrazione dei log verrà posizionata nell’account Lokad in un’area accessibile solo agli utenti con designazione “Owner”. Abbiamo in programma di introdurre un metodo di accesso più diretto - tramite un’interfaccia web dedicata - all’intero trail di audit che già esiste nel back-end della piattaforma Lokad.

5.2 Centralizzate i log di tutti i componenti della soluzione?

Sì. Il design basato sull’event sourcing di Lokad centralizza non solo i log, ma anche tutti i cambiamenti di stato che avvengono nella soluzione. I log, insieme ad altri cambiamenti di stato, sono centralizzati in una piccola raccolta di stream di eventi, gestiti dallo stesso event store. Internamente, i log che non impattano lo stato della soluzione sono segregati da quelli che lo fanno.

Da un punto di vista puramente tecnico, esistono alcuni log relativi alle prestazioni che sono intenzionalmente non centralizzati all’interno dell’event store. Questi log includono misurazioni dettagliate delle prestazioni, come quelle prodotte dallo strumento interno di profilazione delle prestazioni di Lokad (es: quanti millisecondi vengono impiegati per ogni chiamata di funzione durante l’esecuzione di uno script Envision). Questi log di prestazioni non contengono nulla che possa qualificarsi come materiale “security-related”.

5.3 Registrate i cambiamenti e le operazioni eseguite nell’applicazione? Tenete traccia di tutte le transazioni?

Sì. Grazie al design basato sull’event sourcing di Lokad, tutto viene registrato per necessità. Infatti, la soluzione stessa è la somma della raccolta di eventi registrati all’interno della soluzione. Pertanto, il logging è un aspetto fondamentale dell’architettura della soluzione. Questo design basato sull’event sourcing previene l’omissione accidentale di un log che rifletta un cambiamento di stato. All’interno di un framework basato sull’event sourcing, non esistono transazioni, almeno non nel consueto senso di un database transazionale (es: MySQL, Oracle, ecc.). Queste transazioni sono sostituite da eventi che contengono tutte le informazioni associate a un cambiamento di stato.

5.4 Normalizzate i formati dei log dei vari componenti a fini forensi?

Sì. I “log”, da un punto di vista di audit e/o sicurezza, sono le trasformazioni degli eventi sottostanti. Gli eventi sono oggetti tecnicamente serializzati. Per ottenere i log, la soluzione Lokad converte e compila questi eventi in file CSV. Normalizziamo i formati delle date, dei numeri e gli identificatori utente utilizzati nell’estrazione CSV.

5.5 Offrite esportazioni dei log a terze parti tramite qualche protocollo di query?

Sì, previa stipula di un accordo contrattuale con il cliente.

5.6 Monitorate tutte le eccezioni generate nella vostra soluzione?

Sì. Il design basato sull’event sourcing di Lokad ci permette di monitorare tutte le eccezioni generate nella nostra soluzione e di riprodurre le condizioni che hanno portato al problema. Una volta identificate, il team di ingegneria di Lokad elimina tutte le eccezioni riscontrate. Abbiamo sviluppato strumenti dedicati a questo scopo specifico, e manteniamo un backlog molto limitato di eccezioni non risolte.

5.7 La soluzione è in grado di monitorare in tempo reale lo stato di salute dei diversi componenti/servizi?

Sì. I nostri sottosistemi sono stati progettati con endpoint di monitoraggio dedicati ai controlli di integrità. Abbiamo strumenti di monitoraggio, accessibili solo - a partire da gennaio 2023 - ai team di ingegneria di Lokad, che consolidano continuamente le informazioni rese disponibili da questi endpoint di monitoraggio.

Come già accennato, “in tempo reale” è un’espressione piuttosto vaga quando si tratta di sistemi distribuiti. Per scopi di monitoraggio della salute del sistema, la latenza prevista varia da pochi secondi a un minuto (all’incirca).

5.8 La soluzione ha la capacità di integrare strumenti di monitoraggio di terze parti? La soluzione supporta SNMP o JMX, o la capacità di inviare eventi SNMP e JMX a soluzioni di monitoraggio di terze parti?

Sì, a condizione che sia previsto un accordo contrattuale dedicato.

5.9 La soluzione ha la capacità di monitorare i job batch che non sono partiti secondo il programma e monitorare la loro terminazione?

Sì. La soluzione Lokad dispone di un suo scheduler interno (chiamato “Runflow”) per orchestrare compiti a lunga esecuzione all’interno della piattaforma Lokad - tipicamente l’esecuzione di script Envision. Questo scheduler può essere configurato, tramite un’interfaccia web, per specificare un programma e un intervallo di tempo di esecuzione per qualsiasi sequenza di job.

5.10 La soluzione ha la capacità di produrre avvisi proattivi? Ha la capacità di correlare e analizzare errori, e quindi intraprendere azioni proattive?

Sì. Runflow, lo scheduler dei job della soluzione, può avvisare il cliente/Lokad che una sequenza di esecuzione in corso è in ritardo. L’avviso può essere inviato prima del completamento della sequenza. La soluzione Lokad offre ampie capacità tramite Envision (il suo DSL) per analizzare e auto-diagnosticare le situazioni al fine di intraprendere azioni proattive. Pur essendo la piattaforma Lokad dotata di questa capacità, è comunque necessario che un ingegnere implementi - tramite Envision - la logica effettiva, poiché le situazioni di supply chain che qualificano come “errori” possono variare.

5.11 La soluzione dispone di capacità di conservazione dei dati di audit? I dati sono archiviati e cancellati in un database MIS per l’audit delle attività degli utenti?

Sì. Grazie al suo design basato su event sourcing, la soluzione Lokad conserva un ampio registro di audit; molto più esteso di quanto ottenuto con i design più tradizionali che tipicamente utilizzano un database transazionale invece di un event store. La soluzione Lokad non isola un Management Information System (MIS) come sottosistema separato. In effetti, il flusso di eventi rappresenta il registro di audit. Più in generale, Lokad conserva i dati di produzione per la durata del servizio con il cliente. Al termine del servizio, che dipende dai termini contrattuali negoziati, i dati del cliente vengono cancellati, sebbene l’eliminazione definitiva all’interno del sistema di backup possa avvenire alcuni mesi dopo la fine del contratto.

5.12 Il vostro sistema integra un meccanismo di auto-monitoraggio (tecnico e funzionale)?

Sì, la piattaforma Lokad integra diversi meccanismi di auto-monitoraggio a vari livelli.

La piattaforma ospitata su cloud è monitorata dai team di ingegneria software di Lokad. Poiché la piattaforma Lokad è multi-tenant, questo monitoraggio viene svolto principalmente con una mentalità “sistemica”, assicurando che le capacità della piattaforma (compreso il suo profilo prestazionale) siano conformi agli standard. Abbiamo sviluppato un nostro strato di strumentazione per questo scopo. Il monitoraggio “funzionale” è tipicamente specifico per il cliente in quanto dipende dalle caratteristiche della specifica supply chain. Questo monitoraggio è solitamente fornito dai team di supply chain scientists (gli ingegneri forniti da Lokad), conformemente all’accordo contrattuale.

I supply chain scientists di Lokad solitamente si specializzano in una particolare categoria di conto cliente (ad es., aerospaziale). Essi sviluppano strumenti di monitoraggio su misura utilizzando l’account Lokad. Questo monitoraggio include l’assicurarsi che i numeri forniti da Lokad siano corretti, non solo in senso tecnico, ma anche dal punto di vista commerciale del cliente.

5.13 I log vengono esaminati e analizzati in modo tempestivo e sistematico, per rilevare anomalie e indicazioni di violazione?

Sì. Esaminare l’attività in corso della piattaforma Lokad fa parte della nostra routine quotidiana. Il design della nostra piattaforma facilita questo processo.

Vedi anche Logging and Monitoring 5.2.

5.14 I sistemi di gestione dei log sono amministrati da persone che non sono coinvolte nell’amministrazione degli altri sistemi (cioè, segregazione dei compiti)?

Sì. La supervisione dei log e dell’attività generale della piattaforma è effettuata dai Supply Chain Scientists, mentre l’amministrazione generale della nostra infrastruttura è svolta da dipendenti specifici all’interno della nostra divisione IT.

5.15 Le scansioni delle vulnerabilità a livello di applicazione vengono eseguite periodicamente e sistematicamente?

Sì, sebbene tali scansioni rappresentino una parte molto piccola dei nostri processi di sicurezza. Vedi Employees 6.6.

5.16 Esiste un processo definito per la revisione periodica delle regole del firewall efficaci?

Sì, il nostro sistema di produzione è predisposto con regole molto rigide, come l’apertura di un numero molto limitato di porte (configurate tramite Microsoft Azure). La configurazione della nostra infrastruttura è automatizzata e la sua evoluzione segue il nostro consueto processo di revisione del codice. Questa pratica non solo facilita le revisioni periodiche, ma riduce anche la necessità di rivedere manualmente le regole in primo luogo.

5.17 La rete è dotata della tecnologia IDS (Intrusion Detection System)?

No. L’IDS è un design intrinsecamente pericoloso poiché viola il principio di sicurezza del “minimo privilegio”: un componente viene concesso con privilegi elevati al fine di operare come un “man in the middle”. Questo rende l’IDS stesso un bersaglio principale per gli attaccanti, ed estende notevolmente la superficie d’attacco della piattaforma. Tuttavia, Lokad monitora attentamente il traffico web e i comportamenti anomali degli utenti sulla nostra piattaforma. Queste capacità, tuttavia, fanno parte della piattaforma stessa e dunque non sono delegate a componenti software di terze parti privilegiate e isolate.

Vedi anche Employees 6.6.

6. Dipendenti

6.1 I dipendenti hanno NDA (Accordi di Non Divulgazione)?

Sì, tutti i dipendenti di Lokad sono soggetti a una clausola NDA nei loro contratti di lavoro.

6.2 I dipendenti seguono corsi di sensibilizzazione e formazione sulla sicurezza?

Sì, corsi di sensibilizzazione e formazione sulla sicurezza vengono forniti ai dipendenti di Lokad che hanno contatto con dati riservati e/o sistemi ingegneristici che gestiscono dati riservati. Per ulteriori informazioni su questo punto, la lezione Cybersecurity for Supply Chain è dedicata ai supply chain scientists - le persone che gestiscono dati riservati dei clienti.

6.3 Chi ha accesso ai dati del cliente in Lokad?

Il cliente definisce esplicitamente una lista di utenti che hanno accesso al proprio account Lokad. Questi utenti, a seconda dei loro diritti di accesso configurati all’interno dell’account Lokad, possono avere accesso a diverse classi di dati del cliente. All’interno della soluzione Lokad esiste un’applicazione web dedicata alla gestione delle autorizzazioni (chiamata “Hub”).

Da parte di Lokad, per ogni account cliente è presente una breve lista di dipendenti che hanno accesso. Innanzitutto, questa lista include i supply chain scientists (gli ingegneri forniti da Lokad) che implementano e mantengono la soluzione di ottimizzazione della supply chain. È previsto che questi supply chain scientists accedano quotidianamente ai dati del cliente. Internamente, Lokad limita l’accesso agli account cliente esclusivamente ai supply chain scientists assegnati a tali account. Cioè, il Supply Chain Scientist A non può accedere all’Account Cliente B a meno che A non sia stato esplicitamente assegnato alla gestione di questo account (come concordato con il cliente).

In secondo luogo, questa lista include il team di ingegneria incaricato dell’amministrazione del sistema della nostra piattaforma. Di regola, l’accesso diretto ai dati del cliente è poco frequente e limitato all’investigazione di situazioni segnalate sia dai clienti stessi che dai loro supply chain scientists di supporto. Lokad non condivide l’accesso ai dati del cliente con terze parti, ad eccezione della piattaforma di cloud computing.

6.4 Come vengono protette le postazioni di lavoro dei dipendenti?

Ad eccezione del team di ingegneria software, i dipendenti di Lokad operano senza privilegi amministrativi sui dispositivi forniti dall’azienda. Tutte le postazioni di lavoro sono configurate con la crittografia del disco intero per proteggere dai furti di dati che potrebbero verificarsi in caso di smarrimento, furto o affidamento dell’hardware a terze parti (ad es., per riparazioni).

Le postazioni di lavoro utilizzate dai nostri dipendenti non contengono i dati dei nostri clienti. A seconda del compito, un dipendente può scaricare alcuni fogli Excel sul proprio computer - ad esempio per preparare una presentazione - ma la nostra politica prevede di mantenere rigorosamente tutti i dati dei clienti sicuri nel cloud.

6.5 Come vengono protetti gli smartphone dei dipendenti?

I dipendenti di Lokad non dispongono di smartphone forniti dall’azienda. Dati non critici, come i promemoria del calendario, possono essere inviati attraverso dispositivi personali (non forniti dall’azienda), ma gli smartphone, come le postazioni di lavoro, non contengono i dati dei nostri clienti.

6.6 Usate un antivirus?

Sì, le nostre postazioni di lavoro dispongono di Microsoft Defender, come previsto nei setup di Microsoft Windows 10+. Non utilizziamo un altro antivirus oltre a Microsoft Defender, ma il nostro approccio è che questa categoria di strumenti tende a fare più danni che benefici (in termini di sicurezza informatica). A titolo esemplificativo, l’hack SolarWinds del 2020 è considerato una delle più grandi catastrofi della sicurezza informatica di tutti i tempi, ed è stato causato da un software destinato inizialmente a migliorare la sicurezza. Più in generale, quasi tutti i prodotti software destinati a scopi di sicurezza richiedono privilegi di sistema piuttosto elevati. Di conseguenza, questi prodotti software diventano i propri vettori di attacco. La nostra visione della sicurezza informatica è che meno è di più, e che aggiungere componenti tecnologiche molto complesse nel nostro panorama applicativo lo rende quasi invariabilmente meno sicuro, non più sicuro.

6.7 Gli sviluppatori software vengono periodicamente formati sull’utilizzo di metodi di valutazione delle minacce, standard di codifica sicura, checklist di sicurezza note e framework?

Sì. Tuttavia, la maggior parte delle checklist note riflette principalmente architetture che sono “insicure per design”. Quando possibile, preferiamo eliminare la fonte delle insidie di sicurezza già nella fase di progettazione. Vedi anche Employees 6.2.

6.8 Tutti i contratti con i subappaltatori/fornitori esterni di Lokad includono un Accordo di Non Divulgazione (NDA)? Questo NDA copre le informazioni sui clienti?

Sì per entrambi, anche se, al momento della stesura, Lokad non si basa su subappaltatori o forza lavoro esterna. I team di ingegneria software e dei supply chain scientists di Lokad sono composti interamente da persone in impiego diretto e permanente, sotto la supervisione di Lokad.

Tuttavia, se Lokad ritenesse necessario ingaggiare un subappaltatore, questi sarebbero soggetti agli stessi termini di IP (Proprietà Intellettuale) e NDA dei nostri dipendenti permanenti. Questi accordi includono clausole relative alle informazioni sui clienti di Lokad.

6.9 Tutta la forza lavoro esterna di Lokad ha ricevuto la formazione introduttiva interna sulle informazioni e la sicurezza (e formazione continua pertinente)?

Lokad - al momento della stesura - non si affida a subappaltatori o forza lavoro esterna. I team di ingegneria software e dei supply chain scientists di Lokad sono composti interamente da persone in impiego diretto e permanente, sotto la supervisione di Lokad.

Tuttavia, se Lokad ritenesse necessario ingaggiare una forza lavoro esterna, questo sarebbe un requisito. Tutti i subappaltatori/lavoratori esterni sarebbero soggetti agli stessi processi di sicurezza e requisiti di formazione dei nostri dipendenti permanenti.

Come detto in precedenza, attualmente Lokad non si affida a una forza lavoro esterna, pertanto non viene effettuata alcuna formazione in tal senso.

Vedi anche Employees 6.8

6.10 Tutti i contratti con le aziende che forniscono la forza lavoro esterna di Lokad (qualsiasi/e tutti i contractor, consulenti, ecc., che partecipano alla fornitura dei servizi di Lokad) richiedono che i lavoratori esterni siano sottoposti a controlli dei precedenti? Questi controlli dei precedenti sono conformi al livello corrispondente di accesso alle informazioni e alla criticità del ruolo del dipendente?

Lokad - al momento della stesura - non si avvale di subappaltatori o forza lavoro esterna.

Tuttavia, se Lokad ritenesse necessario ingaggiare una forza lavoro esterna, questo sarebbe un requisito. Tutti i subappaltatori/lavoratori esterni sarebbero soggetti agli stessi processi di sicurezza, controlli dei precedenti e requisiti di formazione dei nostri dipendenti permanenti.

Nota: Storicamente parlando, molti dei più grandi - e peggiori - incidenti, come il cyber-spionaggio, sono commessi da persone che hanno un curriculum impeccabile. Questo, tra le altre ragioni, è il motivo per cui Lokad è riluttante a fare affidamento su una forza lavoro esterna e preferisce fortemente contratti di lavoro diretti e a tempo indeterminato.

6.11 Gli account amministrativi vengono disabilitati o cancellati automaticamente al termine del rapporto di lavoro?

Sì. Tutti i dipendenti di Lokad ricevono i loro diritti di accesso tramite un provider di identità federata (Microsoft Azure Active Directory). Al termine del loro impiego, se applicabile, tale accesso viene revocato, disabilitando così automaticamente tutti i relativi diritti amministrativi.

Nota: La maggior parte dei dipendenti di Lokad non riceve mai diritti amministrativi in quanto non necessari per l’esecuzione delle loro mansioni.

6.12 Effettuate controlli dei precedenti penali su tutto il personale che ha accesso a dati sensibili, dati finanziari, dati bancari, dati delle carte di pagamento, ecc.?

Sì, i controlli dei precedenti vengono eseguiti rigorosamente in linea con i requisiti del lavoro svolto.

Va notato che Lokad non gestisce internamente i dati delle carte di pagamento - questi sono gestiti da terze parti. Pertanto, il personale Lokad non ha accesso a dati delle carte di pagamento dei nostri clienti.

6.13 Quali precauzioni adotta Lokad per garantire che il personale non autorizzato non possa accedere ai locali in cui viene svolto il lavoro?

A livello edilizio, Lokad opera in un edificio per uffici che beneficia di sorveglianza di terze parti 24/7 (ventiquattro ore al giorno, sette giorni su sette), con personale di sicurezza in loco.

A livello degli uffici, i locali di Lokad hanno propri punti di accesso sicuri, indipendenti da quelli dell’edificio stesso. Questo ulteriore strato impedisce ai dipendenti di altre aziende presenti nell’edificio di accedere agli uffici di Lokad.

Nota: eventuali visitatori eccezionali (come clienti, potenziali candidati, ecc.) devono essere accolti fisicamente e autorizzati all’ingresso dai membri del personale di Lokad.

6.14 I visitatori sono ammessi nella struttura?

Se “facility” significa “il luogo in cui i dati dei clienti sono memorizzati e processati”, allora no. I dati dei clienti sono memorizzati nei data center di Microsoft Azure. Questi data centres non sono aperti al pubblico - Lokad stesso non può accedervi.

Tuttavia, Lokad accoglie occasionalmente visitatori presso la sua sede centrale. I nostri uffici non sono aperti al pubblico, ma si presentano occasionalmente circostanze eccezionali, come visite di clienti, candidati in attesa di un colloquio, ecc. Tali visite vengono pianificate in anticipo e tali visitatori sono sempre accompagnati dai membri dello staff di Lokad mentre si trovano nei nostri uffici.

6.15 I registri cartacei dei dati (e i supporti elettronici rimovibili contenenti dati) vengono conservati in armadi antincendio sicuri durante la notte?

Lokad non opera con registri cartacei dei dati, né utilizza supporti elettronici rimovibili. Poiché non abbiamo registri fisici da conservare, Lokad non ha bisogno di armadi antincendio.

Anche se occasionalmente potremmo stampare un documento (Lokad stampa pochissimi documenti, se mai), abbiamo anche un trituratore accanto alla stampante. La politica predefinita di Lokad è di non stampare alcun documento sensibile, ma se teoricamente dovesse essere fatto, la nostra politica predefinita è anche quella di triturare immediatamente il documento stampato dopo l’uso.

6.16 Esiste una politica di scrivania pulita? In tal caso, in che misura?

Sì, Lokad adotta una politica di scrivania pulita ben in atto. Questa politica è applicata “by design” attraverso il nostro ambiente digitale.

Ad eccezione di pochi documenti che siamo legalmente obbligati a stampare, o di documenti occasionali stampati per necessità (ad es., un poster per una fiera, anche se anche questo normalmente verrebbe esternalizzato), l’ambiente di lavoro di Lokad è interamente digitale.

Pertanto, alla fine della giornata, i dipendenti di Lokad non hanno nulla da ripulire. Una volta che la sessione del computer del dipendente è stata bloccata - una politica che applichiamo rigorosamente - la scrivania viene effettivamente ripulita.

6.17 Dove arrivano i fax e chi potrebbe avere accesso ad essi?

Lokad non ha mai posseduto una macchina fax - sia essa fisica o virtuale. Non conosciamo alcun caso d’uso convincente che giustifichi un cambiamento della nostra posizione su questa tecnologia.

6.18 Esiste un processo per verificare la restituzione degli asset costitutivi (computer, telefoni cellulari, badge di accesso, token, smart card, chiavi, ecc.) alla cessazione?

Sì, non solo abbiamo un processo in atto, ma anche un software di gestione degli asset IT per supportare questo sforzo e minimizzare la quantità di errori amministrativi.

Tuttavia, abbiamo deliberatamente progettato la sicurezza di Lokad in modo tale da non dipendere dalla restituzione tempestiva degli asset costitutivi. Lokad assume che qualsiasi asset costitutivo abbia una buona probabilità di essere perso o rubato, non importa quanto i nostri dipendenti possano essere disciplinati e addestrati. In pratica, ciò accade molto raramente, ma da un punto di vista ingegneristico, assumiamo il contrario. Per questo motivo, gli asset costitutivi possono essere disabilitati in remoto. Inoltre, applichiamo la crittografia completa del disco ogniqualvolta sia applicabile.

Più in generale, il nostro ambiente di lavoro è stato progettato in modo da non richiedere alcuna memorizzazione persistente dei dati dei clienti su workstation, notebook o telefoni cellulari. Questo design riduce notevolmente la criticità degli asset costitutivi nel caso in cui le nostre altre misure preventive dovessero fallire.

6.19 Le politiche e/o le procedure delle Risorse Umane (HR) sono approvate dalla direzione e comunicate ai soggetti interessati, ed è stato designato un responsabile per mantenerle e rivederle?

Sì, le nostre politiche e procedure delle Risorse Umane sono state formalmente approvate dalla direzione senior. Poniamo una forte enfasi sulla comunicazione chiara, e per questo queste politiche e procedure sono state ampiamente diffuse a tutti i soggetti interessati per garantire una comprensione e un rispetto completi.

Inoltre, abbiamo designato un responsabile che si occupa della manutenzione continua, degli aggiornamenti e della revisione regolare delle politiche e procedure. Ciò garantisce che le nostre pratiche rimangano aggiornate, rilevanti e in linea sia con gli standard del settore che con i nostri obiettivi organizzativi.

6.20 Esistono dispositivi mobili personali (BYOD), piuttosto che di proprietà aziendale, utilizzati dalle persone associate alla vostra organizzazione che abbiano accesso ai dati dei clienti?

No, Lokad non consente l’accesso ai dati dei clienti su dispositivi mobili personali (BYOD). Forniamo ai nostri dipendenti hardware di alta qualità di proprietà aziendale, eliminando la necessità di dispositivi personali. Questa disposizione affronta lo scenario comune in cui i dipendenti ricorrono all’uso dei propri dispositivi a causa dell’insoddisfazione per hardware aziendale di bassa qualità.

Inoltre, i nostri protocolli operativi sono progettati in modo tale che, anche sui dispositivi di proprietà aziendale, i dati dei clienti non vengano memorizzati in modo permanente. Tutto il processamento dei dati avviene all’interno della nostra piattaforma basata su cloud. Sui dispositivi dei dipendenti, i dati dei clienti (se mai accessi) vengono gestiti in maniera transitoria e solo in segmenti minimi, garantendo la massima sicurezza.

Note