LogicNets Security Architecture

Background

Security prevention is an important and fast-changing area of focus for any software company, and LogicNets takes the security of our software and the applications you create with it very seriously. Security issues can exist on multiple levels in the system and there are many different types, each requiring a different approach. These approaches, however, can also have consequences; for example, checking input and output to verify that harmful data is not being introduced requires additional processing power. LogicNets works to continually address security risks and ensure the smooth, safe running of our application and yours.

Security in LogicNets Applications

LogicNets addresses security protection and implementation on multiple levels:

• The LogicNets platform
• Frameworks and solutions built on top of the LogicNets platform
• Infrastructure hosting the platform and frameworks
• Client computers using the platform and solution during production and during development
• Each organization using the platform and platform-based applications, who has access to what and from where

Additionally, LogicNets considers factors such as the security of a client's computer and who might access client applications. While it might sound slightly paranoid, we generally assume the outside world should be considered unsafe and potentially harmful. It's how we keep you safe.

Hosted LogicNets Applications

The LogicNets infrastructure is primarily hosted on Amazon Web Services (AWS) cloud computing platforms. AWS provides LogicNets with active security protection functionality that includes web application firewall (WAF); strict user and password control, including IP whitelisting, for accessing infrastructure, databases, and instances; separating infrastructure components into different subnets, domains, and traffic monitoring; and port whitelisting.

The WAF helps us to protect the platform and solutions against common security leaks/attacks. However, while it uses general rules and forbidden words to filter unsafe content, it cannot provide complete protection and sometimes blocks legal content that may contain blacklisted words. Therefore, LogicNets focuses on a creating security architecture at the platform and solution level to further strengthen the overall security.

LogicNets implements security measures to protect against malicious end users or external hackers as well as malicious design users that have access to a shared design environment. 

OWASP Top 10 Analysis

The Open Web Application Security Project (OWASP) is a nonprofit foundation that works to improve the security of software, and LogicNets tests against their top 10 security areas. If you are newly considering software security, OWASP (owasp.org) is a good general starting point for learning about security threats and how to protect against them.

Injection

Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query. The attacker’s hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization.

LogicNets offers high-level database parts, such as get_records, add_records, update_records, and delete_records, that all build up queries based on the given input. LogicNets properly escapes all of the input to avoid SQL injection. We also provide libraries for (custom-) part developers can use to build XSS-safe functionality efficiently. The library APIs are designed to avoid making mistakes that can introduce security leaks. The publicly available parts are configured by default to render XSS-safe output. The LogicNets Designer also offers validation tools for users to ensure safer parts.

Broken Authentication

Application functions related to authentication and session management are often implemented incorrectly in software, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws. This allows hackers to assume other user's identities temporarily or permanently.

LogicNets has implemented several protections against this vulnerability: hashing/salting passwords, SSO solutions, forced password renewal, minimal password strength, session-pinning, regular and use-case-based session-pinning cookie renewal, automatic account blocking, MFA, and secure connections. Built-in user and role management helps our users to avoid common mistakes in solutions, and our software allows us to quickly roll out fixes.

Sensitive Data Exposure

Many web applications and APIs do not properly protect sensitive data, such as financial, healthcare, and Personal Identifiable Information (PII). Attackers may steal or modify weakly protected data to conduct credit card fraud, identity theft, or other crimes. Sensitive data may be compromised without extra protection, such as encryption at rest or in transit, and requires special precautions when exchanged with the browser.

LogicNets ensures our public parts do not allow session data to be read or modified from other sessions without proper authorization. Additionally, accessing files on disk is blocked except for whitelisted paths and files. We escape the $ in $(..) during content rendering to prevent double-interpolation from allowing exposure of sensitive data from the session context.

XML External Entities (XXE)

Many older or poorly configured XML processors evaluate external entity references within XML documents. These external entities can be used to disclose internal files using the file URI handler, internal file shares, internal port scanning, remote code execution, and denial of service attacks. LogicNets' XML processors do not support external entity references.

Broken Access Control

