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.

Within the last few months, I’ve read several news about slowdowns in the growth of the outsourcing business and particularly the MSS (Managed Security Services) business, at least compared to the high expectations raised in the years before. Does that mean that the cloud is dead before it really starts? I don’t believe, for several reasons:

1. There are different numbers regarding the status and grwoth of the MSS and outsourcing market. Some are much positiver than others – and it is no surprise that the negative ones are cited most (even the IT press more and more acts in the yellow press way…).
2. In days of economic turmoil (and we are still in these days, despite the quick recovery of the bonus mentality in financial institutions), customers tend to first drop external services before they fire employees – that affects MSS.
3. Outsourcing is sort of a “big beast” which is diffcult to tame. It takes a long preparation, it is inflexible. Overall, it needs to adopt to become more flexibile and easier to use. Cloud Computing with its granularity of services is an approach to address the shortcomings of outsourcing.
4. A feedback I had from multiple CISOs regarding MSS is that the quality of service and the level of contol frequently is insufficient – thus it is about implementation and delivery of MSS, not the overall concept.

Two reasons why the Cloud (in my understanding of an approach for a flexible use of IT services with the ability to switch between and choose the best provider, internal or external – e.g. much more about service than about external things from the Internet) will be successful shortly explained:

1. If you think about a matrix like shown below with two axis, Outsourcing is just sort of the specialized approach to the cloud. And from our expectations, the sweet spot for most providers will be around “community clouds”, in the centre of this. That potential for industry clouds, community clouds, and point solutions isn’t unveiled yet. Thus, there is much more in the cloud than is discussed today.
2. The cloud is not new. It didn’t just appear at the sky but grew over years. SaaS is out there for a while, service management as well. Not even to talk about outsourcing. The cloud is, from my perspective, just the result of an evolution from a tactical, opportunistic use of external services towards an strategic approach on how to best provide IT services (external vs. internal). We’re at sort of the “break-even”, to use an analogy.

Cloud Matrix

By the way: The biggest risk for the cloud is too much marketing. But that was the same with Client Server, the Internet, and many other things. None of them disappeared, but all big changes took years to become reality. The same is true for the cloud.

I appreciate your feedback on that! And see you at EIC 2010 and Cloud 10, both to be held in Munich, May 4th to 7th, 2010.

Yesterday, I read an article at a German news web-site about the recent security leaks found in the social network SchülerVZ. The article claims that social networks like SchülerVZ and Facebook (both are mentioned) don’t have any chance to avoid crawlers accesing personal data which should be presented only to friends. Ridiculous!!!

Sorry, that is definitely nonsense!

It is very simple. You have some data which is visible only to some specific persons. You have an authorization policy, which might be expressed in the form of ACLs or XACML or whatever. Some application (the regular frontend, a crawler, an administrative application,…) tries to access data. You have done an authentication. You do the authorization by comparing the authentication information to the authorization information. You decide on whether access is allowed or not. That is done in millions of applications day-by-day. And that shouldn’t work with social network sites? I don’t see any real reason why!

For sure there are two reasons why at least some social networks don’t do that in this way:

• Bad software architecture: Security has to be done by design, from the very beginning. Otherwise it is hard to implement it. Unfortunately, many developers don’t design security in their products but add it at the end, as something painful they have to do at the minimum level.
• Performance considerations: For sure security will affect performance. For any access, you will have to do security checks. You will even have to provide stronger authentication features. But it can be done. Providers will probably require some more hardware to keep the performance level of their social networks. But security has its price.

But to be honest: These aren’t valid reasons. Either you are able to deploy a social network in a secure way and fulfill the data protection laws. Or you should shut the entire thing down. Given that it is possible to secure social networks, the operators should be fully responsible for any security breach.

By the way: Even the databases themselves can be fully secured. That depends a little on the database chosen and the additional technologies in place, like Oracle’s Database Security products (to mention one of the more advanced solutions). OK, that will again cost you some performance and some money. But again it is about “security first”. If the providers of social networks can’t afford the cost of security, their business model just doesn’t work.

XACML (eXtensible Access Control Markup Language) gains an increasing attention as one of the core standards in the field of information security and thus IT security. Whilst standards like SAML (Security Assertion Markup Language) address the problem of authentication, XACML is about authorization – the more complex threat. XACML allows the definition and exchange of authorization policies in a heterogeneous environment. Whether it is about cloud security and controlling the authorization policies of cloud services or about SOA security for internal applications: XACML supports the authorization management in such use cases.

However, there is no such thing as a free lunch: XACML not only tools like XML/SOA Security Gateways which support that standard or cloud services with XACML support. There are two other important aspects:

• XACML in fact means a shift from a more static security approach like with ACLs (Access Control Lists) towards a dynamic approach, based on policies which are applied at runtime. These dynamic security concepts are more difficult to understand, to recertify, to audit and analyze in their real-world implications. Thus, the use of XACML requires not only the right tools but well-thought concepts for policy creation and management.
• XACML is just a foundation to express policies. Within a use case, policy concepts have to be defined. Over time, there should be higher level standards or defined use cases building on XACML and focusing on a standardization of the content of these policies.

Anyway, XACML is very useful. One of the most interesting areas for XACML is SOA Security. Currently, many SOA-based applications still lack a valid concept for authorization. Authorization still frequently is built into these applications. XACML can provide the policies to externalize the authorization management and thus add flexibility to SOA-based applications.

Overall, it is – from my perspective – definitely worth to spend some time exploiting the potentials for XACML to improve the security of systems and applications. There are many areas where XACML can be used successfully today. However, like with any emerging technology, there will be a lot of improvements in the managing and consuming applications (and, hopefully, around the standards ore use cases building on XACML) over the next few years. Thus the step to XACML has to be considered carefully. The good thing is: It is about standards, thus the risk of lock-in isn’t that big.

