FAQ: Sicurezza del Software

Lokad è, prima di tutto, uno specialista della supply chain e il nostro obiettivo principale è fornire decisioni di supply chain superiori attraverso l’ingegnosità tecnologica. Detto ciò, gestiamo importanti dati finanziari quotidianamente, quindi la sicurezza della nostra piattaforma software è una priorità e la trattiamo con la massima serietà. Piuttosto che affrontare 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 dal nostro specifico design del software, dalle scelte di personale e formazione.

Pubblico previsto: Dipartimento IT
Ultima modifica: 21 settembre 2023

Principi di sicurezza

Una delle illusioni più dannose nei circoli del software aziendale è l’idea che la sicurezza possa essere affrontata con checklist di conformità, certificazioni e, più in generale, ogni sorta di lavoro burocratico. Purtroppo, i dettagli della sicurezza sono sempre in 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 per 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 blob semplice, come uno strato di storage 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 strati di persistenza sono solo append-only. Questo è simile al controllo delle versioni in cui le modifiche vengono aggiunte alla fine dei dati esistenti, anziché sovrascrivere l’intero dato. Tutte le modifiche sono tracciate e possono essere annullate. Questo passaggio complica notevolmente l’eliminazione di qualsiasi dato (da chiunque, compresi gli attaccanti), così come il manomettere i log di Lokad.

La maggior parte dei fornitori di software aziendale non riconosce il fatto che le scelte di design di base sono il fondamento stesso 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 - è fornita attraverso un linguaggio di programmazione generale (come Python o JavaScript), i problemi di sicurezza inevitabilmente sorgono. Questo perché è quasi impossibile proteggere completamente un linguaggio di programmazione generale. 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é manca - per design - la capacità di interagire direttamente con il sistema operativo (OS) e i suoi sottosistemi, come il file system.

Più sicuro per 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 degno di vera cura. Nel contesto del software aziendale, questo è difficile poiché l’oggetto di interesse è astratto e scollegato 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 che ci guadagni favori o critiche. Questo è in netto contrasto con molti fornitori aziendali che fanno affermazioni pubbliche irragionevoli (e spesso fantasiose) ². Quando ciò accade, i dipendenti brillanti - quelli capaci di identificare lo scollamento tra la realtà del business e ciò che viene comunicato al mondo esterno - smettono di interessarsi. Questa indifferenza genera compiacenza e seguono problemi di sicurezza. Spesso, quei dipendenti lasciano l’azienda, lasciando dietro di sé quelli “ingenui” - coloro che non riescono a vedere lo scollamento. L’ingenuità, proprio come l’indifferenza, non è un tratto desiderabile per quanto riguarda la sicurezza.

In secondo luogo, Lokad promuove tra i suoi dipendenti una miscela 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 rivedere e aggiornare le pratiche, poiché i dipendenti sono formati e incoraggiati a contribuire. Tale plasticità è utile per anticipare attori malevoli, dato che sono noti per ideare modi sempre più creativi di attaccare. Fortunatamente per Lokad, questa mentalità si rivela anche molto desiderabile per scopi di supply chain, poiché comportamenti avversi - sebbene non necessariamente criminali - sono comuni nella supply chain ³.

Più sicuro 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 top-down. Anche se il pensiero bottom-up ha 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 a 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 a operare con il minor numero possibile di privilegi sulle loro postazioni di lavoro. Ci assicuriamo che tutti siano consapevoli di come funziona l’ingegneria sociale, che può 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 riproposti e corrotti da attori malevoli. Data la portata della formazione, delle competenze e della conoscenza necessarie per prevenire tali attacchi sfumati, Lokad ha generalmente pochi stagisti, rispetto alla maggior parte delle aziende di dimensioni comparabili nel settore. In breve, preferiamo puntare su un team stabile e altamente formato nel lungo termine.

Domande Frequenti (FAQ)

1. Pratiche

1.1 Avete un’Assicurazione di Sicurezza?

Sì. L’assicurazione di sicurezza è un termine generale per una varietà di pratiche come il potenziamento della sicurezza, i test di sicurezza e la gestione delle vulnerabilità. Il potenziamento della sicurezza, presso Lokad, è affrontato innanzitutto attraverso il design. Attraverso scelte di design specifiche, eliminiamo intere classi di vulnerabilità che, a loro volta, eliminano la necessità stessa di potenziamento. Ad esempio, Lokad non si basa su un livello di archiviazione “programmatico” - come un database relazionale - ma su un semplice store chiave-valore. Questo elimina tutti i vettori di SQL injection. Inoltre, i test di sicurezza sono affrontati 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 estesamente automatizzato per garantire che le correzioni possano essere implementate rapidamente.

1.2 Siete conformi a 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 è necessario per rendere sicuro il software. Ad esempio, queste certificazioni richiedono la produzione di documenti e l’installazione di comitati. Onestamente, l’idea che i documenti 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 raggiunge facendo meno, non di più; sfruttando gli sforzi degli ingegneri del software specializzati nella sicurezza del software, non creando team aggiuntivi di non specialisti. A titolo di prova aneddotica, considerate alcune delle catastrofi di sicurezza informatica più gravi, come Heartbleed o Log4Shell. Questi disastri probabilmente sarebbero stati evitati se le migliaia di aziende di software “certificate” avessero scelto di dare priorità alla correzione del codice di terze parti - spesso la causa radice dei problemi - anziché perseguire sigilli commerciali arbitrari.

