Compliance

Policies, roles, configurations, data mappings - together they create sophisticated, but also very complex structure. First step in any compliance functionality is to bring visibility into those structures. And even a seemingly simple mechanism can provide enormous improvements. One such a mechanism is already planned for midPoint development: Object Collections and Views.

The idea of object collections may look simple, but there is unexpected strength in it. Object collections can be slightly extended to support simple compliance reporting. Simply speaking, the collection itself provides already a form of compliance reporting. E.g. even a simple filter can be used to show disabled users or active roles. If we add ability to use expressions in filters then this feature gets more interesting as we would be able to show all the users that are about to expire in next two weeks. If we add a bit of metadata (e.g. timestamp of last lifecycle transition) then the things may be get even more interesting, e.g. we can get ability to show all the roles in proposed lifecycle state that are stuck in this state for more than a month. Or we could show all the orphaned accounts that were detected in last 24 hours.

This will give us very basic compliance reporting. But this can be extended even further. We can extend object collection with the definition of the domain. In other words the collection may know what is the set of all the objects from which the collection is filtered out. For example the collection of disabled employees may know that it is in fact selected from list of all employees. Then the collection can evaluate percentages. For example, the disabled employees collection may show that there are 52 disabled employees, which is 2% of all employees.

The collections could be easily presented in user interface, like this:

This can be accompanied by a list of disabled employees, therefore an administrator can take action to remediate the situation.

This compliance reporting gets even more interesting when it is coupled with policy rules. When a policy rule is evaluated, a special-purpose policy situation property is set. The policy situation is set in every object or even every assignment for which the policy rule is triggered. Then the policy situation can be used to report on the result of policy rule evaluation.

For example, let’s assume that we are about to implement new segregation of duties (SoD) policy. However, we do not want to blindly roll out the policy, as existing role assignments may immediately be in violation and that may impact the business. Therefore we would like to know how many existing assignments are in violation of the policy. We may want to manually resolve the situation for each violation. But that may take some time, it may take days or even weeks. And we would like to monitor the progress. Therefore this is what we can do:

This is a very flexible mechanism as it relies on policy rules that are already quite flexible. E.g. several policy rules may use the same policy situation, therefore their effect may be evaluated together. E.g. several rules may work together to implement data protection policy and the progress of data protection implementation can be monitored by using a single collection. This is a first step to create complex, manageable policies that can be extended in the next steps.

First step is all about seeing a single compliance aspect in isolation. However, it is not enough to comply with just one regulation or recommendation. Information security landscape is far from being flat. The system should be kept in compliance with existing policies, while at the same time it should converge to be compliance to new policies, updated recommendation and business needs. This is a multi-dimensional space. Watching each compliance aspect in isolation is useful, but it would be much more useful to see them together in a form of compliance dashboard.

This is a configurable and partially customizable dashboard dedicated to compliance. It can be used to see many compliance aspects at the same time. Therefore compliance officer can see the state of the system at the first sight. Click on each dashboard widget will bring up detailed information about that specific aspect and any potential problem can be immediately acted upon.

Data collection, analysis and metrics are undoubtedly important. But the metrics themselves will not make anyone compliant. It is an appropriate action taken at appropriate moment that at the very heart of compliance. But an administrator must know that something is wrong before he can take the action. Dashboards are an excellent tool to get an overview. But administrators have better things to do than to sit all day in front of a screen and watch the dashboards. Therefore it is very important that midPoint notifies administrators in case that things go really wrong.

However, midPoint needs to know what "really wrong" means. We probably do not want to wake up an administrator in the middle of the night just because we have discovered an old disabled account. That can surely wait for the morning. But if there is an active orphaned account with superuser privileges - that may require immediate attention. What we need here is definition of conditions and thresholds that can describe various compliance situations. Action can then be associated with such situations. Mild violation could only change the color of associated dashboard widget. More serious violation could send out mail notification. And severe violation could raise a red alert.

Existing midPoint notification system can be reused and extended to send out the notifications. This may include mail notifications, mobile text messages (SMS) or any similar system.

Many compliance metrics are focused on roles, policies, organizations or other objects that are stored inside midPoint. And one can go quite a long way towards compliance by using this approach. But ultimately, it is not the policy that really matters. It is the reality. The policy and the user data may indicate that everything is in order. But midPoint has a strong connection with reality. Synchronization takes place almost all the time. And if we look around it is just a question of time when we discover something that is not all right. MidPoint can discover an orphaned account. Or we can discover that a crucial account that should be there was deleted. Or maybe this particular account has superuser privileges, but it does not any role that would justify that.

Some such situations are handled automatically by synchronization mechanism. Mappings can be used to correct attributes and privileges that are wrong. Privileges can be automatically revoked, accounts may be disabled. But midPoint relies on input data to make correct computation and they may be wrong or outdated. Therefore that particular account really needs superuser privileges, we just do not know about it. And it may not be the brightest idea to act blindly. This may be emergency situation and the privileges may be needed for disaster recovery purposes. Removing the privileges automatically or disabling an account may make the disaster significantly worse. Therefore it may be wiser to notify the administrator and ask for a decision.

This is in fact yet another part of compliance mechanisms. MidPoint synchronization routines discover policy violation - an object which does not comply with a policy. But instead of taking immediate action we will just record the incident - and maybe notify the administrators. The administrators can then take any action they deem appropriate in that specific situation.

MidPoint synchronization mechanisms were designed for extensibility. Therefore we can extend the set of synchronization actions to include compliance-related actions such as notification. We can also simply mark the violating shadow object with a specific policy situation marker. Therefore such object will be seen in compliance dashboards and an administrator can take manual action to remediate the situation.

Some situations are easy to detect by synchronization, for example new account or missing account. Those are big event that are "granular" enough to be detected at this stage. But there are more subtle situations that are more difficult to detect. Maybe an attribute values is wrong. Maybe the account is member of a group where it should not belong. Those events cannot be easily detected by synchronization which works with quite rough-grain events. But there are fine-grain in midPoint: recomputation of attributes values, application of roles, attribute-level reconciliation, processing of entitlements and so on. Those mechanisms can detect violations at a very fine level. However, the only action that midPoint cat take now is to fix the situation by automatically correcting the values. But this can be improved. There may be reactions that are similar to the synchronization reactions. But this kind of reactions may work on a much finer level. They can just record the situation and wait for manual action. Or they can do something even smarter - which leads us to remediation.

Most organizations are perfectly fine with compliance dashboard and on-line compliance reports. But some organizations require more formalities. Maybe a pretty, human-readable and printable report on the progress of data protection compliance is needed to be sent out every week.

MidPoint already has reporting features that can be used to create similar reports. However, reusability of current reporting features for the purposes of compliance reporting is quite limited. It is possible, but it is very likely that a heavy customization of the reporting mechanism may be needed to create nice compliance report. But this can be improved. We can create reporting templates that are tailored especially for the purposes of compliance reporting. This is likely to require new functions in midPoint reporting components, but those functions can be created. MidPoint should be fully capable of creating camera-ready printable compliance reports.

Compliance features are without any doubt necessary. And they will make an excellent extension of existing midPoint features. But we do not plan to stop there. Compliance features can be used to find policy violations and to act on them to remediate the situation. However, such actions may still not be entirely easy to do manually without any assistance. Fortunately, midPoint could provide such assistance. We plan to implement features that could significantly improve remediation process. We consider this to be a natural extension of compliance features.

Please see Remediation page for more details.