Security at ID123

Protecting your data is our priority

Data security is our top priority. We take myriad security measures to ensure that our customer’s data is secure and safe. We have also implemented security measures to prevent fraud and flag abuse of digital ID cards issued through our software. In the spirit of transparency, here are some of the security measures we take to protect the data we store and the services we provide.

Data Security

Security Frameworks

We strive to follow industry best practices when it comes to security and compliance using frameworks and guidelines such as OWASP, NIST, CIS, and CSA.

OWASP

OWASP

Open Web Application Security standards and best practices

NIST

NIST

Cybersecurity Framework

CIS

CIS

Center for Internet Security

Certifications

Our systems governing the management, storage, and protection of information have been verified by third-party audits.

Certification

Badge

Certification

Links

UAF BMG Logo

ISO/IEC 27001:2022

Business Operations

We understand that formal procedures, controls, and well-defined responsibilities ensure continued data security and integrity. We have clear change management processes, monitoring and logging procedures, and various policies which have been set up to ensure operational security. All employees and contractors are provided with security awareness training and confirm they have read and understood our information security policies. We take appropriate disciplinary action against employees who violate our policies. Employees are required to report any observed policy violations or suspicious activities. We require all employees to use strong, unique passwords for company accounts, and to set up two-factor authentication with each device and service where available. Employees are required to encrypt local hard drives and enable screen locking for device security. We maintain an inventory of all information systems used in the course of our business. Only authorized and licensed software products are allowed to be installed by employees on these information systems.

Confidential information may be accessed only by select authorized employees. A subset of our employees has access to production system administrative interfaces and to customer data. By providing access to a subset of employees we are able to offer effective customer support, troubleshoot potential problems, and ensure data security. Access to administrative interfaces is logged and any changes made to settings or data is also logged. Employees are granted access to systems and data based on their role and geography. Each employee’s role-based permissions are reviewed regularly.

Business Continuity

We have a business continuity plan in place that is tested and updated at least annually. Our operations do not have a dependency on a physical office and therefore we can securely offer all services remotely in the event of a natural disaster or pandemic.

Security Operations

Continuous improvements are carried out by conducting security architecture reviews. We contract external security consultants who perform manual penetration tests of new features before each release. These tests are always conducted in a separate environment with no actual customer data present.

Our security operations tasks include:

Weekly vulnerability scans

Activity Log Monitoring

Anomaly detection

Intrusion Detection System

Open Port Monitoring

Brute Force Protection

Network Operations

All access to application infrastructure is restricted to a subset of our network engineering staff. Our software development team does not have access to production infrastructure. Changes to the application, infrastructure, and deployment processes are documented extensively as part of an internal change control process. Each change is reviewed to be compliant with our internal policies.

Access to our production infrastructure utilizes SSH and requires use of a VPN connection

We require a multi-factor authentication mechanism to be utilized

Audit logs are generated for each remote user session

Customers are not allowed direct access to any of the underlying application infrastructure or logs

Monitoring & Notifications

We use several services to automatically monitor both infrastructure and application uptime and availability.

In the case of downtime or emergencies key employees receive:

  • Automatic emails
  • Slack messages
  • SMS notifications

Hosting Infrastructure

Our application infrastructure and data are hosted in Amazon Web Services (“AWS”). Their data centers have been thoroughly tested for security, availability, and business continuity. For more details, please read the AWS Security White paper. AWS uses commercially reasonable efforts to ensure a minimum of 99.95% uptime and maintain a minimum of N+1 redundancy to power, network, and HVAC services. Our infrastructure configuration with AWS is designed to ensure redundancy and seamless failover over and above their 99.95%. The server instances and databases are designed with a goal to prevent single points of failure and automated failover. This design enables uninterrupted operations while limiting both scheduled and unscheduled downtime. We maintain server and database instances in various geographic regions in order to enable our customers to comply with data protection and transfer regulations.

Region Name Geographic Partition Data Center
Africa Logical AWS US Virginia
Asia Logical AWS US Virginia
Australia/Oceania Physical AWS Australia Sydney 
Europe Physical AWS Europe Frankfurt
India Logical AWS US Virginia
Latin America Logical AWS US Virginia
Middle East Logical AWS US Virginia
North America (CA) Physical AWS Canada Montreal
North America (US) Physical AWS US Virginia
United Kingdom Logical AWS Europe Frankfurt

Encrypting Data

Encrypting Data in Transit

