FAQ: Sicurezza del Software

Lokad è, prima di tutto, uno specialista della supply chain e il nostro obiettivo principale è fornire decisioni superiori sulla supply chain attraverso l’ingegnosità tecnologica. Detto questo, gestiamo importanti dati finanziari quotidianamente, quindi la sicurezza della nostra piattaforma software è una priorità e la trattiamo con la massima serietà. Piuttosto che considerare la sicurezza come un’aggiunta da gestire attraverso la burocrazia, crediamo fermamente in un approccio basato su principi che enfatizza la pianificazione e la proattività, come dimostrato dalle nostre scelte specifiche di progettazione del software, di personale e di formazione.

Pubblico di destinazione: Dipartimento IT
Ultima modifica: 21 settembre 2023

Principi di sicurezza

Una delle illusioni più dannose nel campo del software aziendale è l’idea che la sicurezza possa essere affrontata con liste di controllo di conformità, certificazioni e, più in generale, con ogni sorta di lavoro burocratico. Purtroppo, i dettagli della sicurezza sono sempre in continua evoluzione. I problemi sorgono quando attori malintenzionati approfittano del software o delle persone (o entrambi). La sicurezza può quindi essere affrontata solo attraverso l’applicazione sensata di principi generali.

Più sicuro grazie al design

Crediamo che il design sia uno degli aspetti più sottovalutati della sicurezza del software. Qui, il design copre le decisioni fondamentali che sono state prese per sviluppare il software. Le decisioni di design che un’azienda prende hanno enormi implicazioni per quanto riguarda la sicurezza, in particolare la superficie di attacco. Attraverso un design sensato del software, Lokad ha eliminato intere classi di problemi di sicurezza. Ad esempio, Lokad non utilizza un database SQL, ma uno storage di tipo blob come livello di archiviazione strettamente passivo. Questa scelta da sola impedisce interi gruppi di problemi di sicurezza, come gli attacchi di SQL injection, poiché semplicemente non c’è un database SQL da attaccare. Allo stesso modo, tutti i nostri livelli di persistenza sono di tipo append-only. Questo è simile al controllo delle versioni in cui le modifiche vengono aggiunte alla fine dei dati esistenti, anziché sovrascrivere l’intero set di dati. Tutte le modifiche sono tracciate e possono essere annullate. Questo passaggio complica notevolmente l’eliminazione di qualsiasi dato (da parte di chiunque, compresi gli attaccanti), così come la manipolazione dei log di Lokad.

La maggior parte dei fornitori di software aziendale non riconosce il fatto che le scelte di design fondamentali sono la base stessa dei loro prodotti software. Di conseguenza, i loro problemi di sicurezza non hanno fine. Ad esempio, se la configurabilità - quasi sempre un requisito per il software aziendale - viene fornita attraverso un linguaggio di programmazione generico (come Python o JavaScript), inevitabilmente si verificheranno problemi di sicurezza. Questo perché è quasi impossibile proteggere completamente un linguaggio di programmazione generico. Al contrario, Lokad ha fatto la scelta di design consapevole di canalizzare tutta la configurabilità attraverso un DSL (linguaggio di programmazione specifico del dominio) chiamato Envision. Envision è molto più sicuro perché, per design, non ha la capacità di interagire direttamente con il sistema operativo (OS) e i suoi sottosistemi, come il file system.

Più sicuro grazie alla cultura

Nessuna tecnologia e certamente nessun processo può rendere sicuro il software se alle persone non importa. Pertanto, facciamo del nostro meglio per rendere Lokad - sia le sue tecnologie che i suoi processi - qualcosa che meriti una vera attenzione. Nel contesto del software aziendale, questo è difficile poiché l’oggetto di interesse è astratto e distante dalle prospettive e motivazioni individuali delle persone¹.

Innanzitutto, Lokad allinea, per quanto umanamente possibile, i suoi messaggi di marketing con la realtà del suo business. Facciamo questo sia che ci guadagni favore che critiche. Questo è in netto contrasto con molti fornitori aziendali che fanno affermazioni irragionevoli (e spesso fantasiose) in pubblico ². Quando ciò accade, i dipendenti brillanti - quelli capaci di individuare la discrepanza tra la realtà del business e ciò che viene comunicato all’esterno - smettono di interessarsi. Questa indifferenza genera compiacenza e seguono problemi di sicurezza. Spesso, quei dipendenti lasciano l’azienda, lasciando dietro di sé quelli “creduloni” - quelli che non riescono a vedere la discrepanza. La credulità, così come l’indifferenza, non è una caratteristica desiderabile per quanto riguarda la sicurezza.

In secondo luogo, Lokad favorisce 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. Questo crea flessibilità quando si tratta di revisionare e aggiornare le pratiche, poiché i dipendenti sono formati e incoraggiati a contribuire. Tale plasticità è utile per anticipare gli attori malevoli, dato che sono noti per ideare modi sempre più creativi di attaccare. Fortunatamente per Lokad, questa mentalità si rivela anche estremamente desiderabile per scopi legati alla supply chain, poiché comportamenti avversi - sebbene non necessariamente criminali - sono comuni nella supply chain ³.

Più sicuri grazie alla 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 sulla sicurezza è in gran parte un processo dall’alto verso il basso. Sebbene il pensiero dal basso verso l’alto abbia il suo posto, questo tipo di formazione è intrinsecamente debole contro la maggior parte dei rischi informatici. In poche parole, anche se le persone vengono formate per non fare qualcosa, Lokad non può presumere che nessuno farà mai quella cosa ⁴. Pertanto, adottiamo un approccio più rigoroso. Come parte della nostra formazione, scoraggiamo l’uso di chiavette USB e altri dispositivi USB che potrebbero compromettere le macchine. Ci assicuriamo che l’autenticazione a due fattori venga utilizzata ogni volta che possibile. Formiamo il nostro personale affinché operi con il minor numero possibile di privilegi sulle proprie postazioni di lavoro. Ci assicuriamo che tutti siano consapevoli di come funziona l’ingegneria sociale, che può essere utilizzata per ingannare anche le persone più intelligenti.

Più in generale, la formazione sulla sicurezza si concentra sull’aumento della consapevolezza su come il software e i processi possano essere riutilizzati e corrotti da attori malevoli. Data la portata della formazione, delle competenze e delle conoscenze necessarie per prevenire tali attacchi sfumati, Lokad ha generalmente pochissimi stagisti, rispetto alla maggior parte delle aziende di dimensioni simili nel settore. In breve, preferiamo scommettere su una squadra stabile e altamente addestrata nel lungo termine.

Domande frequenti (FAQ)

1. Pratiche

1.1 Avete una garanzia di sicurezza?

Sì. La garanzia di sicurezza è un termine generico che comprende una varietà di pratiche come il rafforzamento della sicurezza, i test di sicurezza e la gestione delle vulnerabilità. Il rafforzamento della sicurezza, presso Lokad, viene affrontato principalmente attraverso il design. Attraverso scelte di design specifiche, eliminiamo intere classi di vulnerabilità che, a loro volta, eliminano la necessità stessa di rafforzamento. Ad esempio, Lokad non si basa su un livello di archiviazione “programmatico” - come un database relazionale - ma su un semplice store di chiavi-valori. Questo elimina tutti i vettori di SQL injection. Inoltre, il testing di sicurezza viene affrontato attraverso un insieme diversificato di metodi; alcuni automatizzati e alcuni manuali, come i test di penetrazione di terze parti. Per la gestione delle vulnerabilità, abbiamo un programma di bug bounty e un processo di rilascio estensivamente automatizzato per garantire che le correzioni possano essere implementate rapidamente.

1.2 Siete conformi alle norme ISO 27001 (ISMS) e/o SOC 2?

No. Crediamo fermamente che queste certificazioni siano distrazioni che rendono le aziende di software meno sicure. Questi processi di conformità enfatizzano una mentalità burocratica che è l’opposto di ciò che è richiesto per rendere sicuro il software. Ad esempio, queste certificazioni richiedono la produzione di documentazione e l’installazione di comitati. Onestamente, l’idea che la documentazione e i comitati producano qualcosa di sostanziale per la sicurezza del software è profondamente discutibile e non è qualcosa che Lokad accetta minimamente.

Nei circoli del software, la sicurezza di solito si ottiene facendo meno, non di più; sfruttando gli sforzi degli ingegneri del software specializzati nella sicurezza del software, anziché creare squadre aggiuntive di non specialisti. A titolo di prova aneddotica, considera alcune delle catastrofi più gravi in materia di sicurezza informatica, come Heartbleed o Log4Shell. Questi disastri probabilmente sarebbero stati evitati se le migliaia di aziende di software “certificate” avessero scelto di dare priorità alla revisione delle code di terze parti - spesso la causa principale dei problemi - anziché perseguire sigilli commerciali arbitrari.

Nel complesso, riteniamo che queste certificazioni siano trucchi di marketing che inducono le aziende a un falso senso di sicurezza (sia figurativamente che letteralmente).

1.3 Seguite le pratiche OWASP?

Sì. OWASP fornisce, attraverso le sue guide, una checklist estesa contro le vulnerabilità comuni riscontrate nel software. Si tratta di una compilazione estesa e di alta qualità che gli ingegneri di Lokad utilizzano per proteggere il nostro software da qualsiasi problema identificato da OWASP. Tuttavia, attraverso le 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 attraverso la funzionalità SSO (single sign-on, qualcosa raccomandato da Lokad), Lokad non deve più “gestire” le password, rendendo superflua tutta la checklist relativa alle password.

