In part one of this three-part governance blog, “Assessing Your Access Governance Capabilities,” I offered 13 questions designed to help you assess your identity governance maturity. These questions were derived from identity governance principles and guidelines taken from chapter 3.1 of NIST’s Special Publication 800-171 – Protecting Controlled Unclassified Information.

Developing Least Privilege Principles and Policies

Beyond the technology itself, the strength of an organization’s least privileged implementation depends on its approach to defining it. Least privilege should be designed and configured based on how the business owners view their risk and the posture they want to take to protect against it. These questions are important because they form the basis for management taking action and investing in a solution to implement their business and security goals. I talked about measuring risk a couple of weeks ago, which breaks out into two broad categories:

• What vulnerabilities does your sensitive information pose to you, and how do they match current breach trends?
• When a breach happens, what are the predicted costs to your organization for each of the data profiles you are protecting?

From this foundation of measured risk, an organization should define its philosophy and corresponding least privilege processes, defining how aggressively they want to apply it. To do this means it must first be measured. Step 1 is for the responsible business owners to determine the risk that each of the different types of resources poses to them and the restrictions or conditions met before granting access. Examples of account types or roles include individual, shared, group, system, anonymous, guest, emergency, developer, manufacturer, vendor, and temporary. Conditions of access beyond just permissions are things like time of day, day of the week, point of origin, or device familiarity.

Effectively Applying Your Least Privilege Processes

For your access governance solution to be effective, it needs the flexibility to protect all your sensitive resources. Typically, this goes beyond data accessed through services and your unstructured data (Doc, XLS, HTML, CSV, JPG, etc.). Proper coverage is more than casting a wide net; it also requires granularity to enforce the specific policy in place. So, beyond importing identity information, you need the flexibility to manipulate permissions and possibly set the context (device, place, time, etc.) that controls when those permissions can be executed.

Beyond robust automation, your organization needs to monitor your protected information from two perspectives:

• Dedicated monitoring solution to watch who and when specific resources are accessed
• Monitor context and behavior to potentially respond if a risk threshold is exceeded
• Ensure that all monitoring capabilities clearly and reliably associate a session with an identity

Workflows That Work

To assess your permission workflows, you need to evaluate user experience and your governance's reach across your organization's resources. You know that you have a well-implemented permissions workflow solution when it's simple for the users to request and gain access to the resources they need. At the same time, resource owners are still able to protect them. The main vulnerability in this scenario is the proliferation of granted permissions, extending them beyond their desired level. In short, maintaining an environment where only the right people have access to the right resources while keeping the organization both efficient and secure. Below are some key areas to vet out:

• Encompassing governance – the more complete your governance implementation, the less often users will have to go outside of it to gain access. Ideally, all resources that require special permission to gain access should be managed through your governance solution. Conversely, when users are forced to go outside an automated request system, it is more hassle for them and less secure for the organization.
• Simplicity for the requester – the workflow tool needs to be easy to find, simple to use, and accessible when and where the requester needs it, which usually means anytime on any device. Once in the tool, the list of resources needs to be easy to find and granular enough that allow requests to be limited to only what is required.
• Effective approver – this part of the implementation takes the most work to bring together. Core to this requirement is bringing all the information needed for a business level approver to make the best permissions decision and do it quickly. The critical element to this requirement is to present all the relevant information in a way that a business owner can promptly understand what access is needed and the level of risk it imposes. A key objective is to protect against approval rubber stamping; he or she needs to make a judgement based on:
  • Does the requestor merit the access?
  • What is the total risk involved by granting access?

Managing SoD Across Your Organization

In that most organizations run lean, it's not uncommon for employees or contractors to wear many hats, carrying with them a diverse set of responsibilities. In these environments that ensuring separation of duties (SoD) for security, and often compliance, can be elusive. NIST summarizes security intent as "separate the duties of individuals to reduce the risk of malevolent activity." For digital services, common collusion risks are responsibilities like configuration management, quality assurance, testing, system management, programming, network security, etc. Other standard SoD implementations are used to enforce policies designed to mitigate against the risk of fraud and made possible through collusion.

