In my last article, we explored how a properly implemented password self-service mechanism can yield a quick and early return on the identity management journey. Password self-service is a cornerstone in the foundation for reduced sign-on (which is essentially what SSO promised to be).

But before we jump in on the password self-service technology, let’s set the people/process foundation. The first step is effective password governance via policy and standards. I hear the groans, but no worries – I promise it won’t be that bad.

Governance Primer

The terms “policy,” “standard,” and “guideline” are often misused. In an effort to set the record straight and make sure that for the purposes of this series we’re all on the same page, let’s review the terms and their definitions.

A policy is a terse, high-level document that specifies what must be done, but not how. A company typically has one all-encompassing security policy that covers a variety of topics: identification, authentication, authorization, etc. The security policy should be fairly short and refer significantly to other documents for details. It also uses authoritative words like “shall” and “must” and avoids conditional words like  “should” and “guideline.” Since policies are high-level, they should stand the test of time without requiring much revision.

A standard is a prescriptive document that explains how the policy statements will be implemented given certain conditions. While they can be short, they tend to be longer than policy documents (since there is often a lot more ground to cover).  For example, if the policy specifies the need for system hardening, the organization might need to create hardening standards for each of the platforms in use (e.g., Windows, UNIX, etc.), and/or for the specific usage of each platform (e.g., hardening standards for DMZ systems, hardening standards for financial systems, etc.). Standards are often technology- or concept-specific, and require more frequent update over time to keep up with changing needs and upgraded system versions.

A guideline is a primer that can help users or administrators apply the standards. It provides educational guidance, and sometimes also includes “nice to haves” that can’t be supported technically.

There is one other document type: a procedure. Procedures simply provide step-by-step instructions on how to implement a particular instruction that is set forth in the standard – for example, there may be a procedure on how to access and configure the UNIX password settings.

Guidelines are suggested, procedures are mandatory.

Building password governance

The growing list of compliance requirements (PCI, SOX, HIPAA, etc), combined with the varying capabilities of an organization’s technologies (those legacy dinosaurs probably have a lot of limitations) have often translated into different password settings on different systems. For an effective password self-service implementation, this has to be reversed – consistency across systems is imperative.

So let’s work through the governance hierarchy as it pertains to passwords, starting at the top.

First, review the corporate password policy and ensure it covers these concepts with appropriate wording:

  • Password standards are enforced consistently across the enterprise (i.e., although the system may not be able to technically enforce an element, it can accept use of the element)
  • Password standards shall comply with the corporate policy and also ensure compliance as required by applicable external regulations
  • Where technically feasible, centralized authentication must be used (e.g., directory authentication) – this will bring the organization closer to SSO over time

Next, review the corporate password standard(s) (note – some password elements may be part of hardening or other system standards) and ensure that the following elements are clearly specified:

  • Minimum length must be lowest common denominator that is applicable to all systems and that still complies with regulatory requirements
  • Complexity must comply with regulatory requirements and be supportable by all systems (if not enforcible, at least usable)
  • Minimum/maximum age and history – including non-technical enforcement mechanisms for those legacy systems that do not support these elements
  • Password rules don’t vary for different user types (e.g., employees, administrators, contractors)

Finally, ensure that any guidelines or procedures related to passwords align with whatever updates are made to the policy and standard(s).

If updates were made to any of the governance documents, be sure to communicate the changes to the user base and help them understand why the changes are being made. Although some may balk at the change, most will recognize that the move to consistency will actually make their lives easier. Also be sure to explain that the changes were made to prepare them for the new features that will come, which will further improve their experience.

In the next article, we’ll discuss developing challenge questions.

About the Author Ioana Bazavan Justus

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

Don't know where to start?

Check out Security Catalyst Office Hours to meet your peers and celebrate the good, help each other, and figure out your best next step. We meet each Friday… and it’s free to attend.