Security of Lokad

Forecasting Engine

Platform

Lokad is, first and foremost, a supply chain specialist and our primary objective is delivering superior supply chain decisions through technological ingenuity. That said, we handle important financial data on a daily basis, thus the security of our software platform is a priority and one we treat with the utmost seriousness. Rather than approaching security as an afterthought to be handled through bureaucracy, we firmly believe in a principled approach that emphasizes planning and proactivity – evidenced by our specific software design, staffing and training choices.

Intended audience: The IT department
Last modified: January 27, 2023

Security principles

One of the most harmful illusions in enterprise software circles is the idea that security can be approached with compliance checklists, certifications and, more generally, all sorts of bureaucratic busy work. Unfortunately, the fine print of security concerns is always in flux. Problems arise as ill-intentioned actors take advantage of software or people (or both). Security can, therefore, only be approached through the sensible application of general principles.

Safer by design

We believe that design is one of the most underappreciated aspects of software security. Here, design covers the fundamental decisions that have been made to develop the software. The design decisions a company makes have massive implications as far as security is concerned, particularly the attack surface. Through sensible software design, Lokad has eliminated entire classes of security issues. For example, Lokad does not use an SQL database - but simple blob storage - as a strictly passive storage layer. This choice alone prevents whole groups of security issues, such as SQL injection attacks, as there is simply no SQL database to attack. Similarly, all our layers of persistence are append-only. This is like version control where changes are added to the end of existing data, rather than overwriting the entire data. All changes are traced, and can be reversed. This step greatly complicates the deletion of any data (by anyone, including attackers), as well as tampering with Lokad’s logs.

Most enterprise software vendors do not acknowledge the fact that core design choices are the very bedrock of their software products. As a result, their security woes are unending. For example, if configurability - almost always a requirement for enterprise software - is provided through a general-purpose programming language (like Python or JavaScript), security problems will invariably arise. This is because it is nigh on impossible to fully secure a general-purpose programming language. In contrast, Lokad made the conscious design choice of channeling all the configurability through a DSL (domain specific programming language) named Envision. Envision is much safer because it lacks - by design - the capacity to directly interact with the OS (operating system) and its subsystems, like the file system.

Safer by culture

No technology, and certainly no process, can make software secure if people just do not care. Therefore, we try our best to make Lokad - both its technologies and processes - something worth genuine care. In the context of enterprise software, this is difficult as the object of interest is abstract and disconnected from peoples’ individual perspectives and motivations^[a].

First, Lokad aligns, as much as is humanly possible, its marketing messages with the reality of its business. We do this whether it wins us favor or criticism. This stands in stark contrast to many enterprise vendors who make unreasonable (and often fanciful) public claims ^[b]. When the latter happens, sharp employees - the ones capable of identifying the disconnect between the reality of the business and what is being communicated to the outside world - cease to care. This indifference breeds complacency, and security woes follow. Often, those employees quit the company, leaving behind the “gullible” ones - those who fail to see the disconnect. Gullibility, much like indifference, is not a desirable trait as far as security is concerned.

Second, Lokad fosters among its employees a mix of curiosity and healthy skepticism about all aspects of our business, both technical and non-technical, including security. This creates flexibility when it comes to revising and updating practices, as employees are trained and encouraged to contribute. Such plasticity is useful in anticipating ill-intentioned actors, given they are known to devise ever-more creative ways of attack. Fortunately for Lokad, this mindset also happens to be highly desirable for supply chain purposes, as adverse behaviors - though not necessarily criminal - are commonplace in supply chain ^[c].

Safer by training

We actively train all of our staff to better understand cyber threats and how to mitigate them. Unlike design and culture, security training is largely a top-down process. Though bottom-up thinking has its place, this type of training is inherently weak against most computer security risks. Simply put, even if people are trained not to do something, Lokad cannot assume that nobody will ever do that thing ^[d]. Thus, we take a stricter approach. As part of our training, we discourage USB flash drives and other USB devices that could compromise machines. We ensure that two-factor authentication is used whenever possible. We train our staff to operate with as few privileges as possible on their workstations. We make sure everyone is aware of how social engineering works, which can be used to fool even the smartest people.

More generally, security training focuses on increasing awareness about how software and processes can be repurposed and corrupted by ill-intentioned actors. Given the scope of training, skill and know-how required to prevent such nuanced attacks, Lokad generally has very few interns, compared to most comparably sized companies in the space. In short, we prefer to bet on a stable, highly-trained team over the long term.

[a] In the video game industry, many if not most employees are truly passionate about video games; not just the ones that happened to be developed by the employer, but by the market as a whole. Many of these employees are not just “doing their job”; they are emotionally invested in the outcome of their work. In contrast, the default state of enterprise software employees is, candidly, immense boredom. Making people care for a piece of enterprise software is an uphill battle, but a necessary one.

[b] Forecasting technologies, a key ingredient of supply chain optimization solutions, are particularly prone to spectacular exaggerations, both in terms of forecasting accuracy and positive outcomes for the client companies. See Top 10 lies of forecasting vendors

[c] Epistemic corruption is a fascinating class of security problem. It degrades software not through code, but the spread of incorrect or harmful beliefs among the specialists who steer the development of the software. See Adversarial market research for enterprise software

[d] Even the most reliable people happen to be exhausted, sick, distressed on occasion. The old adage says that any (computer) system that relies on human reliability is unreliable.