Logging: Il design di event sourcing adottato da Lokad registra tutto per necessità. Se un’azione non viene registrata, allora, per quanto riguarda il sistema, non è mai accaduta. Questo annulla la maggior parte della checklist relativa al logging.

Sicurezza del database: Il livello di persistenza di Lokad non include un database relazionale, solo due componenti non programmatici; ovvero una sorgente di eventi e uno store di chiavi-valori. Questa scelta di design annulla completamente la checklist del database.

In generale, quando possibile, preferiamo evitare i pattern di design ingegneristici inclini agli errori che creano la necessità di tali checklist in primo luogo.

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 un rischio anziché un vantaggio. Pertanto, raccomandiamo vivamente ai nostri clienti di non trasferirci dati personali. Questa raccomandazione fa di solito parte dei nostri accordi contrattuali. Non avendo dati personali in custodia e quindi non elaborando dati personali, 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 comportano l’accesso a informazioni personali identificabili (PII)) nella soluzione di Lokad sono conformi ai requisiti del Data Protection Officer (DPO)?

Sì. Tuttavia, come indicato nella Pratica 1.4, l’ottimizzazione della supply chain - come fornita da Lokad - non richiede dati personali. Pertanto, raccomandiamo vivamente ai nostri clienti di non trasferirci dati personali.

Va notato che la soluzione di Lokad ha un elenco molto breve di terze parti che hanno accesso ai dati PII. A partire da gennaio 2023, questo elenco è limitato a Microsoft Azure.

1.6 Seguite le migliori pratiche di sicurezza?

Sì. Ciò significa che facciamo scelte prudenti, poiché non esiste un accordo a livello industriale su cosa costituisca “le migliori pratiche di sicurezza del software”. Per sua stessa natura, la sicurezza del software esiste in uno stato di costante evoluzione, adattandosi a un ambiente pieno di nuove minacce e vettori di attacco abili. Pertanto, non ci affidiamo categoricamente a terze parti su quali siano le migliori pratiche di sicurezza del software. Invece, definiamo ciò che è meglio per i nostri clienti. Ciò ci consente di assorbire le buone pratiche quando disponibili, senza seguire rigidamente quelle meno consigliabili solo perché sono popolari. Tutto ciò si traduce in pratiche di sicurezza del software attuali, applicabili ed efficaci.

1.7 Effettuate regolarmente test di penetrazione?

Sì. Abbiamo sia test di penetrazione pianificati che non pianificati. Quelli pianificati sono tipicamente finanziati dai nostri grandi clienti che possono, in base all’accordo contrattuale firmato con loro, assumere aziende specializzate per condurre test di penetrazione dei loro fornitori di software chiave, inclusa Lokad. Di solito c’è un certo grado di coordinazione tra il team di ingegneria di Lokad e questi specialisti della sicurezza. I test non pianificati fanno generalmente parte del nostro programma pubblico di bug bounty, in cui specialisti della sicurezza freelance possono cercare di individuare una vulnerabilità nel nostro sistema che è aperta a un potenziale exploit.

1.8 Effettuate regolarmente audit esterni?

No. Detto questo, siamo più che disposti a sottoporci a un audit esterno se l’operazione è finanziata dal cliente. Molti dei nostri grandi clienti hanno disposizioni per tali audit nei nostri accordi contrattuali. Tuttavia, a partire da gennaio 2023, i test di penetrazione eseguiti dai clienti non hanno scoperto abbastanza problemi da giustificare la realizzazione di tali audit.

1.9 Avete un piano di continuità aziendale?

Sì. La più grande contingenza affrontata da Lokad è la cessazione ipotetica dell’azienda stessa. Lokad opera come soluzione SaaS, tuttavia, alcuni dei nostri grandi clienti hanno disposizioni nei loro accordi contrattuali per poter richiedere snapshot completi della nostra base di codice. Questi snapshot vengono messi in escrow con una terza parte concordata in modo che, nel caso in cui Lokad cessi le operazioni, il cliente ottenga automaticamente l’accesso alla base di codice in escrow e una licenza per ricreare la propria istanza del servizio Lokad.

1.10 Avete un piano di comunicazione in caso di crisi?

Sì. Per ogni cliente abbiamo un punto di contatto identificato all’interno della loro organizzazione. Da parte nostra, ci sono almeno due dipendenti di Lokad - un responsabile principale e un sostituto (di solito due dei nostri scienziati della supply chain) - che si occupano di comunicare eventuali messaggi urgenti al cliente. Nella pratica, la maggior parte delle crisi che affrontiamo non sono problemi di sicurezza del software, ma problemi legati alla supply chain - emergenze che Lokad identifica in base ai dati resi disponibili dal cliente. Nel caso di un evento di sicurezza, questo canale viene utilizzato per assicurarsi che i nostri clienti siano informati tempestivamente.

1.11 Come garantite la sicurezza dei sistemi IT del cliente?

Consigliamo vivamente che Lokad non abbia accesso ai sistemi IT del cliente; il sistema IT del cliente dovrebbe solo inviare e ricevere dati da Lokad. Questo approccio è inteso a mitigare la possibilità che un evento di sicurezza presso Lokad si diffonda al sistema IT del cliente. Inoltre, consigliamo vivamente di utilizzare un processo di SSO (single sign-on), in quanto elimina lo scenario ipotetico in cui una password utilizzata 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, il che significa che solo le persone autorizzate possono accedere ai dati in un determinato momento. Essere presenti sulla nostra rete non fornisce automaticamente uno stato o privilegi (questo punto è approfondito in Autenticazione 2.1). Pertanto, sebbene siamo attenti alla sicurezza della rete, ci assicuriamo - come primo passo - che la superficie di attacco associata alle nostre reti sia ridotta al minimo.

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

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 lo sviluppo e l’uso in produzione?

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

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

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

Per ciascuno di questi eventi, la migrazione è stata preparata mesi in anticipo dal team di ingegneria del software di Lokad. Sono stati implementati materiali di formazione e sessioni di formazione pertinenti prima del cambiamento programmato, per garantire la preparazione di tutti i dipendenti di Lokad. Infine, dopo ogni evento di migrazione ci siamo assicurati che il percorso precedente fosse eliminato, come pratica standard di Lokad.

A gennaio 2023, non abbiamo pianificato alcun cambiamento significativo imminente. Se un tale cambiamento dovesse essere introdotto, procederemmo quasi certamente in modo 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 l’eliminazione definitiva dei dati del cliente. Poiché questo processo di terminazione rappresenta un rischio per la sicurezza di per sé, questo punto è oggetto di discussione con ciascun cliente e quindi può variare leggermente a seconda del caso. Dal punto di vista della sicurezza, un attore malintenzionato potrebbe cercare di impersonare il cliente al fine di provocare una terminazione anticipata del contratto (e interrompere le operazioni del cliente). Per prevenire ciò, Lokad e il cliente si impegneranno congiuntamente ad adottare un processo - contrattualmente vincolante - che non sia facilmente vulnerabile a un attacco di ingegneria sociale. Questo processo di solito 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 di manutenzione annuale?

Di solito Lokad addebita una tariffa mensile fissa associata al costo operativo della piattaforma, oltre a una tariffa mensile fissa associata al servizio fornito dagli scienziati della supply chain dedicati al cliente (cioè gli ingegneri forniti da Lokad). I dettagli sono negoziati e specificati nel contratto di servizio tra il cliente e Lokad. Queste due tariffe rappresentano un pacchetto “tutto incluso” con Lokad. Non ci sono costi di manutenzione extra, costi di licenza, integratori di terze parti, consulenti di terze parti, ecc. Il pacchetto include limiti, in termini di ambito e scala, che sono negoziati congiuntamente come parte dell’accordo contrattuale per il servizio.

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

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

1.18 Fornite formazione (in sede/formazione online)?

Sì, Lokad fornisce sia formazioni in sede che a distanza. I dettagli di queste sessioni vengono negoziati come parte dell’accordo contrattuale. Inoltre, Lokad dispone sia di un’ampia documentazione tecnica pubblica che di una serie dettagliata di lezioni sulla supply chain. Queste lezioni coprono la tecnologia e la prospettiva della supply chain di Lokad.

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

Sì, Lokad opera in conformità agli standard rilevanti. Tuttavia, Lokad fornisce ottimizzazione predittiva della supply chain e, come tale, Lokad non controlla direttamente le operazioni. La nostra influenza è in gran parte indiretta, di solito attraverso l’ottimizzazione dell’allocazione delle risorse. Pertanto, gli standard ISO non sono rilevanti qui (cioè non applicabili a Lokad).

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

Vedi Pratica 1.12

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

Sì. Questo è il motivo principale per cui preferiamo affrontare le preoccupazioni di sicurezza “per design”. Eliminando intere classi di minacce nella fase di progettazione, manteniamo la pratica di valutazione delle minacce complessivamente più gestibile. La valutazione delle minacce copre anche gli “attacchi alla supply chain”. Questo è un altro motivo per cui poniamo così forte enfasi sulla riduzione al minimo della quantità di dipendenze di terze parti nella nostra infrastruttura software, poiché ogni dipendenza aumenta intrinsecamente l’area di attacco.

1.22 Il processo di gestione degli incidenti viene eseguito almeno una volta all’anno?

