Skip to main content

Userback Information Security Overview

1. Purpose, Scope, and Organization

This document defines behavioral, process, technical, and governance controls pertaining to security at Userback that all personnel are required to implement in order to ensure the confidentiality, integrity, and availability of the Userback service and data. All personnel must review and be familiar with the rules and actions set forth below.

This document defines security requirements for:

  • All Userback employees, contractors, consultants and any other third parties providing services to Userback (“personnel”),
  • Management of systems, both hardware and software and regardless of locale, used to create, maintain, store, access, process or transmit information on behalf of Userback, including all systems owned by Userback, connected to any network controlled by Userback, or used in service of Userback’s business, including systems owned by third party service providers, and
  • Circumstances in which Userback has a legal, contractual, or fiduciary duty to protect data or resources in its custody.

In the event of a conflict, the more restrictive measures apply.

1.1 Governance and Evolution

This document was created in close collaboration with and approved by Userback executives. At least annually, it is reviewed and modified as needed to ensure clarity, sufficiency of scope, concern for customer and personnel interests, and general responsiveness to the evolving security landscape and industry best practices.

1.2 Security Team

The Userback security team oversees the implementation of information security systems and processes, including

  • Procurement, provisioning, maintenance, retirement, and reclamation of corporate computing resources,
  • All aspects of service development and operation related to security, privacy, access, reliability, and survivability,
  • Ongoing risk assessment, vulnerability management, incident response, and
  • Security-related human resources controls and personnel training.

2. Personnel and Office Environment

Userback is committed to protecting its customers, personnel, partners, and the company from illegal or damaging actions by individuals, either knowingly or unknowingly in the context of its established employment culture of openness, trust, maturity, and integrity.

This section outlines expected personnel behaviors affecting security and the acceptable use of computer systems at Userback. These rules are in place to protect our personnel and Userback itself, in that inappropriate use may expose customers and partners to risks including malware, viruses, compromise of networked systems and services, and legal issues.

2.1 Work Behaviors

The first line of defense in data security is the informed behavior of personnel, who play a significant role in ensuring the security of all data, regardless of format. Such behaviors include those listed in this section as well as any additional requirements specified in the employee handbook, specific security processes, and other applicable codes of conduct.

Training

All employees and contractors must complete the Userback security awareness and data handling training programs at least annually.

Clean Desk

Personnel should maintain workspaces clear of sensitive or confidential material and take care to clear workspaces of such material at the end of each workday.

Unattended Devices

Unattended devices must be locked. All devices will have an automatic screen lock function set to automatically activate upon no more than fifteen minutes of inactivity.

Use of Corporate Assets

Systems are to be used for business purposes in serving the interests of the company, and of our clients and partners in the course of normal business operations. Personnel are responsible for exercising good judgment regarding the reasonableness of personal use of systems. Only software that has been approved for corporate use by Userback may be installed on corporate equipment. All personnel must read and understand the list of prohibited activities outlined in this document. Modifications or configuration changes are not permitted without explicit written consent by the Userback security team.

Removable Storage, No Backups, Use of Cloud Storage

Personnel may not configure work devices to make backups or copies of data outside corporate policies. Instead, personnel are expected to operate primarily “in the cloud” and treat local storage on computing devices as ephemeral. Userback data must be saved to company-approved secure cloud storage (e.g. Google Docs) to ensure that even in the event of a corporate device being lost, stolen, or damaged, such artifacts will be immediately recoverable on a replacement device.

Prohibited Activities

The following activities are prohibited. Under certain conditions and with the explicit written consent of the security team, personnel may be exempted from certain of these restrictions during the course of their legitimate job responsibilities (e.g. planned penetration testing, systems administration staff may have a need to disable the network access of a host if that host is disrupting production services).

