Provisioning is important to keep access under control, as well as Access Governance solutions play a vital role in that game. However, there is a third group of applications which is commonly required: Tools which allow to dive into the details of access controls in specific environments. There are SAP specific solutions and tools for mainframe environments, XACML for standardized entitlement management for custom applications might be counted as well – and there are tools for the world of less structured information, like file servers, Microsoft SharePoint, and others.

These tools are important to enable a detailed analysis of access rights at the level of files, folders, and shares – when looking at file servers. Provisioning helps us to ensure that a user has an Active Directory account and is member of some specific groups. But what are these groups allowed to do – in detail? Some Access Governance solutions might provide some details, but typically not as specific as the expert tools in that area can do. And there are many tools out there. These days I spoke with Protected Networks, but Econet, Tesis, and ASB - to mention just some German vendors – can deliver on this as well, with somewhat different approaches and capabilities. And these are just some examples.

From my perspective, we need a layered approach – Enterprise GRC, Access Governance, Provisioning, and the specific tools for different important application environments. And we need to integrate these tools. That will enable organizations to fulfill the governance needs and compliance regulations at all levels – with an integrated approach and avoiding investing in point solutions.

By the way: If you as a vendor feel that you fall in that category (for AD and file servers, for SharePoint, for SAP), just keep us informed. We might have you on our watchlist but given that this is a market with many smaller vendors in, we might have missed you until now…

Today I opened my Facebook which I use actively since yesterday. When g0ing to my settings, the system informed me about changed privacy settings. What it then recommended was ridiculous: All my very tight settings should be opened up. Instead of sharing information only with my friends, the system suggested that I should share a lot of information with everyone and other, sometimes sensitive information (religion, political opinions) with friends of my friends. I had to manually change back everything to “old settings” which at least was an option I could use. However, from my perspective it is fully inacceptable from a privacy perspective to suggest such changes. If someone has opted for tight settings, this approach just shows that Facebook still hasn’t understood anything.

Besides this, the options for managing “authorizations” or privacy settings, e.g. controlling who is allowed to see what are primitive. I can share everything with my friends. But in many cases I want to share some informati0n only with some of my friends. I can use lists, but I for example can’t use these lists as sort of “groups for ACLs (Access Control Lists)”. At list I didn’t manage to find out how until now. But given that I have friends from business and from my private life, it is very obvious that I won’t share everything with everyone, isn’t it?

Again, like pointed out here and here, there is no reason not to construct social networks secure and with strong privacy settings. For sure it is hard to do it afterwards, once you have a bad security architecture in place. But technically seen, it is feasible – and it is relatively easy. But it requires understanding the needs for privacy (which become an inhibitor to the market for Facebook at least in some countries these days) – and you have to do that.

Why am I using Facebook anyway? Too many people are using it and many said that it is a better way to stay in touch with contacts than the other social networks like Xing or LinkedIn. And, by the way: These other networks are as well not the godfathers or inventors of privacy… I don’t expect Facebook to ever understand privacy and act accordingly. Thus I’ll keep an eye on what I publish there and what I don’t publish and I’ll keep my privacy settings very rigid. For sure I could use more than one Facebook account. But that would be harder to manage and a pain for the ones which are “friends” in private and business life.

Just a side note: Interestingly many startups have significant lacks in their overall software architecture and struggle with things like scalability and adding new features. And even more struggle with increasing security requirements. One reason is the missing understanding for security (see link above). The other is that many startups have CTOs which are pretty inexperienced – interestingly the ones where the founders (and amongst them the CTO) is doing a startup the second or third time perform much better because they have learned many lessons before. There are – like always – exceptions from that rule, e.g. startups with young CTOs doing a very good job. But these are the exceptions. You could bet on what my rating for Facebook is from that perspective…

By the way: If anyone knows how to control all access to the content in Facebook based on my lists of friends, let me know…

Some days ago, we’ve published our report on Hidden Gems 2010 - vendors which are innovative but not that well known, at least not on a worldwide basis. We’ve included 25 vendors. Right now, only 24 of them are hidden. Völcker Informatik, one of the Hidden Gems, has been acquired by Quest Software. There is a good reason for that: Völcker is, from the Quest perspective, a Gem which might help them make shine (even) more than before. And not only from the Völcker perspective.

For sure I like it when a Hidden Gem becomes “more visible”, because it proves our rating of these vendors. So I’m looking forward to see who is next.

