Security: What is the most secure architecture for BPC RiskManager?

From RiskWiki

Jump to: navigation, search


Access Rights

With respect to access security we support trusted login, AD, LDAP, NT Groups, and internally managed methods for user access rights at the application server layer.

Database Acess

Only the application server accesses the database. There is no direct user to database connection ever established (even in report generation), consequently only one access login account is required between the database layer and the application server and there is no need to establish (or desirability in establishing) access rights for a user at the database level.

Browser Plugin & Network Communictions

RiskManager Browser and Non-Browser Clients

The browser based and non browser versions of the Risk Manager client face the same issues and use the same models for network communications. The browser merely hosts a plug-in component (think flash player, or adobe pdf reader) and is essentially used for distribution of that component. Once the plug-in starts it establishes a direct connection to the application server on a different port than that used for normal web communications (which may or may not also be a web server – i.e.. The web server that delivers the base page can use any security model you prefer – and the application server(s) can be on any physical server you desire – not necessarily the same machine as the web server).

The data stream is not a linear ascii data stream like a web page system but a stream of binary delta (change) packets which are essentially unusable out of the context of their stream and the non-delta (change) packets that are not re-transmitted in any case. On a private network this would generally be sufficient, in all but the most extreme scenarios.

The stream itself can also be separately encrypted, our preferred model where additional security is required is that the entire channel is encrypted through a Vitrual Proviate Network (VPN) tunnel (which can be defined to operate on a single port if desired) because these are generally more secure and faster than data-level encryption as they can be imposed at the hardware level. The RiskManager access model is STATEFULL so security models that allow for preservation of state across access are appropriate (hence VPN tunnels are a really good idea).

With respect to VPN solutions, either a fully fledged VPN (ideally hardware implemented for speed) should be used an the entire traffic between client and server tunnelled there-through, or HTTPS (SSL) can be used directly from the client to a dedicated (supplied) listener on the server, however in this latter case you will have to install an SSL certificate on the IIS server running in the application server and use the HTTPSrvr dll instead of (or in addition to) the SocketServer.

Built in to the RiskManager client / application server architecture are three models for communications:

  • Proprietary port using raw TCP/IP (This is the default method)
  • HTTP


Where the survey manager module is used as part of the risk management process, this system uses conventional pure html web pages and will happily utilize secure socket layer or VPN tunnels as desired and appropriate to the location of survey page recipients.

The module is hosted on an IIS web server (any version) and any security model appropriate to web site technology is appropriate for use in this context. The server side of the surveymanager system is 100% STATELESS – so each page transaction is independent of any preceding or following transaction and hence the security model adopted does not even have to allow for preservation of session context across succeeding page submissions – except that common sense dictates that you would at least want the browser to be able to negotiate a login session across succeeding web pages with the web server if only to avoid the inconvenience of the user logging in with each page submitted.

The survey manager is used to deliver and collect compliance information and a variety of other data (such as risk or cause property information). Certificates, secure-socket layer, windows authentication, LDAP, etc access security models as well as no security with anonymous http access are all appropriate and acceptable. In terms of access (rather than data confidentiality), in addition to any access model adopted to log in to a the webserver, the survey engine uses a random key associated with the user ID to confirm the right-of access to the specific web page being served. The user does not need to know this key and it is delivered with the page invitation – so merely knowing the user id does not grant access to a survey. Login based security for respondents (to the extent this is desired) is expected to be handled by the web server / operating system, however there are also dedicated question types that will deliver a login page as part of a survey if that is preferred. In addition there are a variety of special field encryption mechanisms that can be turned on on a user, page, survey, survey instance, organisation, or database level.

Survey manager web pages are never stored as pages, but dynamically generated on the fly based on the user, the organization, the survey, a variety of context and user specific filters and keys, the responses to previous questions or other surveys, internally stored rules and a variety of other factors. All of this is stored in the SM/RM database and only graphical and page layout elements are actually stored on the web server itself (and even these can be stored in the database) – so a surveymanager website can consist of just the surveymanager dll and a single javascript library if necessary. The database accessed by the surveymanager library is determined by the library name (used as a key in the server registry), so again the user never establishes a direct page level connection to the underlying database.


CopyRight Bishop Phillips Consulting Pty Ltd 1997-2012 ( Security: What is the most secure architecture for BPC RiskManager? )
Personal tools