English   Deutsch   Русский   中文    

Blog posts by Martin Kuppinger

Reading Might Help: What You Should Consider before Closing a Cloud Computing Contract

Oct 06, 2015 by Martin Kuppinger

As with most other contracts, be it about a large purchase or an insurance, you should read (standard) contracts with your cloud provider very carefully. Chances are good that you will detect some points that border on insolence. There are certainly good reasons for using the cloud in business of any size, among them cost reductions and the ability to concentrate on the core business. By providing rapid adoption of new services, the cloud also enables quick innovation. But since your whole business will be influenced by the services delivered, they might sooner or later become disruptive to your daily workflow if not properly implemented.

"Uneven" relationship Clearly, the relationship between cloud service provider (CSP) and tenant is "uneven" from the beginning. The latter first of all has to pay for all extras, frequently called Managed Services - even for those that should be naturally included in any cloud contract. This way the customer has to pay more for letting the provider take over more of his normal responsibility. Delivering those kinds of "value-added service" only for much and more money can't be the unique selling point. I wonder what the provider's legal department says to those offers. The providers should be liable for breakdowns in service and data breach or loss. Most if not all deny that responsibility.

Reading the contract carefully can help avoiding the most obvious pitfalls. Make it a game: Find the aspects that could become a challenge for your daily business. There are some, trust me. Begin with the parts of the contract dealing with end-of-service, changes or availability. Don't be surprised if there is a clause that gives your CSP the freedom to go out of business with you at any time. He can also change services flexibly - mind you, flexibility should be on your side in the cloud, not on his - without having to announce it long in advance. Some CSPs think they don't need to announce it at all. Even if the change means that an important application won't run any longer.

Feature changes can pose problems Feature changes can evolve to a massive problem, when employees can't find some data again or see a completely altered user interface. This will lead to an increase in costs for help desk calls. Or imagine you customer relied on a certain feature that suddenly doesn't exist anymore. Just that the CSP thinks it is useless doesn't mean that you do so too.

Another issue concerns availability: Surely it is not always the CSP's fault if a service is not accessible. But where it is, availability guarantees amount to nothing if they are not connected to penalties. CSPs regularly disinclude liability in their contracts for damages on the tenant's side as a consequence of a longer outage - which is understandable. However, like this guarantees are relatively worthless. It should be added in this context that if you really need high availability you'll probably get it a lot cheaper in the cloud than with your internal IT. The cloud idea is not bad in itself.

Customization and the Cloud API (Application Programming Interface) changes might affect the integration between different cloud services or a cloud service and on-premise applications. It might as well affect customized solutions. Customized solutions? Is cloud computing not all about standards? Aren't the greatest benefits to be found in areas where customization won't mean a competitive advantage? Yes, maybe. But most business solutions - CRM, ERP, HR etc. - don't exist in isolation from other applications. They need to be integrated to work optimally. Last but not least APIs have to be upwards compatible. If they change or features will be turned down, the CSP client has to be informed long in advance to be able to prepare for it and to tell his customers in time.

How to find a good CSP So, how do you recognize a good CSP for your business? First of all, he should see the cloud benefits from your perspective, not only from his. For this he has to understand your main issues and challenges. Customers on the other side should always be prepared that things might not run as they expected. Therefore there should always an exit strategy fixed in the contract. This also helps to avoid the problem of a vendor lock-in which often is the result of long-term initial contracts. If a contract ends, the user should get his full data back immediately without any further costs.

Naturally not everybody running a business understands the concept of the cloud and how it works. It suffices to know how to find a good CSP and what elements a contract should contain that's beneficial to the customer.

This article has originally appeared in KuppingerCole Analysts' View newsletter.


Cloud Security: IBM not only protects but detects, connects, and responds

Sep 22, 2015 by Martin Kuppinger

With the announcement of the IBM Cloud Security Enforcer, IBM continues its journey towards integrated solutions. What had started a while ago in the IBM Security division with integrating identity and analytical capabilities, both from the former IBM Tivoli division and the CrossIdeas acquisition, as well as from the Q1 Labs acquisition, now reaches a new level with the IBM Cloud Security Enforcer.