In generale, riteniamo che queste certificazioni siano trucchi di marketing che inducono le aziende in un falso senso di sicurezza (sia figurativamente che letteralmente).

1.3 Seguite le pratiche OWASP?

Sì. OWASP fornisce, attraverso le sue guide, un elenco esteso contro le vulnerabilità comunemente 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 (accesso singolo, qualcosa raccomandato da Lokad), Lokad non deve più “gestire” le password, rendendo superfluo tutto l check-list relativo 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 check-list di 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 chiave-valore. Questa scelta di design annulla interamente la check-list del database.

Più in generale, quando possibile, preferiamo evitare i modelli di progettazione ingegneristica inclini agli errori che creano la necessità di tali check-list 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 passivo piuttosto che un’attività. Pertanto, raccomandiamo vivamente ai nostri clienti di non trasferirci dati personali. Questa raccomandazione è 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 protezione di tali dati, come il GDPR o regolamenti simili.

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

Sì. Tuttavia, come indicato in 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ì. Questo significa che facciamo scelte prudenti, poiché non c’è 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. Questo ci consente di assorbire 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 Conduci regolarmente test di penetrazione?

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

1.8 Conduci regolarmente audit esterni?

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

1.9 Hai 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 Lokad cessasse le operazioni, il cliente otterrebbe automaticamente l’accesso alla base di codice in escrow e una licenza per ricreare la propria istanza del servizio Lokad.

1.10 Hai un Piano di Comunicazione di Crisi?

Sì. Per ogni cliente abbiamo un punto di contatto identificato all’interno della loro organizzazione. Dal nostro lato, ci sono almeno due dipendenti di Lokad - un principale e un sostituto (tipicamente due dei nostri scienziati della supply chain) - che supervisionano la comunicazione di eventuali messaggi urgenti al cliente. Nella pratica, la grande maggioranza delle crisi che affrontiamo non sono problemi di sicurezza del software, ma della supply chain - emergenze identificate da Lokad 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 ti assicuri che i sistemi IT del cliente siano mantenuti al sicuro?

Raccomandiamo vivamente che Lokad non abbia accesso ai sistemi IT del nostro cliente; il sistema IT del cliente dovrebbe solo inviare e ricevere dati da Lokad. Questo approccio è pensato per mitigare la possibilità che un evento di sicurezza presso Lokad si diffonda al sistema IT del cliente. Inoltre, raccomandiamo vivamente l’uso di un processo SSO (accesso singolo), poiché 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 proteggi la tua rete?

Il nostro design adotta un’architettura Zero Trust, che significa consentire solo alle persone giuste di accedere ai dati in un determinato momento. Essere semplicemente presenti nella nostra rete non fornisce automaticamente uno status o privilegi (questo punto è approfondito in Autenticazione 2.1). Pertanto, pur essendo attenti alla sicurezza della rete, ci assicuriamo - come primo passo - che la superficie di attacco associata alle nostre reti sia resa il più piccola possibile.

Lokad utilizza due reti degne di nota. La prima è Microsoft Azure, utilizzata per ospitare la nostra soluzione. La sicurezza della rete Microsoft Azure è interamente delegata a Microsoft. Non utilizziamo capacità di rete “avanzate” - come quelle offerte da Microsoft Azure - oltre ai 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 Garantisci 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ì. Lokad ha, rispetto alla maggior parte dei fornitori di software aziendale, poche dipendenze. Tutte le nostre principali dipendenze sono progetti open-source credibili e ampiamente utilizzati (es: .NET di Microsoft, React di Facebook). Questo rende il nostro processo di audit interno su questo punto specifico una questione semplice.

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

Poiché Lokad ha adottato scelte di design e pratiche di sicurezza sensate fin dall’inizio, è raro che un cambiamento di qualsiasi entità (minore o maggiore) influenzi la 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 era stata preparata mesi prima dal team di ingegneria del software di Lokad. Materiali di formazione pertinenti e sessioni di formazione erano stati implementati prima del cambiamento programmato, per garantire la prontezza di tutti i dipendenti di Lokad. Infine, dopo ogni evento di migrazione ci si assicurava 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, quasi certamente procederemmo in modo simile.

1.15 Come gestisci 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 di per sé un rischio per la sicurezza, questo punto è soggetto a 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 per 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?

Lokad addebita tipicamente 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 dettagliati nel contratto di servizio tra il cliente e Lokad. Queste due tariffe rappresentano un pacchetto “tutto compreso” con Lokad. Non ci sono costi aggiuntivi di manutenzione, 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 i corsi di formazione?

Sì, su richiesta del cliente, possiamo fornire un modello contrattuale che rappresenta un accordo “base”. Tuttavia, le situazioni variano sostanzialmente a seconda della scala dell’iniziativa della supply chain, dei paesi applicabili e dello scopo dei servizi previsti da Lokad. Pertanto, se possibile, preferiamo impegnarci in 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 elaborare il quadro contrattuale più rilevante per la situazione.

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

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

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

Sì, Lokad opera in conformità agli standard pertinenti. Tuttavia, Lokad fornisce ottimizzazione predittiva della supply chain e, come tale, Lokad non controlla direttamente le operazioni. La nostra influenza è in gran parte indiretta, tipicamente 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 integrata a livello di rete, ad esempio su firewall, dispositivi proxy e/o sulla rete come soluzioni separate?

