When I think about managing identities and privileges within an organisation, one of my favorite analogies for the whole privileged identity lifecycle is biblical. Everything starts 'in the beginning' with a super user. Whether someone starts with a server or a workstation, creates on-premise solutions for their network infrastructure or builds out a cloud, they'll always have to start out with an account with god-like power that will control all other accounts accessing that resource going forward in the future.
Now, if you were not there at the set-up of new resources, you'd probably be unaware that there was a super-user account created at the genesis. But that super-user account never goes away and in most cases is used day-to-day, either by someone or something (either applications or automated systems). As time goes on, the knowledge of these super-users accounts, where they are, how they're being used and so on, gets lost. Just as the history of how the bible originated is a mystery to most people except for scholars, so it goes with privileged identities.
As time goes on, things change in the world of IT and, again, most people don't understand the implications. Add new appliances, switches, routers and software and new root accounts pop up. Blend that in with new super-user accounts for things like intrusion detection devices, antivirus systems or DLP and you get a whole new layer of privileges added to the environment. People don't really think about it, they simply interact with it at the user level and the environment continues to evolve and morph.
But when auditors and regulators come in and ask 'Who created all of this?' and ‘Who has access to these accounts?’, you've got a good old fashioned debate on par with creationism and evolution; because there’s no one still around who can answer where the accounts came from and no records detailing who can access them.
Mining the Infrastructure with Privileged Identity Management
So where does privileged identity management play in this metaphor? I like to think of it like being the archeologist of the bunch. When you're managing these identities, your job is to go out and mine the infrastructure, looking for 'fossils,' or those clues that provide your organisation with a view of where those god-like accounts are, how they're being used and what they're being used to do.
It's an important task, because there are plenty of rogue scientists--hackers out in the field--that know all about these fossils. They're also looking for DNA in the bones embedded in the rock that can be used to piece together where the original accounts are in your infrastructure. So much information about these super-user accounts is publicly available, waiting to be mined by the bad guys. Don't believe me? Search Google with the phrase 'default administrator account' and see how many websites there are that list the default account information that will get you into most systems if the logins are not changed. Still don’t believe me? Visit the Default Passwords List website - your passwords are probably there, for the world to see.
Don't kid yourself. Those default logins are lurking in the bedrock. The problem with most organisations today is that the person provisioning new users may do so through a root account without even realizing it. Even if they do know what they're doing, they may not know that these accounts are actually only a subset of all of the privileged accounts out there--many of which have always been accessible through default login information.
The Identity Management Lifecyle
IT folks are somewhat like the priest or the rabbi talking about the bible and conducting well-organized and inspirational services, but not necessarily understanding the history of the materials that they are presenting. Many of the true scholars of the area know information that may shock the flock and those that are leading the flock.
For IT staff, the shock would be if they knew how the process of provisioning and deprovisioning results in many open privileged accounts that can easily be compromised. The process starts with someone getting hired. With a great, wide, wonderful world of systems out there, from an empty mill machine on a factory floor or a key card to get you through the front door, all the way to an SAP system or a really complicated line-of-business system that was written decades ago by an unknown in-house developer, new accounts need to be created to give that employee access to these systems. Some systems may be Windows-based, some Linux-based. It's a smorgasbord.
So, when HR brings someone on board, they have the problem of governance and access in which they have to get these people enrolled into all of the systems they need. The difficulty is that with all these systems out there--legacy and new--you've got to figure out not only what systems they need to access, but what kind of access they're entitled to. In the Windows world it is fairly easy. You just use Active Directory to classify employees in roles for the applications and level of privilege they need and you're done. When they leave the company, you delete them from Active Directory and when they change roles you change their group membership. But enterprise applications creep far beyond the Windows platform and that's the problem. You've got all of these other cultures and religions to deal with as well--and believe me, other operating systems are religions -- plus the cult of SAP and Salesforce to think about.
And while many applications do have Active Directory connectors built into them, the dark secret of it all is that these connectors don't work all that well. Further complicating things, when a company adds new systems, takes systems away or updates them, almost universally these provisioning systems stop working and that ends up leading to more manual work. Over time, these systems just fall apart.
One of the most common reasons the systems fail to work is the problem of paperwork. When someone leaves or joins the company there's usually a mountain of paperwork involved and there is a workflow that has to be taken care of that is partially manual and partially electronic. Now, when people come in to the company, their bosses are screaming for access and that becomes top priority. But when they leave, the sense of urgency just isn't there.
Similarly, when employees change jobs the demand from up top is for new access but no one pressures for the old access to be turned off. So you run into a queuing problem where you can go into any given organisation and potentially see hundreds of people who have been discharged or who have changed their roles and there is one HR person who has to go through the paperwork and go into the systems to get rid of their accounts. A back log inevitably grows. People forget about accounts that are orphaned and left opened to be used by the previous employee or anyone else that knows about the account. The danger is that not only are there low-level accounts in this back log but also privileged accounts with a direct pipeline into the company's most important IT assets.
Bringing in a privileged identity management system automates the digging and the finding of these omnipotent accounts to understand how everything connects together. Putting it in place is a science, one which will better help you control who does what with your most critical data.
And remember, if God created the world in six days, shouldn’t you be able to find and secure all of your privileged accounts in the same amount of time? With the right privileged identity management solution you can.
Privileged Access Lifecycle Management
Banks, insurance companies, and other institutions are faced with the monumental task of managing authorization to mission-critical systems. These organizations have large numbers of internal and external users accessing an increasing number of applications, with each user requiring a different level of security and control requirements. In addition, these organizations must also address identity management concerns that arise from compliance issues related to regulations like SOX, HIPAA, GLBA, and PCI DSS.
High administrative costs due to account maintenance, password resets, inconsistent information, inflexible information technology (IT) environments, silos due to mergers and acquisitions, and aging IT infrastructures make this even more challenging for organizations. Together, these factors are propelling the adoption of privileged lifecycle access management solutions across all industries. Privileged Access Lifecycle Management (PALM) is a technology architecture framework consisting of four continual stages running under a centralized automated platform:
Access to privileged resources; control of privileged resources; monitoring of actions taken on
privileged resources; and remediation to revert changes made on privileged IT resources to a known good state.
Privileged Access Lifecycle Management
Access includes the process of centrally provisioning role based time-bound credentials for privileged access to IT assets in order to facilitate administrative tasks. The process also includes automation for approval of access requests and auditing of access logs.
Control
Control includes the process of centrally managing role based permissions for tasks that can be conducted by administrators once granted access to a privileged IT resource. The process also
includes automation for approval of permission requests and auditing of administrative actions conducted on the system.
Monitor
Monitor includes audit management of logging, recording and overseeing user activities. This process also includes automated workflows for event and I/O log reviews and acknowledgements and centralized audit trails for streamlined audit support and heightened security awareness.
Remediation
Remediation includes the process of refining previously assigned permissions for access and/or control to meet security or compliance objectives, and the capability to centrally roll back system configuration to a previous known acceptable state if required.Automation of the Privileged Access Management Lifecycle includes a central unifying policy platform coupled with an event review engine, that provides controls for and visibility into each stage of the lifecycle.
How to cost justify Privileged Access Lifecycle Management
• Security: Privileged Access is critical for smooth ongoing administration of IT assets. At the same time, it exposes an organization to security risks, especially insider threats.
• Compliance: Privileged Access to critical business systems, if not managed correctly, can introduce significant compliance risks. The ability to provide an audit trail across all stages of the Privileged Access Lifecycle Management is critical for compliance, and is often difficult to achieve in large complex heterogeneous IT environments.
• Reduced Complexity: Effective Privileged Access Lifecycle Management in large heterogeneous environments with multiple administrators, managers and auditors, can be an immensely challenging task.
• Heterogeneous Coverage: An effective PALM solution supports across a broad range of platforms including Windows, UNIX, Linux, AS/400, Active Directory, databases, firewalls, and routers/switches.
Beginning Steps Before Implementing PALM
1. Set Security as a Corporate Goal
Enterprises may have trouble maintaining security because everyone is too busy trying to reach other goals. If you have problems maintaining security in your company, consider adding security as a goal for every level of management.
2. Provide or Enlist in Training as Required
For security to work, everyone needs to know the basic rules. Once they know the rules, it doesn’t hurt to prompt them to follow those rules.
3. Ensure All Managers Understand Security
It is especially important that all members of management understand the risks associated with unsecured systems. Otherwise, management choices may unwittingly jeopardize the company’s reputation, proprietary information, and financial results.
4. Communicate to Management Clearly
Too often, system administrators complain to their terminals instead of their supervisors. Other times, system administrators find that complaining to their supervisors is remarkably like complaining to their terminals.
If you are a manager, make sure that your people have access to your time and attention. When security issues come up, it is important to pay attention. The first line of defense for your network is strong communication with the people behind your machines.
If you are a system administrator, try to ensure that talking to your immediate manager fixes the problems you see from potential or realized misuse of privileges. If it doesn’t, you should be confident enough to reach higher in the management chains to alert for action.
5. Delineate Cross-Organizational Security Support
If your company has a security group and a system administration group, the organization needs to clearly define their roles and responsibilities. For example, are the system administrators responsible for configuring the systems? Is the security group responsible for reporting non-compliance? If no one is officially responsible, nothing will get done. And accountability for resulting problems will many times be shouldered by the non-offending party.
About Philip Lieberman
Philip Lieberman, the founder and president of Lieberman Software, has more than 30 years of experience in the software industry. In addition to his proficiency as a software engineer, Mr. Lieberman is an astute entrepreneur able to perceive shortcomings in existing products on the market, and fill those gaps with innovative solutions. He developed the first products for the privileged identity management space, and continues to introduce new solutions to resolve the security threat of privileged account credentials. Mr. Lieberman has published numerous books and articles on computer science, has taught at UCLA, and has authored many computer science courses for Learning Tree International. He has a B.A. from San Francisco State University.