IBM combines capabilities such as mobile security management, identity and access management, behavioral analytics, and threat intelligence (X-Force) to build a comprehensive cloud security solution that raises the bar in this market.

Running as a cloud solution, IBM Cloud Security Enforcer can sit between the users and their devices on the one hand and the ever-increasing number of cloud applications in use on the other hand. It integrates with Microsoft Active Directory and other on-premise services for user management. While access of enterprise users can be controlled via common edge components, routing traffic to the cloud service, mobile users can access a mobile proxy (World Wide Mobile Cloud Proxy), including support for VPN connections.

The IBM Cloud Security Enforcer then provides services such as application management, a launchpad and an application catalog, entitlement management and policy enforcement, and a variety of analytical capabilities that focus on risks and current threats. It then can federate out to the cloud services.

Cloud security services are nothing new. There are cloud security gateways; there is Cloud IAM and Cloud SSO; there is increasing support for mobile security in that context; and there are Threat Intelligence solutions. IBM’s approach differs in integrating a variety of capabilities. When looking at the initial release (IBM plans to provide regular updates and extensions in short intervals) of IBM Cloud Security Enforcer, there are several vendors which are stronger in single areas, but IBM’s integrated approach is among the leading-edge solutions. Thus we recommend evaluating that solution when looking at improving cloud security for employees.


Why recertification isn’t sufficient anymore – time to look at user behavior and detect anomalies

Sep 08, 2015 by Martin Kuppinger

Imagine you have well thought-out processes for IAM (Identity and Access Management) that ensure that identities are managed correctly and all the challenges in particular of mover and leaver processes are handled well. Imagine you also have a well-working recertification approach implemented and rolled out to your organization. Are you done? Unfortunately not.

Even when you succeed in implementing the core IAM and IAG (Identity and Access Governance) processes including recertification – and not everyone does so – you still are far from the end of your journey.

Why? Because you at best will know that entitlements are assigned correctly and that you meet the “need to know” principle. Unless your joiner, mover, and leaver processes are really well-implemented, you still might be in a situation where users might have excessive entitlements for e.g. 11 months and 29 days, based on a yearly recertification. Yes, you might shorten that period, but that will not solve the problem – it might be 5 months and 29 days at maximum then, but the basic problem remains. That is a good reason for trying to fix the cause (implementing good IAM processes) instead of the symptoms (recertifying).

Furthermore, you still don’t know whether correctly assigned entitlements are abused. What if your backup operator (who must be entitled for backups) does two backups instead of one? One for the business, one to take it home or somewhere else? What if your front office worker accesses all the customer records he has access to within a short period of time, all data ending up at an USB stick? What if a privileged account is hijacked by an attacker who runs privileged actions?

Knowing that the state is correct is no longer sufficient. We need to understand whether entitlements are used correctly. There is no technology in traditional static access management, i.e. creating accounts, assigning them to groups or roles and thus entitling them, which also limits or audits the use of these entitlements. Logging and SIEM provides a little insight.

However, what we really need are more sophisticated approaches. User Activity Monitoring (from the perspective of monitoring and logging) and User Behavior Analytics (the perspective of analyzing collected data) must move to the center of our attention. We need becoming able in identifying anomalies in user behavior. We need setting up processes to deal with suspicious incidents properly – not blocking the business from what it needs to do, not violating worker’s rights, but mitigating risks.

Technology is there, from privileged threat analytics to user behavior analytics and, beyond identities, Real Time Security Intelligence. Such technology can be implemented in a compliant way, even in countries with strong emphasis on privacy and mighty worker’s councils.

When we really want to mitigate access risks, we have to go beyond traditional approaches and even beyond Access Intelligence. We must become able identifying anomalies in user behavior, not only of administrators but also business users (oh yes, there are fraud management solutions for that available as well – so we are not talking about something entirely new). Time to move to the next level of IAM. From preventing (setting correct entitlements) and detecting (recertification and Access Intelligence) to responding, based on better detection and well thought-out, planned incident handling.

This article has originally appeared in KuppingerCole Analysts' View newsletter.


Dealing with risks in IoT and Smart Manufacturing: Time to rethink your (not only IT) security organization

Aug 03, 2015 by Martin Kuppinger

