Security and Centercode

Due to the highly-confidential nature of customer testing, Centercode has taken measures to secure all data contained within our customers’ Centercode Platform Implementations.

This page outlines security features of the Centercode Platform itself, including standard and optional features available to Centercode Platform customers. This page also provides a brief overview of the network infrastructure driving the Centercode Platform and of our standard operational practices for maintaining the Centercode Platform.

Is my data encrypted in transit?
Yes. All connections between the Centercode Platform Implementation and the client connection are always encrypted with TLS 1.2 and 2048-bit encryption keys.

Is my data encrypted at rest?
Yes. We encrypt all web servers, database servers, uploaded files, and backup files at rest using AES 256 and we rotate the keys annually.

Can I supply my own certificates for encryption?
Yes. If your implementation is using a custom domain, we will work with your team to create a new certificate for that domain.

Do you have a firewall to protect your application?
Yes. We utilize multiple layers to protect the application. We have a Web Application Firewall (WAF) at the forefront to block any standard attacks. We utilize AWS security groups that white list specific traffic to the servers based on where that traffic is coming from.

Does Centercode think about security as part of its software development lifecycle?
We start with secure development training for our teams. In addition, we have code reviews throughout the development process. We then utilize automated static and dynamic scanning for each build that will be released into production.

How is my data safe from being accessed by other implementations?
We have both shared and dedicated cloud-based environments available to our customers. The Platform server resources are shared between all customers within the shared environment, but the database and uploaded files are segregated by implementation. The Platform server resources, database and uploaded files are all kept separate within a dedicated environment.

How do you physically protect my data?
The Centercode Platform runs on Amazon Web Services cloud servers. Its production systems are located in a high-security facility in an AWS data center, with a Backup infrastructure is located in a different highly-secure AWS data center. AWS data centers are secure by design, and their controls make that possible. AWS data centers are designed in consideration of potential threats. AWS implements and tests its internal controls to ensure that the systems, technology, and people it deploys counteract potential risks. General information regarding AWS data centers and the audits and certifications held by these data centers can be found at aws.amazon.com.

Can you detect potential threats against the network?
We manage a host-based intrusion detection system (HIDS) on each server. We also log all access into our network so that we can monitor for any inconsistent behavior and react accordingly.

Do your employees/contractors have access to my data?
We have strict requirements on what access each employee/contractor has, which we determine on a “need-to-have” basis. We then regularly re-evaluate which employees/contractors still require access. In addition, we limit environments to the job roles that specifically require access to production servers and data.

Do you conduct background checks on your employees/contractors?
Yes. All Centercode employees and independent contractors are required to successfully pass a background check.

Are your employees/contractors subject to confidentiality obligations that cover my data?
Yes. All Centercode employees and independent contractors are required to execute confidentiality agreements that extend to customer data.

Access to the Centercode Platform is granted via a proprietary login and authentication engine. Each User creates a unique username and password.

Login Details:

• Password complexity standards default to an eight-character minimum with alpha and numeric requirements and prohibits using other identity fields (username, email, first name, or last name). The criteria for passwords can be configured to match policies set by a customer’s Community Manager (via a custom regular expressions string).
• The customer can also optionally (via an Enterprise Edition subscription) integrate the customer’s own supported single sign-on (SSO) system (such as SAML or OAuth 2) with the customer’s Implementation in instances where the customer’s single sign-on system supports two-factor authentication, this feature can then be extended to the customer’s Implementation.
• Passwords are stored in encrypted form (AES/128 bit) using a hash of the User’s complete login credentials.
• Passwords cannot be retrieved or viewed by anyone, including Centercode.
• By default, a User may attempt three invalid password attempts before the User’s account is locked for a short period of time (mitigating against brute force/dictionary hacks).
• Any changes to a User’s basic profile will email the User to inform the User of the change, raising the User’s awareness to any unauthorized changes.

Password Retrieval Security:

• Passwords may not be retrieved (and are never sent) via email.
• Passwords may only be reset using the site and its secured connection.
• Password reset emails send a one-time-use link.

