Frequently Asked Questions
Yes, you can use Access Controls
Yes, you can use Roles
iconik has been assessed by external auditors that have CISSP, OSCP, CEH, PCIP, ISO, CISA, CISM, certifications and following methodologies and standards that include NIST SP800-115, PTES, OWASP and Offensive Security. It was concluded that an unauthorized person cannot penetrate the system, and iconik's security mechanisms are state-of-the-art and effective.
Ultimately it's the customer's responsibility to make sure that any file that is uploaded to iconik is free and safe from viruses and malware.
The Audit logs are for internal use, in the event of a problem please contact email@example.com otherwise for security reasons we will not release the audit or any other logs of the system.
We stored salted hashes of passwords using PBKDF2.
Each customer in iconik is assigned a unique id called
This ID is used to partition the database and almost all database tables have the
system_domain_id as part of their partition key.
This means that database queries can only return data from one customer at a time which decreases the risk of us introducing bugs where we return data for the wrong customer.
Enforcement of this
system_domain_id check is performed in the iconik API gateway service which is the central component all incoming API calls pass through (see iconik Microservices
for a description of the iconik Microservices archtecture) .
Media files which are stored in iconik's storage buckets are likewise stored per
Media files which are stored on your own buckets remain within your control and are not stored together with other customer's media.
Yes, we run a formal Bug Bounty program through our partner Inspectiv. If you have discovered an issue with the iconik system itself, any of our auxiliary systems, or our public website then we ask you to contact firstname.lastname@example.org and report the issue.
Access to the backend resources are limited to a small number of employees with access to the Google Cloud Platform Console Project that we are running the production system on. All support entitled personnel are required to use two factor authentication for their Google Cloud accounts.
iconik testing environments and other environments are separated from the main production environments by accounts, location, complete network isolation and access control.
All data in iconik is encrypted at REST and destruction of encryption keys is a fundemental method of ensuring data is made unrecoverable. When an asset is deleted it is first placed in the recycle bin for a period which by default is 24 hours. After that the asset is deleted from the system which means the media files, proxies and keyframes are deleted using the cloud storage provider's APIs. This will cause the cloud storage provider to delete the files from their object storage and also purge any encryption keys from the KMS. If you use your own storages, please consult the vendor for more detailed information.
Data in iconik's databases are encrypted using Full Disk Encryption and individual records are not encrypted separately. Data in our Cassandra databases is deleted using a "tombstone" marker which marks the data as deleted on disk but does not actually remove the data from disk. The actual delete from disk happens when a process called Repair is run, which happens once every 7 days. At this point the database files are rewritten and any deleted data is purged. When a database file is purged the underlying data doesn't actually get overwritten immediately so it is possible for a determined forensic analyst to retrieve data from the underlying storage system until it has been overwritten, which at our write rates normally takes another few days. We do not currently have any mechanism for securely purging an individual customer's data securely from our database servers.