A01:2021

Broken Access Control

Access control enforces policy such that users cannot act outside of their intended permissions. Failures typically lead to unauthorized information disclosure, modification, or destruction of all data or performing a business function outside the user's limits.

System utilizes several security mechanism which control what authenticated users are allowed to do and what data they could access. That includes:

• object security utilizing Security Schemes (set for users and groups) and Field Level Security (FLS)

• access to each object is controlled on access and a user must present a valid authentication token in order to access data

• restricting access to API functions using system permissions - access is granted only for users with specific permissions.

• parameter tampering or force browsing will not bypass security checks

For more information please refer to manual: Security.

A02:2021

Cryptographic Failures

The first thing is to determine the protection needs of data in transit and at rest. For example, passwords, credit card numbers, health records, personal information, and business secrets require extra protection, mainly if that data falls under privacy laws, e.g., EU's General Data Protection Regulation (GDPR), or regulations, e.g., financial data protection such as PCI Data Security Standard (PCI DSS).

Preventive measures taken:

• system stores password only for internal users

• system stores passwords in encrypted form using strong hashing algorithm

• system doesn't expose user credentials

• system doesn't expose sensitive data about used infrastructure (response filtering)

• SaaS Cloud utilizes TLS 1.3 or TLS 1.2 for network traffic encryption (encryption is enforced)

Datacenter meets security class 3 (SSF 200) requirements and implements:

• ISO 27001 - information security management system (ISMS)

• PCI DSS Certified - the Payment Card Industry Data Security Standard

Read more about Datacenter security: Data Center Information

A03:2021

Injection

An application is vulnerable to attack when:

• User-supplied data is not validated, filtered, or sanitized by the application.

• Dynamic queries or non-parameterized calls without context-aware escaping are used directly in the interpreter.

• Hostile data is used within object-relational mapping (ORM) search parameters to extract additional, sensitive records.

• Hostile data is directly used or concatenated. The SQL or command contains the structure and malicious data in dynamic queries, commands, or stored procedures.

System utilizes following defensive techniques to prevent SQL injections:

• use of Prepared Statements (with Parameterized Queries)

• use of Stored Procedures

• user input filtering (positive or negative server-side input validation)

• application traffic filtering (application firewall)

NoSQL, OS and LDAP injections should not be possible.

A04:2021

Insecure Design

Insecure design is a broad category representing different weaknesses, expressed as “missing or ineffective control design.” Insecure design is not the source for all other Top 10 risk categories. There is a difference between insecure design and insecure implementation. We differentiate between design flaws and implementation defects for a reason, they have different root causes and remediation. A secure design can still have implementation defects leading to vulnerabilities that may be exploited. An insecure design cannot be fixed by a perfect implementation as by definition, needed security controls were never created to defend against specific attacks.

This is a very broad and general requirement at the same time, assuming different ways of attack including simple abuse of the system.

We believe that our system is designed "secure" for the type of data stored and possible use cases. To address a few related concerns:

• CWE-73: External Control of File Name or Path - no, this is fully controlled by the system

• CWE-209: Generation of Error Message Containing Sensitive Information - no - errors do not contain sensitive information

• CWE-256: Plaintext Storage of a Password - no passwords are stored using strong hashing algorithms.

• CWE-266: Incorrect Privilege Assignment - system provides functions to verify effective user permissions

• CWE-434: Unrestricted Upload of File with Dangerous Type/CWE-646: Reliance on File Name or Extension of Externally-Supplied File - no, file types are determined by the actual file content, files are scanned by server side anti-virus on upload.

• CWE-602: Client-Side Enforcement of Server-Side Security - no, security is always enforced on server side. Client relies on security information only for presentation and UI activation.

• CWE-656: Reliance on Security Through Obscurity - no, security rights are always checked per object accessed.

A05:2021

Security Misconfiguration

The application might be vulnerable if the application is:

• Missing appropriate security hardening across any part of the application stack or improperly configured permissions on cloud services.

• Unnecessary features are enabled or installed (e.g., unnecessary ports, services, pages, accounts, or privileges).

• Default accounts and their passwords are still enabled and unchanged.

• Error handling reveals stack traces or other overly informative error messages to users.

• For upgraded systems, the latest security features are disabled or not configured securely.

• The security settings in the application servers, application frameworks (e.g., Struts, Spring, ASP.NET), libraries, databases, etc., are not set to secure values.

• The server does not send security headers or directives, or they are not set to secure values.

• The software is out of date or vulnerable

Without a concerted, repeatable application security configuration process, systems are at a higher risk.

Preventive measures taken:

• systems are deployed using configuration management tool s that ensure consistency and proven configuration options

• On-premises deployments are delivered as preconfigured, read only containers

• cyclic inspection and hardening of configurations of used components

• security updates are applied regularly

• system scanner is used to detect vulnerable components used that needs to be updated or patched.

• set HTTP security headers where appropriate

• filtering error messages sent to client, so they do not expose sensitive information

A06:2021

Vulnerable and Outdated Components

You are likely vulnerable:

• If you do not know the versions of all components you use (both client-side and server-side). This includes components you directly use as well as nested dependencies.

• If the software is vulnerable, unsupported, or out of date. This includes the OS, web/application server, database management system (DBMS), applications, APIs and all components, runtime environments, and libraries.

• If you do not scan for vulnerabilities regularly and subscribe to security bulletins related to the components you use.

• If you do not fix or upgrade the underlying platform, frameworks, and dependencies in a risk-based, timely fashion. This commonly happens in environments when patching is a monthly or quarterly task under change control, leaving organizations open to days or months of unnecessary exposure to fixed vulnerabilities.

• Platform is updated regularly

• Security patches are applied regularly

• System components are scanned for vulnerabilities and system is updated depending on the impact - either via security or standard release.

A07:2021

Identification and Authentication Failures

Confirmation of the user's identity, authentication, and session management is critical to protect against authentication-related attacks

• multi-factor authentication is available to all users

• password requirements can be set in the authentication system

• brut force detection is available to all systems

• client is logged out after idle

• security logs are available (login date, time, IP etc.)

A08:2021

Software and Data Integrity Failures

Software and data integrity failures relate to code and infrastructure that does not protect against integrity violations. An example of this is where an application relies upon plugins, libraries, or modules from untrusted sources, repositories, and content delivery networks (CDNs).

Our system is delivered as a self contained solution that does not rely on any external sources. The system does not load anything dynamically (form trusted or untrusted sources).

Application build process relies on internal package repository and not on online versions. Components are scanned for known vulnerabilities.

A09:2021

Security Logging and Monitoring Failures

This category is to help detect, escalate, and respond to active breaches. Without logging and monitoring, breaches cannot be detected

Application produces logs for user actions and security events like changed permissions, login, document access etc. that can be easily reviewed by system administrator.

Low level logs are managed in Elk/Kibana system.

Application firewall is configured with OWASP ModSecurity Core Rule Set, further customized to meet our needs.

A10:2021

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

End user are not allowed to provide any external URLs as data sources for the system backend.