Vedi Pratiche 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 sulla sicurezza “per design”. Eliminando intere classi di minacce nella fase di progettazione, manteniamo la pratica complessiva di valutazione delle minacce più gestibile. La valutazione delle minacce copre anche gli “attacchi alla supply chain”. Questo è un altro motivo per cui mettiamo così tanto enfasi sulla minimizzazione della quantità di dipendenze da terze parti nella nostra pila software, poiché qualsiasi dipendenza inherently aumenta l’area di superficie di attacco.

1.22 Il processo di gestione degli incidenti viene esercitato almeno annualmente?

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 accidentalmente ai dati di Lokad diventando 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 sono stabiliti congiuntamente con l’azienda cliente e tipicamente supervisionati dal supply chain scientist di Lokad responsabile dell’account (per i clienti che optano per un account gestito).

1.23 La mappatura dei rischi e delle minacce viene riesaminata almeno annualmente?

Sì, anche se tali revisioni vengono tipicamente eseguite regolarmente durante l’anno. Tali revisioni sono comunemente guidate da eventi significativi, come violazioni di sicurezza rilevanti nell’industria del software.

1.24 Anche la valutazione dei rischi viene effettuata sulle funzioni di supporto che potrebbero influenzare la disponibilità, la qualità e/o la sicurezza della soluzione?

Sì. Tuttavia, la piattaforma di Lokad è essenzialmente un monolite che non si basa su alcune “funzioni di supporto” oltre a pochi fondamenti essenziali, come lo Storage Blob e le VM Linux fornite da Microsoft Azure.

1.25 Vengono creati account di sistema dedicati - con solo i diritti di accesso richiesti - 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 daemon 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 dettare i diritti di accesso per i processi pianificati e attivati. Questi processi sono categorizzati come processi “userland” piuttosto che “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 approvato dalla direzione senior.

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

Il nostro piano di governance dei rischi viene periodicamente riesaminato 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 rilevanti per garantire un controllo e un supporto continui.

1.27 Esiste un programma di sicurezza fisica approvato dalla direzione, comunicato ai soggetti interessati, e è stato assegnato un responsabile per mantenerlo e rivederlo?

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

Inoltre, abbiamo designato un responsabile incaricato di mantenere, aggiornare e riesaminare periodicamente il programma per garantirne l’efficacia e la pertinenza. Questo responsabile collabora con vari team e dipartimenti per affrontare eventuali emergenti preoccupazioni sulla sicurezza fisica e assicurarsi che il programma sia allineato alle migliori pratiche e agli obiettivi organizzativi.

1.28 Vengono condotte valutazioni dei rischi fisici e ambientali prima di stabilire la posizione o il sito di un impianto dove 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 del sito di Microsoft. Microsoft Azure effettua approfondite valutazioni dei rischi potenziali, inclusi rischi fisici e ambientali, prima di stabilire uno qualsiasi dei loro data center. Il loro processo di selezione coinvolge l’analisi di fattori come il potenziale di disastri naturali, l’accessibilità, la stabilità dell’infrastruttura e altro ancora.

Sfruttando i data center di Azure, siamo certi che queste valutazioni siano state compiutamente effettuate per garantire i più alti livelli di sicurezza fisica e resilienza ambientale per i nostri sistemi.

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

Sì, anche se non crediamo che l’ “etica” possa essere imposta in modo autoritario dall’alto verso il basso. Questo tipo di approccio produce inevitabilmente risultati indesiderati che vanno contro gli obiettivi originali.

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

Pertanto, Lokad si concentra sul garantire che i dipendenti abbiano la possibilità di prendersi cura genuinamente dei nostri clienti. “Stiamo facendo le cose giuste?” è uno dei nostri mantra. La conformità e l’etica sono, a nostro avviso, 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 della gestione 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 settori che sono specificamente incaricati di gestire e supervisionare queste responsabilità critiche.

Questi individui riportano direttamente al vertice della gestione 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 che è stato approvato dalla direzione, comunicato ai soggetti interessati e un responsabile designato per mantenerlo e rivederlo?

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

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

Inoltre, abbiamo designato un responsabile per la politica che è responsabile del suo mantenimento e della 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 all’autenticazione. Ad esempio, l’accesso alla pagina di login non richiede un’autenticazione preventiva (poiché l’autenticazione è lo scopo principale di questa pagina di login).

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

2.2 Richiedete 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 noi 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 Offrite SSO (accesso singolo)? Supportate 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 Supportate l’autenticazione a due fattori come EZToken, Google Authenticator o Microsoft Authenticator?

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

2.5 Supportate il protocollo di autenticazione OAuth2?

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 larga parte incompatibili. Pertanto, se OAuth2 è un requisito assoluto, per accordo contrattuale, possiamo supportare una specifica variante di OAuth2. Tuttavia, questa disposizione richiede risorse dedicate per garantire la compatibilità con la variante di OAuth2 utilizzata dall’azienda cliente.

2.6 Supportate l’integrazione LDAP?

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

2.7 Impostate 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 è delegata tramite SSO). Questa questione è nelle mani del dipartimento IT del nostro cliente, non del nostro.

2.8 Potete 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 pratica sbagliata. Gli utenti rispondono male (e prevedibilmente) alle richieste di complessità della password eccessivamente rigide, causando un calo complessivo della sicurezza. Inoltre, consideriamo tali richieste di password come “bloatware” che aumenta la complessità di un pezzo di software critico per la sicurezza (gestione delle password), esponendolo (e la soluzione complessiva) a rischi indesiderati. Vedi https://www.sans.org/blog/nist-has-spoken-death-to-complexity-long-live-the-passphrase/

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

2.9 Potete imporre rotazioni programmate delle password?