Frequently Asked Questions (FAQ)

1. Practices

1.1 Do you have Security Assurance?

Yes. Security assurance is an umbrella term for a variety of practices such as security hardening, security testing and vulnerability management. Security hardening, at Lokad, is first and foremost approached through design. Through specific design choices, we eliminate entire classes of vulnerabilities which, in turn, eliminates the very need for hardening itself. For example, Lokad does not rely on a “programmatic” storage layer – such as a relational database - but on a simple key-value store. This eliminates all SQL injection vectors. Furthermore, security testing is approached through a diverse set of methods; some automated and some manual, such as third-party penetration tests. For vulnerability management, we have a bug bounty program, and an extensively automated release management process to ensure that fixes can be swiftly deployed.

1.2 Are your ISO 27001 (ISMS) and/or SOC 2 compliant?

No. We firmly believe that these certifications are distractions that make software companies less secure. These compliance processes emphasize a bureaucratic mindset that is the opposite of what is required to make software secure. For example, these certifications require paperwork to be produced and committees to be installed. Candidly, the idea that paperwork and committees deliver anything of substance for software security is deeply debatable and is not something Lokad accepts in the least.

In software circles, security is usually achieved by doing less, not more; by leveraging the efforts of software engineers who specialize in software security, not creating additional teams of non-specialists. By way of anecdotal evidence, consider some of the most severe cybersecurity catastrophes, such as Heartbleed or Log4Shell. These disasters likely would have been prevented if the thousands of “certified” software companies had chosen to prioritize proofreading the third-party code – often the root cause of problems - over pursuing arbitrary commercial seals of approval.

Overall, we believe these certifications are marketing gimmicks that lull companies into a false sense of security (both figuratively and literally).

1.3 Do you follow OWASP practices?

Yes. OWASP provides, through its guides, an extensive checklist against vulnerabilities commonly found in software. This is an extensive, high-quality compilation that Lokad engineers utilize to safeguard our software from any of OWASP’s identified problems. However, through its design choices, Lokad largely eliminates entire classes of common vulnerabilities highlighted by OWASP. For example:

Password management: By delegating authentication through SSO functionality (single sign-on, something recommended by Lokad), Lokad does not have to “manage” passwords any more, making all the password-related checklist moot.

Logging: The event sourcing design adopted by Lokad logs everything by necessity. If an action is not logged then, as far as the system is concerned, it never happened. This voids most of the logging checklist.

Database Security: The persistence layer of Lokad does not include a relational database, only two non-programmatic components; namely an event source and a key-value store. This design choice voids the database checklist entirely.

More generally, when possible, we prefer to avoid the error-prone engineering design patterns that create the need for such checklists in the first place.

1.4 Are you GDPR compliant?

Yes. However, supply chain optimization – as delivered by Lokad – does not require personal data. We consider personal data a liability rather than an asset. Thus, we strongly recommend to our clients not to transfer personal data to us. This recommendation is usually part of our contractual agreements. By not having personal data in custody, and therefore not processing personal data, we largely eliminate concerns and protocols related to protecting it, such as GDPR or similar regulations. Return to 3.7

1.5 Do all third-party services/solutions (which involve access to Personal Identifiable Information (PII)) in Lokad’s solution comply with Data Protection Officer (DPO) requirements?

Yes. However, as stated in Practices 1.4, supply chain optimization – as delivered by Lokad – does not require personal data. Thus, we strongly recommend to our clients not to transfer personal data to us.

It should be noted that Lokad’s solution has a very short list of third parties that have access to PII data. As of January 2023, this list is restricted to Microsoft Azure.

1.6 Do you follow security best practices?

Yes. This is to say, we make prudent choices, as there is no industry-wide agreement as to what constitutes “the best software security practices”. By its very nature, software security exists in a state of constant evolution, adapting to an environment filled with deft new threats and attack vectors. Thus, we do not categorically defer to third parties on what the best software security practices are. Instead, we define what is best for our clients. This allows us to absorb good practices where available, without rigidly following less advisable ones just because they are popular. All this amounts to software security practices that are current, enforceable, and effective.

1.7 Do you regularly conduct penetration tests?

Yes. We have both planned and unplanned penetration tests. The planned ones are typically funded by our large clients who can, as per the contractual agreement signed with them, hire specialized companies to conduct penetration tests of their key software vendors, which includes Lokad. There is usually some degree of coordination between Lokad’s engineering team and those security specialists. The unplanned tests are typically part of our open public bug bounty program, where freelance security specialists can attempt to find a weakness in our system that is open to a potential exploit.

1.8 Do you regularly conduct external audits?

No. That said, we are more than willing to undergo an external audit if the operation is funded by the client. Many of our large clients have provisions for such audits in our contractual agreements. As of January 2023, though, the penetration tests exercised by clients have not uncovered enough issues to justify such audits taking place.

1.9 Do you have a Business Continuity Plan?

Yes. The biggest contingency Lokad has addressed is the hypothetical cessation of the company itself. Lokad operates as a SaaS solution, however, some of our large clients have provisions in their contractual agreements to be able to request complete snapshots of our codebase. These snapshots are put in escrow with an agreed-upon third party so that, in the event of Lokad ceasing operations, the client would automatically gain access to the codebase in escrow and a permissive license to recreate their own instance of the Lokad service.

