Do you remember the term BAM? BAM is an acronym for Business Activity Monitoring. It was a hype topic in the early 2000′s. And then we didn’t hear that much anymore about this topic. Yes, there are several vendors out there, providing different types of solutions. And like always, there are several vendors who claim to be the leaders in the category of BAM.

When BAM became a hot topic some 10 years ago, the implementations were nothing else than a little advanced analytics. That was, at that point of time, far away from my expectations which were around intelligent, automated, real-time and ex-post analysis of relevant activities in business systems and the identification of critical changes which require intervention. For sure automated reactions as well as alerting should be part of this.

The term BAM came to my attention again when talking with MetricStream recently. MetricStream is one of the leading-edge vendors in the GRC market. They are one of the “Enterprise GRC” vendors (Business GRC would be the better term). But in contrast to many others, they allow for a tight integration with IT systems and IT controls. Based on that, they are able to use automated controls of virtually any type and map this into their system. That in fact allows to integrate what I had expected from BAM years before with a holistic GRC approach. By the way: MetricStream has a pretty high rank on my list of GRC vendors…

When looking at the BAM market I have to admit that there has been evolution since the early years of BAM. There is much more automation than pure analytics, there are several interesting solutions out there. However, MetricStream is somewhat unique with enabling this (without talking about BAM) in the context of Business GRC and thus allowing to add this as a generic approach into what every organization has to do today: Building a GRC infrastructure, with manual and automated controls – where automated controls should provide what BAM has been promising.

I assume that several of you have another opinion – so I’m looking forward for your comments.

EIC 2010 has ended. And like each year, there are some interesting observations. I’ll take three of them:

1. The “classical” IAM topics like provisioning or E-SSO are well understood now – and extended.
2. Federation becomes reality.
3. The cloud impacts IAM – and vice versa.

Topics like provisioning and E-SSO were discussed mainly in the many “Best Practice” sessions. There are many implementations out there. Several of them use MSSPs (Managed Security Service Providers) or other Saas-/Cloud style types of deployment. And they are increasingly integrated with other IT infrastructure elements like the ITIL tools or portals. There is an evolution towards more integrated approaches and thus more architecture options, and it is obvious that the cloud starts to impact this as well. In the area of E-SSO, trends towards more versatility and integration with for example strong authentication technologies as well as the emerging topic of convergence (physical/logical) were the most important ones discussed at EIC.

Federation is becoming reality. It isn’t hype anymore – which is a good sign. Interestingly, the federation sessions I’ve attended at EIC as a panelist or speaker were fully packed – a difference to last year. The value of federation is understood – now it is about implementation.

With the separate Cloud Computing track and the parallel Cloud 2010 Conference we had this year, there was as well a lot of attention on Cloud Computing topics. These sessions were as well crowded. The most important topic was the relationship between the Cloud and IAM/GRC. There were many interesting, though provocing sessions and many practical views, beyond the hype towards the real thing: How can we make the Cloud more secure? And how can we do IAM/GRC in the cloud for internal and external environments? And there were valid answers, not only questions. It was sort of “The Cloud brought down to Earth”…

I’ll blog about many of these aspects more in detail over the course of the next weeks.

I’ve done several webinars around changing architectures for Identity Provisioning and Access Governance during the last few months. And new architectural approaches for Provisioning have been an important topic at the EIC for years. I’ve also written a report on Access Governance architectures recently. That is no surprise. Provisioning has to integrate with IT Service Management in some way. It has to support the standard systems where automation is key as well as other systems which either don’t support automation interfaces (unfortunately there are several apps out there which don’t provide integration points, including several important healthcare apps) or where automation is too expensive. Thus, it is not only about connectors. It is about a flexible support for different approaches, from manual workflows to full bi-directional automation.

For the core systems, it definitely makes sense to automate. Many transactions, high risks – these are reasons to invest in direct connectors. But there are many other systems out there which need to be connected as well. Even while there aren’t that many standard interfaces (Web Services, Command Line Interfaces, JDBC/ODBC, LDAP,…) which are commonly used to interact with target systems, the customization and integration is costly anyhow. “Connector fabrics” and other approaches help, but typically organizations end up with some systems which are tightly connected and others which aren’t.