Potremmo farlo, ma non lo facciamo. Come la complessità minima della password (vedi Autenticazione 2.8), la rotazione programmata delle password è ora ampiamente riconosciuta come pratica sbagliata per la sicurezza del software. Gli utenti rispondono male (e prevedibilmente) 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 della password come “bloatware” che aumenta la complessità di un pezzo di software critico per la sicurezza (gestione delle password), esponendolo (e la soluzione complessiva) a rischi indesiderati. Vedi https://www.sans.org/blog/time-for-password-expiration-to-die/

2.10 Hashate e salate le password?

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

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

Sì, tramite 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 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 quanto lo sia per il software B2C, specialmente freeware.

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

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 Centralizzate 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, compresi i nostri team 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 a condividere account utente tra i propri dipendenti. Tuttavia, ci sono alcuni casi in cui è accettabile avere un account utente che non ha un dipendente corrispondente. Questo avviene tipicamente per il servizio “caricamento robot” lato client incaricato di inviare dati a 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 attraverso canali crittografati (tipicamente TLS).

2.16 Consentite agli utenti di accedere da più dispositivi?

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

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

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

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

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

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 media 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 sfruttano Azure Active Directory per l’autenticazione degli utenti. Quando gli ID utente e le password iniziali vengono distribuiti, 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 uno strato di sicurezza aggiuntivo al processo di autenticazione.

Ester…

È importante notare che non raccomandiamo l’autenticazione a un solo fattore, sia per gli utenti interni che esterni, se l’obiettivo è mantenere uno standard elevato di sicurezza.

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

Sì, gestiamo attivamente e monitoriamo gli ID utente per garantire la sicurezza. Per i dipendenti Lokad, la nostra politica prevede che tutti i diritti di accesso vengano revocati al loro 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à federati. 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 simultaneamente. Questo metodo non solo migliora la sicurezza, ma garantisce anche efficienza nella gestione degli utenti.

Nota: i dettagli relativi alla terminazione dell’accesso degli utenti sono dettagliati 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 degli utenti sono esplicitamente delineati, sia nel contratto che in una procedura concordata congiuntamente, garantendo che le misure di sicurezza di Lokad siano in linea con le esigenze operative dei nostri clienti.

3. Autorizzazione

3.1 La soluzione fornisce diritti di accesso dettagliati?

Sì. La soluzione Lokad include un sottosistema granulare di controllo degli accessi basato sui ruoli (RBAC). Questo consente al cliente di controllare quali “Progetti” e “File” sono accessibili (e da chi) nell’account Lokad. Il RBAC ha la sua interfaccia utente web (dashboard). È disponibile per 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 granulare di controllo degli accessi basato sui ruoli (RBAC) che può essere utilizzato per implementare il PoLP. Tuttavia, attraverso Envision (il DSL della soluzione), Lokad va molto oltre rispetto alla maggior parte del software aziendale 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. Ciò che rimane è semplificato ma comunque ampiamente configurabile. Allo stesso modo, il sistema di file su misura offerto da Lokad elimina anche interi gruppi di privilegi di sistema non necessari.

3.3 Si applicano i diritti di accesso del privilegio minimo?

Sì, anche se ciò che costituisce il privilegio “minimamente accettabile” è deciso in ultima analisi dai nostri clienti. Lokad non può determinare unilateralmente chi beneficia di una designazione “Proprietario” nel personale dei nostri clienti. Tuttavia, possiamo fornire orientamento 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ì. Questo è una forma di implementazione di PoLP ed è coperto nelle risposte 3.1, 3.2 e 3.3

3.5 Avete una classificazione dei dati (livelli di sensibilità) e controlli regolati 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 (Controllo degli Accessi Basato sui Ruoli). 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 degli accessi 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 (Controllo degli Accessi Basato sui Ruoli) 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 ciò, Lokad può interrompere operazioni asincrone a lungo termine (definite da Lokad come “Esecuzioni di Progetto”). Quando viene attivata un’interruzione, garantisce immediatamente (in modo sincrono) che l’elaborazione non influenzi il sistema, come sovrascrivere 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 (o beneficio) di dati PII, e abbiamo clausole contrattuali a tal proposito (spiegate in Pratiche 1.4 & Pratiche 1.5).

Per ulteriori informazioni sui controlli degli accessi e le designazioni, consultare le risposte 3.1, 3.2 e 3.3.

3.8 La soluzione consente filtri di ricerca dei dati 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 (Firewall dell’Applicazione Web)?

No. Il WAF è un design intrinsecamente pericoloso poiché viola il principio di sicurezza del “principio del privilegio minimo”: un componente ottiene enormi privilegi per operare come un “uomo nel mezzo”. Questo rende il WAF 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. Queste capacità, però, fanno parte della piattaforma stessa e quindi non vengono delegate a componenti software di terze parti isolati privilegiati.

Vedi anche Dipendenti 6.6.

3.10 La rete è dotata di tecnologia IPS (Sistema di Prevenzione delle Intrusioni)?

No. L’IPS è un design intrinsecamente pericoloso poiché viola il principio di sicurezza del “principio del privilegio minimo”: un componente ottiene enormi privilegi per operare come un “uomo nel mezzo”. Questo 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 inizia minimizzando l’area della superficie di attacco. Crediamo che sia molto più sicuro eliminare le vie di ingresso progettando, piuttosto che cercare di “prevenirle” come un’idea dopo il fatto.

Vedi anche Dipendenti 6.6.

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

Sì. Lokad sfrutta ReCaptcha, 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 host di salto o server bastion?

