So far this month, we’ve updated the <password policy>, created appropriate <challenge questions>, and come up with a strategy for setting initial passwords. Now we are ready to start training the users and wrap up the month’s activity

Developing user training

Unless you’ve already worked with Michael, chances are that the users at your organization don’t get passwords. This is common: users don’t understand why passwords have to be so complicated or how to effectively transform the rules they are taught into memorable, usable passwords. Go straight to automation with this type of user base and the help desk calls will increase – guaranteed.

The reality is, users will do what’s most convenient to them. If accessing a self-service website is faster and easier than calling the help desk and sitting on hold for a few minutes, they’ll do it. If they have to spend time looking for the site, or if they get frustrated trying to figure out their initial password or how to register questions, they’ll call the help desk instead.

The only way to be successful with a password self-service implementation is to thoroughly train the users, and make it easy for them to use the system. This means:

-        Making sure everyone knows what the password rules are

-        Putting links to the self-service page everywhere you can so users know how to find the page

-        Communicating how the challenge questions work and how to answer them

-        Testing the site on all browser types that might be used to access the self-service site (or clearly communicating which browser types are supported)

-        Helping users understand the limitations of the system (e.g., will the tool be available outside of the corporate network or not?)

Also consider the overall computer literacy of your end-users. Are you rolling out password complexity to some of your users for the first time as part of this implementation? Have those users ever used a computer in a corporate environment? Are they likely to be a computer user at home? If the answer is no, consider a basic computer literacy course first – if they don’t even know how to use a mouse, asking them to come up with an 8-character password with a choice of upper- and lower-case letters, numbers, and punctuation marks will throw them for a loop.

Delivering user training

Spend time delivering the training you’ve developed in ways that work for the users. This may include in-person sessions as well as web-based training. Get management involved – make them early adopters of the system, and have them encourage their departments to participate. Establish a process to ensure that new hires receive this information as part of the standard onboarding sessions. Make sure the training is easily accessible to anyone who needs a refresher. Above all, make sure that end users get the support they need to transition to the new way of doing things – this may entail a little extra up-front work from the help desk, but whomever provides that support needs to be well-versed and make it easy for the users to understand.

Populating the requirements list

At a minimum, this month’s exercise should feed some requirements around challenge questions – how important are selectable questions to the organization? Are one-size-fits-all questions acceptable?

If there are plans to auto-populate the challenge questions from HR, there may be some requirements around the HR integration with identity manager. There may also be requirements on how to get even transient HR data to auto-create initial passwords, if that’s desired.

There may also be some implementation notes – fields that need to be accessible from HR, final challenge questions agreed-upon by the focus group, etc.

Action Recap

This month’s actions are focused on preparing for a successful password self-service implementation:

1. Review and update the password governance documents to ensure that the same password rules apply to all systems and all users
2. Determine how to handle challenge questions and come up with appropriate questions (if needed)
3. Develop and begin to use an initial password formula
4. Develop and thoroughly deliver end-user training, taking the level of computer literacy into consideration
5. Keep the users in the loop – communicate the changes, explain why they are being made, and begin using the new materials (e.g., initial password formula) as soon as possible so they get used to it

How can I help?

Do you need some clarification or additional assistance? Do you have an experience to share with others? Leave a comment below so we can all improve together.

Related posts:

1. Building the Foundation for Successful Password Self-Service Part 4: Initial Passwords
2. Building the Foundation for Successful Password Self-Service: Part 1
3. Building the Foundation for Successful Password Self-Service Part 2: Password Governance

In the last article, we discussed how to establish appropriate challenge questions to facilitate password self-service. But that’s just half of the password self-service equation. The other half has to do with initial passwords, which is the topic of this article.

Initial passwords

All users are assigned an initial password of some sort, which must be reset at the first login (our systems are all configured to force the user to reset their password at first login, right?). How the challenge questions are implemented will determine how the initial password is set up. There are two choices:

-        If users are required to register answers to challenge questions, they need to know their initial password

-        If users’ answers to challenge questions are auto-populated from the HR system, they don’t need to know their initial passsword.

Let’s take a look at both options…

Auto-populated answers to challenge questions

