Here’s a situation we see often: an organization recognizes that it needs to improve its identity and access management (IAM) approach, and wants to invest in a technology solution, but it has minimal IAM policies in place. Maybe it has an understanding around creating complex passwords and how frequently they expire, for example, but it hasn’t yet articulated any critical policies around data retention, user authentication, or BYO devices.
Why does this matter? Because policies are at the heart of governance—and governance is the foundation for a successful IAM program. If you haven’t decided on the policies, controls, and standards that will guide your key identity and access functions, then you’re overlooking an important step with consequences for your entire organization’s approach to risk.
What Are IAM Policies?
IAM policies represent your company’s risk appetite: they codify the boundaries around access and identity that your company’s executives are comfortable accepting. The National Institute of Standards and Technology (NIST) defines access control policies as “high-level requirements that specify how access is managed and who may access information under what circumstances.” Policies also demonstrate compliance with important regulations, and they are the framework around which any IGA tool is implemented.
Your Policies Define Your Risk
A chief executive’s job is to make decisions and allocate capital toward the right investments within the company: often that means weighing investments in innovation vs. investments in risk mitigation. Regulations—and the policies around them—can serve as a forcing function for companies to protect themselves and their customers from risk, knowing that their competitors must also comply with the same regulations.
Policy definition is essentially a risk treatment process in which you’re helping your CEO define how they will respond to, mitigate, or transfer risk. This is an important fact to consider, because many IAM programs are set up under IT (reporting to the CIO or CISO), or even the help desk, and many CISOs well-schooled in cybersecurity policy don’t necessarily understand IAM policy.
Tooling decisions frequently drive policy decisions, and the truth is that if you haven’t figured out what IAM tool settings need to be informed by policy before the tool is implemented, whoever is configuring the tool gets to decide. This should get the attention of your chief executive, because ultimately, your CEO owns the risk that the tool is configured to manage. By defining your policies in the right way, at the right time, and by the right person, your organization officially declares its risk appetite with the appropriate level of authority.
What Can Happen Without Policies
When organizations lapse on policy definition, their policies end up being created by people with zero authority to define appropriate limits. For example, let’s say your organization doesn’t have a policy around bring-your-own (BYO) devices. An employee comes in one day and asks IT to put her work email on her cell phone. The IT rep helping her isn’t sure what to do—no one has requested this before and no one’s provided instructions for how to handle it—so they decide to approve it. But in truth, the IT rep doesn’t have the authority to make this security decision on behalf of the organization. By trying to address a request in the moment—and without a firm, referenceable policy in place—that rep has actually put the organization in jeopardy.
We also see situations where people are simply unaware of existing policies, or fail to enforce them properly. For example, if you’re not currently using automation or IGA tools, you might be enforcing policy on an adhoc basis. And if you are using IGA tools, you really need to have policies in place beforehand. Otherwise, when you install the tool, the person at the controls of that tool is going to end up defining the whole organization’s IAM risk appetite.
How to Develop IAM Policies
Policy development sometimes gets a bad rap. Many organizations have onerous change controls around policies, requiring prolonged layers of review and approval from various departments and steering committees. Often these stringent change controls are an attempt to create policies with an “auditable control.”
This is a good reason to define your policies at a high level whenever possible. By capturing the essential intention of each policy, and then articulating the details within the control standards themselves, you provide your organization with room to adapt to change without changing your risk appetite. For example, “you shall …” statements commonly regulate and control access to identity-based information. Your policy might be, “You shall have a complex password”; then you’ll define “complex password” in the standards and procedures associated with that policy. That way, as you change your definition of what constitutes a complex password, you can change your standards without having to change your policy.
General IAM Policies and Standards
If you’re new to IAM policy creation, you’ll want to start with an umbrella IAM policy that sets the scope of what your IAM program owns. Some organizations line up their policies to NIST’s standard controls list, and some use the European ISO 27001 controls, and some use a mix of both. Organizations that are obligated to adhere to regulatory requirements must be aware of them and have policies written for them. When multiple frameworks are required, you can crosswalk your policy library to ensure all control requirements in all frameworks are addressed in your policy library. Once your policy library is in place, you’ll want to call out all the standards and procedures associated with your policies.
Here’s a brief list of the kinds of policies and standards most organizations capture:
- IAM Policy
- IGA Standard
- Access Mgmt Standard
- PAM Standard
- Directory + Authentication Standard
These IAM-influenced policies/standards might require the input of people outside of IT:
- Data Retention Policy/Standard
- Data Protection Policy/Standard
- Password Policy/Standard
- Remote Access Policy/Standard
Show Us Your Policies
When we ask organizations whether they’d like us to look at their policy library as part of our advisory engagement, many jump at the opportunity because they recognize it’s a critical exercise before implementing an IGA solution. For example, many businesses that have policies around passwords or multifactor authentication (MFA) are missing other policies considered minimum viable for an effective IAM program. Following a policy audit we also meet with compliance to review controls such as Sarbanes-Oxley (SOX). It’s not uncommon that controls will exist without policies, or that different departments (legal, finance, IT) have interpreted regulations in different ways. An audit is a great way to discover which policies you need and don’t have, which policies lack consensus, and which ones may need to be re-written.
Policy Questions to Ask
Following are some questions to ask inside your organization to help you determine whether you need to work on your policies.
- Have your IAM policies and standards been reviewed recently?
- Have your policies/standards been properly circulated within your organization?
- Do your policies reflect the risk treatment of the leaders who have the authority to make decisions and take responsibility?
- Are you thinking about deploying IAM tools that will effectively put in place controls about policy?
Policy definition is a foundational component of any IAM program, and it’s among the many competencies in which our advisors have deep experience. Get in touch with us to learn more.
Comments are closed.