1.10 Do you have a Crisis Communication Plan?

Yes. For every client we have an identified point of contact within their organization. On our end, there are at least two employees at Lokad - a primary and a substitute (typically two of our supply chain scientists) - who oversee communicating any urgent message(s) to the client. In practice, the vast majority of the crises we face are not software security issues, but supply chain ones - emergencies Lokad identifies based on the data that are made available to us by the client. In the case of a security event, this channel is used to make sure that our clients are informed in a timely manner.

1.11 How do you ensure that the client’s IT systems are kept safe?

We strongly recommend that Lokad should not have access to our client’s IT systems; the client’s IT system should only push and pull data from Lokad. This approach is intended to mitigate the possibility of a security event at Lokad spreading to the client’s IT system. Furthermore, we also strongly recommend using an SSO (single sign-on) process, as it eliminates the hypothetical scenario where a password used to access Lokad is intercepted (somehow) and later used to compromise one of the client’s IT systems.

1.12 How do you secure your network?

Our design adopts a Zero Trust architecture, which is to say, only permitting the right people to access data at any given moment. Merely being present on our network does not provide automatic status or privileges (this point is expanded in Authentication 2.1). Thus, while we are mindful of network security, we ensure – as an initial step – that the attack surface associated with our networks is made as small as possible.

Lokad uses two notable networks. The first is Microsoft Azure, which is used to host our solution. The security of the Microsoft Azure network is entirely delegated to Microsoft. We do not use “advanced” networking capabilities - such as those offered by Microsoft Azure - beyond basic load balancers.

The second is the local network of our headquarters in Paris. The security of the local network is internally managed by Lokad’s engineering team. Our local network does not host any component or system that contributes to the production environment.

1.13 Do you guarantee that all components (including third-party ones) and tools (including open-source ones) integrated in the solution are legally valid for development and production use?

Yes. Lokad has, compared to most enterprise software vendors, very few dependencies. All our major dependencies are credible and widely used open-source projects (ex: .NET by Microsoft, React by Facebook). This makes our internal audit process on this specific point a straightforward affair.

1.14 How do you manage major changes in organization and processes in terms of security?

As Lokad adopted sensible security design choices and practices from the start, it is rare for a change of any magnitude (minor or major) to impact security (even hypothetically). In Lokad’s entire history, there are only 3 events that could be considered truly significant from a security perspective: the migration to Microsoft Azure in 2010; the introduction of delegated authentication in 2012 (for clients and employees alike); and, internally at Lokad, the migration from Google Authentication to Microsoft Azure AD in 2022.

For each one of these events, the migration had been prepared months in advance by Lokad’s software engineering team. Relevant training materials and training sessions were implemented prior to the scheduled change, to ensure the readiness of all Lokad employees. Finally, after each migration event we made sure the previous “path” was eliminated, as is standard Lokad practice.

As of January 2023, we do not have any upcoming major changes planned. If such a change were to be introduced, we would almost certainly proceed in a similar fashion.

1.15 How do you manage the end of a contract?

Our agreements detail the termination process at the end of a contract, as agreed with the client. The termination process ends with the final deletion of the client’s data. As this termination process represents a security risk in itself, this point is subject to discussion with each client, and therefore can vary slightly depending on the case. From a security perspective, an ill-intentioned actor could try to impersonate the client in order to trigger an early termination of the contract (and disrupt the client’s operations). To prevent this, Lokad and the client would jointly endeavor to adopt a process - contractually enforced - that is not trivially vulnerable to a social engineering attack. This process typically involves written confirmations and a mandatory delay.

1.16 What is Lokad’s license strategy, associated cost model, and annual maintenance cost model?

Lokad typically charges a flat monthly fee associated with the operating cost of the platform, plus a flat monthly fee associated with the service provided by the supply chain scientists dedicated to the client (i.e., the engineers provided by Lokad). The fine print is negotiated and detailed in the service contract between the client and Lokad. These two fees represent an “all-inclusive” package with Lokad. There are no extra maintenance fees, licensing fees, third-party integrators, third-party consultants, etc. The package comes with limits, in scope and scale, that are jointly negotiated as part of the contractual agreement for the service.

1.17 Can you provide Lokad’s terms and conditions for the license(s), service(s), support, maintenance, and trainings?

Yes, upon client request, we can provide a contractual template that represents a “baseline” agreement. However, situations vary substantially depending on the scale of the supply chain initiative, the applicable countries, and on the scope of the services expected by Lokad. Thus, if possible, we prefer to engage in an initial discussion with a prospective client, in order to clarify the specifics of the supply chain initiative being considered. This helps us to craft the most relevant contractual framework for the situation.

1.18 Do you provide training (onsite/e-training)?

Yes, Lokad provides both on-site and remote trainings. The fine print of these sessions is negotiated as part of the contract agreement. Further, Lokad has both extensive public technical documentation and a detailed series of public supply chain lectures. These lectures cover Lokad’s technology and supply chain perspective.

1.19 Does Lokad’s system meet with relevant legal/local standards (i.e., ISO)?

Yes, Lokad operates in line with relevant standards. However, Lokad delivers predictive optimisation of the supply chain, and as such Lokad does not directly control operations. Our influence is largely indirect, typically through the optimization of the allocation of resources. Thus, the ISO standards are not relevant here (i.e., not applicable to Lokad).