Sì. Abbiamo un sistema essenzialmente simile a ‘Teleport’. Questo offre non solo 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 audit affidabile)?

Sì. Vedi Registrazione e Monitoraggio 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 doveri modificati?

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

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

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

3.15 La tua politica di restrizione degli accessi segue il principio del “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 a un utente specifico e autenticato da un indirizzo IP specifico. In altri scenari, chiunque da qualsiasi luogo può accedere, come nel caso dei contenuti del nostro CDN (Content Delivery Network).

Vedi anche Autorizzazione 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 più API esterne. Una grande parte di queste API è ospitata da Microsoft Azure, con alcune eccezioni come letsencrypt.org. Abbiamo stabilito che mantenere un rigoroso elenco bianco di indirizzi IP potrebbe introdurre complessità che potrebbero bilanciare 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.) ai clienti/clienti 24 ore su 24, 7 giorni su 7, 365 giorni all’anno per segnalare incidenti di sicurezza?

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

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

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

Si noti che mentre il processo dettagliato nel ‘security.txt’ potrebbe essere rivisto, le informazioni più attuali e accurate saranno sempre disponibili a quel punto di accesso. 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 ore su 24, 7 giorni su 7, 365 giorni all’anno per affrontare prontamente le segnalazioni di sicurezza.

4. Gestione dei dati

4.1 Dove ospitate e elaborate i dati?

La nostra piattaforma SaaS (Software as a Service) è ospitata al 100% su Microsoft Azure; più precisamente, è ospitata nel data center Microsoft Azure Europa Nord (con sede a Dublino). I nostri backup sono memorizzati nel data center Microsoft Azure Europa Ovest (con sede ad Amsterdam). In caso di un grave guasto del data center, abbiamo piani di contingenza per migrare la piattaforma a Dublino. Dall’inizio della nostra migrazione su 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 data center.

4.2 Chi possiede i dati?

I nostri clienti rimangono i soli proprietari di tutti i dati che caricano su Lokad. I nostri clienti rimangono anche i soli proprietari di tutti i dati che generano, attraverso il loro account Lokad, sulla piattaforma Lokad. Lokad non utilizza internamente i dati dei clienti per scopi diversi da quelli che contribuiscono direttamente ai compiti che i nostri clienti ci hanno incaricato di svolgere. Lokad non rivende l’accesso ai dati dei nostri clienti a terzi. Lokad non condivide l’accesso ai dati dei clienti, tranne per i pochi fornitori di hosting che contribuiscono direttamente al compito 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 è eseguita dai team di ingegneria di Lokad. Come già accennato, la piattaforma principale di Lokad non include un database transazionale (vedi Autorizzazione 3.6), poiché Lokad utilizza invece un archivio eventi. Questo archivio 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 un archivio eventi e un archivio chiave-valore. Questo approccio differisce sostanzialmente dal design CRUD (Create-Read-Update-Delete) comunemente trovato nel software aziendale. Poiché Lokad è una soluzione SaaS, ci assumiamo la piena responsabilità della persistenza dei dati e della compatibilità futura (per garantire che i dati più vecchi rimangano accessibili).

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

Sì, soprattutto la piattaforma di cloud computing sottostante che Lokad utilizza - 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, sia i nostri team di ingegneria che i nostri team di supporto tecnico sono interni.

4.6 Si separano i livelli (rete, server e applicazioni)?

Sì, tuttavia la gestione a basso livello delle reti e dei server è delegata alla piattaforma di cloud computing sottostante che Lokad utilizza - 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 dati 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 dei DNS).

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

Sì, anche se può richiedere diverse settimane per completare tutti i passaggi. Il processo prevede l’invio di una richiesta formale scritta - emessa da una parte autorizzata all’interno dell’organizzazione del cliente - per avere i dati corrispondenti eliminati permanentemente. In pratica, disposizioni specifiche per tali richieste sono incluse nel contratto tra Lokad e i suoi clienti. I dati verranno prima eliminati dal nostro sistema di produzione principale e poi dal nostro sistema di backup. Quest’ultimo stadio è la causa della relativa “lentezza” dell’operazione. Si tratta di una scelta progettuale, poiché una volta che i dati sono eliminati dal nostro sistema principale, 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 eliminazioni permanenti). Questo design è necessario per evitare intere classi di problemi di sicurezza come l’eliminazione accidentale dei dati da parte di un dipendente del cliente, o l’eliminazione maliziosa da parte di un attaccante. Inoltre, è necessario un processo di eliminazione permanente intenzionalmente lento per mitigare gli attacchi di ingegneria sociale, come ad esempio uno scenario in cui un attaccante si finge un dipendente di un cliente.

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

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

4.9 Offrite accesso diretto al database?

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