Sì. Ci sono molti tipi diversi di incidenti. Uno dei più frequenti è che l’azienda cliente stessa venga violata. In caso di ransomware, ciò porta talvolta i dati di Lokad a diventare accidentalmente l’unico dataset ancora accessibile. Nei casi di furto di identità, ciò porta talvolta a tentativi di accesso all’account di Lokad tramite credenziali rubate. I dettagli dei vari processi di gestione degli incidenti vengono stabiliti congiuntamente con l’azienda cliente e supervisionati tipicamente 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ì, anche se queste revisioni vengono generalmente effettuate regolarmente durante l’anno. Tali revisioni sono comunemente guidate da eventi significativi, come violazioni di sicurezza rilevanti nell’industria del software.

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

Sì. Tuttavia, la piattaforma di Lokad è essenzialmente un monolite che non si basa su alcuna “funzione di supporto” oltre a pochi fondamenti di base, come il Blob Storage e le VM Linux 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 vengono sempre eseguiti come utenti con il minor numero possibile di privilegi.

Sebbene Lokad non utilizzi un database SQL, la piattaforma utilizza un sistema basato sui ruoli per stabilire 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 di governance dei rischi formalizzato approvato dalla direzione che definisce i requisiti del programma di Enterprise Risk Management?

Sì, abbiamo un piano di governance dei rischi formalizzato in atto che è stato approvato dalla direzione senior.

Questo piano definisce 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 dei rischi viene periodicamente revisionato e aggiornato per garantire che rimanga pertinente e allineato con i nostri obiettivi organizzativi e con l’evoluzione del panorama dei rischi. Inoltre, l’implementazione e l’efficacia del programma ERM vengono regolarmente segnalate alla direzione senior e alle parti interessate pertinenti per garantire un controllo e un supporto continui.

1.27 Esiste un programma di sicurezza fisica approvato dalla direzione, comunicato ai soggetti interessati e viene assegnato un responsabile per il suo mantenimento e la sua revisione?

Sì, abbiamo un programma completo di sicurezza fisica in atto che è stato approvato dalla direzione senior. Questo programma è stato comunicato in modo approfondito a tutti i soggetti interessati pertinenti per garantire consapevolezza e adesione.

Inoltre, abbiamo designato un responsabile che è responsabile del mantenimento, dell’aggiornamento e della revisione periodica del programma per garantirne l’efficacia e la pertinenza. Questo responsabile collabora con vari team e dipartimenti per affrontare eventuali emergenti preoccupazioni di sicurezza fisica e garantisce che il programma sia allineato alle migliori pratiche e ai nostri obiettivi organizzativi.

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

Sì, le valutazioni dei rischi fisici e ambientali sono parte integrante del nostro processo decisionale quando si determina la posizione o il sito di un impianto 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 di Microsoft. Microsoft Azure effettua valutazioni approfondite dei potenziali rischi, inclusi quelli fisici e ambientali, prima di stabilire uno qualsiasi dei loro data center. Il loro processo di selezione prevede l’analisi di fattori come il potenziale di catastrofi naturali, l’accessibilità, la stabilità dell’infrastruttura e altro ancora.

Sfruttando i data center di Azure, siamo fiduciosi che queste valutazioni siano state effettuate 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 riteniamo che l’“etica” possa essere imposta in modo autoritario dall’alto verso il basso. Questo tipo di approccio produce inevitabilmente risultati indesiderati che vanno contro gli obiettivi originali.

Come è noto, Enron aveva un codice etico scritto. Questo codice enfatizzava il rispetto, l’integrità, la comunicazione e l’eccellenza. Lo scandalo di 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. C’era quindi una completa disconnessione tra l’etica professata e scritta da Enron e le pratiche commerciali effettive e la cultura aziendale.

Pertanto, Lokad si concentra sul fare in modo che i dipendenti abbiano la possibilità di interessarsi sinceramente ai nostri clienti. “Stiamo facendo le cose giuste?” è uno dei nostri mantra. La conformità e l’etica sono, secondo la nostra valutazione, il risultato di una cultura aziendale adeguata, non l’esito di un programma specifico.

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

Sì. Anche se Lokad non è abbastanza grande da avere un dipartimento autonomo dedicato a condurre audit interni, gestione dei rischi o conformità, certamente diamo priorità a queste aree. Abbiamo individui designati con competenze in questi ambiti che sono specificamente incaricati di gestire e supervisionare queste responsabilità critiche.

Questi individui riportano direttamente al livello più alto della direzione di Lokad, garantendo che la risoluzione di eventuali questioni regolamentari o di conformità in sospeso sia trattata con la massima priorità e riceva la necessaria supervisione al più alto livello della nostra organizzazione.

1.31 Esiste una politica o un programma wireless approvato dalla direzione, comunicato ai soggetti interessati appropriati e un responsabile designato per il suo mantenimento e la sua revisione?

Sì, Lokad ha una politica wireless ben definita che è stata approvata dalla direzione e comunicata a tutti i soggetti interessati pertinenti per garantirne 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 principali rimangano sicure, anche quando forniamo connettività per ospiti o visitatori.

Tuttavia, è importante notare che il nostro principale metodo di connessione avviene tramite Ethernet, prioritizzato per le sue prestazioni superiori e la sicurezza avanzata. Le reti Wi-Fi sono principalmente presenti per consentire riunioni e offrire flessibilità in determinati scenari.

Inoltre, abbiamo designato un responsabile per la politica che è responsabile del suo mantenimento e della sua revisione periodica, garantendo che rimanga aggiornata ed efficace nel affrontare le esigenze e le sfide in evoluzione.

2. Autenticazione

2.1 Impone l’autenticazione per tutti gli accessi?

Sì. L’accesso ai dati del cliente e/o a qualsiasi funzionalità sostanziale della soluzione richiede un’autenticazione preventiva. Tuttavia, per necessità, alcuni punti di contatto non sono soggetti a autenticazione. Ad esempio, l’accesso alla pagina di accesso non richiede un’autenticazione preventiva (poiché l’autenticazione è lo scopo stesso di questa pagina di accesso).

In generale, pochissimi endpoint tecnici non richiedono autenticazione e sono tipicamente parte dell’strumentazione della piattaforma (ad esempio, un endpoint utilizzato solo per verificare che una macchina sia attiva). Va notato che gli endpoint non autenticati non espongono alcun tipo di dati sensibili, figuriamoci i dati effettivi del cliente.

2.2 Richiedi che tutti gli accessi remoti siano protetti? Impone HTTPS per le connessioni web?

Sì. Proteggere gli accessi remoti significa avere l’autenticazione corretta, l’autorizzazione corretta e la crittografia del canale di trasporto stesso, tutto ciò che imponiamo. Questa disposizione copre sia gli utenti client che i dipendenti di Lokad. Anche per il team di ingegneria di Lokad, non esiste un “accesso locale non protetto” ai nostri sistemi di produzione. Non utilizziamo alcun tipo di “località” di rete come bypass di sicurezza.

2.3 Offri SSO (accesso singolo)? Supporti Active Directory (AD)?

Sì. Offriamo SSO (accesso singolo) tramite il protocollo SAML. Active Directory supporta SAML e può essere utilizzato per accedere a Lokad.

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

Sì. Il doppio fattore viene realizzato tramite autenticazione delegata tramite SAML. Attraverso SAML, Lokad non gestisce né il primo fattore di autenticazione né il secondo, poiché questo processo viene delegato.

2.5 Supporti il protocollo di autenticazione OAuth2?

Per impostazione predefinita, Lokad supporta il protocollo di autenticazione SAML. Questo protocollo è supportato dai principali sistemi di identità federati, come Microsoft Office 365 o Google Workspace. La sfida nel supportare OAuth2 è che OAuth2 non è effettivamente un “protocollo di autenticazione”, ma un insieme di linee guida molto estese per progettare “protocolli di autenticazione” che possono divergere in decine di modi.

Di conseguenza, osserviamo che le varie implementazioni di OAuth2 che esistono nel campo del software aziendale tendono ad essere in gran parte incompatibili. Pertanto, se OAuth2 è un requisito assoluto, in base a un accordo contrattuale, possiamo supportare una specifica variante di OAuth2. Tuttavia, questa disposizione richiede risorse dedicate per garantire la compatibilità con la variante OAuth2 utilizzata dall’azienda cliente.

2.6 Supporti l’integrazione LDAP?

Sì, tramite un livello di bridge middleware che sovrappone SAML su LDAP. Tuttavia, la maggior parte dei sistemi di identità federati che supportano LDAP supportano anche SAML. Pertanto, consigliamo di utilizzare direttamente SAML.

2.7 Impone l’autenticazione a due fattori?

Per i dipendenti di Lokad, sì. Per i dipendenti del cliente, lo raccomandiamo vivamente, ma alla fine non possiamo imporlo (poiché l’autenticazione di solito viene delegata tramite SSO). Questa questione è nelle mani del dipartimento IT del cliente, non nel nostro.

2.8 Puoi imporre una complessità minima della password?

Sì, ma in misura limitata. Per quanto riguarda la sicurezza del software, imporre una complessità minima della password è ora ampiamente riconosciuto come una pratica sbagliata. Gli utenti rispondono male (e in modo prevedibile) alle richieste di complessità eccessivamente rigide delle password, causando un calo complessivo della sicurezza. Inoltre, consideriamo tali richieste di password come “bloatware” che aumenta la complessità di un software critico per la sicurezza (gestione delle password), esponendolo (e la soluzione complessiva) a rischi ingiustificati. Vedi https://www.sans.org/blog/nist-has-spoken-death-to-complexity-long-live-the-passphrase/

