FAQ: Software Security

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: September 21st, 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¹.

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 ². 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 ³.

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 ⁴. 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.

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.

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.

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).

1.20 Is there malware protection built at the networking level, for example on firewalls, proxy devices and/or on the network as separate solutions?

See Practices 1.12

1.21 Does the software development process include integrated threat assessment?

Yes. This is the primary reason why we favor addressing security concerns “by design”. By eliminating entire classes of threats at the design-stage, we keep the overall threat assessment practice more manageable. The threat assessment also covers “supply chain attacks”. This is another reason we put such strong emphasis on minimizing the amount of third-party dependencies in our software stack, as any dependency inherently increases the attack surface area.

1.22 Is the incident management process rehearsed at least annually?

Yes. There are many different types of incidents. One of the most frequent is that the client company itself is breached. In the event of ransomware, this does sometimes lead to the Lokad-data accidentally becoming the sole dataset still accessible. In cases of identity theft, this sometimes leads to attempts to access the Lokad account through stolen credentials. The fine-print of the various incident management processes is jointly established with the client company, and typically supervised by the supply chain scientist at Lokad in charge of the account (for clients who opt for a managed account).

1.23 Is the risk- and threat-mapping reviewed at least annually?

Yes, although these reviews are typically performed regularly throughout the year. Such reviews are commonly driven by significant events, such as notable security breaches in the software industry.

1.24 Is the risk assessment also performed on supportive functions that might impact the solution’s availability, quality, and/or security?

Yes. However, the Lokad platform is essentially a monolith that does not rely on any “supportive functions” beside a few core fundamentals, such as the Blob Storage and Linux VMs as provided by Microsoft Azure.

1.25 Are dedicated system accounts - with only the required access rights - created for running system processes?

Yes, dedicated system accounts with appropriate access rights are used for running system processes. Lokad uses daemons in the form of systemd services, which always run as users with as few privileges as possible.

While Lokad does not employ an SQL database, the platform utilizes a role-based system to dictate access rights for scheduled and triggered processes. These processes are categorized as “userland” rather than “system” processes.

1.26 Is there a formalized risk governance plan approved by management that defines the Enterprise Risk Management program requirements?

Yes, we have a formalized risk governance plan in place that has been approved by senior management.

This plan outlines the requirements and guidelines for our Enterprise Risk Management (ERM) program. It is designed to identify, assess, manage, and monitor risks across the enterprise in a structured and consistent manner.

Our risk governance plan is periodically reviewed and updated to ensure it remains relevant and aligned with our organizational objectives and the evolving risk landscape. Additionally, the implementation and effectiveness of the ERM program are regularly reported to senior management and relevant stakeholders to ensure continuous oversight and support.

1.27 Is there a physical security program approved by management, communicated to constituents, and has an owner been assigned to maintain and review it?

Yes, we have a comprehensive physical security program in place that has been approved by senior management. This program has been thoroughly communicated to all relevant constituents to ensure awareness and adherence.

Additionally, we have designated an owner who is responsible for maintaining, updating, and periodically reviewing the program to ensure its effectiveness and relevance. This owner collaborates with various teams and departments to address any emerging physical security concerns and ensures that the program aligns with best practices and our organizational objectives.

1.28 Are assessments of the physical and environmental hazards conducted prior to establishing the location or site of a facility where systems reside?

Yes, assessments of physical and environmental hazards are an integral part of our decision-making process when determining the location or site of a facility for our systems. Given that our systems reside in Microsoft Azure data centers, we benefit from Microsoft’s rigorous site selection and assessment process. Microsoft Azure conducts extensive evaluations of potential risks, including physical and environmental hazards, before establishing any of their data centers. Their selection process involves analyzing factors such as natural disaster potential, accessibility, infrastructure stability, and more.

By leveraging Azure’s data centers, we are confident that these assessments have been comprehensively undertaken to ensure the highest levels of physical security and environmental resilience for our systems.

1.29 Is there a documented internal compliance and ethics program?

Yes, although we do not believe that “ethics” can be enforced in a top-down manner. This sort of approach invariably produces undesirable outcomes that run contrary to the original goals.

Famously, Enron had a written code of ethics. This code emphasized respect, integrity, communication, and excellence. The Enron scandal, which came to light in 2001, revealed that the company had been involved in massive accounting fraud, which was - obviously - at odds with the principles laid out in their code of ethics. There was, therefore, a complete disconnect between Enron’s professed, written ethics and the actual business practices and corporate culture.

