Sean R. Nicholson

As the centralized point of access to organizational information, your Intranet portal may also represent a potential security risk. This is especially true if your portal is accessible to employees via the Internet. If your Intranet authentication is tied to your Active Directory or LDAP, be sure to put policies in place that ensure that your employees change their passwords on a periodic basis. In addition, be sure to encourage (or require) employees to use “strong” passwords, that are comprised of a combination of alpha characters, numbers, symbols and mixed cases.

Unfortunately, according to Wired Magazine the most common password successfully used in a recent Hotmail attack was “123456″. Yes, that’s correct…virtually the same password used by Mel Brooks in Spaceballs to secure his luggage.

As an Intranet professional, it’s important that your employee communications focus on employee education around the topic of frequent password changes, password strength, and their ability to identify and avoid password phishing scams. The Journal of Accountancy provides a great analysis of different types of passwords and their ability to be compromised, as well as a five step process that can be followed to analyze your existing application password strength.

1. Start by developing a full understanding of how your computer system stores passwords.

2. Determine whether your encryption method is powerful enough to safeguard your system, and ensure users choose passwords wisely.

3. If your analysis reveals that your password security is inadequate, begin your search for improvements at the lower end of the cost spectrum.

4. If your assessment reveals that you need an entirely new password management system, look for “yes” answers to each of the following four questions when you evaluate products. (click here to view the additional 4 questions)

5. Regardless of how confident you are in the accuracy and completeness of your security assessment and any remedial solutions you may choose, consider conducting a penetration test.

Source: Journal of Accountancy, July 2009.

If you haven’t run a recent campaign reminding employees of their responsibility to keep corporate information secure, it might be a good time to put one together and teach your employees how to avoid weak passwords and phishing scams.

Angie Cullen

When selecting an Identity Management Application, don’t expected it to integrate seamlessly with every application in your enterprise. Work toward using the tool as a “simpler” sign-on solution instead of a “single” sign-on solution. Setting that correct expectation with your sponsors and users will ensure that they have the right perception of how the tool will work.

Sean R. Nicholson

Who isn’t interested in accomplishing Single Sign-On? You know, that nirvana of Identity Management where users only ever have to sign on to their local workstation and then have completely unfettered access to applications throughout the enterprise. While this concept may sound great  to end-users and executives, it’s an absolute nightmare concept for IT personnel and application administrators.

The Wild, Wild West In An Enterprise With No Identity Management Infrastructure

If you have ever been in an organization with no Identity Management infrastructure or strategy, you probably know how bad it can be…and the larger the organization, the worse it gets. When working with one Fortune 100 company in recent years, I found myself with 15 different User names and passwords on my first day. After asking around whether I was doing something wrong, one of my co-workers indicated “No…that’s just the way we do things here.” Let’s see, I had a login for my desktop, one for the Intranet portal, another for the expense management system, one for my project tracking system, the list went on and on. And to make things worse, each of these different applications had separate password expiration policies, so I was anticipating a future where my passwords were quickly out of sync.

Soon, I was relegated to having to manage my passwords in a password utility called KeePass. Obviously not ideal, but it beat the heck out of having to reset my passwords every time I tried to login because I couldn’t remember my password or getting locked out of the application due to failed attempts. On a side note, I had a conversation with an exec who informed me that most of the corporate executives were keeping their passwords on a piece of paper under their keyboard.

Putting All Your Corporate Identities Into One Basket…A Potential Single Sign-On Nightmare

The flipside to the wild, wild west is a highly organized, very restrictive identity management strategy, but even this scenario can have its downsides. While working with a customer recently that used a common enterprise IdM application to manage a single sign-on environment, the entire enterprise was brought to a grinding halt when the identity policies for their application were corrupted. The end result, no users in their enterprise were able to login to any application in the environment. Basically, their back-office business was brought to a grinding halt until the policies were able to be restored.

The real kicker? This particular organization had also tied their website customer portal accounts to their IdM system, so their entire business was brought to a standstill. Not only were employees irritated at the outage, but customers began flooding the call centers with calls and the call center reps weren’t able to access their CRM system. While watching this fiasco unroll, I began to clearly understand situations where the concept of single sign-on can actually be a bad thing. Every egg in one basket just doesn’t seem like a good idea.

The other downside to true single sign-on is that once an account has been compromised, the hacker has access to your entire infrastructure. This means that users who walk away from their workstations without locking them present a MASSIVE risk to your enterprise. It also places more accountability on your IT professionals who are working on users desktops. Think of the desktop technician who assists an executive with an issue and, during the course of the their assistance, is able to access systems using the executive account. Obviously, these professionals have a high level of accountability in the first place, but having unfettered access to all information inside the enterprise can be a risk.

Simpler Sign-On – The Middle Ground

So what’s the solution? Obviously “single sign-on” isn’t necessarily the silver bullet that execs often think it is, but requiring users to manage disparate user IDs and passwords creates a usability nightmare. The middle ground, then, is a balance of what I commonly refer to as “simpler sign-on”. The idea is to make the authentication process as easy to use for your end-users while maintaining a level of security and application stability that meets your organizational needs. The strategy I often suggest is not a complex one and can be leveraged by any organization, no matter how large or small.  The suggested strategy is as follows:

1) Classify your applications by information risk. Clearly understand and document what risk the information would pose if it were exposed to everyone inside (and potentially outside) your enterprise. While your classifications will be unique to your organization, a guideline to start from might be:

• Low risk applications – Those that surface benign information that is of low risk if it were exposed. Think of the daily lunch menu being posted on the Intranet.
• Medium risk applications – These are systems that often contain a combination of low risk data with high risk data. Intranet portals often fall into this category because they might have the daily lunch menu, but also contain strategic sales, marketing, or organizational performance information that might be risky if it were exposed.
• High risk applications - These systems contain highly sensitive data and often include (but are certainly not limited to) performance management systems, Customer Relationship Management systems, recruiting systems, and corporate records management systems.

2) Assign an appropriate identity management strategy. Decide whether each application should use its native authentication or whether a federated IdM strategy would be appropriate to secure the data.

3) Provide a secure, enterprise methodology for employees to secure their User IDs and passwords. If you’re going to require that your employees have disparate user IDs and passwords, give them a way to secure them. It’s better to provide clear guidance and, ideally, and enterprise application, to store their passwords as opposed to letting them store them on a sheet of paper or spreadsheet. You’d be surprised how cheap and enterprise license for a password storage tool can be.

4) Attempt to synchronize password expirations and document the process. If your employees are going to be required to reset their passwords on a periodic basis (a best practice for information security), be sure that you attempt to synchronize the timing of the password expirations and provide your employees with clear instructions on the process for resetting them. It’s amazing how much simpler the process can be with a single sheet of instructions.

5) Educate your employees on the importance of information security and the reasons behind your policies. Employees are much more likely to accept your IdM strategy if they understand that there is a reason behind it. The fact that the simpler sign-on strategy has been analyzed, streamlined, and employee usability has been considered will help them adopt the process and adhere to the policies.

In the end, it’s always better to be over-protective of your information and access to your organizational systems, but keep in mind that taking employee usability into account can increase employee satisfaction and reduce security risks that occur when employees write down their passwords or store them in unsecured electronic formats. The chase for single sign-on can often lead to additional security and application stability threats, while a more reasonable standard of “simpler” sign-on might achieve the security needed while driving user adoption.

Thoughts or comments? I’d love to hear your experiences with simple sign-on, IdM applications, and constructive criticism of the thoughts in this article.