Let me start with two recent experiences I have had.

Just recently, I was sitting in front of a number of CISOs and had the opportunity to ask them how many of them also had responsibility for IoT and smart manufacturing in their organization. The simple answer: none of the CISOs had. At best, they were informed, but neither responsible nor accountable.

The other one was a conversation in which a business partner, in the context of my recent blog post on Shodan, started complaining about the ignorance of CIOs and CISOs regarding the risks for both Operational Technology environments in smart manufacturing and for IoT in connected things.

While these days we can read a lot about the future role of CIOs, the even more important question appears to be the new role of the CISO and what the future IT security organization must look like.

The fundamentals for restructuring the (not only IT) security organization are:

  • Governance and operations must be kept separate.
  • Operational aspects of security must move into the business divisions, e.g. manufacturing or R&D (when e.g. developing connected things)
  • There must be a comprehensive responsibility for security, across business IT, OT (including but not limited to smart manufacturing), and IoT security.

Just as we have legislative, executive, and judiciary split in government, we need to split responsibilities in our organization. That, in consequence, means that the CISO must not be a subordinate to the CIO, but part of the governance organization. Given the current state of cyber risk, the CISO should be a direct report to the board, in particular to the board member owning responsibility for governance, which most commonly is the CFO or COO.

Unfortunately, the role of CISOs is heavily undervalued in many organizations, which might relate back to the days where organizations did not need a CISO but only had a corporate data protection officer with limited responsibilities. That has changed, and it must become reflected in the organizational structure. I have seen large multi-national organizations where the CISO is three levels below the board, which is just ridiculous.

For the (not only) IT security organization, keeping governance and operations separate also means that there is security governance and security operations. Implementing security is an operational task. It must become an integral part of organizational entities. There must not be separate security organizations anymore, but security must be part of each area of IT, wherever applicable to manufacturing, and part of everything from research to support around connected devices. But governance, from guidelines to auditing, is the job of the CISO.

Notably, there is one part of the security organization that appears to be operational, but should belong to the CISOs department: what we commonly call Security Operations Centers (SOCs) is from my perspective part of the governance function, not the operational function within security. Aside from that, it is cross-divisional (Business IT, OT, etc.), thus it is best placed in the CISOs responsibility.

With the broader view on security, beyond business IT, and the hyper-connected environments we already have, we must get rid of siloed approaches. Smart manufacturing is about connecting business IT and manufacturing. Thus, there must be a central responsibility for IT governance, while operational implementation of security must happen in in the various divisions, with well-defined communication and interfaces in between.

As implementing security becomes part of the operational responsibility, it also should become one of the manager’s objectives. If a manager fails in risk identification and mitigation, he has failed in achieving his business targets. As of today, risk ignorance appears to be the better choice for many managers in trying to achieve their targets. Risk mitigation causes cost. This is a challenge from a short-term, personal perspective. From a mid-term perspective, understanding risks, mitigating these or at least preparing for incidents will save money – which is a positive from an enterprise perspective. Fixing audit findings in “panic mode” costs far more than any other approach.

Redefining the role of the CISO the way described above will also help in getting better in dealing with risks ahead of incidents, because the CISO’s job is to identify risks and propose mitigations – not to ignore them.


Why security increases agility, not inhibits it

Jul 30, 2015 by Martin Kuppinger

A common complaint against Information Security (be it IT security, OT security, or IoT security) is that security costs money but doesn’t deliver business benefits. Wrong!

In a short-term perspective, security incurs cost. Thus, quarterly reporting by organizations and short-term targets pressure security to be an afterthought. However, mid-term and long-term, this changes. It obviously is cheaper to code using simple APIs for security functions than hard-coding security into every application and maintaining that code. Application Security Infrastructures reduce cost. Even more, it makes application development more rapid and agile – the security infrastructure can be changed, updated, and enhanced without affecting applications.

Or, to bring up an example from another recent post:

But that is only one part of the problem. The lack of Security by Design and Privacy by Design is also becoming an inhibitor for the Digital Transformation. An essential element of the Digital Transformation is the change of business models, including rapid innovation and (ever-changing) partnerships.