2. Authentication

2.1 Do you enforce authentication for all accesses?

Yes. Accessing client data and/or any substantial capability of the solution requires prior authentication. However, by necessity, some points of contact are not subject to authentication. For example, accessing the login webpage does not require prior authentication (as authenticating is the whole point of this login webpage). Return to 1.12

Overall, very few technical endpoints do not require authentication, and they are typically part of the instrumentation of the platform (ex: an endpoint only used to check that a machine is up). It should be noted that unauthenticated endpoints do not expose any kind of sensitive data, let alone actual client data.

2.2 Do you require that all remote accesses are secured? Do you enforce HTTPS for web connections?

Yes. Securing remote accesses means having the right authentication, the right authorization, and encryption of the transport channel itself – all of which we enforce. This provision covers both client users and Lokad employees alike. Even for the engineering team at Lokad, there is no “unsecured local access” to our production systems. We do not use any kind of network “locality” as a security bypass.

2.3 Do you offer SSO (single sign-on)? Do you support Active Directory (AD)?

Yes. We offer SSO (single sign-on) through the SAML protocol. Active Directory supports SAML and can be used to access Lokad.

2.4 Do you support two-factor authentication like EZToken, Google Authenticator or Microsoft Authenticator?

Yes. Two-factor is achieved through delegated authentication via SAML. Through SAML, Lokad does not manage either the first authentication factor or the second, as this process is delegated.

2.5 Do you support OAuth2 authentication protocol?

By default, Lokad supports the SAML authentication protocol. This protocol is supported by the major federated identity systems, like Microsoft Office 365 or Google Workspace. The challenge of supporting OAuth2 is that OAuth2 is not actually an “authentical protocol”, but a set of very extensive guidelines to engineer “authentication protocols” that can diverge in dozens of ways.

As a result, we observe that the various OAuth2 implementations that exist within the realm of enterprise software tend to be largely incompatible. Thus, if OAuth2 is an absolute requirement, per contractual agreement, we can support a specific flavour of OAuth2. However, this arrangement requires dedicated resources to ensure compatibility with the OAuth2 variant as operated by the client company.

2.6 Do you support LDAP integration?

Yes, through a middleware bridge layering SAML on top of LDAP. However, the majority of the federated identity system supporting LDAP also support SAML. Thus, we recommend using SAML directly.

2.7 Do you enforce two-factor authentication?

For Lokad employees, yes. For the client’s employees, we strongly recommend it but ultimately we cannot enforce it (as the authentication is usually delegated through SSO). This matter is in the hands of our client’s IT department, not ours.

2.8 Can you enforce minimal password complexity?

Yes, but to a limited extent. As far as software security is concerned, mandating minimal password complexity is now largely recognized as bad practice. End-users respond poorly (and predictably) to overly strict password complexity demands, causing the overall level of security to suffer. Furthermore, we view such password demands as “bloatware” that increase the complexity of a security-critical piece of software (password management), thus exposing it (and the overall solution) to undue risks. See https://www.sans.org/blog/nist-has-spoken-death-to-complexity-long-live-the-passphrase/

We strongly recommend using SSO instead of traditional passwords/strategies. Through SSO, there is no need to introduce any password dedicated to Lokad.

2.9 Can you enforce scheduled password rotations?

We could, but we do not. Much like minimal password complexity (see Authentication 2.8), scheduled password rotation is now largely recognized as bad software security practice. End-users respond poorly (and predictably) to scheduled password rotations. Security can even weaken as employees often make only minor alterations to passwords (in order to reduce the cognitive load associated with frequent rotations). As with minimal password complexity, we see password rotation as “bloatware” that increases the complexity of a security-critical piece of software (password management), thus exposing it (and the overall solution) to undue risks. See https://www.sans.org/blog/time-for-password-expiration-to-die/

2.10 Do you hash and salt passwords?

Yes. We use scrypt as our password-hashing function. As a general rule, we strongly recommend using SSO instead of using traditional passwords/strategies. Through SSO, there is no need to introduce any password dedicated to Lokad.

2.11 Does Lokad’s solution enable CAPTCHA after a set number of authentication failures?

Yes, though authentication delegation (via SSO). While CAPTCHAs are a valuable approach to mitigate a few attack vectors, they fall into the category of software components that are best left entirely outside the scope of a supply chain optimization solution such as Lokad’s. Furthermore, the added value of CAPTCHAs in the context of enterprise software is less clear than it is for B2C software, especially freeware.

2.12 Do you have a general security policy for passwords? Do you have a process to enforce it?

Yes. Our general security policy for passwords is “no passwords”. We strongly recommend SSO, which removes the need to introduce passwords dedicated to Lokad.

2.13 Do you centralize user management?

Yes. Lokad has its own centralized user management for the solution we operate. This subsystem was implemented by Lokad and also covers the accesses of Lokad employees – including our engineering teams.

2.14 Do you allow generic/shared user accounts?

No. Lokad enforces a 1-to-1 relationship between employees and users (as seen by the Lokad platform). We strongly discourage the use of any shared user accounts. In fact, one of the reasons we do not charge per user is to avoid giving our clients an incentive to share user accounts among their employees. However, there are a few cases where it is acceptable to have a user account that does not have a counterpart employee. This happens typically for the client-side “robot upload” service in charge of pushing data to Lokad. As part of our RBAC (Role-Based Access Control), we have a dedicated role (called “uploader”) that provides minimal rights for this single use case.