Thus, Lokad focuses on making sure that employees get a chance to genuinely care about our clients. “Are we doing the right things?” is one of our mantras. Compliance and ethics are, in our estimation, the by-products of an adequate corporate culture, not the outcome of any program in particular.

1.30 Is there an internal audit, risk management, or compliance department, or similar management oversight function, with responsibility for tracking resolution of outstanding regulatory or compliance issues?

Yes. Though Lokad is not large enough to have a standalone department dedicated to conducting internal audits, risk management, or compliance, we certainly prioritize these areas. We have designated individuals with expertise in these domains who are specifically tasked with handling and overseeing these critical responsibilities.

These individuals directly report to Lokad’s top layer of management, ensuring that the resolution of any outstanding regulatory or compliance issues is treated with utmost priority and receives the necessary oversight at the highest level of our organization.

1.31 Is there a wireless policy or program that has been approved by management, communicated to appropriate constituents, and an owner designated to maintain and review it?

Yes, Lokad has a well-defined wireless policy that has been approved by management and communicated to all relevant constituents to ensure adherence. This policy distinguishes between two independent and isolated Wi-Fi networks: one dedicated for employees and another specifically for guests. The distinction ensures that our primary operations remain secure, even as we provide connectivity for guests or visitors.

However, it is important to note that our primary mode of connection is through Ethernet, prioritized due to its superior performance and enhanced security. The Wi-Fi networks are primarily in place to accommodate meetings and offer flexibility in certain scenarios.

Furthermore, we have designated an owner for the policy who is responsible for its maintenance and periodic review, ensuring it remains up-to-date and effective in addressing evolving needs and challenges.

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).

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).

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.

2.19 Is the use of shared accounts and/or access credentials banned, and compliance of these policies monitored?

Yes. See Authentication 2.14.

2.20 Are user IDs and passwords communicated/distributed via separate media (e.g., e-mail and phone)?

Yes, we prioritize the security of user credentials and ensure they are communicated in a manner that aligns with best practices. Internally, our systems leverage Azure Active Directory for user authentication. When user IDs and initial passwords are distributed, Azure Active Directory follows its default patterns which are designed with security in mind. Moreover, we enforce two-factor authentication for our Azure AD, adding an additional layer of security to the authentication process.

Externally, for client-employees connecting to our systems, we strongly recommend the use of Single Sign-On (SSO) and federated identity systems. These systems, by design, support best practices in credential management, ensuring that credentials are communicated in secure ways, often involving separate communication channels or methods for user IDs and authentication mechanisms.

It is worth noting that we do not recommend single-factor authentication, be it for internal or external users, if one’s goal is to maintain a high standard of security.

2.21 Are inactive constituent user IDs disabled and deleted after defined periods of inactivity?

Yes, we actively manage and monitor user IDs to ensure security. For Lokad employees, our policy mandates that all access rights are revoked on their last day of employment, ensuring there is no post-employment access for former employees.

For our clients, we advocate the use of Single Sign-On (SSO) and federated identity systems. This approach streamlines access management. For example, when a client removes an employee from their identity system, access to Lokad is simultaneously terminated. This method not only enhances security but also ensures efficiency in user management.

Note: the specifics regarding the termination of user access are detailed in our contractual agreements with each client. Lokad firmly recognizes the potential operational impact of prematurely deactivating an account and takes active steps to avoid such scenarios. To avoid inadvertent disruptions, the terms of user access termination are explicitly outlined, either in the contract or in a jointly agreed-upon procedure, ensuring Lokad’s security measures align with our client’s operational needs.

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).

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.

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.

3.9 Is the system equipped with WAF (Web Application Firewall) technology?

No. WAF is an inherently dangerous design as it violates the “least privilege” security principle: a component gets granted huge privileges in order to operate as a “man in the middle”. This makes the WAF itself a prime target for attackers, and it vastly extends the attack surface of the platform. However, Lokad does closely monitor its web traffic, and abnormal user behaviors on our own platform. These capabilities, though, are part of the platform itself and thus are not delegated to privileged isolated third-party software components.

3.10 Is the network equipped with IPS (Intrusion Prevention System) technology?

