Learn how Adaface's advanced IT security management helps protect your sensitive information from unauthorized access, phishing, data breaches, and new threats.VIEW SECURITY WHITEPAPER
Candidates can access the conversational assessments they are invited to from any modern browser. Each conversational assessment session has security settings and features that process and protect candidate's data while ensuring ease of access. All of these clients connect to secure servers to provide access to file sharing, code writing, compiling, and engaging with Adaface chatbot, Ada. Our chat infrastructure is comprised of the following components:
Metadata storage servers
Certain information about the conversation with the bot that is useful for creating a good user experience or considered as secondary elements in the overall conversation is called metadata. This metadata includes any files submitted by the user and proctoring information collected by our bot during the assessment. Dedicated storage services are deployed for different types of secondary data based on function and format. Storage servers with sync support and version history are deployed for relevant data like coding editors used during the chat.
Primary information about the chat is stored in a MySQL-backed database service and is sharded and replicated as needed to meet performance and high availability requirements. Primary conversation data acts as a single source of truth for every conversation with the bot and stores important assessment information helpful in administering the assessment and scoring the candidates' performance.
Organization information critical to conducting a chat - assessment data, customizations, settings, and information required for secure candidate authentication is stored in a MySQL-backed database service and is sharded and replicated as needed to meet performance and high availability requirements.
The Metadata servers are responsible for cleaning, processing, and serving secondary data collected during the assessment.
Our chat servers are built to automatically scale based on a surge of concurrent conversational assessments. They handle the logic, data processing, and data synchronization of all primary data collected during the assessment.
This is a separate service dedicated to supporting code compilers. Adaface conversational assessments support 30+ programming languages. To enable concurrent code execution and compilation functionality for candidates, our compiler services are kept on auto-scale infrastructure.
Dashboard/ App Infrastructure
Adaface recruiters can access their Adaface dashboard/ account at any time from the web and mobile clients, or through third-party applications connected to the Adaface application via our integration APIs. All of these clients connect to secure servers to provide access to the Adaface dashboard, access/ create/ edit Adaface test library, access/ create/ delete candidate invites, view candidate scorecards, and manage the candidate pipeline. Our dashboard infrastructure comprises of following components:
Metadata storage servers
Metadata/Secondary data collected from candidates during the conversational assessment is used by the Adaface application to generate scorecards. This metadata includes any files submitted by the user and proctoring information collected by our bot during the assessment. Dedicated storage services are deployed for different types of secondary data based on function and format.
Primary information about the chat is stored in a MySQL-backed database service and is sharded and replicated as needed to meet performance and high availability requirements. The stored assessment information is used to score the candidates' performance and report to the recruiters in real-time.
Organization information required for access management, storing purchased assessments, and administering the assessments are stored in a MySQL-backed database service and are sharded and replicated as needed to meet performance and high availability requirements.
Secondary app servers
Adaface secondary app servers are responsible for scheduling and running automated tasks and notifications. These sub-services are responsible for automating recruiters' workflow and are customizable. Automated tasks include monitoring conversational assessments and ending the unended sessions. They also take care of canceling unused invites so that recruiters can claim the credits and use them for more invites. Our dedicated notification sub-services are responsible for alerting recruiters and candidates via emails. This includes sending reminder emails for inactive candidates and custom test request email notifications.
Primary app servers
Adaface Primary app servers are built to automatically scale based on recruiters' usage. They handle the logic, data processing, and data synchronization of all organization data. They are responsible for authentication, customization, and accessing entire organization data. Security is built into multiple layers of our app servers ensuring that every action is logged and served only based on a user's roles and permissions.
Infrastructure: Behind the scenes
Our engineering team works continuously to innovate and implement secure practices in every layer of our applications. Here are some common segments:
Adaface production systems are housed at third-party subservice organization data centers and managed service providers located in the United States. These third-party service providers are responsible for the physical, environmental, and operational security controls at the boundaries of Adaface infrastructure. Adaface is responsible for the logical, network, and application security of our infrastructure housed at third-party data centers.
Adaface data at rest is encrypted using 256-bit Advanced Encryption Standard (AES). To protect data in transit between apps (currently API, or web) and our servers, Adaface uses Secure Sockets Layer (SSL)/Transport Layer Security (TLS) for data transfer, creating a secure tunnel protected by 128-bit or higher Advanced Encryption Standard (AES) encryption. Similarly, data in transit between an Adaface client (API, or web) and the hosted services is encrypted via SSL/TLS.
Adaface does certificate pinning in modern browsers that support the HTTP Public Key Pinning specification in most scenarios and implementations. Certificate pinning is an extra check to make sure that the service you’re connecting to is really who they say they are and not an imposter. We use it to guard against other ways that skilled hackers may try to spy on your activity.
Perfect forward secrecy
For endpoints we control and modern browsers, we use strong ciphers and support perfect forward secrecy. By implementing perfect forward secrecy, we’ve made it so our private SSL key can't be used to decrypt past Internet traffic. This adds extra protection to encrypted communications with Adaface, essentially disconnecting each session from all previous sessions. Additionally, on the web, we flag all authentication cookies as secure and enable HTTP Strict Transport Security (HSTS).
Adaface’s key management infrastructure is designed with operational, technical, and procedural security controls with very limited direct access to keys. Encryption key generation, exchange, and storage are distributed for decentralized processing.
Industry-accepted best practices and frameworks
Our security approach focuses on security governance, risk management and compliance. This includes encryption at rest and in transit, network security and server hardening, administrative access control, system monitoring, logging and alerting, and more.READ THE WHITE PAPER
We evaluated several of their competitors and found Adaface to be the most compelling. Great default library of questions that are designed to test for fit rather than memorization of algorithms.