2.15 Do you offer secure VPN connections?

No. End-users’ connections are used through encrypted channels (typically TLS).

2.16 Do you allow users to login from multiple devices?

Yes, within limits. In general, the upper limit is 6 devices per user (we do not charge for allowing multiple devices). Each session is restricted to a single IP address. Lokad does, however, reserve the right to change this limit in order to counter some potential threats and/or abuse.

2.17 Does the solution have the ability to forcefully lock and/or log out a user (if seen as malicious)?

Yes. This feature requires “Owner” access rights within the Lokad account.

2.18 Does the system automatically log-off an inactive user after a specified amount of idle time?

Yes, though “idleness” is not the salient factor. Lokad automatically logs off users after a specified amount of time. Users cannot postpone the log-off by being “active”; once the specified amount of time is met, users must re-authenticate.

3. Authorization

3.1 Does the solution provide fine-grained access rights?

Yes. The Lokad solution includes a granular RBAC (Role-Based Access Control) subsystem. This allows the client to control which “Projects” and “Files” are accessible (and by whom) in the Lokad account. The RBAC has its own web user interface (dashboard). It is available to all users with “Owner” designation within the Lokad account. See our user roles and permissions documentation for more.

3.2 Does the solution allow the client to configure access in accordance with the principle of least privilege (PoLP)?

Yes. The Lokad solution includes a granular RBAC (Role-Based Access Control) subsystem that can be used to implement the PoLP. However, through Envision (the solution’s DSL), Lokad goes much further than most enterprise software as far as this principle is concerned.

Through Envision, Lokad has eliminated entire suites of system privileges that are simply irrelevant for supply chain optimization. What remains is streamlined though still vastly configurable. Similarly, the bespoke file system offered by Lokad also eliminates whole groups of unnecessary system privileges.

3.3 Do you enforce least privilege access rights?

Yes, although what constitutes the “least acceptable” privilege is ultimately decided by our clients. Lokad cannot unilaterally determine who benefits from an “Owner” designation on our client’s staff. However, we can provide guidance in this regard. In practice, for our “managed” clients - those who are supported by Lokad’s team of Supply Chain Scientists – we clarify (in writing) the desired organization and corresponding access rights.

3.4 Does the solution have the capacity to hide a particular entity in the system from designated users?

Yes. This is a form of PoLP implementation and is covered in answers 3.1, 3.2 and 3.3

3.5 Do you have a classification in place for data (sensitivity levels), and controls adjusted according to this classification?

Yes. As a built-in element, Lokad restricts, by default, all administrative data (such as the list of users with an account) to the “Owners” of the account. This designation is the highest and most privileged of the RBAC (Role-Based Access Control). All other data within the Lokad account can be segmented according to a user-defined sensitivity classification. This user-defined classification can be applied both to the original data (as uploaded by the client) and to the transformed data (the result of data transformations performed within Lokad’s platform).

For more information on access controls and designations, please see answers 3.1, 3.2 and 3.3.

3.6 Can the solution authorize or block users/roles/transactions in real time?

Yes, though “in real time” requires clarification in the context of a distributed computer system (like the Lokad solution). Updates to the RBAC (Role-Based Access Control) occur synchronously, meaning updates become active within a few seconds (typically less). There are no noticeable delays (such as a one-hour or one-day waiting period). Return to 4.3 Return to IT 2.11

As for interrupting transactions, this is not relevant as Lokad does not have a transactional database. That said, Lokad can interrupt long-running asynchronous operations (referred to at Lokad as “Project runs”). When an interruption is triggered, it immediately (synchronously) ensures that the processing will not affect the system, such as overwriting files. However, stopping the processing is asynchronous and typically takes effect within 20 seconds.

3.7 Does the solution restrict access to Personal Identifiable Information (PII) only to users with the right permission level?

Yes, though the solution is not intended to hold any PII data (beyond the authentication identifiers of the employees with access to the solution). This is the case for both Lokad and the client. Within the solution, only employees with “Owner” designations have access to the list of users. For supply chain optimization purposes, Lokad does not need (or benefit) from PII data, and we have contractual stipulations to this effect (explained in Practices 1.4 & Practices 1.5).

For more information on access controls and designations, please see answers 3.1, 3.2 and 3.3.

3.8 Does the solution allow Personal Identifiable Information (PII) data search filters to disallow wild card searches?

Yes. However, a user with “Owner” designation within a Lokad account can access all users (including client staff) who are authorized to access the account. Lokad cannot restrict this capability as our clients must be able to audit, in full, the list of users with access to their own account.

4. Data Management

4.1 Where do you host and process the data?

Our SaaS (Software as a Service) platform is 100% hosted on Microsoft Azure; more precisely, it is hosted in the Europe North Microsoft Azure data center (based in Dublin). Our backups are stored in the Europe West Microsoft Azure data center (based in Amsterdam). In the event of a major data center failure, we have contingency plans to migrate the platform to Dublin. Since our migration to Microsoft Azure in 2010, we have never faced this situation. All our customers' data reside in Europe, where it will remain even in the event of a major data center failure.

4.2 Who owns the data?

