Controlling business processes with Cibet

I want to draw attention to the general aspect of controlling which is an important issue in many applications from security relevant areas.

Consider a mission-critical application that manages sensible data and processes. The application is run by operators who manipulate data and execute business processes with great care. However, they are all human beings and human beings are buggy by default and make mistakes (the application of cause has been developed by the best IT specialists and thoroughly tested, so it will never fail :-) ).
Typos when entering data, lack of information, communication problems can all lead to false and corrupt data in the system, erroneously executed business processes, even to inadvertent deletion of sensible data. A customer complains after two months that his address was another since and the dunning letter never arrived. Could you restore the data of that point in time and proof what messages you have sent out to what address?

These are the problem areas the Cibet Control framework addresses. Trust is good, Control Is BETter. With Cibet framework it is very easy to add various control mechanisms into a JPA and/or EJB based application. The actual version includes control schemes like:

Archiving: Manipulation of domain objects, data and execution of business processes are archived. The state of domain objects whether newly created, updated or deleted is archived together with metadata like time and id of the user who initiated the action. When a business process is executed, the context parameters and the result are archived with the metadata. From the archived state, domain objects could be reconstructed and business processes could be re-invoked with the same parameters at any time.
The archive entries are secured against manipulation to make them audit-proof and revision safe. It is not possible to silently modify existing archives or to delete or add archive records without detection by Cibet control.

Four-eyes principle: This scheme is an example for a dual control mechanism: A user wants to perform some critical data manipulation or business process. With an applied dual control mechanism the action is not executed in the productive system directly but stored and postponed. A second user must check the data and the action and can approve or decline. Only when the second user approves, the data manipulation or business process is executed in the productive system, otherwise it is discarded.

Six-eyes principle: An even stricter example for a dual control mechanism is the six-eyes principle. In this case a third user must approve a data manipulation or business process before it will get productive. Like in four-eyes principle rules are applied which define which user is allowed to release and reject and what happens on a release.

Cibet framework provides a plugin mechanism which allows adding own control schemes apart from the built-in ones. If for example the approving user in a four-eyes process should have a special role or should be member of some special user group, this can be easily implemented.

The best of all: The Cibet control functionality can be added to an application in a most non-intrusive manner. Even existing applications could be controlled by Cibet with only a few code changes. For the basic functionality only three or four lines of code are necessary.

An example application can be downloaded from the website that demonstrates the integration of Cibet and its functionalities. With this application the purchase department of a perfumery can manage their purchases. Suppliers and orders can be created and suppliers can be modified or removed.

Check it out! Cibet framework can be downloaded from sourceforge or from the project homepage.