No. IPS is an inherently dangerous design as it violates the “least privilege” security principle: a component gets granted huge privileges in order to operate as a “man in the middle”. This makes the IPS itself a prime target for attackers, and it vastly extends the attack surface of the platform. In order to harden the Lokad platform against intrusion, our design starts by minimizing the attack surface area. We believe that it’s much more secure to eliminate pathways for intrusion by design, rather than trying to “prevent” them as an afterthought.

3.11 Does the service utilize DoS (Denial-of-Service) protection technology?

Yes. Lokad leverages ReCaptcha, nginx rate limits, and our own specific components (such as early-fail when authentication is invalid).

3.12 Is all administrative access to the production environment performed through jump hosts or bastion servers?

Yes. We have a system that is essentially similar to ‘Teleport’. This offers not only complete traceability of all the accesses, but also facilitates the secure revocation of access rights from employees.

3.13 Is there a clear authorization process for granting administrative access (and one which produces a reliable audit trail)?

Yes. See Logging and Monitoring 5.1 and 5.11.

3.14 Is there a systematic and regular access-right review process (performed by an authorized person), where administrative access rights are checked against any/all changed roles and duties?

Yes. There are two levels of administrative access rights.

First level: the administrative rights to support the infrastructure of Lokad. These rights are granted and monitored by the IT division of Lokad.

Second level: the administrative access rights within each Lokad account. These rights are granted and monitored by the Supply Chain Scientist in charge of the account – for our managed accounts. Alternatively, these rights are granted and monitored by the client company itself if the account is not managed directly by Lokad/a Supply Chain Scientist.

3.15 Does your access-restriction policy follow the principle of “least privilege”, where only necessary and approved traffic is allowed?

Yes. We apply the principle of least privilege (PoLP) to all access levels of our infrastructure, including networking traffic. The severity of access restrictions vary by use case. For example, for some accesses, only a specific, authenticated user from a specific IP address is allowed. In other scenarios, anybody anywhere can access, as is the case for the content of our CDN (Content Delivery Network).

3.16 Are outbound connections from the production environment restricted?

No, outbound connections from the production environment are not universally restricted. While some specialized servers, such as load balancers, have outbound restrictions, the majority of our servers do not.

Our production VMs require access to multiple external APIs. A large portion of these APIs are hosted by Microsoft Azure, with some exceptions like letsencrypt.org. We’ve determined that maintaining a rigorous whitelist of IP addresses would introduce complexities that might offset the benefits. Restricting outbound connections might offer limited security advantages, but could also introduce complications that potentially undermine our production environment’s security.

3.17 Is there a staffed form of communications (e.g., e-mail, web form, phone, etc.) available to customers/clients 24/7/365 to report security incidents?

Yes, we have implemented the security.txt standard to facilitate the reporting of security incidents.

The security.txt approach is a widely recognized pattern in web security where a specific text file is placed on the website. This text file details how to report security vulnerabilities.

Our security.txt file can be found at https://www.lokad.com/.well-known/security.txt and it outlines the up-to-date process for reporting security incidents. This ensures that anyone, be it a customer, client, or security researcher, can easily find the relevant contact details and guidelines on how to report security concerns to us.

Please note that while the process detailed in the ‘security.txt’ may be revised, the most current and accurate information will always be available at that endpoint. We ensure that the channels of communication mentioned in the file, whether they be e-mail, web form, or another medium, are staffed and available 24/7/365 to promptly address security reports.

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.

4.20 Is the segmentation of data from other customers part of the system design?

Yes, while Lokad is a multi-tenant app, data is separated at the design level between tenants, i.e., client accounts. This partitioning is a first-class citizen of our back-end design. This design prevents programming mistakes that would expose the data of one tenant to another tenant, while further developing mundane features within the platform. The primary underlying storage used by Lokad – Blob Storage by Microsoft Azure – facilitates this sort of strict partitioning at the design level.

4.21 Are effective measures taken to ensure that no customer data is used in development and testing environments?

Yes, by default, the software engineering team does not have direct access to customer data. We have developed extensive ‘mock’ data environments and ‘mock’ datasets to let the software engineering team operate smoothly without access to customer data. Lokad also internally uses its own platform for data crunching purposes (e.g., analyzing the fine-grained consumption of cloud computing resources obtained from Microsoft Azure). This ‘dogfooding’ practice ensures that Lokad also has an abundant supply of non-critical data to use for development and testing purposes.