A simple example that illustrates the limitations caused by the lack of security and privacy by design is the black box EDR (Event Data Recorder) becoming increasingly common an increasingly mandatory by legislation. Both automotive vendors and insurance companies are interested in “owning” the data held in such devices. While I come to the complexity of dealing with data access demands and requirements of various parties later in this post, it is obviously impossible to easily solve this conflict with technology that e.g. relies only on a single key for accessing that data. Modern concepts for security and privacy would minimize such conflicts by allowing various parties to have defined and controlled access to information they are entitled to access.

Cynically said: automotive vendors are rushing to roll out new features to succeed in the Digital Transformation, but by failing to do it right, with Security by Design and Privacy by Design, they are struggling with exactly the same transformation. Neither security nor privacy can be an afterthought for succeeding in the Digital Transformation.

Another example is the scenario described in the recently published Lloyd’s report “Business Blackout”. This report describes the cost of cyber-attacks against the US power grid. While this is more about the cost of security as an afterthought, there is also an indirect agility aspect: new regulations will require better security – and then security by design drives agility.

In general, the ability to provide services in these times of ever-changing (and ever-tightening) regulations as well as massive differences in regulations depends on the ability to re-configure your services, instead of re-coding them.

And maybe even Facebook would have been better advised in spending money for security and privacy by design instead of for lawyers and lobbyists in Europe. Then many more Europeans might use Facebook actively then do today, with more controls for privacy they could use to configure Facebook’s behavior.

The good thing, though, is this: once you have prepared your organization for security by design and privacy by design, it becomes more agile. It is ready for faster development of software or connected things and for more agile transformation of business models. It is a one-time investment, so to speak – with massive long-term, as well as near-term benefits.


It really is worse than your nightmares – try Shodan

Jul 28, 2015 by Martin Kuppinger

Shodan is a computer search engine. They call themselves the “world’s first search engine for Internet-connected devices”, including buildings, refrigerators, power plants, the Internet of Things (IoT), webcams, and whatever else you can imagine. Shodan isn’t new. The search engine has been online for several years now. The only new thing is the change in the URL from www.shodanhq.com to www.shodan.io.

When talking about the challenges we are facing in the IoT and in Smart Manufacturing, I commonly bring up Shodan as an example of what is visible today in this hyper-connected world. Interestingly, most CIOs and other Information Security Professionals, not to mention the rest of the world, are unaware of the fact that such a website exists.

Just the fact that there is such a search engine around is scary. It allows searching for everything that is connected to the Internet. It even allows downloading results and creating reports or using that information in other ways. Running automated attacks based on search results is just one example, even while there clearly are “good” use cases as well.

What is even scarier, though, are the results a simple query such as

“default password” country:de

will show. Just run such query. It proves that reality is worse than your worst dreams. When I ran it today, it delivered 664 results containing default passwords of a variety of systems. Even while you could argue that some of these are not current anymore, quite a number of these passwords will do their job.

The important lesson to learn from the fact that there is Shodan (and that there are others around) is to do the best job you can do on security. Understand your potential attackers, know which devices expose themselves on the Internet (and stop the ones that don’t need to from doing so), avoid standard usernames and passwords, change passwords regularly, harden your systems, etc. At least follow the standard best practices for security. And clearly, “security by obscurity” is not the best, not a good, not even an acceptable practice – it never worked and clearly will not in the age of computer search engines.

Furthermore, when providing connected things or moving towards smart manufacturing, first understand that all these connected things will be visible to the Internet. Thus, they can be attacked. Security must not be an afterthought in IoT and Smart Manufacturing, because the attackers already are waiting for you to connect more things or even entire plants.


Connected Vehicle: Security First

Jul 27, 2015 by Martin Kuppinger

The recently discovered remote hack vulnerability of Fiat Chrysler Jeep cars, based on their Uconnect functionality, puts a spotlight on the miserable state of connected vehicle security these days. Another recently published article in a German newspaper not only identified a gap in functionality but also illustrates on how in particular German automotive vendors and suppliers implement (or plan to implement) security in their connected vehicles.

While the U.S. has introduced the Spy Car Act (Security and Privacy in Your Car Act) which is about defining industrywide benchmarks and standards for security and privacy in connected vehicles and forces the industry to collaborate, similar legislation is still lacking in the EU.

