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:

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 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:

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

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.

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

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:

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:

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:

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.

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

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; socket session timeout occurs after approximately 10 minutes of detected inactivity. The loop application session timeouts are configurable.

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

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.

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.

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.

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:

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:

Other highlights of Benbria’s internal security policy include:

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.

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.

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

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.

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.

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.

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.

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.