For a credential to be trusted it must have been issued by a trustworthy system, there is no value in an end user having a credential stating they are ‘Sam Jones’ if the system that issues it is insecure, in other words the trust you can place in a credential is directly proportional to the trust you can place in the system that issued the credential.
This is why security is the primary factor to consider when choosing a Credential Management System (CMS). A secure CMS must have the capability to permit authorised individuals to carry out their functions, but ensure that the system itself is resilient to attack and misuse from unauthorised individuals. This goes beyond merely securing the individual system components and must encompass the ability to secure the entire end to end process of issuing and managing the lifecycle of credentials. An essential part of this is ensuring that system operators are strongly authenticated before functions can be carried out and that all operations are fully audited.
Security requirements of a CMS can be split between technical features and operational features:
CMS technical security requirements:
- The CMS should support the use of strong PKI-based authentication to access it, ideally for logon and performing operations, to ensure any security operations are carried out by authorised operators or end users.
- Data traffic should be encrypted for privacy (e.g. SSL / IPsec) and to ensure it has not been tampered with between any client and server components
- Data traffic should be resistant to replay attacks (e.g. by use of server generated task IDs) to ensure a network packet cannot be reused at a later date to perform an unapproved operation (e.g. approval of a card issuance)
- Authentication between system components should be in place (e.g. signed and encrypted data exchange) to ensure data traffic is not altered (e.g. to alter the name of the user the credentials are being requested for)
- Any sensitive data (e.g. card unlock codes) should be stored encrypted in the database
- Any API calls should require pre-defined security levels
- The system should support a firewall friendly 3-tier server deployment ensuring application server and database are protected from external attack
- HSMs (Hardware Security Modules) should be used to secure cryptographic processing (e.g. creating secure channels to a smart card) and ensure any, master keys are not exportable
- A CMS should support built-in key management processes, including a key ceremony for secure private key injection onto HSM with full auditing
- A full central audit trail of operator actions and system events should be held in a single central database regardless of the number of servers deployed
- Ideally the CMS should have passed security testing by multiple third parties external to the software vendor
CMS operational security requirements:
- The CMS should implement role-based access controls to ensure operators can only use functions they are authorised to use
- The CMS should use group controls, to ensure operators can only manage users they are authorised to
- The CMS should be capable of implementing role separation to ensure different individuals must carry out each stage of the request and issuance process (the ‘two pairs of eyes’ principle)
- The CMS should support multiple secure means of authenticating users for self-service recovery operations
- Operations recorded in the audit trail should be easily searchable for both investigative and management information, ideally by reports, enquiry or API.
- If smart card printing is required this should be built-in, allowing a combination of electronic and graphical personalisation to occur in a single audited process
How can MyID help?
MyID® secures millions of identities across the world, for large organisations, governments, enterprises, military and police forces, enabling citizens, personnel and employees secure, seamless access to business critical data, systems and networks.
Our credential management system enables organisations to interoperate across multiple software and hardware. Whether you are looking for issue and manage millions of smart cards or smart phones and the PKI technology in between.
We have a number of use cases which detail how MyID help large organisations, governments and enterprises with a MyID credential management system.
A multi-country European bank uses a combination of role based access control and group controls to enable delegated operations, with in-country operators able to issue cards and a global help desk team supporting multiple countries with card unlock services
As US federal government agency uses the 3-tier server deployment capability to deploy only specific CMS functions over the internet; enabling remote office locations to self-collect credentials without exposing unnecessary features over a public network
Customer use customer specific keys to lock cards in transit from the card manufacturer which MyID then swaps out for customer specific keys at issuance. This ensure cards have a secure end to end delivery path and cannot be tampered with prior to issuance utilising MyID’s HSM and built-in key management capabilities
For a managed service, the two pairs of eyes principle is used to enable administrators to create operators and operators to create end users, ensuring a single administrator alone cannot fraudulently issue any credentials
Want to know more – complete the demo request form today.