Raccomandiamo vivamente di utilizzare SSO invece di password/tradizionali strategie. Attraverso SSO, non è necessario introdurre alcuna password dedicata a Lokad.

2.9 Puoi imporre rotazioni programmate delle password?

Potremmo farlo, ma non lo facciamo. Come per la complessità minima della password (vedi Autenticazione 2.8), la rotazione programmata delle password è ora ampiamente riconosciuta come una pratica di sicurezza del software sbagliata. Gli utenti rispondono male (e in modo prevedibile) alle rotazioni programmate delle password. La sicurezza può persino indebolirsi poiché i dipendenti apportano spesso solo piccole modifiche alle password (per ridurre il carico cognitivo associato alle rotazioni frequenti). Come per la complessità minima della password, consideriamo la rotazione delle password come “bloatware” che aumenta la complessità di un software critico per la sicurezza (gestione delle password), esponendolo (e la soluzione complessiva) a rischi ingiustificati. Vedi https://www.sans.org/blog/time-for-password-expiration-to-die/

2.10 Hashi e sali le password?

Sì. Utilizziamo scrypt come funzione di hash delle password. Come regola generale, raccomandiamo vivamente di utilizzare SSO invece di utilizzare password/tradizionali strategie. Attraverso SSO, non è necessario introdurre alcuna password dedicata a Lokad.

2.11 La soluzione di Lokad abilita CAPTCHA dopo un numero predefinito di tentativi di autenticazione?

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

2.12 Hai una politica di sicurezza generale per le password? Hai un processo per imporla?

Sì. La nostra politica di sicurezza generale per le password è “nessuna password”. Raccomandiamo vivamente SSO, che elimina la necessità di introdurre password dedicate a Lokad.

2.13 Centralizzi la gestione degli utenti?

Sì. Lokad ha la propria gestione centralizzata degli utenti per la soluzione che operiamo. Questo sottosistema è stato implementato da Lokad e copre anche gli accessi dei dipendenti di Lokad, comprese le nostre squadre di ingegneria.

2.14 Consentite account utente generici/condivisi?

No. Lokad impone una relazione 1 a 1 tra dipendenti e utenti (come visto dalla piattaforma Lokad). Sconsigliamo vivamente l’uso di account utente condivisi. Infatti, una delle ragioni per cui non addebitiamo per utente è evitare di dare ai nostri clienti un incentivo per condividere gli account utente tra i loro dipendenti. Tuttavia, ci sono alcuni casi in cui è accettabile avere un account utente che non ha un corrispondente dipendente. Questo accade tipicamente per il servizio di “caricamento robot” lato client responsabile del caricamento dei dati su Lokad. Come parte del nostro RBAC (Controllo degli Accessi Basato sui Ruoli), abbiamo un ruolo dedicato (chiamato “uploader”) che fornisce diritti minimi per questo singolo caso d’uso.

2.15 Offrite connessioni VPN sicure?

No. Le connessioni degli utenti finali vengono utilizzate tramite canali crittografati (tipicamente TLS).

2.16 Consentite agli utenti di effettuare l’accesso da dispositivi multipli?

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

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

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

2.18 Il sistema effettua automaticamente il logout di un utente inattivo dopo un determinato periodo di tempo di inattività?

Sì, anche se “inattività” non è il fattore saliente. Lokad effettua automaticamente il logout degli utenti dopo un determinato periodo di tempo. Gli utenti non possono posticipare il logout essendo “attivi”; una volta raggiunto il periodo di tempo specificato, gli utenti devono autenticarsi nuovamente.

2.19 L’uso di account condivisi e/o credenziali di accesso è vietato e il rispetto di queste politiche è monitorato?

Sì. Vedi Autenticazione 2.14.

2.20 Gli ID utente e le password vengono comunicati/distribuiti tramite mezzi separati (ad esempio, e-mail e telefono)?

Sì, diamo priorità alla sicurezza delle credenziali degli utenti e ci assicuriamo che vengano comunicate in modo conforme alle migliori pratiche. 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 modelli predefiniti progettati con la sicurezza in mente. Inoltre, imponiamo 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, consigliamo vivamente l’uso di Single Sign-On (SSO) e sistemi di identità federata. Questi sistemi, per loro natura, supportano le migliori pratiche nella gestione delle credenziali, garantendo che le credenziali vengano comunicate in modo sicuro, spesso coinvolgendo 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, che sia per utenti interni o esterni, se l’obiettivo è mantenere un alto standard di sicurezza.

2.21 Gli ID utente inattivi vengono disabilitati ed eliminati dopo periodi definiti di inattività?

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 di accesso vengano revocati nell’ultimo giorno di lavoro, garantendo che non vi sia accesso post-lavoro per i dipendenti precedenti.

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

Nota: i dettagli relativi alla terminazione dell’accesso dell’utente sono descritti nei nostri accordi contrattuali con ciascun cliente. Lokad riconosce fermamente l’impatto operativo potenziale della disattivazione prematura di un account e adotta misure attive per evitare tali scenari. Per evitare interruzioni involontarie, i termini di terminazione dell’accesso dell’utente sono esplicitamente delineati, sia nel contratto che in una procedura concordata congiuntamente, garantendo che le misure di sicurezza di Lokad siano allineate alle esigenze operative del cliente.

3. Autorizzazione

3.1 La soluzione fornisce diritti di accesso dettagliati?

Sì. La soluzione Lokad include un sottosistema di controllo degli accessi basato sui ruoli (RBAC - Role-Based Access Control) dettagliato. Ciò consente al cliente di controllare a quali “Progetti” e “File” si può accedere (e da chi) nell’account Lokad. Il RBAC ha la propria interfaccia utente web (dashboard). È disponibile a tutti gli utenti con designazione “Proprietario” all’interno dell’account Lokad. Consulta la nostra documentazione sui ruoli e le autorizzazioni degli utenti per ulteriori informazioni.

3.2 La soluzione consente al cliente di configurare l’accesso in conformità al principio del privilegio minimo (PoLP)?

Sì. La soluzione Lokad include un sottosistema di controllo degli accessi basato sui ruoli (RBAC - Role-Based Access Control) dettagliato che può essere utilizzato per implementare il PoLP. Tuttavia, attraverso Envision (il DSL della soluzione), Lokad va molto oltre la maggior parte dei software aziendali per quanto riguarda questo principio.

Attraverso Envision, Lokad ha eliminato intere suite di privilegi di sistema che sono semplicemente irrilevanti per l’ottimizzazione della supply chain. Quello che rimane è semplificato, ma comunque ampiamente configurabile. Allo stesso modo, il sistema di file personalizzato offerto da Lokad elimina anche interi gruppi di privilegi di sistema non necessari.

3.3 Impone diritti di accesso con privilegio minimo?

Sì, anche se ciò che costituisce il privilegio “minimamente accettabile” è deciso in ultima istanza dai nostri clienti. Lokad non può determinare unilateralmente chi beneficia della designazione “Proprietario” nel personale del cliente. Tuttavia, possiamo fornire indicazioni in tal senso. Nella pratica, per i nostri clienti “gestiti” - quelli supportati dal team di Supply Chain Scientists di Lokad - chiarifichiamo (per iscritto) l’organizzazione desiderata e i relativi diritti di accesso.

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

Sì. Questa è una forma di implementazione del PoLP e viene trattata nelle risposte 3.1, 3.2 e 3.3.

3.5 Hai una classificazione dei dati (livelli di sensibilità) e controlli adeguati in base a questa classificazione?

Sì. Come elemento integrato, Lokad limita, per impostazione predefinita, tutti i dati amministrativi (come l’elenco degli utenti con un account) ai “Proprietari” dell’account. Questa designazione è la più alta e privilegiata del RBAC (Role-Based Access Control). Tutti gli altri dati all’interno dell’account Lokad possono essere suddivisi in base a 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 (risultato delle trasformazioni dei dati eseguite all’interno della piattaforma Lokad).

