Skip to main content
Security Guide
Written by Aniko Villeneuve
Updated over a week ago

Scope of Sensitive Data

A key consideration of solution security involves understanding and containing the scope of sensitive information that is mediated by Loop. Loop in its default configuration can collect, transmit and store the following data that could be sensitive:

  • User (consumer or associate user) names

  • User contact information

  • User-submitted free-form text or media content

  • Configuration or other information pertaining to the reputation of the client, its employees, and its customers.

Loop in its recommended configuration does not mediate highly sensitive information (e.g. national identification numbers (SSN, SIN, NINO…), health, credit card, and other commercial information).

Through configuration, however, the client may configure certain custom-fields that prompt for collection of other information. All data collected is managed as per this security guide, however, Loop and Benbria policy do not specifically deal with health, credit or other sensitive data management protocols specifically. Please inquire.

We offer the following additional published and support resources for further information:

  • Loop user and administrator documentation.

  • License Agreement documentation, including Acceptable Use Policy.

  • Consultation during initial configuration, for example during a trial period.

  • Periodic configuration audits.

Loop Security Controls

Security by Design

Isolation of Sensitive Data

Loop service focuses on the front-end customer engagement and experience portion of the client’s operations. As such Loop remains isolated from the client’s own highly sensitive data contained in its commercial and operations systems.

Loop in its default configuration hides entered customer contact information from associate users. It is not exposed to client users and not exposed via the Loop API. Collected contact information may only be used by Loop to facilitate a connection between Loop and the consumers (for example, to exchange messages and bring closure to the consumer’s input or request).

Privacy Policy:  
 In full production subscriptions, Loop can display a link to Benbria’s privacy policy or a link to the client’s own privacy policy.

The client’s Loop users are required to provide proof of identity to access their assigned Loop user interface. User authentication requires both:

  • Username: Unique usernames are enforced within each client’s account.

  • Password: Password is mandatory. The presentation of password is masked on the page during the authentication and password administration procedures. Passwords are stored in Loop in encrypted format; they are never retrievable in plain text.

Loop’s security reference design also specifies the following enhanced authentication capabilities:

  • Enforcement of strong password rules, including a minimum character length and at least one alphabetic and one non-alphabetic character.

  • Lockout following a prescribed number of invalid login attempts.

  • Enforce periodic password change.

  • Maintain user’s password history, preventing re-use.

Reference Architecture

The following figure summarizes Loop’s security design reference, including key security measures in red text that is designed to keep data private and safe. Terminology is described in the sections that follow.

Component Layers and Overview

The figure below captures the components involved in managing data through the Loop platform, including the conceptual application layers (for reference):

Hosting Partners

Benbria works with two of the leading providers of cloud hosting services. As such, Benbria's Loop product leverages best-in-class security from these hosts:

Consumer Rights

The client is obligated by applicable local, state/province, or national law to protect the privacy of customer information. Loop assists the client in meeting these legal obligations in the following ways:

  • Hidden contact information: Loop in its default configuration hides entered customer contact information; it is not exposed to the client’s users and not exposed via its API. Collected contact information may only be used by the client to connect with customer users via Loop, for example to bring closure to the customer’s input or request.

  • Privacy Policy: In full production subscriptions, Loop can display a link to Benbria’s privacy policy or a link to the client’s own privacy policy.

Physical Security

Physical Access

Physical controls are in place to prevent theft of customer data. Customer data is stored on best-in-class secure hosts (see Amazon, Terremark). Physical access to these datacenters is highly restricted.

Physical access to Benbria offices is protected by keycard access. Benbria offices are monitored 24/7 by a staffed security team.

In addition, the following physical security measures have been put in place in the hosting facility:

  • Fire Detection and Suppression:
     Automatic fire detection and suppression equipment has been installed to reduce risk.

  • Power:
     The data center electrical power systems are designed to be fully redundant and maintainable without impact to operations, 24 hours a day, and seven days a week. Uninterruptible Power Supply (UPS) units provide back-up power in the event of an electrical failure for critical and essential loads in the facility.

  • Climate and Temperature:
     Climate control is required to maintain a constant operating temperature for servers and other hardware, which prevents overheating and reduces the possibility of service outages.

  • Management:
    AWS monitors electrical, mechanical, and life support systems and equipment so that any issues are immediately identified. Preventative maintenance is performed to maintain the continued operability of equipment.

  • Storage Device Decommissioning:
     When a storage device has reached the end of its useful life, AWS procedures include a decommissioning process that is designed to prevent customer data from being exposed to unauthorized individuals. AWS uses the techniques detailed in DoD 5220.22-M (“National Industrial Security Program Operating Manual “) or NIST 800-88 (“Guidelines for Media Sanitization”) to destroy data as part of the decommissioning process. All decommissioned magnetic storage devices are degaussed and physically destroyed in accordance with industry-standard practices.

