Ten Guidelines for Managing Passwords in the Enterprise

As a follow-up to my article entitled “The Most Serious Data Threat May be Sitting Next to You,” Mark Sanford from Click Studios sent me a link to their article on “10 Guidelines for Managing Passwords in the Enterprise.” Since data security and data integrity is a critical issue on any enterprise IT project that involves significant data – and they all do – this is extremely timely and appropriate.

Mark and Click Studios have graciously allowed for their article to be provided to the readers of PM Tips. I strongly urge you to also visit their site and the original article here.

10 Guidelines for Managing Passwords in the Enterprise

Today the world is totally dependent on information technology, and many corporations struggle to effectively manage and store passwords securely for their employees. Every other day you hear of large companies exposing customer account details to non-intended audiences, due mainly to poorly managed IT systems and processes. The confidentiality and integrity of sensitive data is paramount to the operations of any size business, and the following guidelines should be considered when choosing any type of electronic password management system (PMS).

1. Remove the need for employees to remember passwords, or even worse, write them down

A key cause of bad password management practices is many employees don’t have a system in which to records their passwords, resulting in them having to either remember them, or write them down and store them in an unsecure manner. The password management system (PMS) must provide adequate functionality, removing the need for employees to remember passwords.

2. Centralize the management of passwords

Centralization of an organization’s passwords is the first step in gaining control of the IT accounts used to operate their business, otherwise there is no visibility or governance of their usage.

3. Ensuring the integrity of sensitive data

To ensure the integrity of data stored in an electronic PMS, there are a few key things to consider:

• Passwords should be encrypted with 256bit AES encryption, and a unique Initialization Vector used for every install
• Users should authenticate against the PMS using their Microsoft Windows domain account credentials
• PMS must provide the option to use two-factor authentication for the user(s) who administer the system
• Sensitive code of the PMS should be obfuscated, to prevent reverse engineering by system or web administrators
• PMS must mitigated against system or database administrators granting themselves access to unauthorized data

4. Make the passwords easily accessible

Users must be able to get to the PMS from any location, must not rely on any client installs, and must give them quick and easy access to their passwords.

5. Must promote the use of strong passwords

The PMS must promote the use of strong passwords, of which the policy for password strength is set by the administrator(s) of the system. Visual representation of password strength must be available when entering passwords, or when reporting against, so the user is constantly reminded if a password’s strength is poor.

6. Must promote regular resetting of passwords

A key component of bad password management practices is not resetting passwords at regular intervals. The PMS must have one or more options for reminding users that passwords are about to expire.

7. Must be portable and recoverable

There is little use centralizing your organization passwords if you’re unable to get to them in case of a disaster. The PMS must provide the mechanism by which all passwords can be exported to a separate file, to be stored outside of existing IT systems – preferable with trusted security personnel.

8. Changes must be traceable and auditable

All large organizations require governance over access to IT systems, and its imperative the PMS must support traceability of all events within it, and must be easily reportable. This applies to standard usage by employees, or administration of the PMS.

9. Must be scalable

If you intend to implement an enterprise class PMS, its crucial the system can scale with your organization, otherwise your investment (time and money) may be wasted.

10. Must be simple to use

As with any IT system, acceptance by its audience is crucial to its success. Provide users with a poorly designed interface, and you will meet resistance at every step. To successfully employ a PMS and realize the benefits it can bring, the PMS must be very simple to use and provide the user community with sound help documentation if required.

(Click Studios – 18^th October 2009)

Defining Risk Management – Part 9: Risk Control

This is the ninth and final installment in the Defining Risk Management series. In this final segment, we look at what risk control is and how we monitor and track the risks that are identified and new ones that are encountered on our projects. This information is again, for the most part, derived from the book “The Project Management Question and Answer Book.”

What is Risk Control?

The process of monitoring and controlling and keeping track of the identified and the unidentified risks is risk control. In this process we hope to identify risks that are no longer possible and risks that are coming due, as well as any new risks that may become evident. We will also monitor risk activity to make sure the risk plans have been carried out successfully. Problems that have been found out in the risk plan can help us adjust the plans for future risk activities.