All HTTP traffic to our production environment runs over a TLS-encrypted connection and we only accept web traffic on secure port. During a web browser’s first site visit, we send a Strict Transport Security Header (HSTS) to the user agent that ensures that all future requests should be made via HTTPS even if a link to the service is specified as HTTP. Cookies are also set with a secure flag.

Encrypting Data at Rest, Database

Our backend utilizes both SQL and NoSQL databases to persist data. All data stored at rest is encrypted using the industry-standard AES-256 algorithm and associated keys are stored in a Key Management System (KMS). Database versions are patched regularly to ensure the most secure and stable version is in production.

Encrypting Data at Rest, Files

Static files, such as images and other documents are persisted in AWS S3 private storage. All static files are encrypted by AWS S3 before they’re stored.

Backups and Recovery

Our backup and replication strategy is designed to ensure redundancy and fail-over protections in the case of a significant infrastructure failure. Our data is backed up and replicated across multiple availability zones. Each regional production database is designed to replicate data between no less than 1 primary and 1 secondary database within the same region but in a different availability zone. All databases are backed up and maintained using industry-standard methods. The primary database will automatically failover to the secondary replica within minutes should an outage occur. All database backups are maintained in the same data region as the primary database. Daily database snapshots are backed up to persistent storage and retained for 30 days or less.

System and Application log files are rotated regularly and consolidated in secure, encrypted, private archive storage where a lifecycle policy is applied which automatically purges the log data after predefined intervals based on its classification. System and Application log files are deleted within 60 days. Log files that are generated with the purpose of monitoring our own internal controls are maintained for 12 months.

Network Firewall

We leverage an network firewall to block DDoS attacks and other network-related intrusions. Other technical measures that have been implemented for security include Virtual Private Cloud (VPC) implementations, security group assignments, and traditional firewall rules.

Development Operations

Development

We use different environments for development, staging, and production. Access to each environment is strictly managed, based on the principles of least privilege. Deployments to production servers are performed only by trusted and authorized engineers and follow documented change management procedures. Post-deployment monitoring is done by a dedicated team that monitors the application for defects and suspicious activity.

Code Review

Our development team follows secure coding standards to ensure our products are developed with security as a top consideration. We perform manual code reviews of changes to sensitive areas of our codebase. We also subscribe to a third-party service that performs an automated static security code analysis daily on development code to proactively detect potentially known vulnerabilities before reaching production.

Included

Quality Assurance

Our quality assurance process subjects all application updates to a thorough security validation check in addition to functional and regression testing. The goal of the security validation process is to discover and remediate vulnerabilities in the application before it reaches production. An update to the application is not approved for deployment until all testing is completed by quality assurance engineers and the security validation has been conducted.

Vulnerability Disclosure

We invite anyone to notify us of issues they might find in our application to further strengthen and secure our platform. All vulnerability report submissions are read within hours of receipt, and we aim to respond to all submissions within 48 hours. You can email your concerns to security@id123.io.

Multi-Tenant Design

ID123 uses a multi-tenant / multi-geographic region data model to host all web service applications and data. Each geographic region is serviced from a virtual private cloud (“VPC”) and each institution tenant is uniquely identified by an Institution ID within that geographic region. A global table of institutions directs the mobile application to the appropriate geographic region based on the location of the card-issuing institution. The IDMS and API are engineered to ensure that they only access data for the authenticated institution that is making the request based on the Institution ID. The mobile application is engineered so that authenticated app users and their authenticated devices are uniquely identified by both a user token and device token. By authenticating both the user token and device token on each request we ensure no app user has access to another user’s data and that the data is only sent to an authenticated device. While we manage the security of our application and our customer’s data, the provisioning and access management of individual accounts is at the discretion of individual institutions.

Data Retention & Deletion

Custom Data Retention Policies

When an institution’s IDMS account is deleted, access to the account will immediately cease. All account data is deleted within the next 24 hours with the exception of accounting information, card data, and card templates. Card templates are set to private and all digital ID cards are archived. Accounting information is maintained in the account to generate a final invoice, if applicable. All card templates and archived card data are deleted 30 days from the institution’s account deletion request. The IDMS offers many data export options that our customers must use to export a backup of their data before the account is deleted.

When an app user account is deleted, the app user’s access to the account will stop immediately. All data provided by the app user to us, as well as associations to any institutionally issued ID cards will be deleted in less than 24hrs unless the user account has been flagged for potential fraud. Any app user account flagged for fraud will be deleted once an investigation is complete and the flag is removed.