Our clients remain the sole owners of all the data that they upload to Lokad. Our clients also remain the sole owners of all the data that they generate, through their Lokad account, on the Lokad platform. Lokad does not internally use clients’ data for any purpose(s) besides the one(s) that directly contribute to the task(s) that our clients have retained us to perform. Lokad does not (re)sell access to our clients’ data to any third party. Lokad does not share access to client data, except for the few hosting providers that directly contribute to the task at hand (ex: renting virtual machines from a cloud computing platform to run the computations as requested by our clients).

4.3 Is the database management handled internally or externally?

The data layer management of Lokad is performed by Lokad’s engineering teams. As mentioned before, the core platform of Lokad does not include a transactional database (see Authorization 3.6), as Lokad uses an event store instead. This event store is implemented and operated entirely by Lokad.

4.4 Does the solution have the ability to switch between RDBMS database (PostgreSQL, Oracle, MySQL) and Non-SQL database (Cosmos)?

Theoretically, yes, but this is moot as the Lokad solution does not use RDMBS. The data persistence layer of the Lokad solution leverages an event store and a key-value store. This approach differs substantially from the CRUD (Create-Read-Update-Delete) design commonly found in enterprise software. Given Lokad is a SaaS solution, we take full responsibility for data persistence and forward compatibility (to ensure that older data remain accessible).

4.5 Are there third parties involved in running the solution?

Yes, most notably the underlying cloud computing platform that Lokad uses – Microsoft Azure. The list of third parties involved in running the solution is very short and restricted to lower-level infrastructure hosting. Lokad does not use third parties to develop, administrate or operate its own solution. In particular, both our engineering teams and our technical support teams are internal.

4.6 Do you separate layers (networking, servers, and applications)?

Yes, however low-level management of networks and servers is delegated to the underlying cloud computing platform that Lokad uses – Microsoft Azure. Thus, the separation of the network and server layers is mostly outside the perimeter managed by Lokad. Within the Lokad solution, we strongly restrict privileges given to the applicative layers so that they cannot administrate their own infrastructure (ex: the applicative layers do not have any write-access to the management of DNS).

4.7 Do you have a process to ensure the permanent deletion of data?

Yes, although it can take several weeks to complete all the steps. The process involves making a formal written request - issued by an authorized party within the client organization - to have the corresponding data permanently deleted. In practice, specific provisions for such requests are included in the contractual agreement between Lokad and its clients. The data will first be deleted from our primary production system and then from our backup system. The latter stage is the cause of the relative “slowness” of the operation. This is a design choice, as once the data are deleted from our primary system, they cannot be accessed again (except via extraordinary disaster recovery processes).

By default, the Lokad solution ensures that all standard delete operations are soft deletes (i.e., not permanent deletes). This design is necessary to avoid entire classes of security issues such as accidental data deletion by a client employee, or malicious deletion by an attacker. Also, an intentionally slow permanent deletion process is needed to mitigate social engineering attacks, such as a scenario in which an attacker impersonates an employee of a client.

4.8 Does the solution have the capacity to soft delete data?

Yes. The Lokad solution adopts an event sourcing design. As such, everything is versioned by default, both the user entries and the changes brought to the file system of Lokad. Thus, all software deletes are soft deletes, and these can be traced and undone, as desired.

4.9 Do you offer direct database access?

Yes, in the sense that the file system – part of the Lokad solution – can be accessed through protocols such as FTPS and SFTP. This access is extensive, in that all data either used as inputs or produced as outputs are stored within this file system.

However, as Lokad does not have a transactional database, there is no underlying database that could be made “accessible”. The closest equivalent in the Lokad architecture is our event store and we do not offer direct access to the event stream. However, provisions could be made in the contractual agreement if a client were to request some specific extractions from this event stream (assuming there is a valid use case).

4.10. How does the solution integrate external data?

The solution can utilize several protocols to integrate external data, most notably FTPS and SFTP. A web user interface is also available to manually upload files. The Lokad solution can integrate any reasonably tabular data. For more on Lokad’s data external integration capabilities, see Go to IT Perspective on Lokad 2.15.

4.11 Does the system have the capacity to handle change data capture (CDC) from real-time data feeds?

Yes, under the provision of a specific contractual agreement with the client. Change data capture is a software design pattern - not a specific data standard or data transfer protocol - and “real-time” expectations can vary from sub-millisecond latencies to sub-minute ones. Features in this area need to be assessed from a supply chain perspective. In our experience, real-time data feeds are rarely relevant for addressing supply chain problems.

4.12 Can all the data within the solution be exported?

Yes, all the data accessible through the file system within the Lokad account can be exported through protocols like FTPS or SFTP.

4.13 Does the solution offer tools to export data?

Yes, the Lokad solution offers a DSL (domain-specific language) named Envision, tailored for supply chain analytics. Envision offers extensive capabilities to reformat the data within the Lokad account.

4.14 What will be the format of the exported data?

The Lokad platform supports all common tabular formats, including CSV and XLS (Microsoft Excel). The platform supports numerous options concerning the format of numbers, dates, delimiters, text encoding, headers, etc.

4.15 Does the solution have Transparent Data Encryption (TDE) of Personally Identifiable Information (PII) data in mobile and back-end storage?

Transparent data encryption is used both on Lokad's back-end storage (through Azure Storage encryption for data at rest) and on Lokad-issued devices (through BitLocker). Lokad does not store PII on devices without TDE enabled.