We will talk more on depth in an upcoming webinar. Register for free!

These days I had a discussion with a vendor who sells different security tools which make up sort of an Endpoint Security “suite” about my and his view on that market. He was sort of offended by my critical view on today’s endpoint security market and claimed that his company and many of his competitors are selling large amounts of licenses to customers. Thus I must be wrong when telling people that the market isn’t really mature today.

My view on endpoint security is, by the way, not as sceptic as the one I have on the DLP market (Data Leakage Protection/Prevention). I think that well integrated, feature-rich endpoint security solutions are an important element within security strategies. But the bar is set high. Endpoint Security solutions have to fully protect different types of endpoints. That includes AV, local firewalls, WLAN security, encryption, device control, and other elements. All these features have to be well managed. And well managed means centrally managed, integrated with existing and potential other new elements of the overall strategy. Active Directory integration is key in Windows environments. Integration with SIEM tools or at least open interfaces are a required feature. For sure, there needs to be one set of policies for all security features of the endpoint. Existing system-level features should be as well integrated, starting with Bitlocker on new Windows versions and for sure as well including interfaces to Windows Group Policies. To name just a few of the expectations I have on Endpoint Security Suites.

Endpoint Security thus goes well beyond the point solutions in the DLP market which I see even more critical.

Unfortunately, no vendor today fully supports all requirements I have on Endpoint Security solutions. That might change over time. But even then, Endpoint Security will be only one element within a security strategy, which has to be combined with IAM (Identity and Access Management) as the foundation for most parts of security, with more advanced information protection solutions (shielding information not only at rest, but as well on move and on use), centralized solutions (which might even overlap with endpoint security to some degree – look at what Finjan provides) and so on.

Thus this mean that you shouldn’t invest in Endpoint Security tools? No, for sure not. But a customer should be aware of the shortcomings of today’s offerings. And he should understand that he addresses only part of the overall problem (even while Endpoint Security at least might address a larger part of the problem, compared to many of the point solutions offered under the label of DLP). And vendors might use the bar I have set as sort of benchmark for their solutions and sort of advice for their product management instead of complaining that the bar is set to high. The fact that they are selling their products only proves that there is a strong demand for endpoint security solutions and that customers are even willing to buy immature solutions – it doesn’t prove that their solutions are mature.

My advice for customers: Understand the strengths and shortcomings of today’s offering in endpoint security, understand endpoint security as part of a larger IT security initiative, and define your selection criteria according to that.

My advice for vendors: Don’t rest on your current success but go a step back and think about what will be needed tomorrow and in some years from now. The Endpoint Security market will evolve, there will be significant changes. And it will be more and more understood as part of a bigger IT security approach.

Yesterday, news spread about the theft of millions of credit card dates at the US company Heartland Payment Systems, based in Princeton, New Jersey. Even while that might be one of the largest cases of data theft in the credit card industry, it wouldn’t be that interesting that I’d blog about. The – from my perspective – really interesting point is, from what I’ve read in the news, the way the attack has been performed.

The information sent is encrypted but has to be decrypted to work with it. The attackers grabbed the then unencrypted information. Surprise? Not really. The problem with security is that virtually any approach is incomplete – and thus inherently insecure. Examples?

• Passwords are frequently encrypted via SSL when sent to a eCommerce website but then decrypted and compared – and often they are even stored unencrypted and sent back in case of a lost password. I’ve just seen this again recently, when I received my password in cleartext via eMail.
• Data is encrypted on a specific type of device using some DLP (Data Loss Prevention) technology. Once delivered, it is decrypted – and might be mailed as an attachment.
• Access Control Lists are enforced to provide security for data at file servers – but they are sent to the client unencrypted and the user might store an unshielded copy (or mail it or do something else).

These are just three examples – of hundreds or thousands. Another was discussed in a Kuppinger Cole Webinar yesterday, where we talked about “service oriented security”, e.g. application security infrastructures, SOA security, and so on. The question was about the security between the applications and the security systems (and eventually the security systems themselves). That is a good question. Often there are security holes somewhere at the center of the security system. SSL itself isn’t the answer. In that case it is about a consistent security approach. Unfortunately, even many IAM and GRC applications don’t provide a really sophisticated security model.

Another interesting point is that there are always other potential security holes. Trojans which grab keystrokes are one example, the man behind you reading the information at your screen is another one. Some of these problems can be adressed, for example with external keyboards for entering sensitive information in eBanking. Others will be always there.

There is no easy solution to these issues. Information Rights Management will help to address many of these problems – I’ve blogged about the need for IRM some time ago. But IRM won’t solve everything. Information has to be processed, thus the systems which process data are extremly sensitive (like in the case I’ve started with). And a business document in an ERP system is, finally, stored in fragments within a database.

From my perspective, the most important point is to work on an authorization strategy (or access strategy) which covers all aspects. Any investment in DLP is at risk as long as it isn’t part of the bigger picture. Point solutions are perfect for masquerading the real security problems, but they don’t really solve them. An overall strategy which identifies the security holes and which tries to use a limited number of well linked technologies is mandatory to minimize security risks. That strategy has to include everything, from the firewall and SSL-secured connections to IRM and the security of backend systems. That is no easy task, especially because there are frequently many different parties involved which all claim that they have found the holy grail for enforcing security. But it can be done – and it will save you a lot of money by avoiding investments in security technology which don’t really solve your problems.

For the ones of you capable of reading German: Please participate in this survey. That fits well to the topic of this blog post.