However, we have engineered a special restricted pipeline to access minimal (read-only) fragments of customer data for diagnostic purposes. This pipeline automatically ensures a strict and fully automated minimization of the data being retrieved. This pipeline also automatically ensures the deletion of the data at the end of the diagnostic operation. See 4.22 for more details about this restricted pipeline.

4.22 If case development or testing requires limited usage of customer data, is there a defined process for ensuring secure and complete destruction of the data in development and testing environments?

Yes, we have engineered a special (read-only) data pipeline dedicated to the exceptional use of customer data for diagnostic purposes - usually performance testing. This data pipeline is only accessible to a restricted portion of the software engineering team.

This data pipeline has been engineered to automatically minimize the fragment of the customer data being retrieved for the diagnostic of interest. This capability lets us operate with what typically amounts to a very small fraction of the original data (as found in the client account). Furthermore, it removes the need for the engineering team to manually check-pick what data to retrieve.

Finally, this data pipeline automatically deletes the retrieved data at the end of the diagnostic operation.

4.23 Are all physical locations of the customer data known and documented, including backup and high-availability systems?

Yes. All customer data is stored in the physically secured data centers of Microsoft Azure, including backups. We do not keep customer data locally (i.e., on Lokad’s premises), nor is customer data kept on employees’ devices.

4.24 Is access to physical server locations limited to employees who require it to perform their work?

Yes, though the data of Lokad’s customers is stored in the secure data centres of Microsoft Azure - a location Lokad has no physical access to. The physical location of Microsoft’s data centers are public knowledge, and Lokad’s choice of data centers is publicly documented.

4.25 Is the Primary Account Number (PAN) only stored if it is absolutely necessary for legitimate business purposes?

Lokad does not receive, store, or manage any client PANs.

The PAN (Primary Account Number) usually refers to the primary number on a credit card or a debit card. It is the sequence of numbers embossed or printed on the face of a card and used to uniquely identify the bank account tied to the card.

To process payments, we rely exclusively on third parties who manage PANs for us. However, it must be noted that the majority of the transactions received by Lokad are executed through wire transfer, eliminating entirely the problem of the management of PANs.

We do have a few PANs – for Lokad’s own cards – that we manage securely, following the guidance provided by the banks themselves.

4.26 Are unencrypted Primary Account Numbers (PANs) never sent by end-user messaging technologies (for example: by email, instant messaging and chat)?

Yes, unencrypted PANs (Primary Account Numbers) are never sent through insecure channels such as email. Lokad provides a built-in secure communication channel on its platform, which is a superior alternative for transmitting sensitive materials. We recommend this channel whenever the use of an insecure channel poses a significant business risk.

Note: By design, Lokad does not receive, store, or manage any client PANs. Hence, there are no unencrypted PAN transfers.

4.27 Do you have a contract in place with your cloud computing services provider(s) and does this contract contain clauses relating to the information security arrangements of the cloud computing services provider(s)?

Yes, Lokad has an Enterprise Agreement (EA) in place with Microsoft for Azure cloud computing services. The Enterprise Agreement typically includes various terms and conditions related to the use of the services, including commitments about the security of the cloud environment.

Microsoft Azure, as one of the leading cloud service providers, places a high emphasis on security. Azure has a comprehensive set of security features and practices in place to safeguard data in the cloud, and these are often reflected in their contractual agreements with enterprise customers.

While we cannot disclose the specific details of our contractual agreement publicly, after more than a decade of collaboration with Microsoft, we are satisfied that this agreement meets our security requirements and standards.

4.28 Are any sub-contractors involved in the processing of the client’s details/data?

No, Lokad does not subcontract the processing of client details or data. Regarding Lokad’s platform, we do buy computing resources - mostly virtual machines and blob storage – from Microsoft Azure, but other than that no third parties are involved when it comes to client data.

As for the provision of Lokad’s professional services, only full-time Lokad employees (in this case, the supply chain scientists) ever gain access to client details or data. Lokad occasionally has a few interns (although much fewer than most comparable companies) for long-term internships, but they operate under the direct and strict supervision of senior supply chain scientist.

Note: Interns are subject to the same confidentiality agreements as full-time supply chain scientists.

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.

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.