Tuttavia, poiché Lokad non dispone di un database transazionale, non esiste un database sottostante che potrebbe essere reso “accessibile”. L’equivalente più vicino nell’architettura di Lokad è il nostro event store e non offriamo accesso diretto allo stream di eventi. Tuttavia, potrebbero essere previste disposizioni nel contratto se un cliente dovesse richiedere delle specifiche estrazioni da questo stream di eventi (ammesso 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, principalmente FTPS e SFTP. È disponibile anche 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 esterna dei dati di Lokad, consultare Vai alla 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 design software - non uno standard dati specifico o un protocollo di trasferimento dati specifico - e le aspettative “in tempo reale” possono variare da latenze sub-millisecond a sub-minute. Le funzionalità in questo ambito devono essere valutate da una prospettiva di supply chain. Nella nostra esperienza, i feed di dati in tempo reale sono raramente rilevanti per affrontare i problemi della supply chain.

4.12 Tutti i dati all’interno della soluzione possono essere esportati?

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

4.13 La soluzione offre strumenti per esportare i dati?

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

4.14 Qual sarà il formato dei dati esportati?

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

4.15 La soluzione ha la crittografia dei dati trasparente (TDE) dei dati personali identificabili (PII) nello storage mobile e back-end?

La crittografia dei dati trasparente è utilizzata sia nello storage back-end di Lokad (attraverso la crittografia dello storage Azure per i dati a riposo) che sui dispositivi emessi da Lokad (attraverso BitLocker). Lokad non memorizza 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 build, ecc.?

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

4.17 La soluzione ha la capacità di limitare gli upload di file in base al tipo e alle dimensioni dei file, e di eseguire la scansione dei contenuti dannosi?

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

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 riflesso nel nostro accordo contrattuale.

Per quanto riguarda la capacità di eseguire la scansione dei contenuti dannosi, Lokad non dispone di questa funzionalità. La nostra soluzione enfatizza la condivisione dei 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 dei contenuti caricati dagli utenti tramite Lokad.

4.18 Qual è il periodo di conservazione dei dati consigliato?

Lokad è un SaaS, quindi, ci assumiamo 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 tipicamente conservati per la durata del servizio Lokad. Infatti, i dati storici di solito sono degni 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 Condivisa”. 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 attraverso script Envision all’interno della piattaforma Lokad. Questi file piatti sono progettati per corrispondere ai requisiti specifici dell’azienda cliente. La documentazione per questi file è inclusa nel “Manuale di Procedura Condivisa” - che è uno dei deliverable iniziali di un’iniziativa tipica di Lokad.

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

Sì, mentre Lokad è un’app multi-tenant, i dati sono separati a livello di design tra i tenant, cioè gli account clienti. Questa suddivisione è un cittadino di prima classe del nostro design back-end. Questo design impedisce errori di programmazione che esporrebbero i dati di un tenant a un altro tenant, mentre sviluppa ulteriormente funzionalità banali all’interno della piattaforma. Lo storage primario sottostante 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 di ‘dogfooding’ garantisce che Lokad abbia anche un’ampia disponibilità di dati non critici da utilizzare per scopi di sviluppo e test.

Tuttavia, abbiamo progettato un pipeline speciale e ristretto per accedere a frammenti minimi (solo lettura) dei dati dei clienti a fini diagnostici. Questo pipeline garantisce automaticamente una minimizzazione rigorosa e completamente automatizzata dei dati recuperati. Questo pipeline garantisce anche automaticamente la cancellazione dei dati alla fine dell’operazione diagnostica. Vedi 4.22 per ulteriori dettagli su questo pipeline ristretto.

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

Sì, abbiamo progettato un pipeline dati speciale (solo lettura) dedicato all’uso eccezionale dei dati dei clienti a fini diagnostici - di solito test di performance. Questo pipeline dati è accessibile solo a una parte ristretta del team di ingegneria del software.

Questo pipeline dati è stato progettato per minimizzare automaticamente il frammento dei dati del cliente recuperato per la diagnostica di interesse. Questa capacità ci consente di operare con ciò che di solito corrisponde a una piccolissima frazione dei dati originali (come si trova nell’account del cliente). Inoltre, elimina la necessità per il team di ingegneria di selezionare manualmente quali dati recuperare.

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

4.23 Sono conosciute 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 memorizzati 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 sono 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 memorizzati nei data center sicuri di Microsoft Azure - una posizione a cui Lokad non ha accesso fisico. La posizione fisica dei data center di Microsoft è di pubblico dominio, e la scelta dei data center da parte di Lokad è documentata pubblicamente.

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

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

Il PAN (Primary Account Number) si riferisce di solito al numero principale su una carta di credito o di debito. È la sequenza di numeri in rilievo o stampati sul fronte di una carta e utilizzati per identificare univocamente il conto bancario legato alla carta.

Per elaborare i pagamenti, ci affidiamo esclusivamente a terze parti che gestiscono i PAN per noi. Tuttavia, va notato che la maggior parte delle transazioni ricevute da Lokad viene eseguita 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 linee guida fornite dalle banche stesse.

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

Sì, i PAN non crittografati (Numeri di Conto Primario) non vengono mai inviati attraverso canali non sicuri come l’email. Lokad fornisce un canale di comunicazione sicuro integrato sulla sua piattaforma, che è un’alternativa superiore per la trasmissione di materiali sensibili. Consigliamo questo canale ogni volta che l’uso di un canale non sicuro comporta un rischio commerciale significativo.

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

Vedi anche la memorizzazione dei PAN

4.27 Hai un contratto in atto con il tuo fornitore di servizi di cloud computing e questo contratto contiene clausole relative agli accordi sulla sicurezza delle informazioni del fornitore 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 vari termini e condizioni relativi all’uso dei servizi, inclusi impegni sulla sicurezza dell’ambiente cloud.

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

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 informatiche - principalmente macchine virtuali e archiviazione blob - da Microsoft Azure, ma oltre a questo nessuna terza parte è coinvolta quando si tratta dei dati del cliente.

Per quanto riguarda la fornitura dei servizi professionali di Lokad, solo 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 dei supply chain scientist 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, questi registri possono essere richiesti dal 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 registro completo delle attività che esiste già nel backend della piattaforma Lokad.

5.2 Centralizzi i registri di tutti i componenti della soluzione?

Sì. Il design di event sourcing di Lokad centralizza non solo i registri, ma tutti i cambiamenti di stato che avvengono nella soluzione. I registri, insieme ad altri cambiamenti di stato, sono centralizzati con una piccola raccolta di flussi di eventi, gestiti dallo stesso event store. Internamente, i registri che non influenzano lo 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 sono 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 spesi per ogni chiamata di funzione durante l’esecuzione di uno script Envision). Questi registri di prestazioni non contengono nulla che possa essere considerato materiale “relativo alla sicurezza”.