The automotive industry currently is in a rush to roll out new smart and digital features (or whatever they perceive as being smart), emulating many other industries facing the need for joining the Digital Transformation. Unfortunately, security is an afterthought, as recent incidents as well as the current trends within the industry indicate.

Ironically, the lack of well thought-out security and privacy features is already becoming an inhibitor for the industry. While the cost of sending out USB sticks with a patch is still considerably low (and the approach is impressively insecure), the cost of calling back 1.4 million cars to the garages is significant, even without speaking of the indirect cost of reputation loss or, if something really goes wrong, the liability issues.

But that is only one part of the problem. The lack of Security by Design and Privacy by Design is also becoming an inhibitor for the Digital Transformation. An essential element of the Digital Transformation is the change of business models, including rapid innovation and (ever-changing) partnerships.

A simple example that illustrates the limitations caused by the lack of security and privacy by design is the black box EDR (Event Data Recorder) becoming increasingly common an increasingly mandatory by legislation. Both automotive vendors and insurance companies are interested in “owning” the data held in such devices. While I come to the complexity of dealing with data access demands and requirements of various parties later in this post, it is obviously impossible to easily solve this conflict with technology that e.g. relies only on a single key for accessing that data. Modern concepts for security and privacy would minimize such conflicts by allowing various parties to have defined and controlled access to information they are entitled to access.

Cynically said: automotive vendors are rushing to roll out new features to succeed in the Digital Transformation, but by failing to do it right, with Security by Design and Privacy by Design, they are struggling with exactly the same transformation. Neither security nor privacy can be an afterthought for succeeding in the Digital Transformation.

From my perspective, there are five essentials the automotive industry must follow to succeed with both the connected vehicle and, in its concept, the Digital Transformation:

  1. Security by Design and Privacy by Design must become essential principles that any developer follows. A well-designed system can be opened up, but a weakly designed system never can be shut down. Simply said: security and privacy by design are not inhibitors, but enablers, because these allow flexible configuration of the vehicles for ever-changing business models and regulations.
  2. Modern hardened implementations of technology are required. Relying on a single key for accessing information of a component in the vehicle or other security concepts dating back decades aren’t adequate anymore for today’s requirements.
  3. Identities and Access Control must become key elements in these new security concepts. Just look at the many things, organizations, and humans around the connected vehicle. There are entertainment systems, engine control, EDR systems, gear control, and many other components. There is the manufacturer, the leasing company, the police in various countries, the insurance company, the garage, the dealer, and many other organizations. There is the driver, the co-driver, the passengers, the owner, etc. Various parties might access some information in certain systems, but might not be entitled to do so in others. Some might only see parts of the EDR data at all times, while others might be entitled to see all of that information after specific incidents. Without a concept of identities, their relations, and for managing their access, e.g. for security and privacy by design, there are too many inhibitors for supporting change in business models and regulations. From my perspective, it is worth spending some time and thoughts in looking at the concept of Life Management Platforms in that context. These concepts and standards such as UMA (User Managed Access) are the foundation for better, future-proof security in connected vehicles.
  4. Standards are another obvious element. It is ridiculous assuming that such complex ecosystems with manufacturers, suppliers, governmental agencies, customers, consumers, etc. can be supported with proprietary concepts.
  5. Finally, it is about solving the patch and update issues. Providing updates by USB stick is as inept as calling back the cars to the garages every “patch Tuesday”. There is a need for a secure approach for regular as well as emergency patches and updates, which most become part of the concept. Again, there is a need for standards, given the fact that every car today consists of (connected) components from a number of suppliers.

Notably, all these points apply to virtually all other areas of IoT (Internet of Things) and Smart Manufacturing. Security must not be an afterthought anymore. The risk for all of us is far too high – and, as mentioned above, done right, security and privacy by design enable rapidly switching to new business models and complying with new regulations, while old school “security” approaches don’t.


Safety vs. security – or both?

Jul 07, 2015 by Martin Kuppinger