There are many approaches to integrate these systems. There might be specific provisioning tools (FIM/ILM, Quest ARS, and others for Active Directory; SAP NW IDM for SAP;…) in place which can be integrated with other provisioning systems. There might be existing processes based on SRM (Service Request Management) tools. There might be the need for additional manual workflows and some access governance to track whether the manual actions have been performed or not.

With other words: Flexibility is key. Flexibility for architectures, where Identity Provisioning and Access Governance tools are just one element – there might be more than one Provisioning tool, there might be SRM, existing workflows, the integration of Provisioning and Access Governance, interfaces to Enterprise Portals, and so on. And flexibility for connections to systems, by not only relying on automation.

Interestingly, I had some briefings in the last few weeks where vendors – like Courion and Aveksa – highlighted new capabilities which are exactly targeted on this. There are other vendors which started with that before. However, it seems to become a major trend right now – open, flexible architectures for Provisioning and Access Governance. For customers, that means that they have to think a little more about the adequate architecture. On the other hand, that might save them significantly more money by choosing an approach which really fits to what they have.

Hope to see you at EIC 2010 in Munich, May 4th to 7th, 2010.

We’re talking a lot about the need for IT to align with business. But it’s not about a one way road. There is no doubt that IT has to think much more “business”. Risk focus (here and here), performance management, the understanding of IT as Information Technology instead of Information Technology, the path towards an ERP for IT,… I think that many CIOs and CISOs are well aware of this and many of them are working towards that goal.

However, if I look at the business side, it appears to me that IT still is somewhat ignored when it is about alignment. Two examples out of many from my practice:

• When talking about GRC initiatives at the IT level, customers frequently complain about risk management initiatives with focus on organizational risks where they are not even able to start a discussion about integration. However, any IT risk is just a risk because its associated with organizational and (sometimes) strategic risk. Thus, you can’t ignore the IT risk perspective from an “Enterprise” GRC perspective (which, by the way, is sort of an arrogant term, ignoring exactly the fact I’m discussing here – “Business GRC” would be much more appropriate). You can’t run a business without IT. It’s part of the operations. And IT risks might have severe impact on your overall business performance – look at fraud in financial institutions, data theft, and so on.
• When talking with the Business GRC vendors – look at the upper layer here – some of them (not all!!!) show an attitude of “we’re doing the relevant business GRC instead of the irrelevant IT things” and claim that they don’t need to provide integration or to support the IT part of the business.

However, given that IT is an important part of every business (the German Bafin – the government agency responsible of auditing and controlling the financial institutions – explicitly claims that IT is a core part of banking business and has to be understood that way), that means ignoring risks. And, even more, it means ignoring that there are elements in risk management which are provided by IT. You need automated controls besides the manual controls. And all the Business GRC tools are IT tools, by the way.

The problem from my perspective is that as well some vendors as many responsibles in the organizations don’t want to play with the IT guys. However, they could not only do a much better job by better executing their controls but they as well could do their job correctly, by really adressing the whole breadth of (operational and strategic) risks.

That’s just one example where business has to learn to better align with IT – and it’s not the only one. Look at the description of business services. For sure there has to be a translation into IT services at some point of time. But before you can do that, you have to have something which can be translated. And frequently, the problem isn’t the translation but what has to be translated. If the original text isn’t sufficient, the translation result never will be. Everyone dealing with software development probably has made this experience: Many issues in software development are caused by an insufficient descriptions of the requirements.

I think that it is time that not only IT understands that it exists only because it provides value to the business but that businesses rely on IT and thus have to align with IT. And that Business/IT alignment is definitely not only something where IT has to learn a lot. Businesses have to do as well – to understand the operational impact of IT (and IT risks), to describe their service requirements, to accept that the operational risk associated with an IT risk has to be balanced with the opportunities of a business service. Just think about all the insecure applications we have in organizations just because a department required them and IT security concerns have been ignored. That has not only been because IT wasn’t able to translate the IT risk into an operational risk – it has been as well because business didn’t understand IT.