Let’s start with the easy one. If HR elements will be used to auto-populate the challenge questions for the user, then a completely random password can be generated and assigned to each user. The user should then be directed to the self-service site to reset their own password.

Clearly, the auto-populated answers option is the best choice, if it is possible. Not only does it avoid the need for mass communications and compliance to get users to answer their challenge questions, but it eliminates the need to communicate an initial password. The organization also has somewhat more control over the quality of the answers. All of these things help on the security front.

User-answered challenge questions

Now for the next best option, which may be the only option for many organizations (sorry). When users are required to register challenge questions before using the self-service system, then they need to know their initial password. While it may seem like a recipe for disaster, there is benefit and time savings to automating the initial password (especially if you have a very large workforce with a high turnover, as we do at our retail stores).

Consider creating a formula consisting of HR elements so that a unique password can be auto-generated and communicated to users via rules. Elements such as date of birth, initials, date of employment, and middle two digits of social security number (among others) can be used to create the formula (special characters or capitalization can be added if needed to ensure the proper level of password complexity). Since the initial password will be used soon after it is generated, elements with long-term risk of change such as street number of current address could also be used. That’s what makes automated initial passwords easier than automated challenge question responses – because the passwords are used soon after time of hire, and only once, you can get away with using data elements that might not be appropriate for answers that persist indefinitely.

The generated password should be cumbersome and unfriendly enough to encourage the user to register on the self-service system and use it to change their password to something more memorable and desirable, but not so complicated that they can’t get it right and end up calling the help desk. Regrettably, this is much easier said than done – more on that in the next article.

If a formulaic initial password is new to the organization, begin using it as soon as possible to get users in the habit. Have your access services team being assigning the initial password per the formula on all new access requests submitted by the users – getting them used to seeing the formula and resultant password will help them transition to the self-service tool. Of course, what I’m describing here may require some work with HR or others to make the necessary data elements available to the people or system that will be auto-generating these passwords.

Now that we have updated password governance, appropriate challenge questions, and a strategy for setting initial passwords, we are ready to start training the users and wrap up the month’s activity. That is the topic for the next article.

Related posts:

1. Building the Foundation for Successful Password Self-Service: Part 1
2. Building the Foundation for Successful Password Self-Service Part 3: Challenge Questions
3. Building the Foundation for Successful Password Self-Service Part 2: Password Governance

So far we have established the value of properly implementing password self-service and successfully tackled building effective password governance. The next step is to develop “challenge questions.”

Challenge questions – definitely a double-edged sword

A key benefit of any password self-service system is the “forgot password” feature. If a user forgets their password, they click on the link, provide their userID, and are prompted to answer some personal questions to authenticate themselves. If they can answer the questions correctly, they are allowed to reset their password.

This is a big cost savings for most organizations – and a big convenience for users when implemented properly.

It’s a simple concept, but coming up with the right questions can be surprisingly tricky. Here are a few things I have learned while implementing password self-service:

• In reality, users can answer whatever they want to the questions, as long as they remember the answer. Most users don’t realize that and assume they have to answer truthfully, so if they are presented with sensitive questions like mother’s maiden name, they may choose to not use the system rather than make something up.
• It is human nature to remember things that are meaningful more than things that aren’t. If the user is presented with a question that doesn’t have meaning to them – or whose meaning changes over time – they could probably make up an answer, but they might not remember it later.
• If the answers can be easily researched or guessed, the system can be readily compromised. Unfortunately, easy to remember is often synonymous with easy to guess, socially engineer, or research.

Picking the right questions

So what is the best way to develop the questions?

First, determine if there is enough information in the HR system to eliminate the need for developing questions. The easiest way to handle password self-service setup is to auto-populate answers from an HR system so that users don’t have to register answers to questions before using the system. Also, the HR system can continue to update the answers if any of them change over time, allowing for less confusion on point-in-time questions. In this case, care should be taken to avoid asking questions that coworkers would easily know the answer to – such as employee numbers, email addresses, and birthdays. Also keep in mind that the full social security number (or even last four digits thereof) is considered to be a restricted data element that should not be stored in an identity management system.

