Table of Contents

Introduction

This page covers interworks.cloud policies and standards used to ensure security and privacy for its users and data, broken up into the following sections:

• Authentication & Authorization - User authentication methods, login failure policy, user roles, and spam protection for BSS and Storefront.

• Cloud Security - Infrastructure security, security incident response, vulnerability scanning, penetration testing, encryption, backups and patch management of the platform infrastructure hosted on Microsoft Azure.

• Application Security - Secure code development, framework security controls, quality assurance, separate environments, and bug bounty program of the platform application.

• HR Security - Training, policies, and confidentiality agreements of the platform employees.

• Data Privacy & Ownership - GDPR and PCI compliance, data ownership, data deletion, and security audits of the platform data.

1. Authentication & Authorization

1.1 User Authentication Methods

1.2 Login Failure Policy & Session Expiration

• The maximum number of failed attempts before a user account is locked out can be set in the Organization Settings tab (e.g. maximum login attempts = 5).

• All sessions implement an idle timeout and absolute timeout.

  • Idle Timeout: Sessions timeout after a specified period of inactivity (e.g. 60 minutes)

  • Absolute Timeout: Sessions timeout after an administratively-configurable maximum time period regardless of activity (e.g. 480 minutes)

1.3 User Roles

1.4 Spam & Abuse

2. Cloud Security

2.1 Infrastructure Security & Data Hosting

The entire platform infrastructure is hosted on Microsoft Azure (West US & West Europe regions), protected by advanced Layer-7 routing and load-balancing devices, network security groups, web application firewalls, and DDoS Protection. Management of the infrastructure is allowed via the Azure portal, utilizing conditional access policies and strong MFA for secure access to both the portal and the virtual machines. The virtual network infrastructure is based on Azure Virtual Network, utilizing separate subnets for each platform component type, different network security groups for fine-grained control of permitted traffic between components and subnets, firewalls, as well as accelerated networking for the virtual machines.

2.2 Security Incident Response

• Endpoint security software is installed on all platform endpoints.

• A third-party vendor operates and maintains a fully-managed SOC and MDR/EDR as a Service solution, providing interworks with SOCaaS/MDRaaS/EDRaaS services

• interworks maintains on a 24x7 basis, through the third-party vendor, an incident response capability to prepare, detect, and quickly respond to an attack. More specifically, the third-party vendor is capable to detect, validate, and escalate a high criticality security relevant incident to interworks within 15 minutes after the initial detection. Including the relevant guidance for immediate actions to be taken to remediate the security incident. The third-party vendor remains at the interworks side until closure of the incident.

2.3 Vulnerability Scanning

Interworks developed a continuous vulnerability scanning program to continuously assess and track vulnerabilities on all critical assets within the enterprise’s infrastructure, in order to remediate, and minimize, the window of opportunity for threat actors. This program includes:

• Daily network vulnerability scanning

• Weekly web application vulnerability scanning

2.4 Penetration Testing

A third-party independent auditing firm quarterly runs penetration tests in our interworks.cloud Platform production environments, against the top-10 OWASP exploits and vulnerabilities. Penetration test reports are available upon request and signing of an NDA.

2.5 Encryption

• All platform data reside in MS SQL databases hosted on Azure SQL managed instances and in Azure Files containers, both encrypted at rest using Transparent Data Encryption (TDE) and Azure storage service encryption (SSE).

• In addition, specific type of data (marked as critical/sensitive) such as contact’s First Name, Last Name, Mobile Phone and Email are further stored encrypted within the MS SQL database tables using SQL Server column-level encryption with AES-256 (certificates are used to safeguard encryption keys, which are used to encrypt data in the database).

• SHA-256 is used for secure password hashing.

• Data in transit are encrypted with TLS 1.2 and higher.

2.6 Backups

Backup frequency varies depending on the type of data:

Virtual Machines & Common storage

Backup Settings

• Local Backups (Azure): Enabled

• Recovery Services Vault: Enabled

• Encryption Settings: By default, the data in the Recovery Services vault is encrypted using Microsoft managed keys. Azure Backup automatically encrypts all the backed-up data while storing in the cloud using Azure Storage encryption. This data at rest is encrypted using 256-bit AES encryption.

• Multi-User Authorization: Enabled

Backup Policies

Azure Files (common storage) and VM backups are stored in geo-redundant storage blobs that are replicated to a paired region.

Azure SQL Managed Instance (SQL Databases)

Backup Settings

• Automated Database Backups (Azure managed): Enabled

• Encryption settings: All databases are encrypted with TDE, therefore all database backups are encrypted at rest.

Backup Policies

Azure SQL Managed Instance backups are stored in geo-redundant storage blobs that are replicated to a paired region. Backups are copied synchronously three times within a single physical location in the primary region by using LRS. Then the data is copied asynchronously three times to a single physical location in the paired secondary region, which result in:

• Three synchronous copies in the primary region within a single availability zone