Thus, both have to learn. And sometimes it appears to me that business has to learn even more than IT. Not only the people within organizations, but as well the consultants at the different levels. So if your consultant for risk management hasn’t yet covered the operational impact of IT risks and how to deal with that, you should ask him why – and if he doesn’t provide a valide answer, you should re-think the engagement…

There is a constant pressure not only on IT but all areas of organizations to reduce costs. However, that frequently ends up with higher risks and potentially higher costs due to these risks. The problem is: Most organizations, especially in controlling and management, think much more about cost than risk. But cost savings (which are not necessarily negative) without a risk view are a risk – somewhat of a tautology, I know…

That is why Risk Management should be a standard and central element in management, as well for business as IT.

Read the rest of this entry »

Last week, there was the news that the Federal Employment Office of Germany will claim for the return of excessive payments from potentially more than a million so called “Hartz 4″ recipients. What appears to be of political and social relevance, is as well interesting for IT – because it’s about the negative impact of archaic software architecture.

Let’s start with the background. Hartz 4 stands for as well social welfare aid as unemployment aid, named after Peter Hartz, a former Volkswagen member of the board and advisor to the German government about how to change and optimize these aids and insurances. There is a significant number of Hartz 4 recipients. Many of them are either families or single parents. Starting Jan 1st 2010, the child allowance has been increased by 20 € per child and month. However, child allowance is charged against Hartz 4, thus Hartz 4 recipients with childrens shouldn’t benefit from that increase – not that social, isn’t it?

Now the problem arises: Many have received the 20 € (or x times 20 €, depending on the number of children) increase – and now that shall be reclaimed. The Federal Employment Office came up with the explanation that this has been because the short period of time between deciding about the increase of child allowance and the due date. However, there were some weeks in between. Regardless of whether the money will be reclaimed or not (there are interesting legal discussions about), that clearly shows, together with other explanations, that there is an IT issue behind.

That issue is a software where such a change obviously has been to complex to perform in time, in a planned, structured manner. That is, looking at topics like “Software Architecture”, “GRC”, and “Externalization of Security”, pretty interesting – especially from the GRC view on software architecture. Obviously, a change of a business policy couldn’t be transferred to the software just in time. That is a typical GRC issue: Business Policies which lead to complex change process in IT, when code has to be adopted to these changes. That leads to issues like time-to-market or, in that case, has a significant social impact. From a GRC perspective, that is an issue – a governance issue IT management has to deal with. IT is a software architecture issue, because such problems occur only due to a non-policy-aware software architecture and due to hard-coding things which shouldn’t be hardcoded. Think about a policy-controlled software and defined request/approval workflows for such fundamental changes. That isn’t hard to architect, it should just be good practice. It would lead to applications which are acceptable from a GRC point of view (with GRC being much more than security…). It were secure. And, most presumably such a software would rely on policies and thus externalization as well for security, especially access controls.

There is little reason to assume that the Federal Employment Office has a software in place that meets these fundamentals of good software architecture. The real bad thing, besides all the unnecessary costs associated with such archaic software, is the negative social impact of that.

For some of you, the acquisition of Burton by Gartner might have been the deal of the year. I (for sure, acting in the same market) will not comment on this. But for me, it hasn’t been the deal of the year even in these first two weeks. Much more important is the acquisition of Archer by RSA. RSA Security, a EMC subsidiary for several years now, has bought one of the leading GRC vendors. In fact it was EMC which acquired Archer but within EMC it has been RSA Security.

Archer is one of the major players in the Enterprise GRC market – I recently discussed the various segments of the GRC market. With the acquisition of Archer, RSA – until now a provider of very specialized components in the SIEM, DLP, and other security related markets – tries to close the gap between the high-level view of Archer (being mainly an Enterprise GRC provider with some level of CCM). That definitely makes sense. And it fits well in EMC/RSAs strategy for Cloud Security. Thus, by integrating the tools of RSA (and other EMC companies), providing information for automated controls, and the high-level view of Archer, the drill-down features, and the manual control capabilities as well as the overall policy and control management, EMC (with RSA and Archer) might be well able to make a big step forward towards an integrated GRC offering.