When restrictions on what authenticated users are allowed to do are not properly enforced, attackers can exploit these flaws to access unauthorized functionality and/or data, such as accessing other users’ accounts, viewing sensitive files, modifying other users’ data, or changing access rights. LogicNets implemented several protections against this vulnerability. Our built-in user and role management helps users to avoid common mistakes. User accounts and roles are managed by internal libraries to avoid unauthorized access to user data.

Cryptographic Failures

LogicNets evaluates the data protection needs for data both in transit and at rest. For example, passwords, credit card numbers, health records, personal information, and business secrets require extra protection, especially if that data falls under privacy laws, like the European Union's General Data Protection Regulation (GDPR), or regulations concerning financial data protection, such as PCI Data Security Standard (PCI DSS). LogicNets employs a mix of cryptographic functions to ensure security, including randomizing, hashing, encryption, decryption, signing, and verification functions.

Security Misconfiguration

Security misconfiguration is one of the most commonly seen issues, and it is the result of insecure default configurations, incomplete or ad hoc configurations, open cloud storage, misconfigured HTTP headers, and verbose error messages containing sensitive information. By default, LogicNets sets configuration parameters to the most secure option and enables authentication by default when a user creates a new project. We work to ensure all operating systems, frameworks, libraries, and applications are securely configured and also patched/upgraded in a timely fashion.

Cross-Site Scripting/XSS

Cross-site scripting, or XSS, flaws occur whenever an application includes untrusted data in a new web page without proper validation or escaping. It can also happen when a user updates an existing web page using a browser API that can create HTML or JavaScript. XSS allows attackers to execute scripts that can hijack user sessions, deface web sites, or redirect the user to malicious sites.

LogicNets provides libraries for custom part developers to use to build XSS-safe functionality efficiently. These library APIs are designed to avoid making mistakes that might introduce security leaks. Our public parts are configured to render XSS-safe outputs, and the LogicNets Designer includes validation tools that allow users to validate the security of their models.

Insecure Deserialization

Insecure deserialization often leads to remote code execution, and it can also be used to perform attacks, including replay attacks, injection attacks, and privilege escalation attacks. $(..) does not support harmful code execution.

Using Components with Known Vulnerabilities

Components such as libraries, frameworks, and other software modules, frequently run with the same privileges as an application. If a hacker exploits a vulnerable component, they can facilitate serious data loss or server takeover. As such, applications and APIs using components with known vulnerabilities may undermine application defenses and enable various attacks and impacts.

Most third-party libraries used by LogicNets run in the browser. The LogicNets architecture defenses against security leaks run server-side, as we assume that the browser should not be trusted. LogicNets ensures that the third-party libraries we use on the server-side are well reviewed and kept current, and we follow a strict update schedule for OS, database, and other infrastructure.

Insufficient Logging and Monitoring

Insufficient logging and monitoring, coupled with missing or ineffective integration with incident response, allows attackers to further attack systems; maintain persistence; pivot to more systems; and tamper with, extract, or destroy data. Most breach studies show that the time to detect a breach is more than 200 days and that it is typically detected by external parties rather than by internal processes or monitoring. To help combat this, LogicNets has set up extensive logging and traffic monitoring in AWS.

Insecure Design

Insecure design is a broad category representing different weaknesses, expressed as "missing or ineffective control design", and there is a difference between insecure design and insecure implementation. LogicNets differentiates between design flaws and implementation defects for a reason: they have different root causes and remediation. To help address insecure design, LogicNets performs regular risk assessments, implemented and audits SOC-2 compliance, and implements multilevel defense against attacks and vulnerabilities inside the application stack and the IT infrastructure.

Server-Side Request Forgery (SSRF)

SSRF flaws occur whenever a web application is fetching a remote resource without validating the user-supplied URL. It allows an attacker to coerce the application to send a crafted request to an unexpected destination, even when protected by a firewall, VPN, or another type of network access control list (ACL).

LogicNets uses a content security policy (CSF) to avoid loading data from unknown/untrusted sources, only allows redirects to whitelisted domains, and constructs and updates URLs using library routines that ensure the correct URL schema, port, and layout.