‍

All Centercode Platform access is through a TLS-secured web interface, using the most current version of HTTPS/TLS. This interface ensures that all data (including login and feedback information) is encrypted when being sent between the web client and Centercode Platform servers. This level of security is designed to prevent rogue users “sniffing” internet IP packets from acquiring meaningful data. This is required for all customers, whether the customer uses a *.centercode.com domain or supplies a custom domain.

TLS Implementation Details:

• 256 Bit TLS Encryption is utilized.
• Non-secure links (http://) are automatically redirected to TLS equivalents (https://).

The Centercode Platform includes a powerful Role-based access engine, allowing Manager-level individuals to define access to an enormous array of Resources and data at two primary Scopes:

1. Community Scope – Each Implementation includes a single named Community.
2. Project Scope – Each Implementation includes Projects within the single Community.

The following are a few of the common areas within the Centercode Platform with Role-based access control:

• Community Administration
• Community User and Team Administration
• Community Reporting
• Community Forms (User Profiles, Test Platforms, Surveys)
• Community Content
• Project Administration
• Project User Administration
• Project Feedback Types
• Project Versions, Builds, and Patches
• Project Content
• Project Tools (e.g. Knowledge Base, Reporting, Email Tools)

The Centercode Platform’s Role engine offers the ability to present Users with highly customized experiences tailored specifically to meet their needs and responsibilities. Upon login (validation of username and password), a User is given access only to the resources that have been granted.

Role- and Team-Based Security Details:

• Teams exist on two distinct Scopes (Community, Project)
• Teams are identified by Team Type, which both restricts and enforces access to specific Roles (e.g., ensuring Managers can always access administrative functionality; ensuring Participants cannot access inappropriate administrative functionality)
• Every Project has its own set of dynamic Roles and Teams
• Project Teams and Roles may be standardized and built into Project Templates
• Any number of Teams can be created
• Users may belong to multiple Teams
• Teams can include any number of the Implementation’s Users

The Centercode Platform uses a per-page-based security scheme so that each User has only the appropriate level of access (if at all) to any page they attempt to access. This scheme is used when both linking to and moving throughout the site. As a User moves from page to page, User security access is checked prior to loading every individual page. This ensures that Users attempting to access unauthorized pages (for instance, by changing values in the URL) will not succeed. Every action taken within the Centercode Platform is logged as a page hit within the User’s session.

The Centercode Platform always follows proper authentication, no matter how the user was linked to the Implementation. This allows for our customers to use external linking (for instance, inserting a link to the Implementation in an automated email message or using a browser bookmark), while ensuring that proper authentication will be followed when a user follows the link.

In order to download files hosted on the Centercode Platform, a User must have been granted the appropriate Role-based privileges. The Centercode Platform employs two levels of file security throughout the application. Most areas of the application default to using Secure level for file security, while key areas (such as Release Management) are allowed to be designated as Not Secure. This allows the Manager flexibility to determine what level of download security is appropriate.

Secure
Secure requires a User to be logged in, but the file link can be bookmarked or copied for later access. The download and User attempting download are logged. Some download managers are supported.

Not Secure
The lowest of the file download types allows sharing of file download links with both Users and non-Users of the application. This security type is most like a typical Internet upload; however, the download attempt is logged via IP address and associated with an anonymous user. Because a login is not required, most download managers are supported.

Common to all download types, direct file paths are never distributed via the Centercode Platform. Instead, links are provided through a secure file proxy, where individual User access is verified prior to serving any file.

Details on File Downloads:

• An additional level of security may be added by encrypting files prior to uploading them to the Centercode Platform.
• Users are granted access to individual files based on standard Centercode Platform Roles.

All unique identifiers that are visible use 16-byte GUIDs (Globally Unique Identifiers). This further ensures that changing form or url values will not result in access to unauthorized data and that Users have no ability to “guess” at values.

GUID Example: 0DB3B55F-AF79-4524-BC4C-32D554696D28

Note that this is an additional level of protection over the Centercode Platform’s standard page-based security. In the event that a User guesses a valid ID string, the standard security scheme would cross check User authorization on that new page, denying access when appropriate.

The Centercode Platform is designed to ensure that non-managers are not able to enter functional HTML or JavaScript of any kind, which would result in uncontrolled scripted actions. This is designed to prevent URL, form, and data manipulation.

Managers, however, are given the ability to enter functional HTML or JavaScript, which allows the Manager to further personalize the Centercode Platform. This ability is only available in the Manager-only areas. For example, a Manager can add JavaScript to each page to track activity within an external tool such as Google Analytics. A Manager can also add HTML to many Resources, allowing them to customize the Centercode Platform and ensure a uniform look and feel throughout the Centercode Platform. A Manager will not, however, be able to add HTML to forms submitted outside of the Manager-only areas.

CSRF attacks are designed to ‘trick’ an unwitting User into performing a malicious, mischievous, insecure, or destructive action.

The Centercode Platform architectural standards include methods to mitigate the potential damage these attacks could inflict, including the Centercode Platform’s use of a token-based approach to CSRF validation designed to ensure that the User is communicating with the intended person (e.g., tests utilizing that person’s secure http-only cookies, that person’s session, and if applicable, that person’s form post body). The Centercode Platform employs data-handling rules that align with these validation practices as a part of secure development practices.

Every Implementation utilizes its own distinct database. In addition, data entered into the Implementation is transported through strictly controlled pathways that manage the flow of this data from end to end. This mechanism ensures that information associated with one Implementation is not inadvertently associated with any other Implementation.

Maintaining the integrity and security of files that are uploaded to the Centercode Platform is just as important as maintaining the integrity and security of other information within the application. All uploaded files are stored in separate folder paths that are dedicated to one specific Implementation. This ensures the files are not inadvertently associated with any other Implementation.

In addition to the standard levels of security used throughout the Centercode Platform, additional passwords may be required on a team-by-team basis at both Community and Project levels. This allows Community or Project Managers to offer an additional level of protection for specific teams that may have access to highly sensitive information or tools.

For example, a Project Manager could require an additional password upon entry into a Project by anyone internal to the company (such as engineers and product developers).

Centercode’s Notice engine may be used to present Users with and/or obtain their agreement to specific information. This includes items such as privacy notices, confidentiality agreements, and other legal agreements like Participant terms. The Notice engine can be used to help Users understand their obligations and responsibilities, and to put Users on notice of the customer’s privacy practices. The customer’s use of the Notice engine helps reduce the chance that Users will act irresponsibly or be surprised by any aspect of their relationship with the customer. These Notices are shown to the Users prior to gaining access to the Community and/or any Project, as determined by the Manager.

Block Notices are notifications used to communicate to Users that they are unable to go further into a Community or Project.

The Enterprise Edition of the Centercode Platform references a database of IP locations that the customer can then set by country or individual IP address to block (or allow) devices coming in from those IP addresses. The customer can use this filtering at the Community and/or Project Scopes level to block (or allow) access accordingly.

The Centercode Platform runs on Amazon Web Services cloud servers, with production systems located in a high-security facility in an AWS data center and backup infrastructure is located in a different highly-secure AWS data center. AWS data centers are secure by design and their controls make that possible. AWS data centers are designed in consideration of potential threats. AWS implements and tests its internal controls to ensure that the systems, technology, and people it deploys counteracts potential risks. General information regarding AWS data centers and the audits and certifications held by these data centers can be found at aws.amazon.com.

Traffic on all but essential ports are filtered out prior to connection to any server and/or service. Traffic is consistently monitored with automatic reporting, notifying Centercode staff of any potentially suspicious entry attempts.

The Centercode Platform utilizes Microsoft SQL Server 2016 SP2 for all database functionality. The rules set on our firewall prohibit direct access to the database by systems that are not physically located on our network. Database servers are locked down using Microsoft standard MS SQL Server security hardening practices adopted by Centercode. The database servers utilize AES-256 encryption at rest.

The Centercode Platform runs on Microsoft Windows 2016 Server, using Microsoft Internet Information Server 10.0 that has been finely tuned and optimized for the Centercode Platform. Web servers are locked down using various security hardening practices adopted by Centercode, and are shielded by strict rules put in place at the firewall. The web servers utilize AES-256 encryption at rest.

The health of every Centercode Platform Implementation is automatically monitored. Anomalies are immediately reported to Network Operations and Centercode personnel for appropriate action. This is achieved using customized Cloudwatch reports and proprietary profiling tools, developed by Centercode specifically to monitor the health of the Centercode Platform.

Additionally, each server’s individual resources are monitored so that we can know when these resources are in danger of becoming inadequate for their given activity level.

The following defines our standard operational practices for maintaining the Centercode Platform.

Database data is backed up locally every 24 hours. Complete backups (files and database) are backed up off-site daily. Backups are retained for 30 days. Backups are encrypted in transit using TLS and backup data is encrypted at rest using AES-256.

The Centercode Platform is designed to maintain a record of all activity that occurs within the application. Should a breach be identified, we will be able to reconstruct the actions that led to the event.

Every page load that occurs within the Centercode Platform is recorded with each User’s session and can be matched with web server logs to provide further details of the path a User account followed through the application. Every administrative action is tagged with the date, time, and User account that affected a change. Every email message that is sent from the application is tagged and logged within the Centercode Platform. Logs are maintained for at least ninety (90) days.

We utilize a host-based intrusion detection system (HIDS), which is an intrusion detection system that is capable of monitoring and analyzing the internals of a computing system, as well as the network packets on its network interfaces.

A WAF is a web application firewall that helps protect web applications against common web exploits that could affect application availability, compromise security, or consume excessive resources. A WAF gives web applications control over which traffic to allow or block by defining customizable web security rules. Centercode uses WAF to create custom rules that block common attack patterns, such as SQL injection or cross-site scripting, as well as rules specific to our application. New rules can be deployed within minutes, allowing us to respond quickly to changing traffic patterns.

Scheduled maintenance are tested in a staging environment prior to introducing it to any Centercode Platform production environment. We thoroughly test each Centercode Platform patch before live deployment.

We back up all data prior to any major server update, allowing for lossless recovery in the event of any maintenance failure. We notify our customers via email prior to any scheduled maintenance.

Centercode Platform updates, such as bug fixes and incremental version releases, are pre-scheduled and handled with the same methodologies and timeframes as scheduled maintenance (see above).

Measures are taken to log, test, and approve material changes to production systems, including:

• Testing and approval of critical/material application changes prior to implementation into production
• Restriction of access for migrating changes into production environments to appropriate individuals
• Regular review of critical changes to confirm appropriateness and authorization
• Local deployment of scheduled maintenance, patches, and material application changes in the test environment prior to being introduced to the production environment
• Customer notification prior to scheduled maintenance or updates
• Backup of all data on servers hosting production systems prior to major updates

We perform vulnerability scans of our networks at least annually and at any time a major change is made to a hosted site that could introduce vulnerabilities. Our scans include looking for:

• Vulnerabilities that allow a remote hacker to control or access sensitive data on a system
• Misconfiguration (e.g., open mail relay, missing patches)
• Default passwords, a few common passwords, and blank/absent passwords
• Denials of service against the TCP/IP stack by using mangled packets
  

We engage a third party to perform a network penetration test on an annual cadence that provides Centercode with a simulated experience of an adversarial attack against our platform and business with an outcome that enables Centercode to remediate vulnerabilities, strengthen security posture and reduce risk .

We are willing to make appropriate arrangements for individual customers to test our security infrastructure via their own resources or using an outsourced security firm. This is a scheduled event, which takes place apart from our primary network and therefore does not affect live implementations.

Centercode is committed to ensuring the safety and security of our customers. We aim to foster an open partnership with the security community, and we recognize that the work the community does is important in continuing to ensure safety and security for all of our customers. We have developed a policy to both reflect our corporate values and to uphold our responsibility to good-faith security researchers that are providing us with their expertise. Read the Centercode Responsible Disclosure Policy in full here.