Per ulteriori informazioni sui controlli di accesso e le designazioni, 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” richiede chiarimenti nel contesto di un sistema informatico distribuito (come la soluzione Lokad). Gli aggiornamenti al RBAC (Role-Based Access Control) avvengono in modo sincrono, il che significa che gli aggiornamenti diventano attivi entro pochi secondi (tipicamente meno). Non ci sono ritardi evidenti (come un periodo di attesa di un’ora o 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 a lungo termine (denominate “Project runs” in Lokad). Quando viene attivata un’interruzione, essa garantisce immediatamente (in modo sincrono) che l’elaborazione non influenzi il sistema, ad esempio sovrascrivendo file. Tuttavia, l’interruzione dell’elaborazione è asincrona e di solito ha effetto entro 20 secondi.

3.7 La soluzione limita l’accesso alle Informazioni di Identificazione Personale (PII) solo agli utenti con il livello di autorizzazione corretto?

Sì, anche se la soluzione non è destinata a 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 designazione “Proprietario” hanno accesso all’elenco degli utenti. Per scopi di ottimizzazione della supply chain, Lokad non ha bisogno (né beneficia) di dati PII, e abbiamo disposizioni contrattuali in tal senso (spiegate in Practices 1.4 e Practices 1.5).

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

3.8 La soluzione consente filtri di ricerca dei dati delle Informazioni di Identificazione Personale (PII) per vietare ricerche con caratteri jolly?

Sì. Tuttavia, un utente con designazione “Proprietario” 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 essere in grado di verificare, integralmente, l’elenco degli utenti con accesso al proprio account.

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

No. Il WAF è un design intrinsecamente pericoloso poiché viola il principio di sicurezza del “privilegio minimo”: un componente ottiene enormi privilegi per operare come “uomo nel mezzo”. Ciò rende il WAF stesso un obiettivo principale per gli attaccanti e amplia notevolmente la superficie di attacco della piattaforma. Tuttavia, Lokad monitora attentamente il proprio traffico web e i comportamenti anomali degli utenti sulla nostra piattaforma. Queste capacità, però, fanno parte della piattaforma stessa e quindi non vengono delegate a componenti software di terze parti privilegiate isolate.

Vedi anche Employees 6.6.

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

No. L’IPS è un design intrinsecamente pericoloso poiché viola il principio di sicurezza del “privilegio minimo”: un componente ottiene enormi privilegi per operare come “uomo nel mezzo”. Ciò rende l’IPS stesso un obiettivo principale per gli attaccanti e amplia notevolmente la superficie di attacco della piattaforma. Per rendere più sicura la piattaforma Lokad contro le intrusioni, il nostro design parte dalla minimizzazione dell’area di superficie di attacco. Crediamo che sia molto più sicuro eliminare le vie di accesso alle intrusioni progettandole, piuttosto che cercare di “prevenirle” come un’aggiunta successiva.

Vedi anche Employees 6.6.

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

Sì. Lokad sfrutta ReCaptcha, i limiti di velocità di nginx e i nostri componenti specifici (come il fallimento anticipato quando l’autenticazione non è valida).

3.12 Tutto l’accesso amministrativo all’ambiente di produzione avviene tramite jump host o server bastion?

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

3.13 Esiste un processo di autorizzazione chiaro per concedere l’accesso amministrativo (e che produce un registro di controllo 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 (effettuato da una persona autorizzata), in cui i diritti di accesso amministrativo vengono verificati rispetto a tutti i ruoli e le mansioni modificati?

Sì. Ci sono due livelli di diritti di accesso amministrativo.

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

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

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

Sì. Applichiamo il principio del privilegio minimo (PoLP) a tutti i livelli di accesso della nostra infrastruttura, compreso il traffico di rete. La gravità delle restrizioni di accesso varia a seconda del caso d’uso. Ad esempio, per alcuni accessi è consentito solo un utente specifico autenticato da un indirizzo IP specifico. In altri scenari, chiunque ovunque può accedere, come nel caso dei contenuti del nostro 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 universalmente limitate. Mentre alcuni server specializzati, come i bilanciatori di carico, hanno restrizioni in uscita, la maggior parte dei nostri server non le ha.

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

3.17 È disponibile una forma di comunicazione attiva (ad esempio, e-mail, modulo web, telefono, ecc.) per segnalare incidenti di sicurezza ai clienti 24/7/365?

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

L’approccio security.txt è un modello ampiamente riconosciuto nella sicurezza web in cui viene inserito un file di testo specifico nel sito web. Questo file di testo fornisce dettagli su come segnalare vulnerabilità di sicurezza.

Il nostro file security.txt può essere trovato all’indirizzo https://www.lokad.com/.well-known/security.txt e illustra il processo aggiornato per segnalare incidenti di sicurezza. Ciò garantisce che chiunque, che si tratti di un cliente, di un cliente o di un ricercatore di sicurezza, possa trovare facilmente i dettagli di contatto pertinenti e le linee guida su come segnalare preoccupazioni di sicurezza a noi.

Si prega di notare che, sebbene il processo dettagliato nel ‘security.txt’ possa essere revisionato, le informazioni più attuali e accurate saranno sempre disponibili a quel punto finale. Ci assicuriamo che i canali di comunicazione menzionati nel file, che siano e-mail, modulo web o un altro mezzo, siano attivi e disponibili 24/7/365 per affrontare prontamente le segnalazioni di sicurezza.

4. Gestione dei dati

4.1 Dove ospitate e processate i dati?

La nostra piattaforma SaaS (Software as a Service) è ospitata al 100% su Microsoft Azure; più precisamente, è ospitata nel centro dati Microsoft Azure Europa Nord (con sede a Dublino). I nostri backup sono archiviati nel centro dati Microsoft Azure Europa Ovest (con sede ad Amsterdam). In caso di un grave guasto del centro dati, abbiamo piani di contingenza per migrare la piattaforma a Dublino. Dal nostro passaggio a Microsoft Azure nel 2010, non abbiamo mai affrontato questa situazione. Tutti i dati dei nostri clienti risiedono in Europa, dove rimarranno anche in caso di un grave guasto del centro dati.

4.2 Chi possiede i dati?

I nostri clienti rimangono gli unici proprietari di tutti i dati che caricano su Lokad. I nostri clienti rimangono anche gli unici proprietari di tutti i dati che generano, tramite il loro account Lokad, sulla piattaforma Lokad. Lokad non utilizza internamente i dati dei clienti per scopi diversi da quelli che contribuiscono direttamente alle attività che i nostri clienti ci hanno incaricato di svolgere. Lokad non vende l’accesso ai dati dei nostri clienti a terzi. Lokad non condivide l’accesso ai dati dei clienti, ad eccezione dei pochi fornitori di hosting che contribuiscono direttamente all’attività in corso (ad esempio, noleggiare macchine virtuali da una piattaforma di cloud computing per eseguire i calcoli richiesti dai nostri clienti).

4.3 La gestione del database è gestita internamente o esternamente?

La gestione del livello dei dati di Lokad è effettuata dai team di ingegneria di Lokad. Come già accennato, la piattaforma principale di Lokad non include un database transazionale (vedi Authorization 3.6), poiché Lokad utilizza invece uno store di eventi. Questo store di eventi è implementato e gestito interamente da Lokad.

4.4 La soluzione ha la capacità di passare tra un database RDBMS (PostgreSQL, Oracle, MySQL) e un database Non-SQL (Cosmos)?

Teoricamente sì, ma questo è irrilevante poiché la soluzione Lokad non utilizza RDMBS. Il livello di persistenza dei dati della soluzione Lokad sfrutta uno store di eventi e uno store di chiavi-valori. Questo approccio differisce sostanzialmente dalla progettazione CRUD (Create-Read-Update-Delete) comunemente trovata nei software aziendali. Poiché Lokad è una soluzione SaaS, ci assumiamo piena responsabilità per la persistenza dei dati e la compatibilità futura (per garantire che i dati più vecchi rimangano accessibili).

4.5 Ci sono terze parti coinvolte nell’esecuzione della soluzione?

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

4.6 Separi i livelli (rete, server e applicazioni)?

Sì, tuttavia la gestione a basso livello di reti e server è delegata alla piattaforma di cloud computing sottostante utilizzata da Lokad - Microsoft Azure. Pertanto, la separazione dei livelli di rete e server è per lo più al di fuori del perimetro gestito da Lokad. All’interno della soluzione Lokad, limitiamo fortemente i privilegi concessi ai livelli applicativi in modo che non possano amministrare la propria infrastruttura (ad esempio, i livelli applicativi non hanno alcun accesso in scrittura alla gestione del DNS).

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

Sì, anche se può richiedere diverse settimane per completare tutti i passaggi. Il processo prevede la presentazione di una richiesta formale scritta - emessa da una parte autorizzata all’interno dell’organizzazione del cliente - per avere i dati corrispondenti eliminati in modo permanente. Nella 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 primario e successivamente dal nostro sistema di backup. L’ultima fase è la causa della relativa “lentezza” dell’operazione. Si tratta di una scelta progettuale, poiché una volta che i dati vengono eliminati dal nostro sistema primario, non possono essere più accessibili (tranne tramite processi straordinari di ripristino in caso di disastro).

Per impostazione predefinita, la soluzione Lokad garantisce che tutte le operazioni standard di eliminazione siano eliminazioni soft (cioè non permanenti). Questa progettazione è necessaria per evitare intere classi di problemi di sicurezza come l’eliminazione accidentale dei dati da parte di un dipendente del cliente o l’eliminazione malintenzionata da parte di un attaccante. Inoltre, è necessario un processo di eliminazione permanente intenzionalmente lento per mitigare attacchi di ingegneria sociale, come uno scenario in cui un attaccante si finge un dipendente di un cliente.

4.8 La soluzione ha la capacità di eliminare dati in modo soft?

Sì. La soluzione Lokad adotta un design di event sourcing. Pertanto, tutto è versionato per impostazione predefinita, sia le voci dell’utente che le modifiche apportate al file system di Lokad. Pertanto, tutte le eliminazioni software sono eliminazioni soft e possono essere tracciate e annullate, se desiderato.

4.9 Offri accesso diretto al database?

Sì, nel senso che il file system - parte della soluzione Lokad - può essere accessibile tramite protocolli come FTPS e SFTP. Questo accesso è esteso, poiché 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 store di eventi e non offriamo accesso diretto allo stream di eventi. Tuttavia, potrebbero essere previste disposizioni nell’accordo contrattuale se un cliente dovesse richiedere alcune estrazioni specifiche da questo stream di eventi (a condizione che ci 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 ulteriori informazioni sulle capacità di integrazione dei dati esterni di Lokad, consultare Vai a Prospettiva IT su Lokad 2.15.

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

Sì, previa stipula di un accordo contrattuale specifico con il cliente. Il change data capture è un pattern di progettazione del software, non uno standard di dati specifico o un protocollo di trasferimento dati, e le aspettative di “tempo reale” possono variare da latenze sub-millisecondo a latenze sub-minuto. Le funzionalità in questa area devono essere valutate da una prospettiva di supply chain. Sulla base della nostra esperienza, i feed di dati in tempo reale sono raramente rilevanti per affrontare i problemi della supply chain.

4.12 È possibile esportare tutti i dati all’interno della soluzione?

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

4.13 La soluzione offre strumenti per l’esportazione dei dati?

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

4.14 Quali saranno i formati 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, degli header, ecc.

4.15 La soluzione dispone di crittografia dei dati trasparente (TDE) dei dati di informazioni personali identificabili (PII) in archiviazione mobile e back-end?

La crittografia dei dati trasparente viene utilizzata sia nell’archiviazione back-end di Lokad (tramite la crittografia di Azure Storage per i dati a riposo) che sui dispositivi emessi da Lokad (tramite BitLocker). Lokad non archivia PII su dispositivi senza TDE abilitato.

4.16 Tutte le password e i segreti utilizzati nell’applicazione sono crittografati e non accessibili in formato testo libero nel codice sorgente, nei file di configurazione, nei parametri di compilazione, ecc.?

Sì. Tutti i segreti a livello di piattaforma sono archiviati 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 ha la capacità di limitare gli upload di file in base al tipo e alle dimensioni dei file e di eseguire la scansione per contenuti dannosi?

Sì, in misura limitata. Per quanto riguarda la dimensione del file, l’ottimizzazione della supply chain richiede frequentemente l’elaborazione di file di grandi dimensioni. Queste dimensioni dei file riflettono l’estrazione dei dati aziendali storici che elaboriamo in ultima analisi (ad esempio, ordini di vendita storici). Data questa realtà, la piattaforma Lokad supporta dimensioni dei file fino a 100 GB.

Per quanto riguarda il tipo di file, abbiamo una whitelist di estensioni conosciute e formati attesi. In caso di un caso d’uso valido, questo parametro potrebbe essere regolato. Questo aggiustamento sarebbe riflessa nel nostro accordo contrattuale.

Per quanto riguarda la capacità di eseguire la scansione per contenuti dannosi, 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, attraverso il suo design, la soluzione Lokad de-emphasizes la condivisione di contenuti caricati dagli utenti tramite Lokad.

4.18 Qual è il periodo di conservazione dei dati consigliato?

Lokad è un servizio SaaS, quindi noi abbiamo la responsabilità di scegliere il periodo di conservazione dei dati appropriato, e questa durata varia a seconda del tipo di dati. I dati storici transazionali, trasmessi a Lokad dal cliente attraverso il data extraction pipeline, vengono di solito conservati per la durata del servizio Lokad. Infatti, i dati storici di solito valgono la pena di essere conservati per periodi arbitrariamente lunghi (al di fuori dei limiti del servizio Lokad). All’altro estremo dello spettro, c’è il dato di strumentazione, che riflette le prestazioni dettagliate della nostra piattaforma. Questi dati sono utili solo per risolvere i rallentamenti imprevisti all’interno della piattaforma. Questi dati sono estremamente granulari e di solito non vengono conservati per più di qualche settimana.

4.19 Fornite la documentazione della struttura dei dati?

Sì, come parte del “Manuale di Procedura Condiviso”. Va notato che Lokad non utilizza un database relazionale, a differenza della maggior parte del software aziendale. Invece, utilizziamo un paradigma di event sourcing. Tuttavia, le strutture dati di interesse (per l’azienda cliente) non si trovano nella sorgente degli eventi, ma nei file piatti prodotti tramite script Envision all’interno della piattaforma Lokad. Questi file piatti sono progettati per soddisfare le specifiche esigenze dell’azienda cliente. La documentazione per questi file è inclusa nel “Manuale di Procedura Condiviso” - che è uno dei deliverable in una tipica iniziativa Lokad.

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

Sì, anche se Lokad è un’app multi-tenant, i dati sono separati a livello di design tra i tenant, ovvero gli account clienti. Questa suddivisione è un elemento di primo piano del nostro design back-end. Questo design impedisce errori di programmazione che esporrebbero i dati di un tenant a un altro tenant, mentre si sviluppano ulteriori funzionalità banali all’interno della piattaforma. Lo storage sottostante primario utilizzato da Lokad - Blob Storage di Microsoft Azure - facilita questo tipo di suddivisione rigorosa a livello di design.

4.21 Vengono adottate misure efficaci per garantire che i dati dei clienti non vengano utilizzati negli ambienti di sviluppo e di test?

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

Tuttavia, abbiamo progettato una pipeline speciale e limitata per accedere a frammenti minimi (solo lettura) dei dati dei clienti a scopo diagnostico. Questa pipeline garantisce automaticamente una minimizzazione rigorosa e completamente automatizzata dei dati recuperati. Questa pipeline garantisce anche automaticamente la cancellazione dei dati alla fine dell’operazione diagnostica. Vedi 4.22 per ulteriori dettagli su questa pipeline limitata.

4.22 Nel caso in cui lo sviluppo o il testing richieda un utilizzo limitato dei dati dei clienti, esiste un processo definito per garantire la distruzione sicura e completa dei dati negli ambienti di sviluppo e di test?

Sì, abbiamo progettato una pipeline speciale (solo lettura) dedicata all’uso eccezionale dei dati dei clienti a scopo diagnostico, di solito per il testing delle prestazioni. Questa pipeline dati è accessibile solo a una parte limitata del team di ingegneria del software.

Questa pipeline dati è stata progettata per minimizzare automaticamente il frammento dei dati dei clienti recuperati per la diagnostica di interesse. Questa capacità ci consente di operare con una frazione molto piccola dei dati originali (come quelli presenti nell’account del cliente). Inoltre, elimina la necessità per il team di ingegneria di selezionare manualmente i dati da recuperare.

Infine, questa pipeline dati cancella automaticamente i dati recuperati alla fine dell’operazione diagnostica.

4.23 Sono note e documentate tutte le posizioni fisiche dei dati dei clienti, compresi i sistemi di backup e di alta disponibilità?

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

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

Sì, anche se i dati dei clienti di Lokad sono archiviati nei data center sicuri di Microsoft Azure, a cui Lokad non ha accesso fisico. La posizione fisica dei data center di Microsoft è di pubblico dominio e la scelta di Lokad dei data center è documentata pubblicamente.

4.25 Il Numero di Conto Primario (PAN) viene conservato solo se è assolutamente necessario per scopi legittimi?

Lokad non riceve, conserva o gestisce PAN dei clienti.

Il PAN (Numero di Conto Primario) si riferisce di solito al numero principale di una carta di credito o di debito. È la sequenza di numeri impressa o stampata sul fronte di una carta e utilizzata per identificare univocamente 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 effettuata tramite bonifico bancario, eliminando completamente il problema della gestione dei PAN.

Abbiamo alcuni PAN - per le carte di Lokad stessa - che gestiamo in modo sicuro, seguendo le indicazioni fornite dalle banche stesse.

4.26 I Numeri di Conto Primario (PAN) non criptati vengono mai inviati tramite tecnologie di messaggistica degli utenti finali (ad esempio: per email, messaggistica istantanea e chat)?

No, i PAN (Numeri di Conto Primario) non criptati non vengono mai inviati tramite canali non sicuri come l’email. Lokad fornisce una comunicazione sicura integrata sulla sua piattaforma, che è un’alternativa superiore per la trasmissione di materiali sensibili. Consigliamo l’utilizzo di questo canale ogni volta che l’uso di un canale non sicuro comporta un rischio commerciale significativo.

Nota: Per design, Lokad non riceve, conserva o gestisce PAN dei clienti. Pertanto, non ci sono trasferimenti di PAN non criptati.

Vedi anche la conservazione dei PAN

4.27 Hai un contratto in atto con i tuoi fornitori di servizi di cloud computing e questo contratto contiene clausole relative alle disposizioni sulla sicurezza delle informazioni dei fornitori di servizi di cloud computing?

Sì, Lokad ha un Accordo Enterprise (EA) in atto con Microsoft per i servizi di cloud computing di Azure. L’Accordo Enterprise include tipicamente varie condizioni relative all’uso dei servizi, compresi impegni sulla sicurezza dell’ambiente cloud.

Microsoft Azure, come uno dei principali fornitori di servizi cloud, pone un’alta enfasi sulla sicurezza. Azure ha un set 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.

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

4.28 Sono coinvolti subappaltatori nel trattamento dei dettagli/dati del cliente?

No, Lokad non subappalta il trattamento dei dettagli o dei dati del cliente. Per quanto riguarda la piattaforma di Lokad, acquistiamo risorse di calcolo - principalmente macchine virtuali e archiviazione di blob - da Microsoft Azure, ma oltre a questo nessuna terza parte è coinvolta per quanto riguarda i dati del cliente.

Per quanto riguarda la fornitura dei servizi professionali di Lokad, solo i dipendenti a tempo pieno di Lokad (in questo caso, gli scienziati della supply chain) hanno accesso ai dettagli o ai dati del cliente. Lokad occasionalmente ha alcuni stagisti (anche se molto meno rispetto alla maggior parte delle aziende comparabili) per tirocini a lungo termine, ma operano sotto la supervisione diretta e rigorosa di un senior supply chain scientist.

Nota: Gli stagisti sono soggetti agli stessi accordi di riservatezza degli scienziati della supply chain a tempo pieno.

5. Registrazione e monitoraggio

5.1 Offri registri di accesso (utente, data, data dell’ultima connessione, ecc.)?

Sì. Lokad fornisce registri di accesso formattati come file CSV. In questo momento, è possibile richiedere questi registri al personale di supporto di Lokad. L’estrazione del registro verrà inserita nell’account Lokad in un luogo accessibile solo agli utenti con designazione “Proprietario”. Abbiamo in programma di introdurre un metodo di accesso più diretto, attraverso un’interfaccia web dedicata, al trail di audit completo che già esiste nel backend della piattaforma Lokad.

5.2 Centralizzi i registri di tutti i componenti della soluzione?

Sì. Il design dell’event sourcing di Lokad centralizza non solo i registri, ma anche tutti i cambiamenti di stato che avvengono nella soluzione. I registri, insieme ad altri cambiamenti di stato, sono centralizzati con una piccola collezione di flussi di eventi, gestiti dallo stesso event store. Internamente, i registri che non influiscono sullo stato della soluzione sono segregati da quelli che lo fanno.

Da un punto di vista puramente tecnico, ci sono alcuni registri legati alle prestazioni che intenzionalmente non vengono centralizzati all’interno dell’event store. Questi registri includono misurazioni delle prestazioni dettagliate, come quelle prodotte dall’strumentazione interna di profilazione delle prestazioni di Lokad (ad esempio, quanti millisecondi vengono impiegati per ogni chiamata di funzione durante l’esecuzione di uno script Envision). Questi registri sulle prestazioni non contengono nulla che possa essere considerato materiale “relativo alla sicurezza”.

5.3 Registri le modifiche e le operazioni effettuate nell’applicazione? Tieni traccia di tutte le transazioni?

Sì. Grazie al design dell’event sourcing di Lokad, tutto viene registrato per necessità. Infatti, la soluzione stessa è la somma della collezione di eventi registrati all’interno della soluzione. Pertanto, la registrazione è un aspetto fondamentale dell’architettura della soluzione. Questo design dell’event sourcing impedisce l’omissione accidentale di un registro che riflette un cambiamento di stato. In un framework di event sourcing del genere, non ci sono transazioni, almeno non nel senso usuale di un database transazionale (ad esempio, MySQL, Oracle, ecc.). Queste transazioni sono sostituite da eventi che contengono tutte le informazioni associate a un cambiamento di stato.

5.4 Normalizzi i formati dei registri dei vari componenti per scopi forensi?

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

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

Sì, previo accordo contrattuale con il cliente.

5.6 Tracci tutte le eccezioni generate nella tua soluzione?

Sì. Il design dell’event sourcing di Lokad ci consente di tracciare tutte le eccezioni generate nella nostra soluzione e riprodurre le condizioni che hanno portato al problema in primo luogo. Una volta identificate, il team di ingegneria di Lokad elimina tutte le eccezioni osservate. Abbiamo sviluppato strumenti dedicati a questo scopo specifico e manteniamo un backlog molto limitato di eccezioni non corrette.

5.7 La soluzione ha la capacità di monitorare lo stato di salute dei diversi componenti/servizi in tempo reale?

Sì. I nostri sottosistemi sono stati progettati con endpoint di monitoraggio dedicati ai controlli di salute. 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” è piuttosto vago quando si tratta di sistemi distribuiti. Ai fini del monitoraggio dello stato di salute del sistema, la latenza prevista varia da pochi secondi a un minuto (approssimativamente).

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ì, previo accordo contrattuale dedicato.

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

Sì. La soluzione Lokad ha il proprio scheduler di job interno (chiamato “Runflow”) per orchestrare attività a lunga durata all’interno della piattaforma Lokad, tipicamente l’esecuzione di script Envision. Questo scheduler può essere configurato, tramite un’interfaccia utente 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 gli errori, per poi intraprendere azioni proattive?

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

5.11 La soluzione ha capacità di conservazione dei dati di audit? I dati vengono archiviati e purgati in un database MIS per l’audit dell’attività dell’utente?

Sì. Attraverso il suo design dell’event sourcing, la soluzione Lokad conserva una traccia di audit estesa, molto più ampia di quanto si ottenga attraverso design più diffusi che di solito sfruttano un database transazionale invece di uno store di eventi. La soluzione Lokad non isola un sistema di informazione di gestione (MIS) come un sottosistema separato. In effetti, il flusso di eventi è la traccia di audit. Più in generale, Lokad conserva i dati di produzione per la durata del servizio con il cliente. Alla cessazione del servizio, che dipende dai termini contrattuali negoziati, i dati del cliente vengono purgati, anche se l’eliminazione finale all’interno del sistema di backup potrebbe avvenire alcuni mesi dopo la fine del contratto.

5.12 Il 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 nel cloud è monitorata dai team di ingegneria del software di Lokad. Poiché la piattaforma Lokad è multi-tenant, questo monitoraggio viene principalmente eseguito con una mentalità “di sistema”, garantendo che le capacità della piattaforma (compreso il suo profilo di prestazioni) siano conformi agli standard. Abbiamo progettato il nostro strato di strumentazione per questo scopo. Il monitoraggio “funzionale” è tipicamente specifico del cliente in quanto dipende dalle specifiche della catena di approvvigionamento data. Questo monitoraggio è tipicamente fornito dai team di scienziati della catena di approvvigionamento (gli ingegneri forniti da Lokad), come da accordo contrattuale.

Gli scienziati della catena di approvvigionamento di Lokad di solito si specializzano in una particolare classe di account clienti (ad esempio, aerospaziale). Creano strumenti di monitoraggio personalizzati utilizzando l’account Lokad. Questo monitoraggio include il controllo che i numeri forniti da Lokad siano corretti, non solo dal punto di vista tecnico, ma anche dal punto di vista del business del cliente.

5.13 I log vengono revisionati e analizzati tempestivamente e sistematicamente per rilevare anomalie e segnali di violazione?

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

Vedi anche Logging e Monitoraggio 5.2.

5.14 I sistemi di gestione dei log sono amministrati da persone non coinvolte nell’amministrazione degli altri sistemi (ad esempio, separazione dei compiti)?

Sì. La supervisione dei log e dell’attività generale della piattaforma è effettuata dagli scienziati della catena di approvvigionamento, mentre l’amministrazione generale della nostra infrastruttura è effettuata da dipendenti specifici della nostra divisione IT.

5.15 Vengono eseguite scansioni periodiche e sistematiche delle vulnerabilità a livello di applicazione?

Sì, anche se tali scansioni sono una parte molto piccola dei nostri processi di sicurezza. Vedi Dipendenti 6.6.

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

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

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

No. IDS è un design intrinsecamente pericoloso in quanto viola il principio di sicurezza del “privilegio minimo”: un componente ottiene grandi privilegi per operare come un “uomo nel mezzo”. Ciò rende l’IDS stesso un obiettivo principale per gli attaccanti e amplia notevolmente la superficie di attacco della piattaforma. Tuttavia, Lokad monitora attentamente il traffico web e i comportamenti anomali degli utenti sulla nostra piattaforma stessa. Queste capacità, però, fanno parte della piattaforma stessa e quindi non vengono delegate a componenti software di terze parti isolate privilegiate.

Vedi anche Dipendenti 6.6.

6. Dipendenti

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

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

6.2 Gli dipendenti ricevono formazione sulla consapevolezza e sulla sicurezza?

Sì, la consapevolezza sulla sicurezza e la formazione sulla sicurezza vengono fornite ai dipendenti di Lokad che sono in contatto con dati confidenziali e/o sistemi di ingegneria che sono in contatto con dati confidenziali. Per ulteriori informazioni su questo punto, la lezione Cybersecurity for Supply Chain è dedicata agli scienziati della supply chain, le persone che gestiscono i dati confidenziali dei clienti.

6.3 Chi ha accesso ai dati dei clienti presso Lokad?

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

Da parte di Lokad, per ogni account cliente c’è un breve elenco di dipendenti che hanno accesso. Prima di tutto, questo elenco include gli scienziati della supply chain (gli ingegneri forniti da Lokad) che implementano e mantengono la soluzione di ottimizzazione della supply chain. Ci si aspetta che questi scienziati della supply chain accedano ai dati del cliente quotidianamente. Internamente, Lokad limita l’accesso all’account del cliente solo agli scienziati della supply chain assegnati a quegli account. Cioè, lo scienziato della supply chain A non può accedere all’account del cliente B a meno che A non sia stato esplicitamente assegnato a gestire questo account (come concordato con il cliente).

In secondo luogo, questo elenco include il team di ingegneria responsabile dell’amministrazione di sistema della nostra piattaforma. Come regola generale, l’accesso diretto ai dati del cliente è raro e limitato all’indagine di situazioni segnalate sia dai clienti stessi che dai loro scienziati di supporto della supply chain. Lokad non condivide l’accesso ai dati del cliente con terze parti, ad eccezione della piattaforma di cloud computing.

6.4 Come proteggete le postazioni di lavoro dei dipendenti?

Ad eccezione del team di ingegneria del software, i dipendenti di Lokad operano senza privilegi amministrativi sui dispositivi forniti dall’azienda. Tutte le postazioni di lavoro sono configurate con crittografia del disco completo per proteggersi dal furto di dati che potrebbe essere causato dalla perdita, dal furto o dalla fiducia in terze parti (ad esempio, per le riparazioni).

Le postazioni di lavoro utilizzate dai nostri dipendenti non contengono i dati dei nostri clienti. A seconda del compito da svolgere, un dipendente può scaricare alcune schede Excel sul proprio computer, ad esempio, per fare una presentazione, ma la nostra politica è quella di mantenere rigorosamente tutti i dati dei clienti al sicuro nel cloud.

6.5 Come proteggete gli smartphone dei dipendenti?

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

6.6 Utilizzate un antivirus?

Sì, le nostre postazioni di lavoro hanno Microsoft Defender, come previsto dalle configurazioni di Microsoft Windows 10+. Non abbiamo un altro antivirus oltre a Microsoft Defender, ma la nostra opinione è che questa classe di strumenti tende a fare più danni che benefici (in termini di sicurezza informatica). A titolo di prova aneddotica, l’hack di SolarWinds del 2020 è considerato una delle più grandi catastrofi di sicurezza informatica di tutti i tempi ed è stato causato da un software che avrebbe dovuto migliorare la sicurezza in primo luogo. 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 loro stessi vettori di attacco. La nostra prospettiva sulla sicurezza informatica è che meno è meglio e che l’aggiunta di pezzi di tecnologia molto complessi nel nostro panorama applicativo lo rende quasi invariabilmente meno sicuro, non più sicuro.

6.7 I programmatori di software vengono periodicamente addestrati all’uso di metodi di valutazione delle minacce, standard di codifica sicura, elenchi di controllo di sicurezza ben noti e framework?

Sì. Tuttavia, la maggior parte degli elenchi di controllo ben noti riflette principalmente architetture “non sicure per progettazione”. Quando possibile, preferiamo eliminare la fonte di insidie per la sicurezza nella fase di progettazione. Vedi anche Dipendenti 6.2.

6.8 Tutti i contratti con i subappaltatori/la forza lavoro esterna di Lokad includono un Accordo di Non Divulgazione (NDA)? Questo NDA copre le informazioni dei clienti?

Sì per entrambi, anche se Lokad - al momento della stesura - non si affida a subappaltatori/forza lavoro esterna. I team di ingegneria del software e di scienziati della supply chain di Lokad sono completamente formati da persone sotto l’impiego diretto, permanente e supervisione di Lokad.

Tuttavia, se Lokad dovesse ritenere necessario impegnarsi con un subappaltatore, sarebbero soggetti agli stessi termini di proprietà intellettuale (IP) e NDA dei nostri dipendenti permanenti. Questi accordi includono termini relativi alle informazioni sui clienti di Lokad.

6.9 Tutto il personale esterno di Lokad ha ricevuto la formazione interna di Lokad sulle informazioni e sulla sicurezza (e la formazione continua pertinente)?

Lokad - al momento della stesura - non si affida a subappaltatori/forza lavoro esterna. I team di ingegneria del software e di scienziati della supply chain di Lokad sono completamente formati da persone sotto l’impiego diretto, permanente e supervisione di Lokad.

Tuttavia, se Lokad dovesse ritenere necessario impegnarsi con 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 già detto, Lokad attualmente non si affida a una forza lavoro esterna, quindi non si svolge alcuna formazione di questo tipo.

Vedi anche Dipendenti 6.8

6.10 Tutti i contratti con le aziende che forniscono la forza lavoro esterna di Lokad (qualsiasi/ogni appaltatore, consulente, ecc., che partecipa 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 affida a subappaltatori/forza lavoro esterna. I team di ingegneria del software e di scienziati della supply chain di Lokad sono completamente formati da persone sotto l’impiego diretto, permanente e supervisione di Lokad.

Tuttavia, se Lokad dovesse ritenere necessario impegnarsi con 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 la cyber-spionaggio, sono commessi da persone che hanno un passato 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 automaticamente disabilitati o eliminati alla fine del rapporto di lavoro?

Sì. Tutti i dipendenti di Lokad ricevono i loro diritti di accesso tramite un provider di identità federato (Microsoft Azure Active Directory). Alla fine del loro rapporto di lavoro, se applicabile, questo accesso viene revocato, disabilitando automaticamente tutti i diritti amministrativi associati.

Nota: La maggior parte dei dipendenti di Lokad non riceve mai diritti amministrativi poiché non sono necessari per l’esecuzione dei loro compiti.

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 effettuati 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 di 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 di edificio, Lokad opera in un edificio per uffici che beneficia di sorveglianza di terze parti 24 ore su 24, 7 giorni su 7, con sicurezza in loco.

A livello di ufficio, i locali di Lokad hanno i propri punti di accesso sicuri, indipendenti da quelli dell’edificio stesso. Questo ultimo livello 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 da membri del personale di Lokad.

6.14 Sono ammessi visitatori nella struttura?

Se per “struttura” si intende “il luogo in cui vengono archiviati e elaborati i dati dei clienti”, allora no. I dati dei clienti vengono archiviati nei data center di Microsoft Azure. Questi data center non sono aperti al pubblico - Lokad stessa non può accedervi.

Tuttavia, Lokad occasionalmente accoglie visitatori presso la sua sede centrale. I nostri uffici non sono aperti al pubblico, ma occasionalmente si verificano circostanze eccezionali, come visite di clienti, candidati in attesa di un colloquio, ecc. Tali visite vengono pianificate in anticipo e i visitatori sono accompagnati da membri del personale di Lokad durante tutto il tempo trascorso nei nostri uffici.

6.15 I record di dati cartacei (e i supporti elettronici rimovibili contenenti dati) vengono conservati in armadi ignifughi sicuri durante la notte?

Lokad non opera con record di dati cartacei, né opera con supporti elettronici rimovibili. Poiché non abbiamo registri fisici da archiviare, Lokad non ha bisogno di armadi ignifughi.

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

6.16 È in vigore una politica di scrivania pulita? In tal caso, fino a che punto?

Sì, Lokad opera con una politica di scrivania pulita saldamente in vigore. Questa politica è applicata “per design” attraverso il nostro ambiente digitale.

Ad eccezione di alcuni documenti che siamo legalmente obbligati a stampare, o documenti occasionali che vengono stampati per necessità (ad esempio, un poster per una fiera, anche se anche questo sarebbe tipicamente esternalizzato), l’ambiente di lavoro di Lokad è strettamente 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 in questione è effettivamente ripulita.

6.17 Dove arrivano i fax e chi potrebbe avervi accesso?

Lokad non ha mai posseduto una macchina per i fax - che sia fisica o virtuale. Non conosciamo alcun caso d’uso convincente per cambiare la nostra posizione su questa tecnologia.

6.18 Esiste un processo per verificare il ritorno degli asset costituenti (computer, telefoni cellulari, carte di accesso, token, smart card, chiavi, ecc.) al termine del rapporto di lavoro?

Sì, abbiamo non solo un processo in atto, ma anche un software di gestione degli asset IT per supportare questo sforzo e ridurre al minimo gli errori amministrativi.

Tuttavia, abbiamo progettato deliberatamente la sicurezza di Lokad in modo che non dipenda dal ritorno tempestivo degli asset costituenti. Lokad assume che ogni asset costituente abbia una buona possibilità di essere perso o rubato, indipendentemente da quanto disciplinati e addestrati possano essere i nostri dipendenti. Nella pratica, ciò accade molto raramente, ma dal punto di vista dell’ingegneria, facciamo l’assunzione opposta. Per questo motivo, gli asset costituenti possono essere disabilitati a distanza. Inoltre, applichiamo la crittografia completa del disco quando 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 allevia considerevolmente la criticità degli asset costituenti nel caso in cui le nostre altre misure preventive dovessero fallire.

6.19 Le politiche e/o procedure delle Risorse Umane (HR) sono approvate dalla direzione e comunicate ai soggetti interessati, e viene designato un responsabile per la loro manutenzione e revisione?

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

Inoltre, abbiamo designato un responsabile che è responsabile per la manutenzione continua, gli aggiornamenti e la revisione regolare delle politiche e delle procedure. Ciò garantisce che le nostre pratiche rimangano attuali, pertinenti e in linea sia con gli standard del settore che con gli obiettivi organizzativi.

6.20 Ci sono dispositivi mobili personali (BYOD), invece di dispositivi di proprietà dell’azienda, utilizzati da persone associate alla vostra organizzazione che hanno 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à dell’azienda, eliminando la necessità di dispositivi personali. Questa disposizione affronta lo scenario comune in cui i dipendenti ricorrono all’uso dei propri dispositivi a causa della insoddisfazione per l’hardware aziendale di scarsa qualità.

Inoltre, i nostri protocolli operativi sono progettati in modo tale che anche sui dispositivi di proprietà dell’azienda, i dati dei clienti non vengano memorizzati in modo permanente. Tutta l’elaborazione dei dati avviene all’interno della nostra piattaforma basata su cloud. Sui dispositivi dei dipendenti, i dati dei clienti (se mai accessibili) vengono gestiti in modo transitorio e solo in segmenti minimi, garantendo la massima sicurezza.

Note