Risk control and monitoring are part of the risk management process and must be started early in the project and continued until the end. As the project progresses, we will find that many of the risks will change, some will no longer be possible, others will happen and be disposed of, and new risks will be identified. In addition we will learn about the project and the risks associated with it and adjust our vision of individual risks.

The level of risk tolerance should be monitored as well. The attitude of the stakeholders will change during the course of the project. Communication with all stakeholders is important since it gives us a means of assessing changes in their risk tolerance.

Risk control may involve changing the way we look at risk. There are several reasons why this might take place. The risk tolerance of the stakeholders may change; the risk tolerance of the project team may change. As the project progresses toward its completion, certain risks that were thought to be very important to the success of the project may become risks that are no longer thought of as being so important.

In the beginning of the space shuttle project, the heat-resistant ceramic tiles were originally thought of as being one of the major risks in the program. If the tiles were lost or their integrity was compromised, the heat of reentry, some 3,000 degrees Fahrenheit, could reach the airframe’s aluminum structure and cause breakup of the ship. As time went by and NASA flew over one hundred missions with the space shuttle vehicles and the whole take-off and landing process became routine, the perceived severity of the risk diminished. During this time there were minor failures of the reentry tiles, but these failures proved to be minor repairs, and the shuttle vehicles suffered only minor damage. A program to develop a method of repairing risks in space was discontinued because it was deemed impractical. Part of the impracticality was probably because of the perceived reduction in the probability and impact of heat shield failures.

On February 1, 2003, just three days after the anniversary of the crash of the space shuttle Challenger, Columbia, the oldest space shuttle in the fleet, disintegrated on approach to landing. At this writing the investigations have hardly begun, but the heat shielding tiles are once again suspect because there is little that can go wrong on reentry except for a heat shield failure.

We see that during the project, the evaluation of the risk of heat shield failure began as a high risk. As time went on, the risk was revalued lower and lower. After the crash, the valuation of the risk has no doubt been raised higher than its former level.

In all projects, as we gain knowledge and experience about the project and its risks, we will change our attitude toward the risks in the project. This is natural and important. As we learn, we must change the level of effort we spend in certain areas or we will never have the resources, time, or money to complete any project.

A control system for risk is influenced by the organization the project is being managed under as well. In a project that is high in risk, we might have a person who is at a high level and is exclusively responsible for managing risks. On projects that are relatively routine by comparison, the risk manager may be the person responsible for the tasks that are most affected by the occurrence of a risk. These persons are responsible for communicating risk progress to the project manager and other affected stakeholders.

Risk audits can be used to document the effectiveness of the risk plans and the strategies that were used to mitigate, avoid, or transfer risks. A judgment can be made as to whether it was cost-effective to ignore the risks that were ignored.

Deviations in the project performance may indicate the effect of risks on the project. The earned value reporting system is helpful in identifying trends in performance on the project. Generally, schedule slippage and cost overruns are the result of some problems that have occurred. Trends in certain areas may indicate that risks are more severe than was anticipated or that new risks have taken place. One important product of the earned value reporting system is the indication of the cost and completion date at the end of the project. The sooner these slips in schedule or budget overruns can be communicated to the stakeholders, the better it will be for the project. Schedule slides and budget overruns that are severe enough can result in project termination.

A workaround is an unplanned response to a risk that was previously unidentified. These are the unknown risks that were discussed at the beginning of this chapter. They are also the risks that were passively accepted since these were deemed to be risks that would be ignored. Workarounds are paid for from funds from the contingency reserve or the management reserve, depending on whether the risk was identified and accepted or whether it was unknown until it occurred. In any case, the funding for the workaround comes out of these accounts and is put into the operating budget of the project, and a new baseline is created.