Although using HR data can be a very simple and effective way to set up the challenge questions, many companies will find that there is not enough usable information in the HR system to make this work – the answers have to be private enough so that others can’t guess them or look them up, but common enough so that the users themselves will know and remember them.

So back to our original question – what is the best way to develop the questions?

Answer: Set up focus groups. Engage HR, InfoSec, management from various areas of the organization, and a sampling of different types of end users to help create questions, and to test their usability. It will be the job of InfoSec to make sure that the questions aren’t too easy to guess or research, and HR will ensure that the questions aren’t offensive to anyone (or violate union-related restrictions, if that applies).

Hopefully, the self-service system allows users to select questions they feel comfortable answering from a larger list. If that’s the case, it greatly simplifies things for the design team because it allows for the creation of a number of questions, and each user can select the subset that they feel is most appropriate for their experience. In fact, organizations that do not yet have a technology selected should add “user-selectable challenge questions” to the requirements list and weight the importance on the higher end.

Some systems, however, don’t allow for question selection – all users have to answer all of the questions presented, which creates an additional layer of complexity:

• The popular questions (mother’s maiden name, city of birth, etc.) are also available as public record – if someone wanted to know that information badly enough, they could find it (this is true regardless of the selectability of questions to answer)
• “Favorites” (favorite movie, favorite food, etc.) can change over time, or they might not apply to all users (e.g., I don’t have a favorite sport so when I’m asked that, it’s hard for me to come up with a memorable answer)
• Family questions can be problematic in this day and age: not everyone has a spouse or a child and increasingly, not everyone has two parents
• Residence questions are more difficult these days: people move around a lot more than they used to
• Education questions can also be problematic. For example, I work in retail and we have a fixed-question system. Some of our employees are high school students, so we can’t ask about high school graduation. Many of our employees have never gone to college even if they are old enough, so we can’t ask questions about that, either.

When faced with a fixed question set, guide the focus group to come up with point-in-time questions that avoid the problems above. For example:

• On what street were you living when you turned 16 years old? (Rarely will there be an employee younger than 16, this level of detail is hard to research, and it allows for multiple residences at that age, but it may also be difficult for the user to remember)
• What is the name of the first high school you attended? (Doesn’t imply graduation, and also allows for attending multiple schools)
• What is the first name of the person who primarily took care of you as a child? (Could be confusing for someone who had two engaged parents, but this question does not imply parents, and it is hard to research. It could be easy to guess by coworkers who get to know the person)

Once the questions are finalized, communicate them to the end-users so they become familiar with the concept. Even if the self-service tool implementation is a few months out, it’s never too early to engage the end users

In the next article, we’ll develop a strategy for creating initial passwords.

Related posts:

1. Building the Foundation for Successful Password Self-Service: Part 1
2. Building the Foundation for Successful Password Self-Service Part 2: Password Governance
3. The Leadership Challenge in Today’s Security Environment

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.

Related posts:

1. Building the Foundation for Successful Password Self-Service: Part 1
2. Policies don’t have to be painful
3. Justification for Security Policy / Awareness Position

Note from Michael: this month we’re going to try something different with this series by breaking the articles up into smaller chunks and serve them on a weekly basis. Same series, same great content, delivered in smaller chunks. Cool?

By now, you’re so sick of userID cleanup that you’re probably wondering why you didn’t select a more pleasant career – like tax collector. The good news is that if you’ve made it this far, your userID cleanup days are over! Congratulations on defeating that monster – it was a big one! As long as processes are in place and being followed to keep the data clean until identity management takes over, you’re home free on userID management. Unfortunately, there are other types of cleanups yet to be done, but those come later so let’s not spoil the moment.

Why all the painful and tedious cleaning and prep with no apparent return? In my experience, the organizations that avoid instant gratification syndrome by taking the time to build a solid foundation run smoother and faster during the balance of the implementation. It all boils down to investment – and paying some dues.

Having a clean user base sets the needed foundation on which to build productive functionality like password self service, which is this month’s topic.

Introducing password self-service