The list below is by no means exhaustive, but attempts to provide a framework for activities which fall into the category of unacceptable use.

  • Under no circumstances are personnel of Userback authorized to engage in any activity that is illegal under local, state, federal or international law while utilizing Userback-owned resources.
  • Violations of the rights of any person or company protected by copyright, trade secret, patent or other intellectual property, or similar laws or regulations including, but not limited to, the installation or distribution of “pirated” or other software products that are not appropriately licensed for use by Userback.
  • Violating or attempting to violate the terms of use or license agreement of any software product used by Userback is strictly prohibited.
  • Revealing your account password to others or allowing use of your account by others. This includes colleagues, as well as family and other household members when work is being done at home.
  • Introduction of malicious programs into the network or server (e.g., viruses, worms, Trojan horses, e-mail bombs, etc.).
  • Effecting security breaches or disruptions of network communication. Security breaches include, but are not limited to, accessing data of which the employee is not an intended recipient or logging into a server or account that the employee is not expressly authorized to access. For purposes of this section, “disruption” includes, but is not limited to, network sniffing, ping floods, packet spoofing, denial of service, and forged routing information for malicious or unlawful purposes.
  • Circumventing user authentication or security of any host, network or account or attempting to break into an information resource or to bypass a security feature. This includes running password-cracking programs or sniffer programs, and attempting to circumvent file or other resource permissions.
  • Attempting to interfere with or deny service to any other user.
  • Providing information about, or lists of, Userback personnel to parties outside Userback.
  • Installation of software which installs or includes any form of malware, spyware, or adware as defined by the security team.

2.2 Human Resources Practices

Background Checks

Background checks are conducted for personnel with access to production infrastructure prior to their start date. The consequences of problematic background check results may range from a limitation of security privileges, to revocation of employment offer, to termination.

Training

All staff and contractors go through a vetting process where they are subject to background checks and confidentiality agreements.

We provide an ongoing program of security awareness training designed to keep all members of staff informed and vigilant of security risks. This includes regular assessment of comprehension to measure the program’s effectiveness.

Separation

In the case of personnel termination or resignation, the security team coordinates with human resources to implement a standardized separation process to ensure that all accounts, credentials, and access of outgoing employees are reliably disabled.

3. Personnel Identity and Access Management

3.1 User Accounts and Authentication

Each individual having access to any Userback-controlled system does so via a G Suite user account denoting their system identity. Such user accounts are required to have a unique username, a unique strong password of at least 8 characters, and a two-factor authentication (2FA) mechanism.

Logging into Userback Systems

Logins by personnel may originate only from Userback-managed devices. Authentication is performed by Google’s account management system, details of which can be found at https://gsuite.google.com/security. Userback leverages G Suite’s facilities of detecting malicious authentication attempts. Repeated failed attempts to authenticate may result in the offending user account being locked or revoked.

Logging into Third Party Systems

Whenever available, third-party systems must be configured to delegate authentication to Userback’s G Suite account authentication system (described above) thereby consolidating authentication controls into a single user account system that is centrally managed by the security team.

When authentication to G Suite is not available, unique strong passwords must be created and stored in the Userback approved password management system. Passwords must be paired with two-factor/MFA authentication.

Revocation and Auditing of User Accounts

User accounts are revoked (that is, disabled but not deleted) immediately upon personnel separation.

Secure Workstations

All company pcs and laptops use encryption for storing any potentially sensitive data. All company pcs and laptops use anti-malware and antivirus software.

3.2 Access Management

Userback adheres to the principle of least privilege, and every action attempted by a user account is subject to access control checks.

Role-based Access Control

Userback employs a role-based access control (RBAC) model utilizing Google-supplied facilities such as organizational units, user accounts, user groups, and sharing controls.

Web Browsers and Extensions

Userback may require use of a specified web browser(s) for normal business use and for access to corporate data such as email. For certain specified roles such as software development and web design, job activities beyond those mentioned above necessitate the use of a variety of browsers, and these roles may do so as needed for those activities.

Any browser that is allowed to access corporate data such as email is subject to a whitelist-based restriction on which browser extensions can be installed.

Administrative Access

