What are the requirements for enterprise event security?

In a SOA, to be effective, we need to share both data and events.  Events, as I have discussed before, are the messages that applications send to the common infrastructure to inform subscribers that well-understood business events have occurred.  This includes things like "a sale was made" and "a product was shipped."  It may also include things like "an employee has ceased working for the company."

The last example above, an employee quits or is fired, is interesting.  From the employee's standpoint, it may be a private event.  If they were fired, it may be quite embarrassing, not something they want broadcast.  On the other hand, from the viewpoint of the company, it could be of very high importance that the applications in IT be immediately notified of the employee's dismissal, so that all permissions can be revoked, and workflow processes involving that person can be redirected to another person or team to accomplish.

Revocation of credentials: we've got Active Directory.   That one is fairly straight forward for a Microsoft-based IT team.

Changing workflow: most folks screw this up.  I've seen my share of workflows.  It is rare, to say the least, to find a workflow system where the business told IT to prepare for the day when their employees would be fired.  Mature systems usually add the event handling somewhere... sometimes it is entirely manual, occasionally requiring a data support analyst to write a SQL Query to reassign tasks from one person to another. That's a mess.

So clearly, we need to share the firing of an employee as a broadcast event in the IT infrastructure.  The question is this: do we secure it?

The ramifications of placing security models in an EAI space are oddly different than similar situations in an application.  If an app knows that Joe can access Contoso's sales record but Mary cannot, then Mary doesn't see it. Pretty simple.  However, the app knows.  We, as developers, can still build in referential integrity around the fact that the sale was made.  By extension, if an event occurs in another system, this system may need to know about it, even if NONE of the users of this system need to be informed about it.

It may sound striking, but when you look at it, it makes sense.  Applications have their own identitiy, and their own security.  They are full actors in the system.  An app can see an event.  In fact, I would say that all apps that support the enterprise security model should be allowed to subscribe to ANY event. 

Of course, I said the key words: apps that support the enterprise security model.  What does that mean?  That means that there is a way for an event to either carry security in the event message or in the subscription process, so that the apps that subscribe to the event respect the right of the enterprise to control who, among the human population, can see the event.  It's a little like saying that the app has signed the corporate NDA and will respect the wishes of the company to keep some data secure, even from its own users.

In other words, it is OK to allow our apps to see things that we, as human users, cannot see.  Certainly, the support analysts will need the right to investigate exceptions and find data errors.  Other than exception handling and auditing, it is entirely reasonable to restrict events to be viewed by the app, but none of the users of the app.

So, how do we correctly share and manage event security?  That is the question I'd like to answer.

If you know of a good answer, please drop me a link.  I'm investigating two avenues:

1. Including the security policy in the event message itself, and/or
2. Including the security policy in the subscription, so that the subscriber has a consistent policy to follow for all events.

If you know of a good answer to this question, please share it.

Comments

• Anonymous
  July 18, 2007
  i would think that your 2nd avenue (Including the security policy in the subscription) would be the avenue to follow with any special exceptions written into the subscriber

• Anonymous
  July 19, 2007
  This is a great question Nick and one which I think about to help solve the SOA needs of a SaaS service. Although very complicated to influence and organization toward, the 'trusted subsystem' technique is the way to go to have federated identity and enable an integrated role and rule-based access. And the means to get there is a Secure Token Service (STS) which solves how this can be done to securely communicate between application partitions. The delegation approach is also an option although the thinking at the moment is that STS, in a green-fields situation, is the prefered method if acheivable in your organization. Of course, in an enterprise environment, we work with disparate systems with variations of technologies vendors, COTS packages, legacy applications, etc. So, you cannot rule out the credential cache method. There's plenty of info on MSDN regarding STS, but here's a great MSDN article which describes what I'm talking about. http://msdn2.microsoft.com/en-us/architecture/bb417064.aspx

• Anonymous
  July 19, 2007
  Also, here's a great blog entry by Matias on the topic http://staff.southworks.net/blogs/matiaswoloski/archive/2007/03/10/The-holly-grail-of-Enterprise-SOA-security.aspx

• Anonymous
  July 19, 2007
  @Gabriel, Good response, Gabriel.  This a good description of STS.  The problem is that the scenario described, both in your response an in the blog entry you posted to, is a situation where the caller is aware of the fact that he is calling the provider, and the provider specifically grants permission to the caller to call him. Not the case with a publish-subscribe model, and that is what we use for events.  In this model, there are no humans involved, and therefore, their credentials are not useful.  It's all app-to-app.  In addition, the event messages are specifically One-to-Many, and the subscriber app does not know (and should not need to know) the publisher app.  The subscriber would need to trust the infrastructure that sends it the event message.   Two ways I can see using STS to solve this:

1. When an app subscribes to a message, it also must grant access to a particular role that the publishers of that event have already agreed to transmit under.  This creates a form of coupling and is an example of mechanism 2 (above).
2. There can be a standard set of roles that the senders of all events can use, depending on the classification of the security that should be applied to the event.  All these roles are members of a single group.  All subscribers allow messages from any member of that group using STS.  Depending on the SAML claim, we can allow specific type of application behavior in the subscribing system when the event is collected.  This is an example of mechanism 1 (above). I'm liking the idea of a standard set of roles.

• Anonymous
  August 06, 2007
  Sure, the security holes are the big big troubles for each organization. How may cases we know involving some admin or any kind of person responsible for working with sensitive or secured information deliberately leaving the holes in the firm farm so that they're able to access it if they are fired. I don't know if I answer your question about "how do we correctly share and manage event security?", but I'll just share some info I now know as I spent months trying to develop something similar myself and didn't have much luck. You know, I am talking about auditing. After several guesses/trials/talks to colleagues we decided that the core entity we should pay attention to is our Active Directory info. We have a distributed network and a huge set of administrators each holding the responsibility to a dedicated part of AD info. If not deliberately, then caused by a human factor there's a real probability that information may leak. In fact we had an incident with the sensible info leaked by mistakenly left changes that were made by one of the administrators that left our team in a while. We had no ability to track that for ourselves then and it is the great deal of luck that the admin was so kind to inform us about this problem. So we started searching for a solution that can be implemented in such a large organization as ours and found Active Administrator, a tool from Scriptlogic. We liked how they organized the Active Directory security management and auditing there. Here's <a href="http://www.scriptlogic.com/active-directory-auditing.asp">the example</a> shown on their site. The fact that they store the collected info on the SQL database excellently showed the advances of putting the event management onto a system capable of working in a domain environment and strong enough to stand under the load made by the network with thousands of computers. In other words, that's great that it's possible to monitor the security objects and audit changes to a particular attributes having them logged into a DB. Being compared to a standard way where it is needed to handle each particular event log of a particular remote computer separately, this approach is far more easy manageable for an admin like me.

• Anonymous
  August 07, 2007
  The comment has been removed