4.16 Are all the passwords and secrets used within the application encrypted and not accessible in free text format in the source code, configuration files, build parameters, etc.?

Yes. All the platform-level secrets are stored in Key Vault, a service offered by Microsoft Azure. The user passwords are internally salted and hashed with Scrypt as per standard practices.

4.17 Does the solution have the capacity to restrict file uploads based on file type and sizes, and scan for malicious content?

Yes, to a limited extent. Concerning file size, supply chain optimization frequently requires large files to be processed. These file sizes reflect the extraction of the historical business data that we ultimately process (ex: historical sales orders). Given this reality, the Lokad platform supports file sizes up to 100GB.

Concerning file type, we have a whitelist of known extensions and expected formats. In the event of a valid use case, this parameter could be adjusted. This adjustment would be reflected in our contractual agreement.

Concerning the capacity to scan for malicious content, Lokad does not have this feature. Our solution emphasizes sharing platform-generated content. Furthermore, the very design that we have adopted ensures that the files generated within Lokad are safe, even if the input files are not. Conversely, through its design, the Lokad solution de-emphasizes the sharing of user-uploaded content via Lokad.

4.18 What is the recommended data retention period?

Lokad is SaaS, thus, we bear the responsibility of choosing the appropriate data retention period, and this duration varies depending on the type of data. Transactional historical data, transmitted to Lokad by the client through the data extraction pipeline, is typically preserved for the duration of the Lokad service. Indeed, historical data is usually worth retaining for arbitrarily long periods (outside the boundaries of the Lokad service). At the other end of the spectrum, there is the instrumentation data, reflecting the fine-grained performance of our platform. This data is only useful for troubleshooting unexpected slowdowns within the platform. This data is extremely granular and is usually not kept for more than a few weeks.

4.19 Do you provide documentation of the data structure?

Yes, as part of the “Joint Procedure Manual”. It should be noted that Lokad does not utilize a relational database, unlike most enterprise software. Instead, we use an event sourcing paradigm. However, the data structures of interest (for the client company) are not located in the event source, but in the flat files produced through Envision scripts within Lokad’s platform. These flat files are engineered to match the specific requirements of the client company. The documentation for these files is included in the “Joint Procedure Manual” – which is one of the deliverables in a typical Lokad initiative.

5. Logging and monitoring

5.1 Do you offer access logs (user, date, last connection date, etc.)?

Yes. Lokad provides access logs formatted as CSV files. At this point in time, these logs can be requested from the Lokad support staff. The log extraction will be placed in the Lokad account in a place accessible only to users with “Owner” designation(s). We plan to introduce a more direct access method - through a dedicated web interface - to the complete audit trail that already exists in the backend of the Lokad platform.

5.2 Do you centralize the logs of all the components in the solution?

Yes. The event sourcing design of Lokad centralizes not just the logs, but all the state changes that happen in the solution. The logs, along with other state changes, are centralized with a small collection of event streams, managed by the same event store. Internally, the logs that do not impact the state of the solution are segregated from those that do.

From a purely technical perspective, there are some performance-related logs that are intentionally not centralized within the event store. These logs include fine-grained performance measurements, such as those produced by Lokad’s internal performance profiling instrumentation (ex: how many milliseconds are spent for every function call during the execution of an Envision script). These performance logs do not contain anything that qualifies as “security-related” materials.

5.3 Do you log changes and operations performed in the application? Do you keep track of all the transactions?

Yes. Due to the event sourcing design of Lokad, everything is logged by necessity. In fact, the solution itself is the sum of the collection of events recorded within the solution. Thus, logging is a fundamental aspect of the solution’s architecture. This event sourcing design prevents the accidental omission of a log that reflects a change of state. Under such an event sourcing framework, there are no transactions, at least not in the usual sense of a transactional database (ex: MySQL, Oracle, etc.). These transactions are replaced by events that contain all the information associated with a change of state. Return to 8.11

5.4 Do you normalize the log formats of the various components for forensic purposes?

Yes. The “logs”, from an audit and/or security viewpoint, are the transformations of the underlying events. The events are technically serialized objects. In order to obtain logs, the Lokad solution converts and compiles these events into CSV files. We normalize date formats, number formats, and user identifiers that are used in the CSV extraction.

5.5 Do you offer log exports to a third party via some query protocol?

Yes, under the provision of a contractual agreement with the client.

5.6 Do you track all exceptions thrown in your solution?

Yes. Lokad’s event sourcing design allows us to track all the exceptions thrown in our solution and reproduce the conditions that led to the issue in the first place. Once identified, Lokad’s engineering team eliminates all the observed exceptions. We have engineered dedicated tooling for this specific purpose, and we keep a very limited backlog of unfixed exceptions.

5.7 Does the solution have the capacity to monitor the health of the different components/services in real time?

Yes. Our subsystems have been engineered with monitoring endpoints dedicated to health checks. We have monitoring tools, accessible only – as of January 2023 – to the engineering teams at Lokad that continuously consolidate the information made available by those monitoring endpoints.

As previously mentioned, “in real time” is quite vague when it comes to distributed systems. For system health monitoring purposes, the expected latency ranges from a few seconds to a minute (approximately).

5.8 Does the solution have the capacity to integrate third-party monitoring tools? Does the solution support SNMP or JMX, or the ability to send SNMP and JMX events to third-party monitoring solutions?

