21.02.2014 by Martin Kuppinger
Microsoft Rights Management Services (RMS) is a solution that might help Secure Information Sharing become a topic for the masses, at least at the enterprise level. I just recently wrote a report on the product. However, as with any Information Security technology – especially ones that are Cloud-based – there are questions about security details.
For Microsoft Azure RMS specifically, it is worthwhile to look at this post. It describes in detail how RMS protects and consumes documents. The other document worth having a look at is a whitepaper Microsoft published a while ago. That whitepaper goes (among other topics) into detail regarding two important aspects:
- The various deployment options from fully Cloud to “pretty much on premises”
- The BYOK (Bring Your Own Key) approach that allows doing a lot of things based on local HSMs (Hardware Security Modules)
These might answer some of the questions you might have concerning security and confidentiality of Microsoft RMS.
20.02.2014 by Martin Kuppinger
In my new report “Entitlement & Access Governance”, published yesterday, I introduce a new term and abbreviation: EAG for Entitlement & Access Governance. Thanks to Dave Kearns for proposing that term – I like it because it reflects what this is about.
EAG describes approaches that some vendors currently call “Data Governance,” but enhanced and extended. It is about combining fine-grained entitlement management at the system level and the cross-system Identity Provisioning and Access Governance. We see an increasing number of vendors moving in that direction, closing the gap between Identity Provisioning and Access Governance on the one hand and the system-level, detailed management of entitlements on the other.
There always has been a predetermined breaking point between the Identity Provisioning layer (and the Access Governance layer on top of Provisioning) and the system-level entitlement management. While Identity Provisioning typically works on the level of, for instance, Active Directory global groups or SAP business roles, many systems (including Active Directory and SAP) have another system-specific hierarchical entitlement structure below that level. System administrators manage these. If a system administrator changes low-level entitlements – instance.g., the ACLs of a local group that is part of a global group – the Identity Provisioning system will not recognize that, at least not in most common deployments today. It will also become too complex to manage everything top-down, so there is a reason for system-level solutions.
EAG balances these requirements, by centralizing functions such as request and approval while leaving system-specific tasks local. I expect EAG to become the next big evolutionary step in core IAM, with some preliminary solutions already out there.
14.02.2014 by Martin Kuppinger
NIST (the US National Institute of Standards and Technology) has now released the final version of their Cybersecurity Framework for Critical Infrastructures. As requested, this is not a set of new regulations or fundamentally new concepts for security, but, to quote my colleague Prof. Dr. Sachar Paulus, a “well-written summary document incorporating different approaches (lifecycle views, maturity views, communication aspects, risk posture analysis…) that helps getting an operational grasp on the necessary activities, and therefore well-suited as a guideline or education piece for technicians / practitioners. It is by no means sufficient (nor meant) to replace an ISMS (Information Security Management System). So: good that it exists, but in essence nothing new.”
However, it is very likely that it will lead, in consequence, to new regulations. Sector-specific agencies are obliged to engage in a consultative process with various governmental agencies to determine whether current regulations are sufficient for the critical infrastructures sector. This in consequence most likely will lead to new regulations.
When looking at the framework and its Appendix A, the fact that there is nothing really new in this framework becomes obvious. That leads to a simple bit of advice: follow common good practices and standards such as ISO 27001:2013 and CoBIT 5. If there will be a need for new regulations in future, this will happen because too many organizations in critical infrastructures do not follow established good practices.
10.02.2014 by Martin Kuppinger
It is a common scenario in organizations that the marketing department, business development, or the sales department asks the IT department to support social logins on some of the corporate websites, including eCommerce sites. Admittedly, IT also sometimes proposes such functionality, having technology on hand that allows for simple integration of such social logins.
My colleagues and I have written about that topic before, primarily from an information security standpoint and as part of the BYOI (Bring Your Own Identity) theme. The main reason for social logins is that users want a simple way to login to applications. Social logins are convenient, but limited in their identity assurance.
However, there is another aspect of social logins I have not seen discussed so far, neither by IT nor by marketing people. It is about customer relationships, confidentiality, and competitive advantage.
So let us have a look at what happens when using social logins. Let us assume that there is a customer C that wants to access the eCommerce website E. He might use a social login, maybe using social network F or G. There might be an advertising service A as well in the game and another business B, which as well relies on social logins or works with that advertising service. Finally, there are other websites, let us call them D so that we have all letters A to G in that example.
C logs into F (in fact, he remains logged in there). C accesses E. When he does that, he has the social login and BYOI experience. However, at that time F learns that C is a customer of E. F uses, as part of its business model, that information to provide information to an advertising service A (depending on the social network, that might be its own or an external one). B relies on that service as well. Thus, when C starts looking at other websites (D) that also might work with A, he might see adverts for goods related to his interests – adverts of business E or business B. Even more information might flow, being available in F because C has left a comment somewhere or – as part of today’s or tomorrow’s business models – being sold by A or F to the competitor B.
This theoretical example shows that supporting social logins could be an excellent way to inform competitors about the interests of customers. Does this really make sense from a marketing perspective?
In essence, social logins obviously are not what marketing should request. But what are the alternatives for BYOI? FIDO Alliance, which we covered several times in our posts, might become a game changer in that area. They are not an IdP, but they support the flexible use of strong authentication methods. Combined for instance with integrated strong authentication in devices such as fingerprint readers in mobile devices, this is a way for users to easily register to websites with strong authentication, without relying on a social login. However, the FIDO Alliance does not provide the user’s attributes in a way social networks can do. Some of the authenticators could, other IdPs (Identity Providers) could also, based on a strong yet simple authentication.
BYOI is not about social logins only. It is about enabling the user to use their “own” identity – a preferred one, chosen by him – with various relying parties (RPs). From a marketing perspective, it might be well worth while to evaluate the alternatives to social logins when requesting support for BYOI.
Learn more about the challenges of social logins in our webinar next week (in German language): “Marketing will das Facebook-Login. Und was ist mit der Informationssicherheit?”
06.02.2014 by Martin Kuppinger
Recently, there have been various articles on the NSA and GCHQ (Britain’s Government Communications Headquarter) collecting date from “leaky apps”, including data from Angry Birds, Google Maps, Facebook, Flickr, or Twitter.
Look at another story in that context: There have been extensions to Google’s Chrome browser that have started to spam users with advertisements. What happened? Advertisement companies acquired the extensions and used them in a way unintended by the original developers. Once installed, there is no control over what extensions are allowed to do or not. The extensions are updated automatically. How simple would it be for criminals or for national intelligence services to do the same? Clearly, they would not push spam, but pull information.
Back to the apps (by the way, the same applies to the traditional web counterparts of these services, if there are ones)… The combination of a lack of security and the excessive collection of data about users and their behavior is what we would call a “gefundenes Fressen” in German. A ready-to-serve meal for the NSA.
Simply said: NSA and the others just piggyback on these services. Without companies such as Facebook, Google, or Apple, NSA would have a much harder play. The Reform Government Surveillance Alliance, driven by AOL, Apple, Facebook, Google, LinkedIn, Microsoft, Twitter, and Yahoo, probably is the most hypocritical alliance these days. Why did Apple not implement more user control of the collection of data by apps from the very beginning? Less data would have been available to the NSA. Instead of doing that, they removed apps helping the user in controlling app behavior from their appstore. Why did Twitter, Facebook et al not encrypt traffic from the very beginning? Some of the service providers do now, but most started far too late. NSA then still could have requested access to data, but it would have made the life and work of intelligence services tougher.
With more user control, more user consent, more built-in security, and options for the user to choose between free services (paid in the “privacy” currency) and paid services that ensure privacy, this situation would change. Yes, the companies would have to re-think their business models. But that is what will happen anyway, after Edward Snowden has opened the Pandora’s Box. Attention is still mainly on the behavior of intelligence services. But that will inevitably change.
When talking about hypocritical behavior, there are others to blame as well. The users that naively assume that there is such a thing as a free lunch when using free services on the Internet. There isn’t. If you know and accept this, fine. But then you shouldn’t blame the NSA for using that data as well.
However, my favorite example of hypocritical behavior is another one. My daily newspaper – and yes, I still read a print newspaper – is the local “Stuttgarter Zeitung”. Recently, they devoted the entire page 2 to the loss of privacy on the Internet. On the other hand, a few days ago they applauded themselves for having passed the number of 5,000 (or so) Facebook friends for their online presence. They have a Facebook plug-in on the website of their online edition. They support registering for commenting on articles in the online edition based on your Facebook account. Isn’t that the perfect example of hypocritical behavior: on one hand letting Facebook collect more data and on the other bashing on them?
It’s the decision each of us must make, which currency he wants to use to pay for services. However, we should have a choice. And the ones who are the enablers for the NSA collecting masses of data shouldn’t blame NSA – NSA just piggybacks on their business model. They could change this, starting with encryption of traffic and collecting only the minimum of required information, and ending with providing alternatives to “paying in the currency of privacy”. But we should end this hypocrisy. Bruce Schneier recently published two interesting articles that fit in the context here and here.
04.02.2014 by Martin Kuppinger
A recent discussion in the “Identity Management Specialists Group” on LinkedIn had the title “On point. Agree. Gartner says attributes are the new role for identity?”
I wondered a little about a rather old discussion appearing again. In fact, there rarely has been pure role-based access control. On the other hand, roles are one of the most important, if not the single most important attribute in attribute-based access control. There is no conflict, but we are just looking at the natural evolution.
I commented on another of these discussions nearly two years ago in another post. If you want more detail, have a look at the podcast recording of the KuppingerCole Webinar “Enterprise Role Management Done Right: Build the Bridge between Business and IT”.
We clearly will need some kind of abstraction – we might call that roles or something else. But clearly, the discussion about “attributes instead of roles” is an artificial one, miles away from practical experience and use cases.
19.12.2013 by Martin Kuppinger
On Monday this week, we have published the KuppingerCole Predictions and Recommendations for 2014. They differ from other publications of people looking into the crystal ball in one important aspect: we not only provide our predictions, but also recommendations. More on that below.
Information Security is in constant flux. With the changing threat landscape, as well as a steady stream of innovations, demand for Information Security solutions is both growing and re-focusing. Based on new offerings and changing demand, KuppingerCole predicts several major changes in the Information Security market. KuppingerCole specifically identified the following areas where we see massive change in 2014:
- Software Defined Networking (SDN) – Software Defined Computing Infrastructures (SDCI)
- Integrated Real-time Network Security Analytics
- Cloud IAM (Identity and Access Management)
- Digital, Smart Manufacturing & Smart Infrastructure: ICS & SCADA
- API Economy
- IoEE (Internet of Everything and Everyone)
- BYOI (Bring Your Own Identity) and Biometric Authentication
- Big Data
- Cloud Service Provider Selection and Assurance
- Ubiquitous Encryption
The document provides both predictions and recommendations. The latter focus on how organizations should react to the changes we predict. It is not always best to jump on every trend and hype – in many cases, it is about defining strategies first and performing organizational changes before starting to implement new types of technologies. Do not rely on predictions only.
Have a look at our document. The best place to learn more about these topics is the upcoming European Identity and Cloud Conference (EIC) 2014, Munich, May 13th to 16th. And don’t miss all our current and upcoming research on these topics.
13.12.2013 by Martin Kuppinger
I have read many predictions recently that SDN (Software Defined Networking) is the next big thing in IT. Wrong. It is not. It is just a small piece in a bigger story. And just looking at SDN is not sufficient.
The next big thing is SDCI – Software Defined Computing Infrastructure. This is about “software-defining” everything. Hardware virtualization – “software defining hardware”, so to speak – is a reality. Software Defined Storage is becoming increasingly popular. SDN is another element. A number of vendors, such as VMware, talk about a Software Defined Cloud Datacenter. I don’t like that term, because the “Cloud” element might be nice from a marketing perspective, but tends to narrow things down to a specific form of Computing Infrastructure. So I will use SDCI for now.
When looking at SDCI versus SDN, claiming that SDN is the next big thing is like inventing a locomotive but no rail infrastructure. It is only about solving a portion of the problem, from a technical, network-centric view.
However, SDCI is far more than that. It is about managing how business services are operated on a flexible computing infrastructure, which must include all elements of this infrastructure. It is about defining the policies for the entire infrastructure. This is an interesting challenge, because it is not about network, storage or other technical policies anymore, but about translating the business policies. Regulatory compliance, security requirements, availability, performance, but also the willingness of business to pay for a certain level of service – all that flows into policies that define how infrastructure is used and how to balance various requirements.
SDCI also will revolutionize security, in particular network security. In dynamic environments, there is no place for traditional firewalls anymore, but there are fantastic new opportunities for securing information. Such infrastructures allow us to manage security consistently across “machines”, storage, and network, in the context of business policies and in the context of identities. Instead of having multiple disparate approaches to security – a little bit of firewall here, a little bit of endpoint security here, some IAM there, etc. – we are heading towards integrated security. This integrated security still can be layered, but it will be layered in an integrated manner, unlike “layered” security today, which means using multiple levels of disparate security where no one really knows how good the combined result really is – just because there is no integration, no consistent view, no consistent policies.
The security aspect is another reason why SDNs for themselves are not what we need. SDNs are about continuing segregation. They allow us to repeat mistakes on a higher level. SDCI allows us to do things better. That’s the reason why SDCI is the next big thing – and it will become a real big thing.
04.12.2013 by Martin Kuppinger
In various discussions over the past month, mainly in the context of Privilege Management, I raised the (somewhat provocative) claim that shared accounts are a bad thing per se and that we must avoid these accounts. The counterargument I got, though, was that sometimes it is just impossible to do so.
There were various examples. One is that users in production environments need a functional account to quickly access PCs and perform some tasks. Another is that such technical user accounts are required when building n-tier applications to, for instance, access databases. Administrators commonly tend to groan when approaches for avoiding the use of shared accounts such as root are considered.
There are many more examples, but when you look at reality there are sufficient examples and reasons of how it is possible to avoid shared accounts (or at least their use). In many healthcare environments, fast user switching has been used for years now. The strict regulations in this sector frequently have led to implementing Enterprise Single Sign-On tools that allow for rapid authentication and access to applications with an individual account. These solutions frequently have replaced previously used shared functional accounts. So why shouldn’t they work in other environments as well?
When looking at n-tier applications, it is worth it to dive somewhat deeper into end-to-end security. There are many ways to implement end-to-end security. Standards such as OAuth 2.0 make it far easier to implement such concepts. Provisioning tools have supported database systems and other systems for a number of years. Oracle has just “re-invented” database security in its Oracle Database 12c, with tight integration into IAM (Identity and Access Management). Aside from the argument that end-to-end security just does not work (which is wrong), I sometimes hear the argument that this is too complex to do. I don’t think so. It is different to do. It requires a well-thought-out Application Security Infrastructure, something I was writing about years ago. It requires changing the way software architecture and software development are done. But in many, many cases technical accounts are primarily used due to convenience reasons – architects and developers just do not want to consider alternative solutions. And then there always is the “killer argument” of time to market, which is not necessarily valid.
When I look at administrators, I know about many scenarios where root or Windows Administrator accounts are rarely used, except for firefighting operations. The administrators and operators instead rely on functionally restricted, personal accounts they use aside of their other personal accounts they use for standard operations such as eMail access. That works well and it does not hinder them from doing a good job in administration and operations. But it requires thoroughly thinking about the concept for these accounts.
So there are many good reasons to get rid of shared accounts, but few, if any, valid ones to continue using them. Given that these accounts are amongst the single biggest security risks, it is worth starting to rethink their use and openly consider alternative solutions. Privilege Management tools are just helping with the symptoms. It is time to start addressing the cause of this security risk.
Have a look at our KuppingerCole reports. We will publish a new Leadership Compass on Privilege Management soon. Given that shared accounts are a reality and will not disappear quickly, you might need a tool to better secure these. Have a look at the new report, which will help you selecting the right vendor for your challenges.
03.12.2013 by Martin Kuppinger
Last week, the German BSI (Bundesamt für Sicherheit in der Informationstechnik, the Federal Office for IT Security), published a document named “ICS-Security-Kompendium”. ICS stands for “Industrial Control Systems”. This is the first comprehensive advisory document published by the German BSI on this topic so far. The BSI puts specific emphasis on two facts:
- ICS are widely used in critical infrastructures, e.g. utilities, transport, traffic control, etc.
- ICS are increasingly connected – there is no “air gap” anymore for many of these systems
It is definitely worth having a look at the document, because it provides an in-depth analysis of security risks, best practices for securing such infrastructures, and a methodology for ICS audits. Furthermore it has a chapter on upcoming trends such as the impact of the IoT (Internet of Things) and the so-called “Industry 4.0” and of Cloud architectures in industrial environments. Industry 4.0 stands for the 4th industrial revolution, where factories are organizing themselves – the factory of the future.
As much as I appreciate such publication, it lacks – from my perspective – an additional view of two major areas that are tightly connected to ICS security:
- Aside from the ICS systems, there is a lot more of IT in manufacturing environments that frequently is not in scope with the corporate IT Security and Information Security departments. Aside from attacks to such systems, for instance in the area of PLM/PDM (Product Lifecycle/Data Management), there are standard PCs that might serve as entry point for attacks.
- This directly leads to the second aspect: It is not only about technical security, but about re-thinking the organizational approach to Information Security in all areas within an organization, i.e. a holistic view on all IT and information. Separating ICS and manufacturing IT from the “business IT” does not make sense.
The latter becomes clear when looking at new business cases such as the connected vehicle, smart metering, or simply remote control of HVAC (heating, ventilation, and air conditioning) and other systems in households (or industry). In all these scenarios, there are new business cases that lead to connecting both sides of IT.
Also have a look at our KuppingerCole research on these issues, such as the KuppingerCole report on critical infrastructures in finance industry (not about iCS) and the KuppingerCole report on managing risks to critical infrastructure.