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.
Open Web Application Security standards and best practices
Center for Internet Security
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.
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.
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
Intrusion Detection System
Open Port Monitoring
Brute Force Protection
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
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||Logical||AWS US Virginia|
|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||Physical||AWS Europe Frankfurt|
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.
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.
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.
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.
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.
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 firstname.lastname@example.org.
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
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
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.
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