When it comes to OT (Operational Technology) security in all its facets, security people from the OT world and IT security professionals quickly can end up in a situation of strong disagreement. Depending on the language they are talking, it might even appear that they seem being divided by a common language. While the discussion in English quickly will end up with a perceived dichotomy between security and safety, e.g. in German it would be “Sicherheit vs. Sicherheit”.

The reason for that is that OT thinking traditionally – and for good reason – is about safety of humans, machines, etc. Other major requirements include availability and reliability. If the assembly line stops, this can quickly become expensive. If reliability issues cause faulty products, it also can cost vast amounts of money.

On the other hand, the common IT security thinking is around security – protecting systems and information and enforcing the CIA – confidentiality, integrity, and availability. Notably, even the perception of the common requirement of availability is slightly different, with IT primarily being interested in not losing data while OT looking for always up. Yes, IT also frequently has requirements such as 99.9% availability. However, sometimes this is unfounded requirement. While it really costs money if your assembly line is out of service, the impact of HR not working for a business day is pretty low.

While IT is keen on patching systems to fix known security issues, OT in tendency is keen on enforcing reliability and, in consequence, availability and security. From that perspective, updates, patches, or even new hardware and software versions are a risk. That is the reason for OT frequently relying on rather old hardware and software. Furthermore, depending on the type of production, maintenance windows might be rare. In areas with continuous production, there is no way of quickly patching and “rebooting”.

Unfortunately, with smart manufacturing and the increased integration of OT environments with IT, the risk exposure is changing. Furthermore, OT environments for quite a long time have become attack targets. Information about such systems is widely available, for instance using the Shodan search engine. The problem: The longer software remains unpatched, the bigger the risk. Simply said: The former concept of focusing purely on safety (and reliability and availability) no longer works in connected OT. On the other hand, the IT thinking also does not work. Many of us have experienced problems and downtimes to due erroneous patches.

There is no simple answer, aside that OT and IT must work hand in hand. It’s, cynically said, not about “death by patch vs. death by attacker”, but about avoiding death at all. From my perspective, the CISO must be responsible for both OT and IT – split responsibilities, ignorance, and stubbornness do not help us in mitigating risks. Layered security, virtualizing existing OT and exposing it as standardized devices with standardized interfaces appears being a valid approach, potentially leading the way towards SDOT (Software-defined OT). Aside of that, providers of OT must rethink their approaches, enabling updates even with small maintenance windows or at runtime, while enforcing stable and reliable environments. Not easy to do, but a premise when moving towards smart manufacturing or Industry 4.0.

One thing to me is clear: Both parties can learn from each other – to the benefit of all.


The business case for user empowerment

Jun 09, 2015 by Martin Kuppinger

At the end of the day, every good idea stays and falls with the business model. If there is no working business model, the best idea will fail. Some ideas appear at a later time and are successful then. Let’s take tablets. I used a Windows tablets back in the days of Windows XP, way before the Apple iPad arrived. But it obviously was too early for widespread adoption (and yes, it was a different concept than the iPad, but one that is quite popular these days again).

So, when talking about user empowerment, the first question must be: Is there a business case? I believe it is, more than ever before. When talking about user empowerment, we are talking about enabling the user to control their data. When looking at the fundamental concept we have outlined initially back in 2012 as Life Management Platforms (there is an updated version available, dating late 2013), this includes the ability of sharing data with other parties in a controlled way. It furthermore is built on the idea on having a centralized repository for personal information – at least logically centralized, physically it might be distributed.

Such centralized data store simplifies management of personal information, from scanned contracts to health data collected via one of these popular activity-tracking wristbands. Furthermore, users can manage their preferences, policies, etc. in a single location.

Thus, it seems to make a lot of sense for instance for health insurance companies to support the concept of Life Management Platforms.