However, this shouldn’t be limited to security-related IT controls but should cover all types of IT controls, including service management, access governance, and others. Standards like Cobit show how many different controls are relevant. And, from the high-level perspective (the Archer view), it should even go beyond IT controls and IT GRC. Thus the acquisition of Archer shouldn’t be understood as the final but the first step. Integration of what EMC and partners are offering is the logical next step – but to fully deliver on the idea of an integrated GRC, EMC might have to add some other technologies (like access governance and, especially with focus on the cloud, service management).

Anyhow: The acquisition makes sense, no doubt about that. And I’m convinced that it hasn’t been the last one in the GRC market for this year.

One issue when dealing with GRC (Governance, Risk Management, Compliance) is that there is no single person which is responsible within organizations. And there is a simple reason for that: There are far too many GRCs out there. Vendors provide completely different offerings using the same acronym. That’s not new, but in the case of GRC, there is even more uncertainty raised than usual in the IT industry.

From my perspective, the solutions might be segmented into four layers:

• The so called “Enterprise GRC” which should be better named “Business GRC” or something because the other technologies are as well around the “Enterprise” but sometimes more focused on IT. Vendors in that space are, amongst others, companies like OpenPages, Bwise, Mega. The focus is on business risks and business controls, a high level view and frequently mainly on manual controls.
• The layer which is best described with the term “Continuous Controls Monitoring”, which is about looking at specific IT systems and issues from a business perspective. Order processes, delivery status, and such things. Typically there is a mix of automated and manual controls, and some systems focus more on specific enterprise applications (billing,…), whilst others focus more on the consistency of the entire process. Vendors here are, amongst others, companies like SAP (Process Control, Risk Control) and Oracle, mainly for their environments, and such ones like Approva.
• The layer which I’d call “specific/specialized GRCs”, amongst which IAM-GRC solutions (sometimes called “access governance”) and SIEM solutions are the most popular ones, even while I’d add several service management tools as well as long as they focus on service fulfillment and the service management process itself. These tools provide much more depth on specific controls, typically only a small subset of all IT controls. IAM-GRC for example focuses on roundabout 4 of 210 COBIT controls, the ones around identity and access. However, the level of automation is significantly higher and controls are much more specific. In each of the segments here we have a lot of vendors.
• System-level tools around operations management, system-level auditing, integration of system-level logs and that stuff – tools which really do a deep dive into the access controls of file servers and shares and other aspects.

With a big picture like that, it becomes obvious, that we have several elements within a GRC strategy. Business and IT have to work closely together to define what is needed in which area and how these tools interfere and how they have to be integrated. With this view, the need for a single person as responsible one for GRC diminishes. There are at least two, one at the business and one at the IT level. And there are even more for different “operational” tools at the lower levels.

If companies have defined their big pictures, it is easier for them to identify which tools they need to implement it. And it is easier for vendors to identify the persons to speak with.

More important from my analyst perspective is the first aspect: Companies which don’t have a clearly defined strategy on GRC will most likely end up with a mix of tools, non-integrated, not always providing the required features. Thus: A GRC roadmap and a GRC architectural blueprint are mandatory.

More about the system-level aspects might be heared (for the ones who read this soon) at our webinar today. A replay will be available soon.

Even more information about this topic and especially the IAM-GRC aspects (Access Governance) will be available at the Kuppinger Cole Virtual Conference on this topic December 8th to 9th. Registration for that conference is free.

The Deutsche Bahn has been sentenced to a penalty of 1,1 Mio Euro for breaches of the German data protection law, e.g. the privacy regulations in Germany. That is the record penalty based on the BDSG (Bundesdatenschutzgesetz), how the law formally is called. The reason for that penalty were abusive analysis of employee data, to identify potential cases of corruption and fraud. Data of bank accounts of suppliers and employees were compared. That became public, there was a lot of public discussion about – the topic was top in the news for several days. And the CEO, Hartmut Mehdorn, was (factually) fired.