During the last weeks, with all the discussions about security- and privacy-related issues in social networks like Facebook or SchülerVZ, I’ve had some talks with people. My position is that these issues are a result of bad software architecture. The counter argument sometimes has been that when building these networks the focus has been on functionality, not security – and that the business model of these networks is based on the functionality. What was meant by that is that you should first care about functionality and that security is somewhat irrelevant because it doesn’t help you in achieving your business goals.

However, that is fundamentally wrong. The current issues prove that the business model of these social networks is threatened by security weaknesses. They also prove (like any good software architect knows) that it is virtually impossible to add good security afterwards. You have to build it in from the very beginning. Trying to fix issues by blacklists or whitelists or by adding some URL obsfucation or something like that always will address symptoms, not the cause.

What we currently observe at many social networks and eCommerce sites is that there is more attention on security and privacy issues – and the providers are struggling with this because their software security architecture doesn’t allow to flexibly react on this. For sure some of these providers are somewhat reluctant in changing their privacy and security settings because their model relies on “openness”. Anyhow, even Facebook has had to make changes, and that will continue.

Good software security architecture would allow these providers to just change some settings by configuration. That would be easy and not very expensive if the software were well constructed, with security in mind from the beginning. That includes the ability to flexibly use different authentication mechanisms and a consistent authorization model which is configurable. For sure there is some more work to do in architecting and developing such a system – but it is significantly less work than trying to fix problems afterwards (and, besides this, doing it from the beginning is a solution and not a patch which leads to patchwork with security and privacy holes).

However, the most important lesson one can learn from that situation is that software security is relevant to any business model. If it inhibits growth, if it leads to a loss of trust and in consequence of users then it affects the business. The  argument that it is first about time-to-market isn’t really valid. It doesn’t take much more time and efforts to do software security right then to ignore this – especially because some security always has to be added before releasing a software. The real valid rule is: You always will pay for bad software architecture. And you will pay for bad software security architecture. That is like in real life architecture and construction – go back to the bible, even there it is told that you shouldn’t build your house on sand. Ignoring software security at the beginning is nothing else than building houses on sand. And a good business model which thinks strategic doesn’t ignore that fact.

Building software without a good software architecture is sort of building a car without breaks. You can argue that the car is for driving, not breaking. And you can argue that it is about functionality not security. But would you trust in a car without breaks?

Microsoft has introduced the concept of claims-based securitywith it’s “Geneva” project. Claims are sort of attributes which are provided by identity providers in the form of tokens and consumed by applications. In fact they are one way to make federation easier and more user centric. “Geneva” provides the tools at all levels to work with claims. The concept of claims is used by some other groups at Microsoft and we probably will see several Microsoft applications with support for claims within the next months.

However, the biggest impact might be on the Windows operating system itself. Claims could make that much more flexible from a security management perspective than today’s mainly ACL-based security model. ACLs are too static and too complex in management to really fulfill the customer needs today. Not only in Windows, but in other operating systems as well. If you think about an operating system which consists of services (Service Providers, Relying Parties) and relies on Identity Providers to provide claims, the entire Security Management can become much more efficient. Based on Policies, using dynamically provided claims. Authorization might be done by the services based on policies and claims or by specialized authorization engines within the operating systems on behalf of the services (the latter not yet being part of “Geneva”).

It is, without any doubt, not that easy to perform such a fundamental change. ACLs are at least somewhat understood, claims are new. There has to be a migration path and compatibility. But if we look at all the options we have, claims appear to be the most promising concept for the future security at the operating system level. One interesting side effect is that the same policies might be applied to other elements in the security infrastructure as well – external access management tools and so on.

Meet me at European Identity Conference 2010 and Cloud 2010 Conference, Munich, May 4th to 7th.

There are so many myths out there about Cloud Security – time to start putting them away…