5.13 Are logs reviewed and analyzed in a timely manner and systematically, in order to detect anomalies and indications of breach?

Yes. Reviewing the ongoing activity of the Lokad platform is part of our daily routine. The design of our platform facilitates this process.

5.14 Are log management systems administered by people who are not involved with administrating the other systems (i.e., segregation of duties)?

Yes. The supervision of the logs and general activity of the platform is performed by Supply Chain Scientists, while the general administration of our infrastructure is performed by specific employees within our IT division.

5.15 Are application-level vulnerability scans performed periodically and systematically?

Yes, although such scans are a very small part of our security processes. See Employees 6.6.

5.16 Is there a defined process for the periodic review of effective firewall rules?

Yes, our production machine comes with very tight rules, such as opening a very limited number of ports (configured through Microsoft Azure). The configuration of our infrastructure is scripted, and its evolution follows our usual code review process. This practice not only facilitates periodic reviews, but also mitigates the need to manually review the rules in the first place.

5.17 Is the network equipped with IDS (Intrusion Detection System) technology?

No. IDS is an inherently dangerous design as it violates the “least privilege” security principle: a component gets granted huge privileges in order to operate as a “man in the middle”. This makes the IDS itself a prime target for attackers, and it vastly extends the attack surface of the platform. However, Lokad does closely monitor its web traffic, and abnormal user behaviors on our own platform. These capabilities, though, are part of the platform itself and thus are not delegated to privileged isolated third-party software components.

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.

6.7 Are the software developers periodically trained to use threat assessment methods, secure coding standards, well-known security checklists, and frameworks?

Yes. However, most well-known checklists primarily reflect architectures that are “insecure by design”. Whenever possible, we prefer to eliminate the source of security pitfalls at the design-stage. See also Employees 6.2.

6.8 Do all contracts with Lokad’s subcontrators/external workforce include a Non-Disclosure Agreement (NDA)? Does this NDA cover customer information?

Yes to both, though Lokad - at time of writing - does not rely on subcontractors/an external workforce. Lokad’s software engineering and supply chain scientist teams are fully staffed by people under the direct, permanent employment and supervision of Lokad.

However, if Lokad were to deem it necessary to engage with a subcontractor, they would be subject to the same IP (Intellectual Property) and NDA terms as our permanent employees. These agreements include terms regarding information on Lokad’s clients.

6.9 Has all of Lokad’s external workforce been provided Lokad’s internal information and security induction training (and ongoing relevant training)?

Lokad - at time of writing - does not rely on subcontractors/an external workforce. Lokad’s software engineering and supply chain scientist teams are fully staffed by people under the direct, permanent employment and supervision of Lokad.

However, if Lokad were to deem it necessary to engage with an external workforce, this would be a requirement. All subcontractors/external workers would be subject to the same security processes and training requirements as our permanent employees.

As previously stated, Lokad currently does not rely on an external workforce, hence no such training takes place.

6.10 Do all contracts with companies that provide Lokad’s external workforce (any/all contractors, consultants, etc., who participate in the delivery of Lokad’s services) require that the external workers are screened using background checks? Are these background checks in accordance with the corresponding level of access to information and the criticality of the employee’s role?

However, if Lokad were to deem it necessary to engage with an external workforce, this would be a requirement. All subcontractors/external workers would be subject to the same security processes, background checks, and training requirements as our permanent employees.

Note: Historically speaking, many of the largest - and worst - incidents, such as cyber-espionage, are committed by people who have impeccable records. This, amongst other reasons, is why Lokad is reluctant to rely on an external workforce and strongly prefers direct, open-ended employment contracts.

6.11 Are the administrative accounts automatically disabled or deleted at the end of employment?

Yes. All Lokad employees receive their access rights through a federated identity provider (Microsoft Azure Active Directory). At the end of their employment, if applicable, this access is revoked, thus automatically disabling all the associated administrative rights.

Note: Most Lokad employees are never granted administrative rights as these are not needed for the execution of their duties.

6.12 Do you perform criminal background checks on all staff that have access to sensitive data, financial data, banking data, payment card data, etc.?

Yes, background checks are performed strictly in line with the requirements of the job being performed.

It should be noted that Lokad does not internally manage payment card data - this is managed by third parties. Thus, Lokad staff does not have access to any payment card data from our clients.