However, dealing with corruption and fraud is a must for the management of any corporation. Heinrich von Pierer, the former CEO of Siemens, had to leave the company because he didn’t address corruption and fraud. Hartmut Mehdorn did it – and lost as well. Obviously, there are regulations in conflict. The problem of both was that they had no valid concept of which regulations are relevant, which are in conflict and how to deal with these conflicts. The Bahn analyzed far too much data and didn’t put that approach into a bigger concept, openly discussing it with the works council and so on.

So one lesson which should be learned by everyone with responsibility for compliance regulations (and the BDSG is one of them) is: Analyze the relevant regulations, clearly define the valid approach to deal with, discuss it with the works council as far as employee data is affected, talk with your auditors – in fact have a strategic approach on how to operationalize the regulations.

The second interesting aspect around the “Bahn” case is that the penalty is a record penalty – and only 1.1 million Euro, which is sort of paid out of the petty cash. Thus it hurt some people at the Bahn, loosing their jobs. But it is only a small penalty from the perspective of the large corporation. It seems that the BDSG is sort of a “law that has no teeth” (in German the saying is “toothless tiger”…). But there is good news (from the perspective of enforcing privacy and data protection): The new amendments of the BDSG will change things fundamentally – the tiger will get teeth.

GRC – Governance, Risk Management, Compliance. A typical buzzword, but well established right now. However, the problem of all emerging markets associated with a buzzword arises here as well: There are many different vendors with different types of offerings, all claiming to solve the GRC problem. But: The GRC problem has many facets and is (beyond “we have to manage risk, we have to be compliant”) largely undefined. We’ll publish a report these days on a GRC reference architecture followed by, probably in early November, a market segmentation report, placing vendors in one or more appropriate segments. Like every valid and successful emerging market, GRC will move from a large set of different solutions towards a market with some well defined segments of vendors.

There are the so called “Enterprise GRC” vendors like Mega, OpenPages, or Bwise. But even between these there are significant differences. There are vendors working more at the level of CCM (Continuous Controls Monitoring), including companies like Approva. There are IAM-GRC vendors like Aveksa, BHOLD, Engiweb, Sailpoint, and several others. There are IAM solutions with added GRC capabilities – in the meanthime most of them. There is GRC support in BSM (Business Service Management) applications. And, and, and… I don’t want to unveil to much from the upcoming reports which you will find at our website but like to focus on another aspect:

Which GRC approach to choose?

First of all, I believe that we have to use the potential of GRC for better interfacing Business and IT. There are business controls, there are IT controls. These have to be mapped. Thus, we should end with solutions which support as well the business as the IT requirements. That will never ever be a single solution, but a combination of some. High level controls and dashboards, CCM approaches and more specific solutions for different groups of IT controls. It should as well be an approach which isn’t only “detective” or, more correct, “reactive” but finds the balance between proactive/preventive and reactive/detective.

The big picture is relatively easy to describe, like we have done in our reference architecture.

The way towards that is much more difficult. There are many influencing factors like the industry and size of the organization, the current organizational structure (especially around the responsibility for GRC issues), the process maturity of the organization, the maturity of IT management approaches, and so on. Thus there can be different (and more than one) starting points. But in any case, there should be a well agreed (but coarsely described) “big picture”, as the guideline for building a GRC roadmap.

I personally believe that three factors are most important:

• Providing quick wins
• Providing a business view which, from the beginning, starts in integrating with IT – only manual controls are’t sufficient, it is always about the appropriate mix of manual and automated controls
• Closing the loop – don’t focus only on the reactive part (like with pure “access certification”) but start acting on the results, for example by integrating provisioning to fix the detected problems

These are some of the most important criteria to choose solutions in the GRC space.

Have a look at our event website for upcoming events and webinars around GRC.

And, for sure, don’t hesitate to ask for our advice on building your GRC “big picture”.