Role-Based Access Control

Role-Based Access Control

We support role-based access control with four main roles preconfigured in the system, Owner, Manager, User, and Restricted for IDMS Admins. Additional custom roles can be created and assigned to IDMS admins in order to provide additional privileges. Upon an account’s creation, only the account owner has access to all the account’s functionality, including the ability to create new IDMS admins and manage existing admins. The account owner may optionally grant administrative control to another role to manage IDMS admins and their permissions. By default, only the account owner and appointed managers can create card records and issue card invitations. As an additional security measure, administrators can access admin activity logs that provide a history of administrative activities that take place within the IDMS. Admins can view the type of action performed, the admin who performed the action, and the date the action took place.

Password Policy and Storage

During an IDMS login creation or password update for an IDMS Admin user, we require a strong password that contains the following, 8 characters or more, at least one number, and special character as well as a lower and uppercase letter. We do not store the actual passwords: we only store one-way encrypted hashes. If an IDMS Admin user incorrectly enters an account password on multiple attempts, the account will be temporarily locked to prevent brute-force attacks. To further protect account access, two-factor authentication is available and can be turned on in the institution’s account settings. Following an email change, password change, or similar sensitive user account changes occur, the user is always notified in order to quickly be able to respond, should an account attack be undergoing.

During mobile app registration by an app user, we do not ask for a password. We authenticate with a one-time password sent to the user’s email address. After registration, a user can add a locally stored PIN code for added security or use the device’s built-in biometrics to secure the application. There are multiple ways an app user can authenticate themselves when adding a card. They can use a unique identifier + security question or they can use Single Sign-On to authenticate themselves with their identity provider.

Request Throttling
& Captcha

Our API employs IP whitelisting and request throttling based on predefined security limits per account. All log-in web pages are limited to a certain number of attempts before they are locked for a short period of time. Additionally, many forms that are not authenticated for login have “Captchas” which prevent brute-force submissions.

XSS and CSRF Protection

To prevent Cross-Site Scripting attacks (XSS) all output is per default escaped before hitting the browser potentially causing XSS attacks. To prevent Cross-Site Request Forgery (CSRF) attacks each page generates a random CSRF token. Additionally, ID123 has implemented the Content Security Policy (CSP) HTTP header that whitelists which assets (javascript, images, stylesheets, etc.) the user’s browser should allow to load and execute. A correctly implemented CSP-header effectively eliminates any malicious javascript (XSS attacks), specially crafted files covered up as images, and similar attacks based on the browser’s trust of the served assets.

Security Policies

Information Security

Governing principles for the secure operation and management of the information technology used and/or maintained by us and for the protection of our information assets.

Network Security

Installation policies, ownership and configuration management standards of server and network resources that we operate.

Physical Security

Our standards for the safety of our physical computer systems as well as other physical resources on company premises.

Data Destruction

The standard for the controlled disposal and destruction of media storing confidential data when it is no longer necessary for business use.

Network Usage

Responsibilities of the users of our network to prevent unauthorized access, and respect the rights of other information resource users.

Incident Response

Ensures that, in the event of a security incident, parties affected are informed and we will take the proper action to assess and resolve the situation.

Vendor Access Policy

Vendor access procedures for our information resources, vendor responsibilities, and protection of customer information.

Secure Software Development Policy

Standards for the development of software that is intended to be operated within or interact with the production environment.

Internal Password Policy

Enforces the password security of accounts, both local and cloud-based, used by our employees.

IT Risk Assessment Policy

Our policies and procedures for the purpose of determining areas of vulnerability, and to initiate appropriate remediation.

Acceptable Use Policy

Protects our employees and customers and outlines the acceptable use of our computer equipment, software and network.

Change Management Policy

Our change management procedures for planned upgrades, maintenance, or fine-tuning of our software, network or information resources.

Red Flag Policy

Applies to all of our employees and subcontractors who are involved in handling information that can be used to identify a specific person in connection with a Covered Account.

Patch Management Policy

Applies to all of our employees and subcontractors who are involved in handling information that can be used to identify a specific person in connection with a Covered Account.

Workstation Security Policy

Policy governing Workstations issued by the company used at our facilities or while working from home.

Report Suspected Identity Theft

If you suspect identity theft has occurred within our mobile application, please fill out this form. In addition, please contact the institution who issued you the ID card and report the suspected identity theft. The institution will be able to disable your compromised credential.