|
|
|
|
Main
Page by Topic |
||
|
C. Statistics |
||
CTRM
System Security
This page
shares some thoughts and considerations with regard to Security for CTRM
Systems.
Outline
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.
Considerations include:
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.
1.4) Other
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