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.
31.03.2011 by Martin Kuppinger
In the recent months I’ve done a lot of research around database security, talking with vendors like Oracle, IBM (Guardium), Sentrigo (now McAfee), Imperva, Bitkoo, and some others as well as with several end user organizations who either are using database security products or evaluating those technologies.
When looking at the market it is very important to understand that it is not a homogeneous market. The different solutions range from firewalls to specific tools for label security or data masking. Some are tightly integrated with databases, others are non-intrusive. I will provide a broad overview in an upcoming research note which covers the entire database security market and the vendors therein.
But before selecting the right vendor and the right tool for your database environment, you should ask and answer another question: How does this fit into your overall IT security strategy and implementation? I’m not a friend of point solutions in security. Solving one problem without looking at all the other problems doesn’t necessarily increase the overall level of security achieved. It might give a better feeling, but frequently there is still too much attack surface left.
Just think about securing your databases with a firewall. Some of the attack surfaces left are:
- Security issues in the applications which access data in the databases
- Administrative actions
- All actions performed locally at the database server
- Copying or deleting the database with administrative access at the operating system level
And that’s just a short and incomplete list. From a strategic perspective, you have to look at how to secure the stack. Recently I’ve been at a customer who discussed about where to best start securing his apps. As a quick start, I proposed to him to build a simple spreadsheet with his (defined) 30 most critical apps and the stack these apps are using – including operating system, application platforms, hypervisors, and for sure the databases. That simple spreadsheet will give him an impression of the dependencies he has to keep in mind – it visualizes that security isn’t about point solutions.
I don’t say you should not invest in database security – but that should be one element of security. Thus, database security has to be put into context.
One interesting aspect within that are database firewalls. There are some firewalls out there, inspecting packets for SQL traffic based on policies. However, when inspecting packets – why not for everything? CIFS/SMB traffic to file servers? Web service security? That would allow to apply a consistent set of policies wherever it is appropriate. It would provide a consistent layer of security. For sure that won’t solve all problems, but the advantage in contrast to having a “DB firewall”, a “Sharepoint firewall”, a “CIFS/SMB firewall”, and so on is obvious. Another example is around privileged user (account, identity, access) management, e.g PxM. That is important for database management systems, but it is important for other types of systems (apps, operating system, hypervisors, network appliances,…) as well. I’d opt for a solution which covers all.
For sure there are as well many database specific aspects of security, like data masking and others. And given that there isn’t the “multi-purpose firewall” or other solutions which cover everything out there, it is about using several solutions. There is also some good reason for specialized tools – easier to implement, easier to manage, more specific features. However, they should be used as part of an overall strategy, not as isolated point solutions. Customers have to look at it from that perspective – and vendors should move forward to provide more integrated solutions over time.
Good security is achieved by strategy, not by tactics.
EIC 2011: Munich, May 10th to 13th – the place to be for IAM, GRC, Cloud Security, Database Security, and more…
15.02.2011 by Martin Kuppinger
Quest today announced that they will acquire e-DMZ Security, a PxM (Privileged Access, Account, Identity, User Management) vendor. That comes to no surprise given that PxM has been one of the last (relatively) white spots at the IAM map of Quest Software. Quest is further completing its portfolio, being a full-service provider for IAM now and offering one of the most complete portfolios in the market.
The e-DMZ portfolio consists of several module, providing different types of PxM capabilities:
- Managing passwords for privileged accounts in a central repository
- Application password management to get passwords out of scripts and applications
- Privileged session management to monitor and manage sessions of privileged users
- Privileged command management with the capability to limit the commands allowed within sessions
With these features, Quest closes some gaps. Together with products like Quest Authentication Services, Quest One ActiveEntry, or Quest ActiveRoles Server, plus the monitoring capabilities provided by different Quest tools, Quest can provide a comprehensive set of features to manage all types of accounts and their access.
However, that will require (like with virtually any PxM platform) some integration work to be done given that customers have to work with several products. One-stop-shopping doesn’t necessarily lead to a single-step-installation. With the increasing number of tools, Quest will have to look on how to provide the balance between integration and modularity to its customers. Integration in the sense of providing well integrated solutions which are up and running quickly – and modularity with focus of the Quest approach to provide focused products instead of monstrous suites.
Whilst not being the most prominent vendor in the PxM market, e-DMZ security provides good support as well for UNIX/Linux as for Windows environments, which fits well into the Quest portfolio.
27.01.2011 by Martin Kuppinger
Some days ago, a vendor talked at an analyst meeting about the relationship between virtualization and security. The argument was: At the hypervisor you can combine network security management, server security management and some other aspects of security management – I can’t remember everything. Thus virtualization increases security, because you have one point of control.
Right – as long as you can control what administrators and operators are doing. Unfortunately, that’s not the case in typical virtualization environments. There is no PxM (Privileged Access, Account, Identity, User) Management at all. And in that case, combining everything is a problem, a nightmare from a compliance point-of-view. For sure there is a value in having a single point-of-control, but only if you are able to adequatly control use of this.
I’ve asked the speaker about the solutions around PxM offered by that vendor – there weren’t any.
Without specific virtualization security solutions, PxM being one very important amongst them, there is a virtualization security risk. There is a potential of increasing security by using adequate technology, which is provided by several vendors. But claiming that there is a value of combining a lot of highly elevated administrative actions without being able to manage them doesn’t make any sense.
For a comprehensive overview on what customers expect around virtualization security just have a look at that survey.
And don’t forget to register for EIC 2011 and Cloud 2011.
09.12.2010 by Martin Kuppinger
There is a good reason to add functionality to specific types of devices, especially in the network. Doing security at the edge can be highly efficient. Thus, implementing for example PEPs (Policy Enforcement Points) for access management into network access gateways is, from the perspective of efficiency, a pretty good idea. And when looking at what the network vendors like Cisco, F5 Networks, and all the others are doing, the number of add-ons which can be added to these devices and run locally has increased significantly.
Basically the same, still at a lower level, could be observed around VMs. Hypervisors tend to become more capable of doing things. And especially when looking to client-side hypervisors, there is a slight tendency to add more and more features to them - starting with AV done centrally for many machines and probably ending with supporting the standard user interface at some point of time in the future.
However, as well network devices as hypervisors aren’t really secure by design. If we look at how many specific tools are out there to better protect these devices or software layers and if we look at the risks around privileged accounts especially for network equipment and VMs, it becomes obvious that there is a gap between what these devices or hypervisors can do and how they are protected themselves. Every new feature also provides sort of a new attack surface – in an environment which isn’t the dream of a security guy (maybe it’s the dream of an attacker, but that’s what we want to avoid).
The best would be to make these devices and software layers secure by design. Granular access control, centralized policy management based on XACML, tightly integrated with the provisioning and PxM (Privileged “whatever – user, identity, access, account” Management), standard auditing interfaces which allow integration across devices from different vendors without heavy integration work at the (still too technical) SIEM layer, and so on.
However, that will take some time. In the meantime there are two things you can do: Balance the values and the risks – can you afford to pay the price in security for better efficiency? And protect these devices consistently by management tools, PxM with support for these devices, maybe together with SSO, and auditing and analysis mechanisms.
22.12.2009 by Martin Kuppinger
I’ve blogged several times about PAM (Privileged Account/Access Management) in the last few months, stating that I expect more integration of PAM with existing IAM applications (Here, here, here, and here). Now IBM is moving forward on this with their PIM offering. It’s interesting to observe what IBM is doing these days. There hadn’t been that many news from IBM for a pretty long time. But this year IBM has increased its speed significantly. The release of TIM 5.1 with many significant improvements, their approaches around risk and compliance with tight integration to TIM as well as other IBM products, and some other news prove that IBM is back on track and should be rated amongst the leading vendors in the broader IAM space again – with some interesting visions and strategies, becoming a trendsetter in some areas.
Amongst them is their PIM approach. IBM isn’t new in that market. Their TAMOS (Tivoli Access Manager for Operating Systems) products is out for many years. But right now, they are building a solution which is tightly integrated with TIM and TAM E-SSO (Tivoli Access Manager Enterprise Single Sign-On). Shared IDs can be provisioned by TIM and TIM as well manages pools of shared IDs. TAM E-SSO checks out/in shared IDs when accessing apps. Thus, IBM drives the tight integration of provisioning, E-SSO, and PAM which definitely makes sense. However, the integration is currently within the IBM world of IAM apps, not beyond. Anyhow, this is an interesting approach and IBM is currently leading this trend.
The solution is currently deployed as IBM Global Strategic Solution, e.g. bei IBM Global Services to selected customers, thus at the first stage to general availability. But for existing IBM customers (TIM, TAM E-SSO) it is definitely worth to talk with IBM about that.
An interesting question in this context is whether this will affect the overall PAM market. First of all, it confirms what I’ve described earlier in my blogs: There will be a convergence of PAM with provisioning and other IAM solutions. And with more vendors providing such integrations (some are providing some integration or are working on that), customers are likely to pick the “integrated PAM”. However, there is no doubt that at that point of time the PAM specialists in most cases have more feature-rich offerings, which might complement even these integrated PAM approaches or replace them in case that specific features are required. Thus, there will be a “stand-alone” PAM market for the foreseeable time. On the other hand I expect more acquisitions of PAM specialists to happen given that the larger vendors might want to speed-up the development of their integrated PAM offerings by acquiring a product and integrating it. Another point to mention: IBM’s approach shows that PAM is moving out of a niche towards a mainstream IAM market segment.
For now, it is to me to wish you all a MERRY CHRISTMAS and a HAPPY NEW YEAR!
And don’t miss EIC 2010 and Cloud 2010 next year! Hope to see you there and to discuss some of my thoughts with you in person.
11.08.2009 by Martin Kuppinger
These days I have been talking with Siemens on enhancements for their DirX Identity product, a provisioning tool (and, by the way, a pretty good one). Amongst the new features is some support for Privileged Account Management (PAM). That’s interesting. I’ve blogged some time ago about the possibility of provisioning vendors starting to acquire PAM vendors and adding these capabilities to their provisioning products.
Siemens didn’t acquire but implemented some own technology. They mainly focus on providing one-time passwords for the use of privileged accounts and re-setting these passwords after use. This is combined with strong authentication, using smartcards. In fact it is sort of a mix between product (resetting passwords and all that stuff) and project (adding strong authentication using other products). But finally they became a pioneer in integrating PAM with provisioning.
There is no doubt that the leading PAM suites like the ones provided by Cyber-Ark or Lieberman Software provide a much broader feature set. However, integrating that with provisioning tools, identity lifecycles, and existing (self) service interfaces is a valid approach. I expect other vendors to follow, adding PAM support as well. However, the specialists will provide a more sophisticated solution at least for a pretty long period of time (unless they become acquired…).
But what Siemens has done proves my thesis on PAM moving into provisioning, servicing the specific requirements of customers. And it proves that PAM is moving from a niche topic towards a mainstream technology in the broader IAM market.
Regarding the term PAM (or PIM or PUM): I prefer Privileged Account Management because it is about accounts which are associated to a person and their digital identity. The user is sometimes associated with an account, sometimes more understood as a construct in between, e.g. a user-ID with some accounts associated and sometimes the situation that some person with one digital identity could have multiple user-IDs. For what is managed, PAM seems to be the most appropriate term, from my point of view.
24.06.2009 by Martin Kuppinger
IBM yesterday has announced its Tivoli Identity Manager 5.1. If you read the list of new features you might end up with the same question like me: Why is it only version 5.1, e.g. a minor (.1) release instead of TIM 6? Amongst the new features are fundamental things like Role Management, SoD support, attestation and, last not least, support for some Privileged Account Management (or Privileged Identity Management, the term IBM is using). With other words: IBM has significantly expanded the feature set of its product, mainly adding a lot of IAM-GRC features to what TIM delivers. Given that they have some other interesting solutions in the GRC space, especially for analytics and dashboards, IBM definitely improves its positioning in that emerging market segment.
So the GRC stuff is one of the new areas in TIM 5.1. That’s nice, but we have seen that before. Many vendors have either added such features to their products or have released separate GRC platforms – with advantages and disadvantages in both approaches. IBM in fact has tied in that area.
Much more interesting is the addition of PIM capabilities to a provisioning solution. Even while not every aspect of PIM will be solved by what TIM 5.1 delivers, that fulfills my expectations of PIM becoming more and more part of provisioning tools – which is just logical, given that it is about managing accounts. IBM is the first vendor in the market who delivers an integration in that area. Novell might become a close follower given that they have recently acquired a PIM vendor.
With these additions, IBM would have gould reasons to name the release of TIM as version 6.0 instead of 5.1. But understanding the reasons for version numbers is definitely amongst the hardest things in IT.
However, IBM shows that they are intensively acting to improve their positioning in the IAM and GRC market space. Being one of the first big companies which had entered that market, there hasn’t been that much evolution for some time. But now IBM is definitely back and moving forward significantly, acting as a strong competitor for the other players in the market. And once they deliver on full GRC solutions, beyond IAM-GRC and access controls (and IBM is amongst the ones who might deliver on that given their strengths in areas like SIEM, ITSM, and others…) IBM might even further improve its positioning.
26.03.2009 by Martin Kuppinger
The PAM/PIM/PUM (Privileged Account/Identity/User Management; I prefer PAM) market is one of the boom markets in IT. I’ve blogged about that recently (here and here). And I’ve talked with many vendors in that market segment about what they are currently delivering and about what they have in mind for the future. These briefings and the ongoing analysis on PAM proves my thesis that it is still a relatively immature market (not saying that all the products are immature – there are some really good tools out there…).
The PAM market currently is in the typical situation of all emerging markets:
- There are mainly small vendors.
- First large vendors are entering the market, mainly through acquisitions.
- There is no “standard feature set” but many different approaches to solve the problems of PAM.
The latter part is particular interesting to me. Besides the frequently limited support for different platforms and applications as well as for different types of privileged accounts, there are many different technical approaches and features. Some vendors focus on limiting administrative capabilities, other store passwords centrally, some support single sign-on features and so on. Last week I had a briefing with Cyber-Ark which recently announced their PIM Suite v5. Adam Bosnian of Cyber-Ark had a slide in his presentation which showed the evolution from their first solution towards the state of their new suite of PAM solutions. That included aspects like
- Privileged Password Management
- Privileged User Provisioning
- Privileged SSO
- Privileged Session Management
- On-Demand Privileges
That list shows that there are many element. When talking with Novell about their Fortefi deal (not really an acquisition, more sort of an asset deal), they also talked about different elements like managing (and limiting) the access as well as auditing privileged access.
Even while some vendors (like Cyber-Ark) are adding more and more features, there is, from my perspective, still no complete solution which fully addresses every part of the PAM problem. Thus it is important first to analyze the specific requirements before choosing a PAM platform. And: Any selection should keep in mind that privileged accounts are found in every operating system as well as in many applications (including the technical users).
I’m convinced that we’ll observe to things within the next 24 months:
- The PAM tools will converge to a common standard feature set plus some additional capabilities – like it has happened for example in the are of Client Lifecycle Management some time ago.
- There will be some acquisitions of smaller vendors, mainly by the established players in the IAM market. They will start integrating PAM into their suites.
- There will be, on the other hand, new vendors which become visible – especially because there are several small vendors out there which have solved that problem for a small number of enterprise customers and specific platforms sometimes years ago. Some of them and probably some start-ups will enter the market.
Don’t forget to attend my webinar today on another hot topic, Cloud Computing.
And you definitely should attend the European Identity Conference.
12.03.2009 by Martin Kuppinger
Over the course of the last few months, PAM (Privileged Account Management), also called PIM (Privileged Identity Management) or PUM (Privileged User Management) became increasingly popular. The main driving force behind this increase in popularity are the auditors, which more frequently look at the state of privileged accounts and, in many cases, detect and criticize shortcomings in that area.
Privileged accounts include administrative accounts (UNIX/Linux root accounts, Windows administrators), system accounts, service accounts, and technical users. It is important not to limit the scope of PAM to root account management. There are far more privileged accounts which have to be covered by PAM solutions. Privileged accounts are at high risk, because they have all or many or at least some sensitive access rights. And privileged accounts typically aren’t personal user accounts but specific types of accounts which in some cases (root accounts, administrators, and to some degree technical users) are actively used by several users.
In fact it is a combination of three factors which puts privileged accounts at risk: The broad range of access controls assigned to this accounts (up to full access), the lack of a clear responsibility for these accounts and thus a reliable life cycle management, and the fact that at least some of these accounts are used by different people and thus the credentials tend to become common knowledge.
The vendors in the PAM space support different approaches to deal with these issues, including restricted access, automatically generated one-time passwords, and a better support for lifecycle management. Given the technical differences between operating systems, there have to be differences in the approaches. Over time, we will need (and we expect, from an analyst perspective) more comprehensive tools which support several of these approaches.
However, the current state of the PAM market shows that there is still a long way to go. There are several strong solutions as well for Unix/Linux as for Windows environments. But tools which support both “operating system worlds” are still missing. The integration with existing lifecycle management solutions (e.g. identity provisioning) is, if existing, typically week. PAM is, despite the fact that some of the point solutions are out for years, still sort of an emerging market. With the increasing awareness and increasing sales two things are very likely to happen:
- Established vendors in the IAM space will start acquiring PAM specialists and integrate these tools with their existing offerings. Novell has been amongst the first with their Fortefi acquisition (correctly: the asset deal) and has a clear vision for integrating the new Novell Privileged User Management with other Novell offerings and to expand the functionality. Quest has as well a tool in its portfolio.
- The feature sets of existing products will be enhanced. It is the typical phase of “feature comparison checklists” where vendors try to add some features which customers find valuable in competitive products. That as well will include an increasing support for as well Unix/Linux as Windows environments.
Despite the fact, that PAM still is sort of an emerging market with many smaller vendors, the risks associated with privileged accounts make it mandatory for many organizations to either invest in PAM or to expand their investments beyond some core systems (like the critical AIX or Solaris servers) to other platforms.
By the way: We’ll provide a lot more information and thoughts around PAM in an upcoming webinar (German Language) as well as at our European Identity Conference in May.