Article posted: Jan 11, 2019
Q&A with Dan Isaaman, Dot Origin Co-Founder & Technology Director
For the latest installment of our partner and customer Q&A blog series, we spoke with Dan Isaaman, Co-Founder and Technology Director of Guildford, UK-based Dot Origin Ltd. Dot Origin, founded in 1997, is a leading distributor and developer of products and solutions that use smartcards and other hardware-based security technologies for applications including physical security, logical (IT/network) security, PKI, encryption, loyalty, process automation, payment, transport and many others. Dot Origin, which also has offices in the U.S., has direct relationships with many manufacturers and software vendors in the security industry including Versasec, ACS, Gemalto, G&D, HID, Identiv, MULTOS, NXP, and Thales, and it stocks, sells and supports their products through a network of resellers and sales channels. Our discussion with Dan focused on smartcards.
1. As a company that offers many security solutions, why are you so keen on smartcards as a two-factor authentication method?
Unlike most other two-factor cybersecurity approaches, the use of a smartcard for logon (and optionally also for digital signing and encryption of documents and emails) provides a really secure and effective defense against many types of attack, as well as concrete proof that a specific person has undertaken those tasks. The solution is based on well-established PKI technology and principles, and relies on processes and procedures to ensure that a card is issued to a specific person, at which point that person carries around the only copy of their private key. Their key is held in a secure environment that prevents it from ever being exposed or used without their knowledge, since they must also enter a PIN or passcode each time it is used. If the PKI is well constructed then this proof is valid even in a court of law, and this is a major reason why large enterprises often select smartcards as their identity and access tokens.
2. What advice do you give your customers about their use of smartcards?
A great benefit is that smartcards can also be used for photo-ID, building access and other applications such as enterprise print management. This way, the card becomes an important part of everyday life within an organization. We advise our customers that their staff must be trained to treat smartcards with care, equal to how they treat their PCs and other issued equipment, and to keep their cards in rigid badge holders for protection. Ideally, whatever process that would apply to replace a lost or broken laptop or other essential hardware item, should equally apply to their smartcards, while implementing physical access using the same card ensures that it will not be forgotten at home or left plugged into a workstation!
3. Lots of companies have offices around the world, so what's the process you recommend for them in terms of their smartcards?
Generally, main offices with suitable HR or IT staff should be responsible for issuing smartcards to their local employees as part of a documented on-boarding process, which can be managed nicely by the Versasec CMS software. For quickly issuing replacement cards to users at remote satellite offices, as opposed to individual remote workers, we recommend keeping a few spare smartcards on site, and setting up an issuance facility/kiosk of some kind. That could mean a separate PC running the vSEC:CMS self-service client, and/or a nominated vSEC:CMS operator token with rights to issue only emergency credentials, for example. Depending on roles and responsibilities within the organization, this could be operated remotely by the IT helpdesk, or by a local employee.
4. You mentioned that the 'lost or stolen' process for satellite offices versus individual remote workers differs. How should these individual workers be addressed?
Managing security for individual workers who do not often visit an office can be challenging. We have tested the use of a TPM-based virtual smartcard for backup purposes, but this does not work well in an offline scenario. We believe that the most practical fallback option is to provide these users with emergency username/password access, until a replacement smartcard can be issued. This can be implemented by setting long and complex passwords on the user accounts, ensuring that these are cached locally, and only advising the details when needed. However, it must be pointed out that this provides a security risk compared with disabling password access completely, as is more common with smartcard deployments. As usual, it is a matter of balancing security against convenience. But in our book, security always comes first!