CSG servers sits between your business applications and your existing hardware security modules (HSMs). A central policy file determines which crypto operations each application can perform and identifies the correct key to use. Applications connect to CSG through one of the supported APIs and CSG distributes crypto requests across all the available HSMs.
The policy acts like a firewall, preventing applications from performing any crypto operations that are not specifically allowed. It also specifies security properties, such as mode of operation, padding, key algorithm and key length - exactly the sort of data that security and audit teams need access to (and control over). Application keys are managed by CKMS, which pushes approved keys across the network to the CSG HSMs.
Modern HSMs are immensely powerful, but many of them sit almost idle because of the difficulty in securely sharing HSMs between different business applications. Thanks to CSG, you can fully utilize these expensive resources.
CSG produces signed audit logs that capture every crypto operation and administrative changes performed by the system. In addition to making demonstrating compliance a breeze, this detailed data capture can also allow itemized billing of crypto usage.
System uptime and performance were of utmost consideration during the design of CSG. HSMs can be added and removed from the platform without any down-time, allowing for maintenance or scaling activities to be performed while production applications continue running. Similarly, a correctly configured CSG cluster can be upgraded without interrupting service. Crypto tasks are distributed between all available HSMs, regardless of vendor.
CSG provides detailed monitoring data, accessible from the administration client or via a web service. This data allows operators to monitor the status of the system and react to changes in demand before they affect production service.
CSG allows security teams to regain control of crypto and reduce the risk of attack. CSG uses a central policy file in a similar way to a set of firewall rules - unless something is explicitly allowed it's forbidden. Security teams can grant applications just enough privilege to complete their necessary functions.
The policy file is also the place where security parameters are configured. Each permitted crypto operations is restricted to a certain mode of operation, padding, key algorithm, key-size and so on. It's much easier to audit these settings when they reside in one location. Additionally, the security team can make sweeping changes to these parameters without touching the affected applications at all.
Crypto Query Language (CQL) is the primary interface to CSG and enables developers to rapidly integrate applications. Compared to APIs such as PKCS #11, CQL has no learning curve and delegates all security decisions (including key selection) to the CSG policy file. CQL can be used from Java, .NET and C/C++ or through CSG’s RESTful API. An example of an encryption command is shown below:
DO ENCRYPT FROM App TO Database WITH DATA 57FD01A… Each developer will be given a welcome pack that describes which CSG servers to connect to and which commands they have access to. Templates for welcome packs are supplied with CSG.
CSG integrates seamlessly with Cryptomathic Key Management System (CKMS) for management of application keys - throughout their entire life cycle. CKMS operators define and approve keys that will be used by CSG applications and push them automatically over the network to all CSG servers in the cluster. For more information on the benefits of using CKMS, including information on compliance, auditing and work-flow improvements, see CKMS™.
At the leading edge of security provision within its key markets, Cryptomathic closely supports its global customer base with many multinationals as longstanding clients.