However, there might be a counterargument: The health insurance company wants to get a full grip on the data. But is this really in conflict with supporting user empowerment and concepts such as Life Management Platforms? Honestly, I believe that there is a better business case for Health Insurance Companies in supporting user empowerment. Why?

  1. They get rid of the discussion what should happen to e.g. the data collected with an activity tracker once a customer moves to another health insurance company – the user can just revoke access to that information (OK, the health insurance still will have to care for its copies, but that is easier to solve, particularly within advanced approaches).
  2. However, the customer still might allow access to a pseudonymised version of that data – he (or she) might even do so without being a customer at all, which then would allow health insurance companies to gain access to more statistical information, allowing them to better shape rates and contracts. There might be even a centralized statistical service for the industry, collecting data across all health insurance companies.
  3. Anyway, the most compelling argument from my perspective is another one: It is quite simple to connect to a Life Management Platform. Supporting a variety of activity trackers and convincing the customers that they must rely on a specific one isn’t the best approach. Just connecting to a service that provides health data in a standardized way is simpler and cheaper. And the customer can use the activity tracker he wants or already does – if he wants to share the data and benefit from better rates.

User empowerment does not stand in stark contrast to the business model of most organizations. It is only in conflict with the business models of companies such as Facebook, Google, etc. However, in many cases, the organizations such as retailers, insurance companies, etc. do not really benefit from relying on the data these companies collect – they pay for it and they might even pay twice through unwillingly collecting information that is then sold to the competition.

For most organizations, supporting user empowerment means simplified access to information and less friction by privacy discussions. Yes, the users can revoke access – but companies also might build far better relationships with customers and thus minimize that risk. There are compelling business cases today. And, in contrast to 2012, the world appears being ready for solutions that force user empowerment.

This article has originally appeared in the KuppingerCole Analysts' View newsletter.


Consent – Context – Consequence

May 21, 2015 by Martin Kuppinger

Consent and Context: They are about to change the way we do IT. This is not only about security, where context already is of growing relevance. It is about the way we have to construct most applications and services, particularly the ones dealing with consumer-related data and PII in the broadest sense. Consent and context have consequences. Applications must be constructed such that these consequences can be taken.

Imagine the EU comes up with tighter privacy regulations in the near future. Imagine you are a service provider or organization dealing with customers in various locations. Imagine your customers being more willing to share data – consent with sharing – when they remain in control of data. Imagine that what Telcos must already do, e.g. in at least some EU countries, becoming mandatory for other industries and countries: Handing over customer data to other Telcos and “forgetting” about large parts of that data rapidly.

There are many different scenarios where regulatory changes or changing expectations of customers mandate changes in applications. Consent (and regulations) increasingly control application behavior.

On the other hand, there is context. Mitigating risks is tightly connected to understanding the user context and acting accordingly. The days of black and white security are past. Depending on the context, an authenticated user might be authorized to do more or less.

Simply said: Consent and context have – must mandatorily have – consequences in application behavior. Thus, application (and this includes cloud services) design must take consent and context into account. Consent is about following the principles of Privacy by Design. An application designed for privacy can be opened up if the users or regulations allow. This is quite easy, when done right. Far easier than, for example, adapting an application to tightening privacy regulations. Context is about risk-based authentication and authorization or, in a broader view, APAM (Adaptive, Policy-based Access Management). Again, if an application is designed for adaptiveness, it easily can react to changing requirements. An application with static security is hard to change.

Understanding Consent, Context, and Consequences can save organizations – software companies, cloud service providers, and any organization developing its own software – a lot of money. And it’s not only about cost savings, but agility – flexible software makes business more agile and resilient to changes and increases time-to-market.


Author info

Martin Kuppinger
Founder and Principal Analyst
Profile | All posts
KuppingerCole Blog
KuppingerCole Select
Register now for KuppingerCole Select and get your free 30-day access to a great selection of KuppingerCole research materials and to live training sessions.
Register now
Cloud Risk & Security
Many organizations are concerned about the use of cloud services; the challenge is to securely enable the use of these services without negating and the benefits that they bring. To meet this challenge it is essential to move from IT Management to IT Governance.
KuppingerCole CLASS
Trusted Independent Advice in CLoud ASSurance including a detailed analysis of the Cloud Assurance management tasks in your company.
 KuppingerCole News

 KuppingerCole on Facebook

 KuppingerCole on Twitter

 KuppingerCole on Google+

 KuppingerCole on YouTube

 KuppingerCole at LinkedIn

 Our group at LinkedIn

 Our group at Xing
Imprint       General Terms and Conditions       Terms of Use       Privacy policy
© 2003-2015 KuppingerCole