Online Access

Within the Benbria Engineering team, only the Development Operations (DevOps) team member, his alternate, his manager, and his director have the credentials to SSH to the hosted production environment.

Within the Benbria Operation/Support team, authenticated Ops team members have access to the Loop administrator's UI, which has access to see account data and to modify account configuration. This access is required for deployment, operations, and support purposes.

No other Benbria members have access to the production environment.

Database Security

The operational and reporting databases are hosted in Amazon Web Services (AWS) and encrypted on disk using industry standard AES-256 encryption. This includes AWS S3, AWS RDS and MongoDB Atlas (Hosted in AWS).

S3 Encryption

S3 Encryption is used for AWS, and all new object uploads to Amazon S3 buckets are encrypted by default with server-side encryption with Amazon S3 managed keys (SSE-S3).

Server-side encryption protects data at rest. Amazon S3 encrypts each object with a unique key. As an additional safeguard, it encrypts the key itself with a key that it rotates regularly. Amazon S3 server-side encryption uses 256-bit Advanced Encryption Standard Galois/Counter Mode (AES-GCM) to encrypt all uploaded objects.


Amazon RDS encrypted DB instances use the industry standard AES-256 encryption algorithm to encrypt the data on the server that hosts our Amazon RDS DB instances. After the data is encrypted, Amazon RDS handles authentication of access and decryption of the data transparently with a minimal impact on performance. Our Amazon RDS encrypted DB instance has all logs, backups, and snapshots encrypted.

MongoDB Atlas

All MongoDB Atlas network traffic is protected by Transport Layer Security (TLS), which is enabled by default and cannot be disabled. Customer data that is transmitted to MongoDB Atlas, as well as customer data transmitted between nodes of your MongoDB Atlas Cluster, is encrypted in transit using TLS. We are using MongoDB Atlas for protection of our reporting databases.

Transmission Security

Data is encrypted during electronic transit when using the Internet and other unsecured networks. The connection between Benbria Engineering team members and the hosted Amazon or Terremark operating system is secured by the Secure Shell (SSH) cryptographic data protocol, including use of the RSA cryptosystem. The access is also enforced by strictly using Multi-Factor Authentication (MFA). TLS (Transport Layer Security) is used to encrypt communication between client workstations and servers. TLS provides secure communication over the internet by encrypting data in transit and ensuring its integrity. Loop is configured in Amazon Web Services (AWS) to support HTTPS (HTTP over TLS) to encrypt HTTP traffic.

Web applications hosted in Amazon Web Services (AWS) can comply with Network Address Translation (NAT) translation by utilizing AWS NAT Gateway or AWS NAT Instance services. NAT translation is commonly used in AWS to allow instances in private subnets to access the internet or other AWS services while preserving security by not exposing the instances' private IP addresses. By utilizing AWS NAT services, web applications hosted in AWS can comply with NAT translation requirements while ensuring secure and controlled access to the internet and other external resources. Benbria has AWS resources that can accommodate advanced networking needs.

User Interface Security: The pipe between the hosted Loop application server and the user’s device is secured by the Secure Socket Layer (SSL) cryptographic protocol, where browsers and devices support it. SSL prevents data sent over the Internet from being retrieved; for example it prevents man-in-the-middle and phishing attacks.

Access points to the data are controlled by the authorization infrastructure of Benbria's Loop product, which includes access control via username and strong password.

There is a user active session timeout provided by the SSH connection which is 12 hours and 10 minutes for Socket that includes the HTTP Sessions and Socket Server used for bi-directional/real-time communication. This is configurable only for User sessions, and Users can choose to explicitly terminate a User's Sessions at any time.