1. The cloud is inherently insecure. No, not really. There are providers which deliver a high level of security. The cloud can be more secure than internal IT, given that services are frequently operated very professional.
2. The cloud is more secure than the internal IT. No, as well not. The cloud is neither secure or insecure. It is about the single service which might be more or less secure. And it always depends on with what you compare, e.g. how strong security in the existing internal environment really is. Thus, it is important to define security requirements in service descriptions and SLAs and to measure security.
3. Cloud Security issues are new. No, most of them are not. They are the same like in outsourcing or the tactical use of external services we are doing for years right now. The difference is that there are much more services to deal with – which is an opportunity to handle security in a standardized way and improve it beyond the typical ad-hoc approaches of the past.
4. Security is the task of the Cloud Service Provider. Yes and no. Service providers have to provide a high level of security and they have to inform about. But you can’t just rely on them. You’re always the one who defines his security requirements and is responsible for their fulfillment – by chosing appropriate service providers.
5. We can’t do things outside of the EU. A myth. There are some legal aspects around operations on privacy-related data which have to be observed. But overall it’s not about that things can’t be done but more about a big grey area of uncertainty.
6. SAML solves the IAM issues in the cloud. No, definitely not true. SAML is the first little step towards the target of externalized security of cloud services. But that’s only about the separation of administration and authentication. The much more interesting topic of authorization (XACML and other standards) has to be solved as well. And few cloud service providers support XACML today. Few support own proprietary web services as an alternative. Not to speak of auditing interfaces…
7. Security in the cloud can’t be measured. Somewhat true – in the sense of: Most providers don’t support risk metrics, a detailed auditing and so on. But theoretically not true, because these interfaces can (and should) be provided.

More on Cloud Security and some of the myths and real issues in the KuppingerCole Virtual Conference on Cloud Security. Register for free!

And for sure at Cloud 2010, parallel to EIC 2010.

Last week I had an interesting briefing with IBM regarding their Guardium acquisition. With that acquisition of a company specialized on database security, IBM becomes the second large vendor investing in that area, following Oracle who has Database Security products in its portfolio for some years now. The IBM/Guardium deal fits pretty well in the current time, when looking at the increasing problem of information theft. Besides IBM and Guardium there are some smaller vendors in that market which I will cover in another post near-time.

IBM Guardium, in contrast to the Oracle approach, is not tied to a specific database management system but works as an external solution. There are obviously pros and cons for both approaches. Performance, administration, flexibility regarding the defined policies and other aspects differ significantly. Thus, before choosing solutions, a detailed analysis of these approaches should be performed (and KuppingerCole will provide a market overview for database security around April which might be a good starting point for such an analysis).

The entry of IBM in that market shows an increasing maturity and relevance of this particular IT market segment. And it raises the question of which role database security can play within IT security. From my perspective, it is an interesting area which is mandatory to protect sensitive information. Information in databases is at risk, and cases like BKK or the stolen data from Swiss banks offered to the German government prove that. However, this is just one element within an IT security strategy focusing on authorized access to data. Securing the database with the wrong policies or with giving away privileged accounts to untrustworthy parties won’t help much. Thus, database security projects never ever should be driven by the database guys but must be understood as an element within IT security blueprints. Only a consistent approach to security will really reduce the security risks and thus the related operational risks.

Even more I think that database security always will be somewhat limited in its scope. Once data is outside the database, it doesn’t protect the data anymore. On the long run we might have to fundamentally rethink the concepts of today’s databases and make them “security-aware”. What do I mean by that? Data within databases should be inherently protected. Think about applying concepts we find today in Information Rights Management (IRM) at the document-level at a much more granular level to data within databases, ensuring that any record (or part of a record) can only be accessed according to defined policies. Such an approach would have massive impact on the existing technology. How to index? How to deal with encrypted information? How to define these policies? However, if you look at database security from a very fundamental point-of-view, it becomes obvious that applying database security to existing databases won’t fully solve the problem because it is only about “data at rest”.

Nevertheless I think that any organization has to think about implementing database security in the meantime, until we have better solutions sometimes in the far future – I’d expect fundamental changes to database technology to take at least 10-15 years to become ready for mass adoption. It might take even a little longer. To cite John Maynard Keynes, the famous economist who focused on theories with a short-term view when being critized for not looking at long-term evolutions: “On the long term we are all dead”. Given that, short-term we should evaluate and implement existing database security approaches, rethink the authentication and authorization approaches within databases (using the GRANT statement a little bit more detailed…) and integrate this with our overall IT security and governance approaches (and especially IAM). In the meantime, the vendors have to think about how to do the next fundamental step to make DBMS inherently security-aware.

Last week, the German health insurance company BKK had to unveil a severe information leak. The company has become blackmailed because someone had stolen masses of sensitive patient records. Besides the fact, that the way that this happened shows an astonishing carelessness when dealing with IT security and privacy at the BKK and raises many questions (see below), there are some interesting new options for the German government to work with this data.

You could for example take such patient records and combine them with the recently acquired stolen data from Switzerland about potential tax fraud. If you take for example people who recently showed insomnia or started bed-wetting, that should be fully sufficient for an initial suspicion by the attorneys. And that is just the tip of the iceberg. There are so many other interesting opportunities of combining patient records with other types of information… Thus the thief probably should have approached the German government instead of the BKK. They are always willing to buy stolen things and to make use of that, like they have proven recently.

