Identity is who we are. It’s what we do and how we do it. In the digital realm, our identities are part of what affords access to the systems, tools, accounts, and functionality that make it possible to perform job responsibilities and effectively contribute to the organizations for which we work. In the workplace, employees don’t typically have provenance over one’s own digital identity, and should rarely have management over the access that identity provides (a system of checks and balances ought to be in place for admins). Along with this comes a considerable IT and security burden.
Identity in today’s enterprises is complex and cumbersome, but information security teams have long known that identity and access management are an adversary’s gateway to protected information. Particularly in larger companies, where churn is higher and more opportunity for employees to move up, down and sideways exists, IT teams have a difficult time keeping track of identity and access management (IDAM), despite the availability of automated solutions on the market. Why does IDAM continue to be a problem? Because tools don’t fix everything, processes are broken, and new technologies like cloud and mobile introduce obstacles at every turn.
An organization serious about protecting its data needs to get serious about managing identity and access management. Doing so isn’t an easy task, but one that should take precedence over some of the shinier and fancier and more fun things security pros get to do. Who wants to manage Active Directory when there is interesting malware to hunt?
InfoSec Insider spoke with Jonathan Sander, VP of Product Strategy at Lieberman Software, to get a better understanding of why IDAM is such a challenge and what security teams can do—collaboratively with IT and operations teams—to start inching towards the goal line of more accurate and secure identity and access management.
One of the easiest ways for an adversary to breach an organization is through stolen identities. We’ve seen it over and over, yet companies continue to struggle with it. Why is that?
Sander: The trouble with identity is that it’s part of everything technology touches, and it’s becoming more central as organizations move to cloud and towards full digital transformation. What is the first thing the IT department needs to do when a new employee joins the company? Create an identity so that person can log on and become productive. But it’s never just one identity. As IT has grown in layers, each layer has come with its own layer of identity as well. If this new employee needs to touch applications deployed ten years ago, three years ago, and the SaaS applications just recently rolled out, it’s likely the employee will have three different identities to utilize all of these tools. Some organizations are able to offer employees single sign-on, but that doesn’t eliminate the problem entirely; three separate identity footprints will still need to be managed. Three is just an example, an easy number; the number of identities and connected applications will be significantly higher for any organization that’s been around for a number of years and has gone through many waves of IT transformation.
Complexity in identity management is also exacerbated by the one constant in every organization: change. As people join, move, and leave, they create a wake of identity turbulence. While many organizations have cultivated decent processes that accommodate new employees (to overcome productivity challenges), and employees leaving (to overcome regulatory challenges), there is often a huge gap in processes that can manage internal job changes for which the employee acquires new responsibilities. When a person’s role shifts from a business perspective, it’s logical that his or her access should adjust alongside it. Often, though, the reality is that the employee simply accrues access as she or he moves. This leaves senior employees with layers of access that reflect his/her first job and associated responsibilities all the way through to the current one. If an employee has moved between lines of business and levels of responsibility, the result can be someone with a huge amount of access, at least, and access that violates separation of duties regulations, at worst.
The “privilege” in privileged access management indicates that special rights have been granted, yet so many companies run with privilege on regular user accounts. Why?
Privilege is tricky because, as humans, we want to trust the people we work with. We work together every day, know about colleagues’ personal lives, and therefore trust that coworkers are inclined to do the right thing. Organizations trust their IT folks, and so they give them the privileges they ask for, assuming the “do no wrong” principle. From the employee side, if I’m the admin, I likely want my job to be as easy as possible and may want the full power of my administrative rights attached to my regular account so that extra steps don’t have to be taken in my day to day work. When a security practitioner raises to executives the danger of providing open access, a common response is, “We trust our people.” Of course we all trust someone until the day they do something they shouldn’t do—accidentally or out of spite. Unfortunately, the trust problem simply can’t account for the instance the employee goes from being trustworthy to being a threat.
Often misapplied access is also a reflection of how IT rolls out applications and other technology. If you’re building a new application to test and model for deployment, you’ll generally choose the easiest options—including running it with easily managed and accessed identities. That may mean an application or process runs as a normal user. As that technology is pushed through its lifecycle toward production deployment, it can be easier to add privileges and rights to the account that is now embedded into the application rather than changing the identity and risking other consequences, like breaking the app or not being able to access it. Once the app or process is fully deployed, the result is an identity which is far overprovisioned and may be in use by what should be a non-privileged user, effectively, as a service account.
The most common form of too much admin power, however, is when a non-privileged user has local admin authority on her/his desktop. This is done for the convenience of both IT and the user. If the user wants to install a different web browser, a new application, or other seemingly harmless tool, they can do it without wasting IT’s time. That said, admin privileges on individual desktops or laptops presents a giant risk, because a user who can install any new application at will can also become a conduit for malware unwillingly by clicking on the wrong thing.
What privileged accounts should be running, and how should organizations limit them?
Every single thing in IT, on premises or in the cloud, has at least one associated admin credential. Limiting privilege is often out of the [user] organization’s control. One exception to this is when internally deploying or writing applications. The basic rule is to create distinct privileged accounts to have differentiated functions that are easily understood, controlled, and maintained. If that’s too complex to determine at the outset of a project, IT and security teams should create as few as possible. By their very nature, privileged accounts defy attempts to limit them. In the end, teams need to grant as many rights as whatever enabled processes require.
The best way to mitigate the risk associated with privileged accounts is to ensure that all use of them is temporal and tracked. No human should have constant access to a privileged account. When a person needs privilege, a predetermined process with built-in checks, commensurate with associated risk, should be triggered. A “break the glass” process may be instituted, as well, to enable emergency access; that process should trigger significant levels of scrutiny, though, so that any use of “emergency privilege” will become immediately known to many others in the organization, including security, IT, and business executives.
Another disturbing quality of privileged accounts is that they can mask the true identity of the user (which makes the account a perfect vehicle for wrongdoing). When a user logs on as root, the IT or security team can’t see the person behind the credentials. If eight admin users know a root password, it can’t be determined who was doing work as root at that time. However, if root access during a specified time period is tracked, the possibilities of who was using the account can be narrowed, which means other users can be exonerated if anything malicious, suspicious, or inappropriate occurred.
What are some tips for running privileged accounts?
Service accounts are an organization’s weakest point in the world of privileged accounts. Because they are hard to swap or change once a service is running, they tend to stay in place with the same password for lengthy periods. Since they are also connected directly to running applications, many people often know the long-unchanged password. It’s easy to find people using service accounts as a shortcut to processes since access is available and the accounts come coupled with powerful privileges. When designing applications and building backup, continuity, and high availability, teams should also implement a plan for how and when service account passwords will be changed. At very least, this should happen any time someone comes or goes within the admin group.
Passwords, themselves, are a problem, too. Many passwords sit in application configuration files, backup scripts, and/or connection strings for databases completely in the clear for anyone to see. Many organizations use complex orchestration platforms and scripting to automate many aspects of their application management and systems deployment, so why not use these to change out passwords as well? Organizations may not be able to alter the applications and systems from requiring storage of passwords in the clear, but at least security teams can make passwords’ value a moving target.
In addition, people are commonly given a password only when a session is required. If you hand someone the password for a privileged account, they can use it however and whenever they like. If the system is provisioned to create sessions launched as a specific user, then that user is only going to be able to do whatever that session allows. This process can be applied at the application layer, too. In this case, the user logs in as a database administrator (DBA) with his DBA rights by launching the database management application instead of putting them on the server with a full session with those elevated rights.
If your organization has Linux systems and you have not already done so, disable the ability to login remotely as the root user. Users should always log in with a personal or generic low-power account and then elevate to root.
Gartner suggests that companies should “use contextual and risk-appropriate authentication for privileged access.” What does that practically mean?
If an organization has created a mechanism to control privileged accounts, contextual and risk-based authentication means making sure a user must perform extra steps when extra risk is involved. That may mean that any time someone wants to access Amazon Web Services (AWS) as a portal admin user, she must authenticate with multi-factor so that the security department has extra assurance the person is who she claims to be since she’s using a high risk user ID. That may also mean that even though a user is allowed to use the AD Domain Admin ID when he is in the office, he may be barred from using it if logged in from a VPN or perhaps even from a remote and/or particular location. This will cut down on unauthorized use and privilege abuse, and, theoretically, stop malicious users from accessing your organization’s data, networks, and applications.