6.13 What precautions does Lokad take to ensure that non-authorized personnel cannot access the premises where the work is performed?

On the building-level, Lokad operates in an office building that benefits from 24/7 (twenty-four hours a day, seven days a week) third party surveillance, with staffed security on site.

On the office-level, Lokad’s premises have their own secure access points, independent from those of the building itself. This last layer prevents employees of other companies within the building gaining access to Lokad’s offices.

Note: any exceptional visitors (such as clients, potential candidates, etc.) have to be physically welcomed and permitted entry by Lokad staff members.

6.14 Are visitors permitted in the facility?

If “facility” means “the place where client data is stored and processed”, then no. Client data is stored in the data centers of Microsoft Azure. These data centres are not open to the public - Lokad itself cannot access them.

However, Lokad does occasionally welcome visitors to its corporate headquarters. Our offices are not open to the public, but exceptional circumstances occasionally arise, such as clients visiting, job applicants waiting for an interview, etc. Such visits are planned ahead of time and such visitors are accompanied by Lokad staff members at all times while in our offices.

6.15 Are paper data records (and removable electronic media containing data) stored in secure fireproof cabinets overnight?

Lokad does not operate with paper data records, nor does it operate with removable electronic media. As we have no physical records for storage, Lokad has no need for fireproof cabinets.

While we may occasionally print a document (Lokad prints very few documents, if ever), we also have a shredder next to the printer. Lokad’s default policy is to not print any sensitive document, but if it theoretically had to be done, our default policy is also to shred the printed document immediately after use.

6.16 Is there a clear desk policy in place? If so, to what extent?

Yes, Lokad operates with a clear desk policy firmly in place. This policy is enforced “by design” through our digital environment.

Except for a few documents that we are legally compelled to print, or occasional documents that are printed out of necessity (e.g., a poster for a trade show, though even this would typically be outsourced), Lokad’s work environment is strictly digital.

Thus, at the end of the day, Lokad’s employees have nothing to clear. Once the computer session of the employee has been locked - a policy that we strictly enforce - the given desk is effectively cleared.

6.17 Where do faxes arrive and who could have access to them?

Lokad has never owned a fax machine - be it physical or virtual. We no not know of any compelling use case to change our stance on this technology.

6.18 Is there a process to verify the return of constituent assets (computers, cell phones, access cards, tokens, smart cards, keys, etc.) upon termination?

Yes, we have not only a process in place, but also an IT asset management software to support this effort and minimize the amount of clerical errors.

However, we have deliberately engineered the security of Lokad not to depend on the timely return of constituent assets. Lokad assumes that any constituent assets have a fair chance of being lost or stolen, no matter how disciplined and trained our employees might be. In practice, this very rarely happens, but from an engineering perspective, we make the opposite assumption. For this reason, constituent assets can be remotely disabled. Moreover, we apply full drive encryption whenever applicable.

More generally, our work environment has been designed not to require any persistence storage of client data on workstations, notebooks, or cell phones. This design considerably alleviates the criticality of the constituent assets in the event our other preventative measures were to fail.

6.19 Are Human Resource (HR) policies and/or procedures approved by management and communicated to constituents, and is an owner designated to maintain and review them?

Yes, our Human Resource policies and procedures have been formally approved by senior management. We place a strong emphasis on clear communication, and as such these policies and procedures have been thoroughly disseminated to all relevant constituents to ensure complete understanding and compliance.

Furthermore, we have designated an owner who is responsible for the ongoing maintenance, updates, and regular review of the policies and procedures. This ensures that our practices remain current, relevant, and in alignment with both industry standards and our organizational objectives.

6.20 Are there any personal (BYOD), rather than company-owned, mobile devices used by individuals associated with your organization that have access to client data?

No, Lokad does not permit access to client data on personal (BYOD) mobile devices. We provide our employees with high-quality, company-owned hardware, eliminating the need for personal devices. This provision addresses the common scenario where employees resort to using their own devices due to dissatisfaction with substandard company hardware.

Furthermore, our operational protocols are designed such that even on our company-owned devices, client data is not permanently stored. All data processing occurs within our cloud-based platform. On employee devices, client data (if ever accessed) is handled transiently and only in minimal segments, ensuring maximum security.

Notes

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. ↩︎
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 ↩︎
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 ↩︎
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. ↩︎