Since contingency plans and workarounds are not part of the project baselines until they occur, they should be initiated and approved by the execution of an official change notification. Remember that changes to the baselines should require an official change notification as the vehicle for showing the change in funding, schedules, and scope resulting in a new and current baseline.

The Skill Set of the Project Manager – Another View

In my article “The Characteristics of the Project Manager,” I began what ended up being a five-part series and still probably needs a final summary article – assuming I’m done and have no more characteristics to share…which I probably do.

I’m always open to new and different information as well as different opinions on information I’ve already provided so far in articles on the PM Tips site. That’s why I’m presenting this excerpt from Gary Heerkens’ book entitled “Project Management.” It covers what he considers to be the overall skill requirements of a project manager. It’s not exactly the same concept as the characteristics of a project manager, but it’s close.

Skill Requirements of the Project Manager

To fulfill the responsibilities of the role of project manager and handle the challenges you’ll face, you’ll need very diverse skills and a wealth of knowledge. So what knowledge and skills does it take to be an effective project manager?

There are many ways to slice up this pie. The way that makes the most sense to me is to break it down into four major knowledge and skill categories:

1. project management process skill
2. interpersonal and behavioral skills
3. technology management skills
4. desired personal traits

Let’s examine each in detail.

Project Management Process Skills

Project management process skills (sometimes called the “hard skills”) are knowledge and skills related to the mechanics of project management. You should be extremely knowledgeable about project management tools, techniques, and process technology and be able to apply them. For example, you should be know how to prepare a comprehensive customer requirements document, construct a network diagram, and construct a work breakdown structure. Without these skills, you’ll find it very difficult to coordinate and facilitate the creation of a high-quality project plan and to maintain control during project execution. Also, since these skills are a basic expectation, you can expect to encounter problems of respect from your team members if you’re deficient in this area. As mentioned earlier, this skill set is the main focus of this book.

Interpersonal and Behavioral Skills

Since managing projects is all about getting things done through other people, your skills in dealing with people are of immeasurable value. Closely tied to your interpersonal skills are your behavioral skills: your personal conduct, style, and approach. Together, these two skill sets are often called the “soft skills.” Here are some examples of soft skills:

• team and individual leadership
• oral and written communication
• conflict resolution
• negotiation
• influencing
• delegating
• coaching and mentoring

For individuals coming to project management from a highly technical background, soft skill development can be particularly challenging. Later in this chapter we’ll discuss methods for developing these skills.

Technology Management Skills

Most projects have one or more embedded technologies. An embedded technology refers to the process or technology areas at the core of the project. Examples might include software development, chemical processing, or commercial construction. Your ability to guide and coordinate the application of these technologies is crucial to your success as a project manager. If you’re like Brad, you’ll probably have sufficient knowledge and skills in the primary embedded technology of the project. However, it’s likely that there will be several technology areas associated with your project. Although they will differ in focus, the process steps and related skills involved in managing their successful application will be similar.

Among these technology management skills are the following:

• proficiency in project’s core (primary) technology
• proficiency in supporting technology areas
• industry knowledge
• ability to prepare comprehensive technical specifications
• design skills
• product knowledge
• process knowledge
• management of intellectual property
• patent knowledge

Desired Personal Traits

Many studies have been performed to correlate personality traits to success as a project manager. Although each study reveals slightly different results, the traits shown in Figure 3-1 appear in most. Possessing these traits will stand you in good stead in your role as project manager.

• Honesty and integrity
• Thinks like a generalist
• High tolerance for ambiguity
• High tolerance for uncertainty
• Persuasive
• Assertive
• Process-oriented
• Self-aware/reflective
• Open and accessible
• Politically astute
• Decisive

Of these personal traits, I consider the following four to be among the most critical.

1. Thinks like a generalist—Project managers must always be thinking in terms of the big picture. This can be a challenge for those who are accustomed to focusing more narrowly. Although this trait certainly requires knowledge in many different areas, what’s crucial is that you must pay attention and care about everything and everybody.