Benbria utilizes many of the data and network security afforded by our hosting partner AWS.

  • Secure Network Architecture:
     Network devices, including firewall and other boundary devices, are in place to monitor and control communications at the external boundary of the network and at key internal boundaries within the network. These boundary devices employ rule sets, access control lists (ACL), and configurations to enforce the flow of information to specific information system services.

  • Secure Access Points:
     AWS has strategically placed a limited number of access points to the cloud to allow for a more comprehensive monitoring of inbound and outbound communications and network traffic.

  • Distributed Denial Of Service (DDoS) Attacks.
     AWS API endpoints are hosted on large, Internet-scale, world-class infrastructure that benefits from the same engineering expertise that has built Amazon into the world’s largest online retailer.

  • Man in the Middle (MITM) Attacks.
     All of the interactions with AWS APIs are done via SSL-protected endpoints, which provide server authentication.

  • IP Spoofing.
     Amazon EC2 instances cannot send spoofed network traffic. The AWS-controlled, host-based firewall infrastructure will not permit an instance to send traffic with a source IP or MAC address other than its own.

  • Authentication Mechanisms.
    Multiple authentication methods are supported by Loop including Basic Authentication and Token-Based Authentication. Loop supports Security Assertion Markup Language (SAML) to connect to any Identity Provider (IdP). SAML enables Single Sign-On (SSO) authentication, allowing Users to authenticate with Loop with their existing security credentials.

Data shall not be printed, exported or otherwise removed by Benbria staff.

Please see the "Loop Security Reference Architecture" (P3) summary table for more information.

Access Control

Policies and Management

Information security policies at Benbria are issued, approved, supported, and regularly reviewed by senior DevOps and engineers. The employees are informed of the best practices and security policies during security review meetings.

“Clear Desk” policy. Benbria's IT Security Policy requires enabling session time-out settings on desktop and mobile devices. In addition, need-to-know data (e.g. for troubleshooting) shall not be printed.

Passwords & Authentication

A password policy is in place that included complexity, reuse, lockout and expiration. For administrative access to our accounts on Amazon and Terremark hosts: Amazon and Terremark security hardening features apply. Please see URL links (provided above) to Amazon and Terremark security documentation.

For client user access to the Loop Employee User Interface (our web UI): Loop supports complex passwords and third party policies for regular change as required.


From time to time, subcontractors are used to provide service related to the delivery of Loop services. All security requirements are maintained in such cases.

User-Level Access Control

Loop provides a comprehensive authorization infrastructure that allows and constrains access and privileges to what is required for each user role. Role based authorization is applied automatically based on the user’s authentication information. The following sections and tables summarize the authorization structure of Loop in its default configuration:

Benbria Users and Employees

Loop’s authorization infrastructure (described above) applies also to Benbria personnel. Benbria carefully controls the number of employees that have access to the system and its account data. Most Benbria personnel have access to no more than loop data aggregated per market vertical. Only those authorized members of Benbria’s Engineering team whose role requires administering Production software deployments have access the to the hosted resources, the corresponding SSH private key, and account-specific data.

Benbria Authorized Users

Notation: ● authorized by default for role, ○ authorization optionally available.

Similarly, Loop’s code development environment is access controlled. Only authorized Benbria Engineering team members have access to code repositories. And, an Authorization infrastructure ensures code is tightly configuration managed. For example:

  • Development engineers create code and after internal review and peer approval through Pull Request process check-in to the Master Development branch of the code repository.

  • The release engineer promotes version controlled code to a Candidate Release branch of the repository.

  • Test engineers can perform functional testing on the deployed version of Candidate Release branch.

Other highlights of Benbria’s internal security policy include:

  • Engineering team adherence to secure coding best practices.

  • Security risk is documented and managed (i.e. threat risk assessments, vulnerability trees).

  • Release management: each deployment is rigorously feature and regression tested on a separate staging server before deployment to production.

  • Deployments to Production are full automated.

Disaster Recovery


As a part of our formal disaster recovery plan, the Loop production database is backed up hourly via automated processes.

Hourly backups are kept for the most recent 72 hours, daily backups for the most recent week, weekly backups for the most recent five weeks, and monthly backups are kept indefinitely (subject to change for improvement without notice).