5.3 Registri i cambiamenti e le operazioni eseguite nell’applicazione? Tieni traccia di tutte le transazioni?

Sì. Grazie al design di event sourcing di Lokad, tutto viene registrato per necessità. Infatti, la soluzione stessa è la somma della raccolta di eventi registrati all’interno della soluzione. Pertanto, il logging è un aspetto fondamentale dell’architettura della soluzione. Questo design di 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 log dei vari componenti per scopi forensi?

Sì. I “log”, da un punto di vista di audit e/o sicurezza, sono le trasformazioni degli eventi sottostanti. Gli eventi sono oggetti tecnicamente serializzati. Per ottenere i log, la soluzione Lokad converte e compila questi eventi in file CSV. Normalizziamo i formati delle date, i formati numerici 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 di event sourcing di Lokad ci consente di tracciare tutte le eccezioni generate nella nostra soluzione e riprodurre le condizioni che hanno portato all’errore in primo luogo. Una volta identificate, il team di ingegneria di Lokad elimina tutte le eccezioni osservate. Abbiamo progettato strumenti dedicati a questo scopo specifico e manteniamo un backlog molto limitato di eccezioni non risolte.

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. Disponiamo di strumenti di monitoraggio, accessibili solo - a partire da gennaio 2023 - ai team di ingegneria di Lokad che consolidano continuamente le informazioni rese disponibili da quegli 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 lavori batch che non sono stati avviati in programma e monitorarne la terminazione?

Sì. La soluzione Lokad ha il proprio scheduler di lavori 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 lavori.

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

Sì. Runflow, lo scheduler di lavori 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. Anche se la piattaforma Lokad fornisce questa capacità, è comunque necessario che un ingegnere implementi - attraverso 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 ed eliminati in un database MIS per l’audit dell’attività dell’utente?

Sì. Attraverso il suo design di event sourcing, la soluzione Lokad conserva una traccia di audit estesa; molto più grande di quanto si ottenga attraverso design più comuni che di solito fanno leva su un database transazionale invece di un event store. La soluzione Lokad non isola un Sistema Informativo di Gestione (MIS) come un sottosistema separato. In effetti, lo stream 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 eliminati, anche se l’eliminazione definitiva all’interno del sistema di backup potrebbe avvenire alcuni mesi dopo la fine del contratto.

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

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

La piattaforma ospitata su cloud è monitorata dai team di ingegneria del software di Lokad. Poiché la piattaforma Lokad è multi-tenant, questo monitoraggio è in gran parte eseguito con una mentalità “sistemica”, garantendo che le capacità della piattaforma (compreso il suo profilo di performance) siano conformi agli standard. Abbiamo progettato il nostro strato di strumentazione per questo scopo. Il monitoraggio “funzionale” è tipicamente specifico del cliente poiché dipende dalle specifiche della supply chain data. Questo monitoraggio è tipicamente fornito dai team di supply chain scientists (gli ingegneri forniti da Lokad), come da accordo contrattuale.

I supply chain scientists di Lokad di solito si specializzano in una particolare classe di account clienti (ad esempio, aerospaziale). Creano strumentazioni di monitoraggio personalizzate 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 aziendale del cliente.

5.13 I log vengono esaminati e analizzati tempestivamente e sistematicamente, al fine di rilevare anomalie e segnali di violazione?

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

Vedi anche Logging and Monitoring 5.2.

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

Sì. La supervisione dei log e dell’attività generale della piattaforma è svolta dai Supply Chain Scientists, mentre l’amministrazione generale della nostra infrastruttura è svolta da dipendenti specifici all’interno 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 Employees 6.6.

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

Sì, la nostra macchina di produzione è dotata di regole molto rigide, come l’apertura di un numero molto limitato di porte (configurato tramite Microsoft Azure). La configurazione della nostra infrastruttura è scriptata, e la sua evoluzione segue il nostro solito 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 “principio del privilegio minimo”: un componente ottiene enormi privilegi per operare come un “uomo nel mezzo”. Questo 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. Queste capacità, però, fanno parte della piattaforma stessa e quindi non vengono delegate a componenti software di terze parti isolati privilegiati.

Vedi anche Employees 6.6.

6. Dipendenti

6.1 Gli dipendenti hanno accordi di riservatezza (Non-Disclosure Agreements)?

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 della sicurezza e sulla sicurezza?

Sì, la consapevolezza della 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 ai supply chain scientists - le persone che gestiscono i dati confidenziali dei clienti.

6.3 Chi ha accesso ai dati del cliente 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. C’è un’applicazione web all’interno della soluzione Lokad dedicata alla gestione delle autorizzazioni (chiamata “Hub”).