Some words about the BKK case itself: The BKK had outsourced some tasks to a call center. There hasn’t been an auditing about the privacy, IT security, or data protection approaches of that outsourcer. In fact, it appears that there have been other outsourcers and freelancers involved. Besides this, there was an IT company involved which did the support for the outsourced call center. The employees of that IT company had some privileged accounts with access to massive amounts of sensitive patient records.

Overall, there has obviously been a lack of understanding of IT security and privacy issues I seldomly have seen before, at least not in the healthcare and finance industry. No valid concept for differentiated access controls, no privileged access management, no data leakage prevention, nothing. Incredible – but true.

My colleague Jörg Resch recently blogged a lot about approaches for “lightweight” authentication and the risks associated with them. There are many companies out there with new or claimed-to-be-new approaches on more or less strong and more or less valid authentication. Whether that’s the approach of isec, of GrIDsure, of Yubikey or one of the many other vendors out there, I doubt that there is the holy grail of authentication amongst. Some of them are definitely interesting, some of them not.  Many of them are interesting as one element in an authentication strategy – like GrIDsure, which is OEMed by other vendors as part of their solutions. There is no doubt that many of these solutions can provide value in specific use cases – Multifactor Corp. provides something for and from the cloud, Yubikey is lightweight, GrIDsure as well. There are other approaches where I doubt that they really provide the required usability. I’m not a friend of approaches where you have to recognize pictures or faces, but they appear to have their market as well.

However, what’s really important around all these approaches for strong authentication are two other aspects:

1. How do they integrate and work together?
2. Are they adequate to protect the transactions and interactions within a specific use case?

My point is: It is not about choosing the authentication mechanism but it is about choosing the best mix of few mechanisms, depending on your use cases. That requires an authentication (and authorization) strategy. That requires platforms for versatile authentication like the ones offered by vendors like ActivIdentity, Entrust, Oracle, and others. That requires a clear understanding of the risk and thus the security requirements of different use cases. Than it is about choosing the appropriate mechanism or a mix of them, to use step-up authentication if required and so on.

The biggest risk is that authentication is either not usable or to simple. That might happen when relying on a single mechanism. By mixing several ones, things become muh easier.

To learn more about that, you definitely should visit the European Identity Conference in Munich, May 4th to 7th. And there will be a market overview on the strong authentication market by KuppingerCole within the next few days – have a look at www.kuppingercole.com/reports.

My colleague Jörg Resch blogged today about the ignorance regarding layered security approaches. Yes, there is no absolute security. Security is something which is tightly related to risk. Given that we can’t have the perfect security, especially not with people using systems, it’s always about the balance between the security-imposed risk and the cost of risk mitigation.

That’s a very simple balance: The higher the risks are the more you can and should spend on risk mitigation – as long as risk mitigation is feasible (which is not always the case – a life insurance doesn’t help you mitigating the risk of dying…). I thoughtfully used the term “security-imposed risk”. It is NOT about security risks, but about the consequences of security-related incidents. Stolen data and their abuse, illegal transactions, customer loss due to a decrease in credibility,… – that’s what it is about.

But that doesn’t change the fundamental: When thinking about security we have to think about risks. I’ve blogged about Risk Management before. What we have to understand is that there is not THE information or system which has to be protected. We have different types of systems, information, and transactions which are at different risk. And we have to apply security (technology and organization) according to the risk associated with these different systems, information, and transactions.

There is not THE level of security you need. You need appropriate security for different types of transactions and interaction (and the related systems). Using risk as the main criteria in decisions about security investments helps to optimize what is done in IT security. And focusing on few consistent approaches at different levels (for example few different types of authentication with step-up features and so on, based on a versatile authentication platform; for example a consistent authorization strategy with few consistent levels of management and protection) will be much cheaper than spending too much money for point solutions like many (not all) of the DLP tools out there.

Understanding that different types of interactions and transactions have to be protected differently is the key to succesful IT security concepts. Risk is the core criteria to do that. Interestingly, that is not really new. What governmental and military organizations are doing in “information classification” (having started long before the invention of the computer) is nothing else than using risk as a criteria and definining different levels of protection for different interactions and transactions. Such concepts don’t have to be extremly complex. But a differentiated view has to be the guideline for everything which is done in IT security.

To learn more about this and to discuss this with your peers, have a look at our upcoming virtual conferences and our European Identity Conference 2010.