Yes, under the provision of a dedicated contractual agreement.

5.9 Does the solution have the capability to monitor batch jobs that did not start on schedule and monitor their termination?

Yes. The Lokad solution has its own internal job scheduler (called “Runflow”) to orchestrate long-running tasks within the Lokad platform - typically the execution of Envision scripts. This scheduler can be configured, through a web user interface, to specify a schedule and an execution time frame for any job sequence.

5.10 Does the solution have the capacity to produce proactive alerts? Does it have the ability to correlate and analyze errors, and then take proactive actions?

Yes. Runflow, the solution’s job scheduler, can alert the client/Lokad that an ongoing execution sequence is running late. The alert can be sent prior to completion of the sequence. The Lokad solution offers extensive capabilities through Envision (its DSL) to analyze and self-diagnose situations in order to take proactive action. While the Lokad platform provides this capability, it still requires an engineer to implement – through Envision – the actual logic, as the supply chain situations that qualify as “errors” can vary.

5.11 Does the solution have audit data retention capabilities? Are the data archived and purged into an MIS database for auditing user activity?

Yes. Through its event sourcing design, the Lokad solution preserves an extensive audit trail; much greater than what is obtained through more mainstream designs that typically leverage a transactional database instead of an event store. The Lokad solution does not isolate a Management Information System (MIS) as a separate subsystem. In effect, the event stream is the audit trail. More generally, Lokad retains the production data for the duration of the service with the client. Upon service termination, which depends on the negotiated contractual terms, the client data is purged, although the final deletion within the backup system might happen a few months after the end of the contract.

5.12 Does your system integrate a self-monitoring mechanism (technical and functional)?

Yes, the Lokad platform integrates multiple self-monitoring mechanisms on various levels.

The cloud-hosted platform is monitored by Lokad’s software engineering teams. As the Lokad platform is multi-tenant, this monitoring is largely performed with a “system” mindset, ensuring that the capabilities of the platform (including its performance profile) are to standard. We have engineered our own instrumentation layer for this purpose. The “functional” monitoring is typically client-specific as it depends on the specifics of the given supply chain. This monitoring is typically provided by the teams of supply chain scientists (the engineers provided by Lokad), as per contractual agreement.

Lokad’s supply chain scientists typically specialize in a particular class of client account (e.g., aerospace). They craft bespoke monitoring instrumentation using the Lokad account. This monitoring includes making sure that the numbers delivered by Lokad are correct, not just in a technical sense, but from the client’s business perspective, as well.

6. Employees

6.1 Do employees have NDAs (Non-Disclosure Agreements)?

Yes, all Lokad employees are subject to an NDA provision in their employment contracts.

6.2 Do employees undergo security awareness and security training?

Yes, security awareness and security training are provided to Lokad employees who are in contact with confidential data and/or engineering systems that are in contact with confidential data. For more information on this point, the lecture Cybersecurity for Supply Chain is dedicated to supply chain scientists – the people who handle confidential client data.

6.3 Who has access to the client data at Lokad?

The client explicitly defines a list of users who have access to its Lokad account. These users, depending on their access rights as configured within the Lokad account, may have access to various classes of the client’s data. There is a web application within the Lokad solution dedicated to managing permissions (named “Hub”).

On Lokad’s end, for each client account there is a brief list of employees who have access. First and foremost, this list includes the supply chain scientists (the engineers provided by Lokad) who implement and maintain the supply chain optimization solution. These supply chain scientists are expected to access the client’s data on a daily basis. Internally, Lokad restricts client account access to only the supply chain scientists assigned to those accounts. I.e., Supply Chain Scientist A cannot access Client Account B unless A has been explicitly assigned to manage this account (as arranged with the client).

Second, this list includes the engineering team in charge of the system administration of our platform. As a rule of thumb, direct access to client data is infrequent and limited to investigating situations reported either by the clients themselves or by their supporting supply chain scientists. Lokad does not share access to the client data with any third-party, with the exception of the cloud computing platform.

6.4 How do you secure the employee workstations?

Except for the software engineering team, Lokad employees operate without administrative privileges on their company-provided devices. All workstations are configured with full-disk encryption to protect against data theft that could be caused by the hardware being lost, stolen, or trusted to third parties (e.g., for repairs).

The workstations used by our employees do not contain our clients' data. Depending on the task at hand, an employee can download a few Excel sheets to their machine – to make a presentation, for example – but our policy is to strictly keep all client data secure in the cloud.

6.5 How do you secure employee smartphones?

Lokad employees do not have company-issued smartphones. Non-critical data, like calendar reminders, can be pushed through personal (non-company issued) devices, but smartphones, like workstations, do not contain our clients’ data.

6.6 Do you use an antivirus?

Yes, our workstations have Microsoft Defender, as per Microsoft Windows 10+ setups. We do not have another antivirus beside Microsoft Defender, but our attitude is that this class of tool tends to do more harm than good (in terms of computing security). By way of anecdotal evidence, the 2020 SolarWinds hack is considered one of the biggest computer security catastrophes of all time, and it was caused by a piece of software that was supposed to improve security in the first place. More generally, nearly all software products intended for security purposes require rather high system privileges. As a result, these software products become their own attack vectors. Our perspective on computer security is that less is more, and that adding very complex pieces of technology into our applicative landscape almost invariably makes it less secure, not safer.