Access to administrative operations is strictly limited to security team members and further restricted still as a function of tenure and the principle of least privilege.

Regular Review

Access control policies are reviewed regularly with the goal of reducing or refining access whenever possible. Changes in job function by personnel trigger an access review as well.

Key Management

Userback maintains a strict policy for assigning and distributing keys which may access any production or development systems.

  • Access keys to the production servers are only distributed to CTO and Sys Admin Lead
  • Keys are never stored in any online system
  • Keys are never stored anywhere as plaintext
  • Individual access keys are generated per employee with developer only access

3.3 Termination

Upon termination of personnel, whether voluntary or involuntary, the security team will follow Userback’s personnel exit procedure, which includes revocation of the associated user account and reclamation of company-owned devices, and all other corporate equipment and property prior to the final day of employment.

4. Technology

4.1 Software Development

The security and development teams conduct code reviews and execute a static code analysis tool on every code commit. Reviewers shall check for compliance with Userback’s conventions and style, potential bugs, potential performance issues, and that the commit is bound to only its intended purpose.

Security reviews shall be conducted on every code commit to security-sensitive modules. Such modules include those that pertain directly to authentication, authorization, access control, auditing, and encryption.

The security and development teams shall establish and adhere to a formal software release process and production data is not used in the test or development environment.

4.2 Datacenter Security

We use a third-party, top-tier datacenter that maintains several industry-recognized certifications, including FedRAMP, ISO, SOC, PCI, and more.

Our hosting provider is also compliant with numerous regulations, privacy standards, and frameworks, including HIPAA, HITECH, GLBA, the EU Data Protection Directive, EU-US Privacy Shield, FISMA, and more than 30 others.

4.3 Third Party Services

For every third-party service or sub-processor that Userback adopts, the compliance team shall review the service and vendor, on an ongoing basis, to gain assurance that their security posture is consistent with Userback’s for the type and sensitivity of data the service will store or access.

Userback relies on Amazon Web Services to satisfy specific security controls related to the AWS data centers and AWS services. For more information on Physical and Environmental Security, as well as the Logical Access and Security controls for AWS services, please see the AWS Security

Information: https://aws.amazon.com/architecture/security-identity-compliance/

5. Data Classification and Processing

5.1 Data Classification

Userback maintains the following Data Confidentiality Levels:

  • Confidential – Information only available to specific roles within the organization. Data must be encrypted at rest and in transit. Access to data requires 2FA/MFA.
  • Restricted – Access restricted to specific roles within the organization and authorized third parties. Data must be encrypted at rest and in transit. Access to data requires 2FA/MFA.
  • Internal – Information is available to all employees and authorized third parties. Data must be encrypted at rest and in transit.
  • Public – Information is available to the public.

Data Confidentiality is determined by:

  • The value of the information, based on impacts identified during the risk assessment process.
  • Sensitivity and criticality of the information, based on the highest risk calculated for each data item during the risk assessment.
  • Policy, legal, regulatory, and contractual obligations.

5.2 Userback Employee Access to Customer Data

Userback employees may access Customer Data only under the following conditions.

  • From managed devices.
  • For the purpose of incident response, or customer support.
  • For no longer than is needed to fulfill the purpose of access.
  • In an auditable manner.
  • Customer Data is not used in development or test systems.
  • Product usage metadata may be utilized for analytics, performance monitoring, and service/feature improvement.

5.3 Customer Access

Userback provides web user interfaces (UIs), application programming interfaces (APIs), and data export facilities to provide customers access to their data.

5.4 Exceptional Cases

The security team in conjunction with executive management may approve emergency exceptions to any of the above rules, in response to security incidents, service outages, or significant changes to the Userback operating environment, when it is deemed that such exceptions will benefit and protect the security and mission of Userback, Userback customers, and visitors of Userback customers’ websites.

5.5 Data Encryption

