Main Page by Topic
CTRM System Security
This page shares some thoughts and considerations with regard to Security for CTRM Systems.
1) Types of Security
2) Read and/or Write
3) Considerations for CTRM Systems.
1) Types of Security
1.1) Login security. Typically a username and password.
1.1.1) Support for SSO (Single Sign On).
1.1.2) Allowing multiple people to log in with the same username/password at the same time? Or not? E.g., for a shared support login.
1.2) Functional level security
Idea is that everything you can do in the system should have a corresponding security.
For example, might have a security privilege to allow for a user to create a new counterparty.
1.3) Trade Book level security
Have special security per user for access, read or write, to certain
a) Trade Books (a.k.a., Portfolios)
b) And/or different Trading Desks (a.k.a., internal business units)
To clarify, a user would need both a functional level security, e.g., ‘Trade Booking’ as well as write access to a particular Trade Book to be able to enter a trade (a.k.a., book a trade) to a particular trade book.
For example, may want to have security around each Trade Status that a user can process a trade to in terms of deal entry lifecycle. This example may be considered a subset of the ‘Functional Level Security’ topic above. Idea is that some things may need a special setup or screen or a finer level of detail than you might use for the generic functional level security objects.
2) Read and/or Write
2.1) Firms may want a special user type for read only. This may be partially for easy of setup, i.e., have one place where you can specify that a user can look at things, but not make updates.
2.2) When creating the security model, i.e., designing how it will work, try to be consistent for having separate read and write where appropriate. E.g., especially for trades, where some users will need to be able to read/view trades, e.g., the confirmations group, but shouldn’t as a general rule be entering in or updating trades.
3) Considerations for CTRM Systems
3.1) Have ‘hooks’ so firms can add their own extra types of functional level security.
3.2) If you have a menu item that is controlled by a security privilege, e.g., ‘save counterparty’, you always want to show it and make it active, whether or not the user has security.
If it is hidden or grayed out to make it inactive, they won’t know what security privilege they need to make it active.
If you keep it active, if a user selects it, they should get a message telling them that they don’t have the security needed, and give the precise name and/or ID number of the needed security.
3.3) For security failures, i.e., when a user tries something that they are not allowed to do, that should be logged.
This can help the support team. For example, suppose a user tried the example above, which was to select the ‘Save Counterparty’ menu item, which they found was blocked. If they reach out to their support, the support person can just check the log and see what the needed security privilege is.
Why is this helpful? Users are not necessarily trained in being complete, clear, and precise when reaching out to support. They may not have taken the time to note the security block message produced by the system.
3.4) For when the system checks security, even when it passes for a user, should have an ability to write to a log what security was checked. This is the reverse of the above. This is useful/needed to help firms figure out which security privilege would need to be removed to block certain functionality from certain users.
3.5) For any API calls made by custom-developed processes, they should also call the appropriate security for the user, for API calls that are made where they are for a given user.
3.6) Will want to have a ‘super user’ type privilege or privileges, e.g., ‘read all trades for all portfolios’ that you can give to server type users or ‘users’ who run end of day processes.
3.7) On the topic of documentation:
For a large CTRM system with many different functional areas, there could be hundreds or more security privileges. Documenting these can be a challenge, as many of them require specialized or a working level of knowledge just to understand what and where the security privilege can impact things.
It isn’t necessarily a good thing to have too much documentation on each specific functional level security, as you can make the assumption/requirement that people reading the security privilege documentation are already generally familiar with the system area, which would be covered in another document.
3.8) Since there may be 100s of functional level security privileges, it can be a big maintenance job to have to assign them to each user individually. So one approach is to great sets/groups of privileges that be assigned to users. E.g., privileges would be assigned to a group and users would get/be assigned one or more of those groups, so as to get the functional level security for the collected items in that group.
Introduction to CTRM
Click on this link for a great introduction to CTRM software: Introduction to CTRM Software