2. A high tolerance for ambiguity—This competency will be particularly challenging if you’re technically oriented. You’ll often receive mixed signals or contradictory data. You need to develop processes for finding truth and narrowing down inputs without getting frustrated. This will probably not be easy for you.

3. A high tolerance for uncertainty—As with ambiguity, this is particularly challenging if you’re entering project management from the technical arena. Most technically oriented people are accustomed to precision. As a project manager, the norm is to make many decisions without sufficient information. You must condition yourself to making decisions that are only acceptable, not perfect.

4. Honesty and integrity—Although obvious virtues, these traits are worthy of specific mention. Whenever studies are performed on the traits that people most admire or desire in leaders, honesty and integrity always rise to the top. One of the best behavioral traits for a project manager is to be known as doing what you say you’ll do. Closely related is the issue of integrity, having a reputation as someone who will follow principles, even in the face of adversity or temptation.

Together, the combination of hard skills, soft skills, functional competencies, and personal traits compose the raw material for your overall capability as a project manager. But how should you develop that capability?

Skills that are somewhat mechanical can be learned or developed through self-study, reading, or facilitated training and practice. Many of the hard skills fall into this category. However, as you migrate toward the soft skills, the preferred mode of development moves from programmed learning to coaching or mentoring. Here, soft skills are best developed through observation and feedback from others— preferably those in a position to do so.

Sensitive Data Often Exits with Employees

I’m not sure how this relates directly to Project Management. It really doesn’t, I guess, other than the fact that when employees exit many times they’re actively working on one of our projects and the same findings you read about below can affect your customers on the projects you manage in addition to the company you work for.

Dr. Larry Ponemon put together this document back in February on “Data Loss Risks During Downsizing”. I’m only including a portion of it here that outlines some of the key findings of national study performed by the Ponemon Institute and sponsored by Symantec.

The bottom line is that 59% of employees who leave or are asked to leave are stealing company data. And 79% admit that their former employer did not permit them to leave with the company data. The lack of care some companies take in ensuring that they’re protected when employees leave still amazes me.

Please read on…I’ll provide a link to the full study at the end of this article…

Key Findings

Following are the most salient findings of this survey research. Please note that most of the results are displayed in bar chart format. The actual data utilized in each figure and referenced in the paper can be found in the percentage frequency tables attached as the Appendix to this paper.

Employees are stealing data and are more likely to do so when they don’t trust their employer. According to 63% of respondents, their previous job required them to access and use proprietary information such as customer data, contact lists, employee records, financial reports, confidential business documents, software tools or other intellectual properties. More than 59% report that they kept company data after leaving their employer. It is very interesting to note that employees who do not trust their former employer to act with integrity and fairness are more likely to take the data. Sixty-one percent of respondents who were negative about the company took data while only 26% of those with a favorable view took data.

Employees are stealing proprietary and confidential data that might affect their former company’s business competitiveness and could result in a data breach. Sixty-five percent of those respondents who admit they took data left with email lists followed by 45% who took non-financial business information and 39% took customer information, including contact lists.

The most susceptible documents to theft are email lists and hardcopy files. Sixty-four percent of respondents took email history and hardcopy files (62%). Of least interest to employees are PDF files (9%), access database files (8%) and source code (3%).

Employees are stealing data in different ways. It is interesting that most employees (61%) who stole valuable customer and other business information are taking it in the form of paper documents or hard files. The next most popular means of transferring data is by downloading information onto a CD or DVD (53%) or onto a USB memory stick (42%) followed by sending documents as attachments to a personal email account (38%).

Employees who take company data are defying company rules. Of those employees who admit to stealing company information, 79% report they do not have permission to do so and 5% are unsure. The top reasons given for stealing data include: “everyone else is doing it, the information may be useful to me in the future, I was instrumental in creating this information, the company can’t trace the information back to me and the company does not deserve to keep this information.”

