At the foundation of any SIF deployment is a Zone Integration Server (ZIS). It is software, the invisible courier that reliably delivers information from one source to one or more destinations. Not blindly, but aware of the information objects that are of interest to the various applications, aware of what they're privileged to send and receive, and aware of the security requirements of each application's connections. Translating this awareness into enforced policies, it provides secure and reliable message broker services.
ZIServer is Visual Software's Zone Integration Server, built for today's needs and tomorrow's growth. Built using Microsoft's .NET 3.5 Platform, LINQ and SQL Server, it is designed for flexibility, performance, scalability, auditability, manageability and security.
ZIServer is the only Zone Integration Server available to offer true high-availability capabilities in every sense. In both our Standard and Enterprise models, we offer configurations that allow our customers to set up their environments with full redundancy for both the database services and web components. We also support a remote disaster recover center model where the ZIServer implementation is split across two data centers in different cities for locations that may be prone to flooding or other natural challenges.
For more on high-availability ZIServer configurations, see "ZIServer at the Enterprise Level".
Visual Software has always been at the forefront of the push to make sure that any private information stays private and that people who have the responsibility of safeguarding privacy rights are given the tools they need to adequately do their job.
Our work in this area began when we started investigating the differences between US and UK data privacy laws and made changes to our internal corporate policies and software to comply with them.
For example, in the US, the StudentPersonal object has an element named "NeglectedDelinquent". Since it is in the StudentPersonal object, all applications subscribing to that object would receive the StudentPersonal, complete with the NeglectedDelinquent status. We would need to trust that all the receiving applications that did not need that information would be responsible enough to receive then properly discard this information. Many feel uncomfortable with it going there in the first place.
Other information in the StudentPersonal SIF object that people might feel uncomfortable having distributed to a wide audience might include:
First, we define for each object a list of the elements that are questionable for each object (like the one mentioned above). (We don't include elements like BirthDate or FirstName for two reasons: we don't want to require the administrator to look past all of the elements that will never be selected and we want ZIServer to be able to process these filters quickly.)
Then, when you are assigning permissions to agents in ZIServer, if an agent is subscribing to an object that has restrictable elements, the object name shows up in the list as a hyperlink (as in this screen shot):
(Click on the thumbnail to see a full sized screen)
When you click on the object name, you are shown the list of restrictable elements. Here you get to choose which elements' values will never make it to this agent.
So, for a single message being sent to ZIServer, there may be several different versions distributed to subscribing agents. This is because the filters are set up for each subscriber independently.
For example, information that may be appropriate to send to a nurse's office application may not be appropriate to send to a library application, so the two may be configured differently.
(Click on the thumbnail to see a full sized screen)
Having several versions of the same message is unusual - excellent for security and privacy protection, but unusual. For this reason, ZIServer audits what it does. For each variation of a message it creates, it creates an audit copy and logs it. Furthermore, for all versions of ZIServer that support full auditing (Standard and above), the audit database is maintained separately so that it can be kept on a separate secure server.
(Click on the thumbnail to see a full sized screen)
Visual Software has been able to make these changes without compromising compatibility with any existing agents. It is compatible with US versions 1.5r1, 2.*, and the UK version 1.1. ZIServer's default configuration (without any filtering) is the same as the standard SIF definition.
If your ZIS is used to pass information for vertical reporting, you can use this feature to guarantee that only the information you want leaves your server - you now control who sees what information, down to the element level.
In
the UK, the Becta organization has published a series of guidelines for schools that outline solid principles for data handling. In these guidelines, they specify two roles within a school
with data responsibilities:
Senior Information Risk Officer (SIRO): this is typically the head teacher (principal); the person who sets policy and has overall responsibility for information risk management.
Information Risk Owners (IAO): these would typically be department heads such as assessment records, medical information and special educational needs data.
Since the people with the ultimate responsibility for the security and privacy of the school's data are typically not the same people with the IT background or the access to the SIF configuration tools, we have created a set of tools designed especially for them. These tools allow them to:
See how security has been set up for the agents that affect the data they over which they have responsibility.
Search audits in case of emergency using a simple interface and be able to drill down to the detailed information that was passed between applications, see when it was moved and look through error logs at any time.
An example of the screen that allows a SIRO to look through security settings for agents he or she manages is as follows:
(Click on the image to see a full sized screen)
In this example,
The SIRO could have been managing several zones, one is selected from a dropdown list at the top.
In that zone, there are several agents he or she for which he or she has responsibility; the ProviderUK agent has been selected. The display shows that this agent is registered HTTP (not HTTPS), auditing is turned on, it is providing 26 objects and is not subscribing to any objects.
In the next section, it shows each of the objects along with a description of those objects. It also shows if element-level filtering is set for any of the objects.
In ZIServer, we allow users to keep track of security impact levels for each SIF element or attribute. These are defined separately from the SIF specification and show here as advice to the school personnel. In the bottom section of the screen, we show each element of the object, the corresponding impact level and whether or not the element has been set up for element-level filtering.
In the following example, we see a sample audit search screen that a SIRO may see:
(Click on the image to see a full sized screen)
At the top of the screen is the area where the search criteria is entered. The user may search past SIF traffic using date ranges, agent names, object names or anything that might appear in the message itself. The search will bring back a list of messages that meet the criteria as well as any error messages that were generated that might meet the same criteria.
On seeing this list of messages, the user can see the message details by clicking on the message summary, causing a window to be created with the original details in it.
For more details on ZIServer or the Security and Auditing tools, give us a call at the number below or ask us to give you a call by sending us a request through our Contact Us page.