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.

Broken Object-Level Authorization (API1:2023)

APIs tend to expose endpoints that handle object identifiers, creating a wide attack surface for object-level access control issues. Object-level authorization checks should be considered in every function that accesses a data source using an ID from the user.

The LogicNets runtime controls access and modification of key elements such as passwords, authentication, and authorization configurations within the runtime and has implemented measures to avoid authorization mistakes or misbehavior. Additionally, you should implement or consider implementing API controls for each web service.

Broken Authentication (API2:2023)

Authentication mechanisms are often implemented incorrectly, allowing attackers to compromise authentication tokens or to exploit implementation flaws to assume other users’ identities temporarily or permanently. This compromises a system's ability to identify the client or user, which compromises API security overall.

The built-in security protections available for the LogicNets system and customer-built applications are also enabled for system APIs and customer-built APIs. See LogicNets Security Architecture for more information. Authentication is enabled by default for customer-built APIs. 

The LogicNets runtime offers the following methods for API authentication/authorization:

1. Cryptographic random passwords are generated for server users by default, and the system does not allow manually created passwords.
2. LogicNets supports token-based authentication using RSA256 signed public/private key pairs (Web Services Access Control). The authentication token is generated and signed on the server side for client-side outbound API calls (authentication.external_users) to avoid having private keys transported/available in an unprotected client.
3. LogicNets supports using the OAuth access token for outbound API calls that are generated during the user authentication process.

LogicNets supports outbound URL whitelisting, and this is enabled by default. This prevents sending out credentials or security tokens to incorrect endpoints. LogicNets also supports IP whitelisting and/or blocking (realized with the AWS infrastructure).

Broken Object Property Level Authorization (API3:2023)

This category combines API3:2019 – Excessive Data Exposure and API6:2019 – Mass Assignment and focuses on the root cause: the lack of or improper authorization validation at the object property level. This leads to information exposure or manipulation by unauthorized parties. The LogicNets runtime supports roles for authorization and has code review processes in place for reviewing system API changes.

The LogicNets runtime offers the following functionality:

• Inbound and outbound request and response validation against an Open API schema.
• LogicNets supports (by default enabled) outbound URL whitelisting, and this is enabled by default. This prevents sending out credentials or security tokens to incorrect endpoints.

Unrestricted Resource Consumption (API4:2023)

Satisfying API requests requires resources such as network bandwidth, CPU, memory, and storage from LogicNets. If customers request other resources, such as emails/SMS/phone calls or biometric validation, LogicNets works with service providers to make this available using API integrations and charges per request. Successful security attacks can lead to denial of service or an increase in operational costs.

LogicNets-hosted solutions are always protected with an AWS WAF, which protects against large numbers of requests and aborts long-lasting requests. Additionally, LogicNets' default server setup restricts payload size. Every customer has a set of reserved resources (CPU, memory) via dedicated instances and the system only processes API calls from an authenticated client. Therefore, overloading APIs affects the individual customer and not LogicNets as a whole.

Broken Function-Level Authorization (API5:2023)

Complex access control policies with different hierarchies, groups, and roles, and an unclear separation between administrative and regular functions can lead to authorization flaws. By exploiting these issues, attackers can gain access to other users’ resources and/or administrative functions.

The LogicNets runtime supports roles for authorization and has detailed code review processes in place for reviewing system API changes. Users can model the GET, POST, PUT, and DELETE verbs as separate endpoint logicnets, so the system will reject those verbs that are not explicitly modeled.

LogicNets offers a built-in tool that shows all apps/APIs that have a direct start URL or can be started via the dashboard. This tool also shows which users, user groups, and associated roles have access to these tools.

Unrestricted Access to Sensitive Business Flows (API6:2023)

Some APIs risk exposing certain business flows, such as posting a comment, and the functionality has the potential to harm the business if it is used excessively in an automated manner. This does not necessarily come from implementation bugs.

LogicNets-hosted solutions are protected by a state-of-the-art AWS WAF firewall that blocks access from risky IP addresses. By default, the system APIs and customer-modeled APIs require authentication and authorization to avoid usage by unknown or unverified users. AWS blocks access from well-known malicious IPs, and LogicNets implemented alerts that happen when traffic is allowed from a malicious known source. 

LogicNets supports IP whitelisting and/or blocking (realized with the AWS infrastructure). LogicNets also offers a built-in tool that shows all apps/APIs that have a direct start URL or can be started via the dashboard. This tool shows which users, user groups, and associated roles have access to these tools.

Server-Side Request Forgery (API7: 2023)

Server-Side Request Forgery (SSRF) flaws can occur when an API fetches a remote resource without validating the user-supplied URI. This enables an attacker to coerce the application to send a crafted request to an unexpected destination, even when protected by a firewall or a VPN. The LogicNets runtime supports encrypted outbound web calls and allows restricting redirects. By default, it verifies the HTTPS server certificate and hostname of the remote server.

Security Misconfiguration (API8:2023)

APIs and the systems supporting them typically contain complex configurations, which are meant to make the APIs more customizable. Software and DevOps engineers can miss these configurations or forget to follow security best practices when it comes to configuration, opening the door for different types of attacks.

The built-in security protections available for the LogicNets system and customer-built applications are also enabled for system APIs and customer-built APIs. LogicNets-hosted solutions are protected using AWS firewalls and other security measures, which are kept current with the latest recommendations.

LogicNets offers a built-in tool that shows all apps/APIs that have a direct start URL or can be started via the dashboard. This tool also shows which users, user groups, and associated roles have access to these tools.

Improper Inventory Management (API9:2023)

APIs tend to expose more endpoints than traditional web applications, so making proper and updated documentation is very important. Proper inventory of hosts and deployed API versions also are important to mitigate issues such as deprecated API versions and exposed debug endpoints.

LogicNets automatically updates system API endpoints when updating the LogicNets runtime and removes existing/legacy APIs. APIs are not available/accessible unless (server) users are explicitly authorized to use them, and customers are actively encouraged to update their installations. 

LogicNets has Swagger-based documentation available for all system APIs. Additionally, LogicNets performs an audit of all deployed endpoints, including API endpoints, on its environment twice a year. During the process, rogue installations are identified.

LogicNets supports IP whitelisting and/or blocking (realized with the AWS infrastructure). LogicNets also supports outbound URL whitelisting, which is enabled by default. This prevents sending out credentials or security tokens to incorrect endpoints.

Unsafe Consumption of APIs (API10:2023)

Developers tend to trust data received from third-party APIs more than user input, adopting weaker security standards. To compromise APIs, attackers go after integrated third-party services instead of trying to compromise the target API directly.

LogicNets implemented time-outs to avoid hanging applications when outbound APIs do not respond or lack performance. By default, the system treats external data, such as data from databases and outbound web APIs, as unsafe and escapes it unless it is explicitly marked as safe. Additionally, LogicNets supports outbound URL whitelisting, which is enabled by default. This prevents sending out credentials or security tokens to incorrect endpoints.