Only 16% say they were permitted to keep sensitive, confidential or proprietary information. However, their reasons are suspect. Specifically, the top two reasons for their belief that it was acceptable are “other laid-off employees kept this information when they left the company (54%) and no one checked their belongings when they left the company (50%).” Only 11% report that their former supervisor said it was permissible to keep this information.

Companies are failing to take proper steps to stop data theft. While a small number (4%) of employees told their employers that they were taking data, only 15% of companies conducted a review or performed an audit of the paper and/or electronic documents that employees were taken. If they did, respondents report that it was not complete (45%), or worse, superficial (29%). Approximately 41% of respondents say the review was conducted by their direct supervisor or manager followed by the human resources personnel. Approximately 89% report that their company did not do an electronic scan of devices such a portable data-bearing equipment or USB memory sticks.

Employees leave their laptops but take CDs, USB memory sticks and PDAs. Ninety-two percent of employees took CDs/DVDs followed by USB memory sticks (73%) and PDAs (17%). Only 9% kept their Blackberry and 3% kept their laptops.

Employees were able to access their former employer’s computer system or network after departure. According to 24% of respondents, their ability to access data continued after they left the company creating a data security risk. Of these respondents, 32% say that they accessed the system and their credentials worked and 38% say their co-workers told them that their access rights continued. In the case of 35% of the respondents, access to the system continued one week or longer.

While only 4% report that they gained access using a co-worker’s authentication credentials after departure from the company, 51% said their supervisor told them they would have access to the company’s system, email or network for a specified period of time. More than 44% continued to receive email on their company’s account.

Employees’ reasons for leaving are mixed. Approximately 37% were asked to leave, 38% found a new job and 21% moved on because they are anticipating a layoff. Immediately after leaving their former company, 61% took paper documents or hard files, 53% downloaded information onto a CD or DVD and 42% downloaded information onto a USB memory stick.

Implications and recommendations for companies

All companies share the potential risk of having a data breach because of the actions of former employees. In addition, they have allowed competitive information about customers, business partners and other intellectual property to walk out the door putting them at a competitive disadvantage. We recommend that companies immediately assess the potential data loss from former employees who had access to sensitive and confidential data as part of their job.

Dr. Larry Ponemon presented this paper entitled “Data Loss Risks During Downsizing” on February 23, 2009. To read the full 24-page study, go here.

US$50 Million Expansion Project for Stevens Hospitals

As reported by Earth Times

FOLSOM, Calif. – (Business Wire) Meridian Systems, the Plan-Build-Operate (PBO) technology solutions leader for project-based organizations, announced today that Stevens Hospital of Edmonds, Washington, has selected ProjectTalk^® to standardize its construction management processes. ProjectTalk, Meridian’s online project management and collaboration solution based on Prolog^® software, provides robust functionality in a Software as a Service (SaaS) environment. Stevens Hospital worked directly with P7 Integration, a Meridian Systems Value Added Reseller (VAR), to implement ProjectTalk to manage the upcoming US$50 million expansion project.

Stevens Hospital typically has more than a dozen projects in process at any given time with approximately 10 percent dedicated to new construction. The current expansion project will add a new, two-story Emergency Room (ER) building with 32 ER beds, 30 acute care beds as well as underground parking, totaling 75,000 square feet.

As a public healthcare organization serving Edmonds, Washington and its surrounding communities, Stevens Hospital worked with P7 Integration’s professional services to implement ProjectTalk. The online project management solution is designed to manage complex capital projects more effectively, improve construction project accountability and provide the visibility needed for an expansion project of this size. P7 Integration sells the Prolog suite of applications and provides implementation, training and consulting services.

“The hospital’s goals for the implementation included standardizing on one centralized location for all project data, increased project team collaboration, ability to access current project data at any time and status updates for key personnel,” said Stefan Rehnfeldt, Stevens Hospital’s construction manager. “ProjectTalk is a crucial system for effectively managing vast amounts of information to keep the project on track. In addition, we are using ProjectTalk to successfully manage schedule tasks, project budgets, and document control.”

Read the full story here…