Because SoD violations can span systems and application domains, effective implementation needs to measure the entirety of organizational systems and system components. So, when an approver is "in the trenches," he needs the right information to ask the right questions and identify a change that hasn't been properly vetted. Beyond implementing SoD as a security best practice, organizations that interact with financial services have Sarbanes Oxley Act (SOX) compliance requirements that make it even more critical to get it right. The three most common SoD scenarios that organizations need a robust solution for include:

• Requester/approver workflows – while rubber-stamping permissions approval is a general security issue, providing SoD related information in an easily digestible format for quick decisions is paramount.
• SoD Reviews - organizations should have regular SoD reviews to protect themselves from various threats from over-privileged users. With the right tool, this review can be a quick process.
• SOX Audits – too often, generating reports attesting to compliance is an arduous process, the worst-case scenario being that you have a find. With the proper foundation in place, audits can be essentially a reporting process. 

Maintaining Permissions Integrity

Having the most tuned environment — least privilege without reducing efficiency — requires active and competent participation by the information owners themselves, including periodic access reviews. To have any hope of ferreting out excessive rights, the information owners need to have access to a simple and informational tool. We need to acknowledge that permissions management isn’t high on the information owner’s priority list, so the faster and less painful access reviews are, the more likely they will be a worthwhile security practice. The broadest set of governance data, such as applications and services, employees or their status, risk threshold, etc., need to be searchable. In addition to making it easy to stay on top of permissions management, information owner training on the risks of excessive rights for both information compromises and audit finds is equally valuable.

Placing the white light on your most significant risks ­– the best use of data owners’ time is to draw their attention first to the accounts or permission sets that create the highest risk scenario. Bringing that information to the forefront in those situations and presenting it in a way that is easy to understand allows the highest risk configurations to be the most attention. 

Quick drilldowns – before you can offer drilldowns to information owners, you need to have a comprehensive entitlement repository from which everybody’s access to everything is searchable and manageable. Common types of operations that likely should be offered include:

• Entitlements catalog from which security and owners can search and manage collections, groups, permissions, and other attributes
• Business roles search and view – manage birthright permissions gained from the role as well as searchable roles to find the entitlement sources.

Management consoles should be customizable to allow for specialized views and management of accounts and permissions.

Compliance and Attestation

The following organizational objectives typically drive governance attestation exercises:

• Self-audit conducted either within a department or across the entire organization. These audits are used to measure the effectiveness of current security policies and processes. 
• Internal attestation exercises conducted as part of a risk management initiative to assure a partner or customer that your organization meets specific security criteria or levels.
• External audits conducted by a regulatory agency, such as those found in the financial or health industries, to verify compliance with government mandates, such as PCI, HIPAA, SOX, GDPR. In that audit finds at this level may result in a fine, these external audits tend to drive the internal ones.  

Micro certifications (MC) are used to strengthen your confidence in the attestation. MC’s approach is to continually monitor for any permission changes for the protected resources and verify on the fly that those changes comply with defining criteria. For confidence in the added security of MC’s, you need an implementation that monitors for out-of-band modifications made outside of the governance platform. Administrators are alerted to investigate the permissions change whenever a change is identified.

Ideally, reporting is simply a snapshot of permissions status controlled from a central point of the administration dashboard. Different industries each have their specific set of report requirements, and the best option is a solution that offers a variety of pre-built reports that can be customized.  

In part 3 of this series, I’ll map NetIQ capabilities to the identity governance principles and capabilities discussed in the blog.

More Information

Join our Community. Have technical questions about NetIQ Identity Governance and Administration? Visit the Identity Governance and Administration User Discussion Forum. Keep up with the latest Tips & Info about NetIQ Identity Governance and Administration. Do you have an Idea or Product Enhancement Request about Identity Management? Submit it in the Identity Governance and Administration Idea Exchange. We’d love to hear your thoughts on this blog. Log in or register to comment below.

What Is Identity Governance and Administration?