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).
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.
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):
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:
Amazon Elastic Compute Cloud (Amazon EC2), including Amazon’s increased Multi-Factor Authentication (MFA) security layer: https://aws.amazon.com/security/
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.