• Three synchronous copies in the paired region within a single availability zone that were copied over from the primary region to the secondary region asynchronously.

2.7 Logs

The platform generates log entries regarding application related operations and stores them in log files and log databases. Platform related logs that are stored in databases are also transferred to a central log management system (ELK). The transfer is conducted through secure (encrypted) connections. Platform related file logs are not transferred to a central log management system. They are retained locally for one year and there are automation mechanisms in-place allowing remote retrieval based on specific criteria (on-demand retrieval for support/investigation purposes via MS Teams channel).

The log files on servers and systems are encrypted at rest through Azure Disk Storage Server-Side Encryption. The indexed data that are stored in the central log management system (ELK data nodes) are not encrypted at rest.

All platform related file logs are retained for a year on servers and systems hosted on Azure. Logs that are gathered in ELK have longer retention period. Platform related logs that are stored in databases are retained for at least six months, logs stored in the centralized log management system are retained for 330 days.

2.8 Patch Management

• We maintain the integrity of the Interworks platform by applying the latest operating system and application security updates/patches in a timely manner

• We ensure patch management compliance and other repetitive maintenance via automation

3. Application Security

3.1 Secure Code Development (SDLC)

The Security effort that is applied during SDLC in our platform, according to our development phases (e.g. Analysis, Implementation, and Testing phase) is as follows:

1. Analysis Phase

   1. Identify Security Requirements & Security User Stories

   2. Review Security Design & Architecture

   3. Identify Threats (Threat Modeling)

2. Implementation Phase

   1. Use secure coding practices, input validation, and output encoding.

   2. Analyze source code before compiling to validate the use of secure coding policies (SAST).

   3. Conduct manual reviews of all relevant code on a line-by-line basis to validate the use of secure coding policies and/or identify security vulnerabilities (Secure Code Review).

   4. Manage the Security Risk of Using Third-Party Components (Dependency Analysis).

3. Testing Phase

   1. Perform Manual Security Testing to test security of fully integrated and running code and uncover vulnerabilities.

   2. Perform Automated Security Testing & Fuzzing to test security of fully integrated and running code and uncover vulnerabilities.

3.2 Framework Security Controls

interworks leverages modern and secure open-source frameworks with security controls to limit exposure to OWASP Top 10 security risks. These inherent controls reduce our exposure to SQL Injection (SQLi) and Cross Site Scripting (XSS), among others.

3.3 Quality Assurance

Our Quality Assurance (QA) department reviews and tests our code base. Dedicated application security engineers on staff identify, test, and triage security vulnerabilities in code.

3.4 Separate Environments

The testing and staging environments are separated from the production environment on a logical level, and no service data is used in our development or test environments.

3.5 Bug Bounty Program

If a user has discovered a security vulnerability, we encourage them to get in touch with us immediately. Their disclosure will help us address the issue promptly and ensure the safety of our users and data. For more information regarding Bug Bounty Program, please visit this page: Hall of Fame - interworks.cloud

4. HR Security

4.1 Training

All employees complete Security and Awareness training annually and during onboarding.

4.2 Policies

interworks has developed a comprehensive set of security policies that are updated frequently and communicated to all employees.

4.3 Confidentiality

All employee contracts include a confidentiality agreement.

5. Data Privacy & Ownership

5.1 GDPR Compliance

All of the above mentioned sections participate in safeguarding the privacy and security of personal data within the interworks.cloud Platform. If after reviweing the above the customer has SPECIFIC questions on GDPR coverage, then he may proceed with sending them to the Risk & Comliance Department at dpo@interworks.cloud.

5.2 PCI Compliance

Our platform is not required to be PCI compliant because we neither store nor submit credit card information (e.g., credit card number, security code, name, expiration date).

• All the integrations we support work either by redirecting the user to a secure page hosted by the payment gateway provider or embedding a form managed by the provider in our system (the iframe approach).

• We support recurring charges via tokenization, where the credit card is represented in our system from a token the provider has shared with our system.

5.3 Data Ownership

Customer has full and exclusive ownership of any data (customer records, orders, invoices, payments, etc.) stored in our Platform SQL tables. As per our Data Processing Agreement (available upon request for customer’s review), the Platform customer is the “Data Controller“ and interworks.cloud Ltd. or IWCP, LLC are the “Data Processors“.

5.4 Upon Termination

We are obliged to delete all Platform Customer data within 30 calendar days of cancellation order, but not earlier than 7 calendar days following the cancellation order. Platform Customers must take all precautions and measures for adequately backing up their data before being deleted.

5.5 Security Audits

The following documents may help in assessing interworks.cloud's security posture with respect to its Platform service:

• Interworks ISO 27001 certificate -

• Interworks GDPR Readiness CEO Statement -

• Interworks Privacy Policy -

• Interworks Information Security Policy -

Furthermore, bespoke customer surveys or questionnaires may be answered upon mutual agreement on the scope and potential additional cost of answering them (NDA required).