All browser connections and communication is transmitted over HTTPS, ensuring data privacy and integrity. Our servers only support the highest level of encryption 256-bit cipher suites TLS 1.2 or TLS 1.3, protecting against unauthorized disclosure, modification, and replay attacks.

  • All non-essential ports and external network interfaces blocked by default
  • No financial data or credit information is stored in any Userback system
  • All account passwords are stored as one-way hashes
  • All account data is encrypted and securely stored in database

5.6 Data Retention

Each customer is responsible for the information they create, use, store, process and destroy.

On expiration of services, customers may instruct Userback to delete all customer data from Userback’s systems in accordance with applicable law as soon as reasonably practicable, unless applicable law or regulations require otherwise.

5.7 Data Sanitization and Secure Disposal

Userback uses Amazon Web Services for all infrastructure. AWS provides the following guidance regarding their data lifecycle policies:

Media storage devices used to store customer data are classified by AWS as Critical and treated accordingly, as high impact, throughout their life-cycles. AWS has exacting standards on how to install, service, and eventually destroy the devices when they are no longer useful. When a storage device has reached the end of its useful life, AWS decommissions media using techniques detailed in NIST 800-88. Media that stored customer data is not removed from AWS control until it has been securely decommissioned.

6. Vulnerability and Incident Management

6.1 Vulnerability Detection and Response

The Userback security and development teams shall use all of the following measures to detect vulnerabilities that may arise in Userback’s information systems.

  • Cross-checking vulnerability databases with all systems and software packages that support critical Userback services.
  • Code reviews on every security-sensitive code commit.
  • Vulnerability scanning on Userback services.

The Userback security team shall evaluate the severity of every detected vulnerability in terms of the likelihood and potential impact of an exploit, and shall develop mitigation strategies and schedules accordingly. Suitable mitigations include complete remediation or implementing compensating controls.

6.2. Incident Detection and Response

The Userback security team maintains an internal Incident Response Policy which contains steps for preparation, identification, containment, investigation, eradication, recovery, and follow-up/postmortem.

The Userback security team shall use all of the following measures to detect security incidents.

  • Continuous monitoring of AWS network traffic and workloads for malicious or unauthorized activities.
  • Continuous monitoring of logs to detect potentially malicious or unauthorized activity.
  • Conduct reviews on the causes of any service outages.
  • Respond to notices of potential incidents from employees, contractors, or external parties.

The Userback security team shall make a determination of whether every indicator is representative of an actual security incident. The severity, scope, and root cause of every incident shall be evaluated, and every incident shall be resolved in a manner and timeframe commensurate with the severity and scope.

In the event that a data breach affecting a customer has been detected, Userback will maintain communication with the customer about the severity, scope, root cause, and resolution of the breach.

7. Business Continuity and Disaster Recovery

7.1 Availability and Resiliency

Userback services shall be configured in such a manner so as to withstand long-term outages to individual servers, availability zones, and geographic regions. Userback infrastructure and data is replicated in multiple geographic regions to ensure this level of availability.

7.2 Disaster Recovery

Userback targets a Data Recovery Point Objective (RPO) of near-zero for at least 7 days, and up to 24 hours beyond 7 days.

Due to the distributed nature of Userback services, Recovery Time Objectives (RTO) are near-zero for geographic disasters. RTO for systemic disasters involving data recovery is targeted at 6 hours.

Userback tests backup and recovery processes on at least a monthly basis.

7.3 Business Continuity

Business Risk Assessment and Business Impact Analysis

Userback’s risk assessment committee will include business risk assessment and business impact analysis for each Key Business System that is used by the organization. The outcome of ongoing risk assessments will update or create recovery plans for Key Business Systems and update prioritization of systems compared to other key systems.

Distribution, Relocation, and Remote Work

Userback prioritizes policies, tools, and equipment which enables independent, distributed remote work for all staff if emergencies or disasters strike.

Notification and Communication

Userback has established internal communications using secure, distributed providers using industry standard security protocols. Staff and management will be notified via existing channels during any emergency event, or when any data recovery plan is initiated or deactivated.