The main reason for installing a PAM system is to provide greater security to the granting of access to systems at a specialist functionality level.

Editor’s note: This chapter is excerpted from chapter 4 of Identity Management: A Business Perspective.

Benefits

There are some added side benefits:

• Logging and monitoring of access to systems at a privileged level can be enabled. If a user remains online for extended periods of time, an alert can be raised and action taken. While this might not indicate nefarious activity, limiting access and returning users to a lower privileged account can minimize the opportunity for mistakes that might inadvertently cause business disruption.
• PAMs can be configured to automatically notify a manager whenever a privileged account has been accessed. This provides an extra level of monitoring that lessens the likelihood of privileged account abuse.
• PAMs can also be used to provide additional protection to relying systems. For instance, if system administration work is undertaken only in business hours, the PAM system can restrict access to elevated privilege accounts outside business hours.

Drawbacks

There are some issues to contend with when deploying a PAM system:

• Business continuity—centralizing account management in one system creates a business dependency on the system and, in fact, PAM systems become mission-critical infrastructure, for obvious reasons. If a PAM system experiences an outage, it is likely that access to other systems, at a privileged level, will be lost. It is therefore very important that PAM systems are built on high-availability or redundant systems and are adequately backed up. Backup data is also critical and must be adequately protected.
• Audit data—anyone wishing to subvert a system and remove audit trails of covert activity needs access to the system logs of the PAM It is therefore important to ensure that logs are adequately protected in a remote data store. Various technologies can be used to ensure that logs and audit reports remain tamper-proof. These might include storing logs on a protected subnet, the use of encryption, and/or requiring the use of electronic signatures for access.
• Assurance levels—as noted previously, system administration accounts require a high level of authentication, and PAMs give access to multiple systems at these elevated permission levels. If the PAM provides SSO for privileged users to access multiple systems, it is important that the selected authentication level for the PAM system matches the security level of the most stringent account access available from the system. For instance, an account requires strong password authentication for access to a mail system administrator account but also provides access to a medical records system requiring a smartcard certificate. The PAM system must require users to use their smartcard for access to the system, or prompt for a second factor if the user is not authenticated at the required level.

Strategic Approach to PAM

A PAM system acquisition should be approached from a strategic viewpoint that considers the wider implications of managing elevated privileges. Too often a PAM solution is acquired to provide a point solution for a specific problem. This obviates the benefit of comprehensive identity and access management. It is better to consider the management of elevated privileges as one component of a mature IdM environment and leverage the other components as part of this task.

Other aspects of an IdM environment that should be addressed in light of the PAM requirement are:

• SSO—does the PAM solution allow system administration personnel SSO? If there is an SSO solution in place within an organization, what are the rules for including PAM-controlled accounts in the SSO environment?
• Security information and event management (SIEM)—does the PAM system need to communicate with the SIEM system? If the organization uses a SIEM system, is there a need for visibility on out-of-band system administration usage? Any abnormal privileged account usage would normally be visible in the PAM system; the PAM system should also notify the organization’s monitoring and audit facilities of such events.
• Identity federation—in some cases, privileged account access must be given to external For example, a common requirement is for a heating and air-conditioning contractor to have access to a building control system. In this instance, it is important for the system to be part of an identity federation environment that avoids the use of a generic account for the contractor but at the same time does not require the organization to maintain contractor accounts in its identity management system.

A strategic approach treats the PAM requirement as part of a holistic solution for an organization’s identity and access management task. Privileged accounts are but one aspect of the provisioning and access control task. Many IdM solution vendors have a solution for privileged accounts that is integrated with the identity management system. Thus an organization’s PAM requirement should ideally be added to the system requirements list for the IdM environment and not treated in isolation.

Bottom Line

A PAM system is an important component of an organization’s security and data loss prevention solution. PAMs often represents “low-hanging fruit” when it comes to delivering a quick and effective solution to the protection of accounts with elevated permissions. But PAM systems should be part of the organization’s strategic approach to identity and access management and not a “quick fix” as a result of an audit failure.

Conclusion

Access control is the target of IAM environments. There’s no one-size-fits-all because each organization is on its own trajectory from basic authentication to role-based authentication and may or may not have an application for

authorization. Organizations must develop their own approach to role-based systems and determine how to provision into target applications. Options range from the use of AD groups to setting entitlements directly into target system databases.

For organizations that adopt ABAC systems, the ability to modify legacy systems for policy enforcement and develop a policy administration capability is important.

Use Case: StateGov

Q & A

Q. Is ABAC a natural progression from RBAC?

A. No. ABAC is a different approach from RBAC. A mature RBAC environment, whether it provisions in AD groups or directly into relying applications, will satisfy most organizations and should only be replaced by an ABAC deployment if there is a need for:

• A more fine-grained authorization environment that evaluates multiple attributes, including context attributes such as time of day or geo- positioning
• Better governance with centralized policy administration to harmonize policy across multiple applications
• Reduced software development costs by externalizing decision-making, and removing access control logic from computer programs

It is expected that more fine-grained attribute-based access control will be adopted by specific industry sectors. For instance, health care could significantly improve access to medical applications with an ABAC installation that checks a health professional’s credentials to operate a machine before giving access, or checks the hospital’s roster before allowing access to an OT application.

Q. Should an ABAC system be XACML based?

A. Not necessarily. While XACML is arguably the most sophisticated ABAC protocol, there are other options. In fact, NIST strongly supports a Next Generation Access Control model (refer SP-800-162). XACML does, however, provide a complete framework, defining communication protocols between the decision point and the policy information point as well as the request-response messages between an application’s PEP and the decision point. This means that, in a fully compliant deployment, components of the system should be easily swapped out and replaced by components from other suppliers.

It is noted that there are some variants of XACML. For instance, while the XACML protocol is XML-based, due to market pressure, a JSON variant is supported, which allows data between the enforcement point and decision point to be communicated in JSON arrays.

It’s also important to realize that not all XACML system are fully compliant, with system suppliers often developing proprietary extensions for specific purposes.

Q. When is a standalone PAM system indicated rather than using the organization’s identity management system?

A. PAMs are often installed after an audit failure or a data breach as a result of a compromised privileged account. Installing a PAM will immediately fix the problem and provide a level of governance over the management of accounts with elevated privileges.

Ideally a strategic view of account management should be taken, which includes the need for management of system administration and service accounts in the organization’s access control policy and procedures. Often PAMs are deployed after an audit that identifies that there are too many privileged accounts and/or orphaned accounts with elevated privileges that have never been disabled. This does not indicate a need for a PAM; rather, it indicates poor identity management practices that need to be rectified.

Check back for another article excerpt series. Can't wait? Buy Graham's book today at the MC Press Bookstore.