All backups are then stored off-site using an Amazon S3 Storage service. Backup media is stored off-site in a trusted facilities (hosted providers).


Loop’s build, hardware provisioning and deployment pipeline is automated. This enables Benbria to quickly provision new compute instances and configure them into fully working environments in the case of disaster recovery. Instances can be setup in different physical regions in the case of mass network failures.

We have fully automated all stages of provisioning a new Loop environment including provisioning of cloud resources, installation of supporting services, service discovery to orchestrate configuration of multiple physical servers and deployment of Loop platform applications. This minimizes the amount of time needed to recreate a new environment.

We have a mirror copy of our production environment running in the data centre located in a different AWS region, which is regularly updated with the latest software versions and is on stand-by so it could be started within minutes in case of a disaster, this environment is referred to as DRP (Disaster Recovery Plan environment).

In the event of a major disaster to the data center all of the production traffic will be redirected to the DRP environment to ensure availability of the service to customers. The latest backup is then restored into the new DRP environment.

Patches and Upgrades

Automation also allows patches and updates to be deployed with zero service downtime. Discovered vulnerabilities can be fixed on-the-fly and without service interruptions in most cases. In addition to security patches, rapidly deploy configuration changes or system updates across all servers (such as Heartbleed) are also possible via our automation capabilities.

Security patches are deployed quickly and effectively. For example, regarding the Heartbleed issue that plagued the internet in May 2014, Loop was effectively patched within hours, much faster than the response time than that of many software companies such as Yahoo Mail.


Systems are monitored 24/7 and alerts are triggered for abnormal load or performance that may impact the availability and responsiveness of the system resources. If additional server resources are deemed as necessary, new servers will be provisioned and deployed during an agreed-upon maintenance and release schedule.


Incident and Change Management

Incident Management Process

A formal incident management process exists that includes IT security breaches (viruses, hacking, etc.) which is current and reviewed annually.

For Amazon and Terremark host incidents: such incidents are formally reported to Benbria by the supplier.

For Benbria incidents: Incidents are managed by our DevOPS team who monitors the health and status of production environment and reviews Centralized Reporting and Logging regularly to identify any potential incidents

Incident Analysis Process

A formal process exists to track and notify customers of loss or theft of systems with customer data. Root cause analysis (RCA) is performed in cases an asset is reported lost to link it back to gaps in physical security.

For incidents reported by Amazon and Terremark, Benbria's process requires passing on any information to our active customers and partners.

For Benbria incidents: Benbria's process requires conducting an analysis of incident impacts: outage, data access, integrity, risk, recovery, repeat mitigation. Our process does not formally, explicitly state whether these analyses be kept internal to Benbria or shared externally. However, in practice Benbria's operational procedures have us communicating openly with our customers and partners about any account-impacting matters, including security incidents.

Configuration Audits

Authorized Benbria Operations and Engineering team members conduct regular audits of account configuration for both consistency and use in accordance with Benbria’s Acceptable Use Policy. Operational issues or situations of increased security/privacy risk are proactively communicated to the client for evaluation or action.

Note that auditors do not have access to data that Loop keeps hidden, for example passwords or customer contact information.

Activity Logging

Loop tracks and stores audit information on users who create and contribute to loop data. Audit logs are used as needed for investigative or corrective purposes. Audit trail data may contain sensitive data (e.g. customer contact information) and is therefore not normally shared outside authorized Benbria Engineering team members.


Security Testing

The development team process includes security requirements gathering, implementation, and verification steps before acceptance into production. Each development feature includes a security evaluation component. Where the feature can possibly impact security, then feature specific security documentation and testing is implemented. This occurs in addition to regular release level security testing. Web application security testing is a specialized type of AST that focuses on identifying vulnerabilities in web-based applications. This type of testing typically involves a combination of manual and automated testing methods, such as SQL injection testing, cross-site scripting (XSS) testing, and authentication testing.


Developers periodically receive detailed coding and design training in application security through periodic meetings that focusing on product and process security. Topics include: industry vulnerabilities, security trends, development best practices, etc.

Customer Education and Awareness is also an important aspect of Benbria security principles. An advisory is provided on newest malware and possible vulnerabilities and threats and how our software planning to implement or already implemented secure or patching mechanisms in order to keep the service reliable and data intact.

Did this answer your question?