Password self-service is identity management functionality that enables end-users to reset their own password should they forget it. This is done by having the user register (or pre-populating from HR records) answers to some personal questions. If the user forgets their password, they simply click on the “forgot password” link, which takes them to the self-service page. The user supplies their userID and then they are prompted to answer a subset of the questions. If they answer correctly, they are allowed to reset their password. This is common practice on most banking sites, so most of us are familiar with this technology – at least from an end-user perspective.

Password self-service is considered by many to be a good first step in the identity management journey since it promises a significant return on investment (ROI) – done right, it can reduce calls to the help desk by as much as 40%. But only if it’s done right. Proper planning and implementation are critical to successful password self-service. Fail here, and the number of calls to the help desk can actually increase!

The dream of Single Sign-On; the realities of passwords

Let’s talk for a moment about Single Sign-On (SSO) – the holy grail of passwords. Conceptually, SSO means that a user logs in once in the morning, and then all other logins that they’d normally have to perform throughout the day are handled magically (and hopefully securely) in the background to save the user a lot of brain cells in remembering various passwords, and time in typing them. Nice idea, but in practice single sign-on simply does not exist.

Today’s reality is reduced sign-on – meaning, there is some background magic, but the biggest part is just having synchronized passwords across the environment, and/or encouraging/enforcing the use of directory-based authentication. Both of these practices achieve the same result: only one password to remember instead of many. Users still have to type their password in when prompted, but they only have to remember the one password.

As we focus on password self-service – which allows for synchronization and resets on the primary directories – it is natural to be lured by the sweet song of SSO, but resist the urge – believe it or not, SSO has little or no ROI.

How is that possible?

What costs money is the time spent by help desk personnel in resetting passwords – on average it may take three minutes for a help desk representative to reset one password, and a large company may get thousands of calls per month. Actually typing in known passwords takes very little time – let’s call it five seconds per typing. If a user has to type in their password 10 times per day, as long as they know the password this amounts to less than one minute per day of effort. Unless the organization is just that high-performing that an extra minute per day matters, the ROI is negligible when compared to the cost and effort it takes to fully integrate the systems to enable SSO.

Now, if a full integration is warranted for other reasons – like auto provisioning/deprovisioning and user recertification, which have a positive ROI – SSO can be a nice added bonus. More on this in August.

Approach

The key to a successful password self-service implementation is having underlying processes that can handle being automated, and also making sure that end-users understand what to do, why, and how. This means:

1. Having an appropriate password policy
2. Determining usable challenge questions
3. Creating an initial password formula that works
4. Developing a robust training plan for your users
5. Training the users

Each of these processes has some nuances and gotchas that – if properly handled – can really ease the implementation. We’ll get started with password policies in the next article and cover all five processes over the course of the month.

Related posts:

1. Identity Management in 13 Easy Steps
2. The First Brick: Understanding Identity Management
3. Data Cleanup Part 2: Other UserIDs

On Friday, The Web Squeeze posted an interview with me. We had a blast discussing backups, passwords, building more secure websites and a bit about the human paradox and Into the Breach.

I’m impressed with The Web Squeeze (http://thewebsqueeze.com/) and hope to get more involved in additional ways.

In the meantime, I really enjoyed the banter (enough to really get me thinking about getting a new show or two going) and the professionalism extended to me by Jacob and Linda.

I hope you consider taking a listen; more – share it with the folks you know in development and see what they say. Use this as a springboard for conversations.

Here is the link: http://www.thewebsqueeze.com/freelance-podcasts/into-the-breach.html

Related posts:

1. Into the Breach – Audio Series – Chapter 6 (Implementing The Strategy to Protect Information)
2. Into the Breach – Audio Series – Chapter 5 (The Strategy to Protect Information)
3. Join the Journey — Launching Catalyst onTour and coming to your house!

Join Michael Santarcangelo as he reveals essentials for businesses to protect their information. Michael was a featured guest at the Microsoft Small Business Summit to share strategies from his book, Into the Breach: Protect Your Business by Managing People, Information and Risk. In this segment, Michael discusses the impact of security breaches, the hidden damages and explains his personal experience in how these events can happen to anyone. The segment ends with Michael outlining 5 steps every business must take to protect information.

No related posts.

No related posts.