Da parte di Lokad, per ciascun account cliente c’è un breve elenco di dipendenti che hanno accesso. Innanzitutto, questo elenco include i supply chain scientists (gli ingegneri forniti da Lokad) che implementano e mantengono la soluzione di ottimizzazione della supply chain. Ci si aspetta che questi supply chain scientists accedano ai dati del cliente quotidianamente. Internamente, Lokad limita l’accesso all’account cliente solo ai supply chain scientists assegnati a quegli account. Cioè, Supply Chain Scientist A non può accedere all’Account 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 delle situazioni segnalate sia dai clienti stessi che dai loro supply chain scientists di supporto. Lokad non condivide l’accesso ai dati del cliente con terze parti, ad eccezione della piattaforma di cloud computing.

6.4 Come si proteggono 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 proteggere contro il furto di dati che potrebbe essere causato dalla perdita, dal furto o dal affidamento a terze parti (ad esempio, per 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 tabelle Excel sul proprio computer, ad esempio per creare una presentazione, ma la nostra politica è quella di mantenere rigorosamente tutti i dati dei clienti sicuri nel cloud.

6.5 Come si proteggono gli smartphone dei dipendenti?

I dipendenti di Lokad non hanno smartphone forniti dall’azienda. I dati non critici, come 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 nei setup di Microsoft Windows 10+. Non abbiamo un altro antivirus oltre a Microsoft Defender, ma la nostra posizione è che questa classe di strumenti tende a fare più male che bene (in termini di sicurezza informatica). A titolo di prova aneddotica, l’hack SolarWinds del 2020 è considerato una delle più grandi catastrofi della sicurezza informatica di tutti i tempi, ed è stato causato da un software che doveva 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 rende quasi invariabilmente meno sicuro, non più sicuro.

6.7 I software developers vengono periodicamente formati all’uso di metodi di valutazione delle minacce, standard di codifica sicura, checklist di sicurezza ben noti e framework?

Sì. Tuttavia, la maggior parte delle checklist ben note riflette principalmente architetture “insicure 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 Riservatezza (NDA)? Questo NDA copre le informazioni dei clienti?

Sì ad entrambi, anche se Lokad - al momento della stesura - non si affida a subappaltatori/una forza lavoro esterna. I team di ingegneria del software e di supply chain scientist 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 IP (Proprietà Intellettuale) 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 rilevante in corso)?

Lokad - al momento della stesura - non si affida a subappaltatori/una forza lavoro esterna. I team di ingegneria del software e di supply chain scientist 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 ai requisiti di formazione dei nostri dipendenti permanenti.

Come già detto, Lokad attualmente non si affida a una forza lavoro esterna, quindi non si tiene alcuna formazione del genere.

Vedi anche Dipendenti 6.8

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

Lokad - al momento della stesura - non si affida a subappaltatori/una forza lavoro esterna. I team di ingegneria del software e di supply chain scientist 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 lo spionaggio informatico, sono commessi da persone con un passato impeccabile. Questo, tra le altre ragioni, è il motivo per cui Lokad esita 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 cancellati alla fine del rapporto di lavoro?

Sì. Tutti i dipendenti Lokad ricevono i loro diritti di accesso attraverso un fornitore 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 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. Di conseguenza, il personale Lokad non ha accesso a nessun dato 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 dove viene svolto il lavoro?

A livello dell’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 sul posto.

A livello dell’ufficio, i locali di Lokad hanno i propri punti di accesso sicuri, indipendenti da quelli dell’edificio stesso. Questo ultimo strato impedisce ai dipendenti di altre aziende all’interno dell’edificio di accedere agli uffici di Lokad.

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

6.14 Ai visitatori è permesso entrare nella struttura?

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

Tuttavia, Lokad accoglie occasionalmente visitatori presso la sua sede centrale aziendale. 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 sono pianificate in anticipo e i visitatori sono sempre accompagnati da membri del personale Lokad durante la permanenza nei nostri uffici.

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

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

Anche se potremmo occasionalmente stampare un documento (Lokad stampa pochissimi documenti, se mai), abbiamo anche una distruggi documenti accanto alla stampante. La politica predefinita di Lokad è quella di non stampare alcun documento sensibile, 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 libera? In caso affermativo, in che misura?

Sì, Lokad opera con una politica di scrivania libera 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 di 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.

Quindi, 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 assegnata è effettivamente ripulita.

6.17 Dove arrivano i fax e chi potrebbe avervi accesso?

Lokad non ha mai posseduto una macchina per i fax - 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ì, non solo abbiamo un processo in atto, ma disponiamo anche di un software di gestione degli asset IT per supportare questo sforzo e ridurre al minimo la quantità di errori amministrativi.

Tuttavia, abbiamo progettato deliberatamente la sicurezza di Lokad in modo che non dipenda dal ritorno tempestivo degli asset costituenti. Lokad presume che qualsiasi asset costituente abbia una buona probabilità di essere perso o rubato, indipendentemente da quanto disciplinati e addestrati possano essere i nostri dipendenti. Nella pratica, ciò accade molto raramente, ma da un punto di vista ingegneristico, 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 postazioni di lavoro, notebook o telefoni cellulari. Questo design allevia notevolmente 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 costituenti, e viene designato un responsabile per mantenerle e rivederle?

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

Inoltre, abbiamo designato un responsabile incaricato della manutenzione continua, degli aggiornamenti e della revisione periodica delle politiche e 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), anziché di proprietà dell’azienda, utilizzati da individui associati alla vostra organizzazione che hanno accesso ai dati dei clienti?

No, Lokad non permette 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 con l’hardware aziendale di bassa qualità.

Inoltre, i nostri protocolli operativi sono progettati in modo che anche sui dispositivi di proprietà dell’azienda, i dati dei clienti non siano memorizzati permanentemente. 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