September 30, 2014
Hot Topics:
RSS RSS feed Download our iPhone app

Project Management Issues to Consider

  • September 9, 2005
  • By Marcia Gulesian
  • Send Email »
  • More Articles »

This article is about the under-discussed use and misuse of security technology, use and misuse of statistics software, and use and misuse of people in projects that use project management applications. These matters can be at the heart of why some projects fail, just as easily as those other matters more commonly examined in palimpsests on the art of project management.

Today, relatively low-cost, trusted, security technology is readily available and easy to use. At the same time, powerful statistical tools that can be used to analyze situations under risk—often very effectively—by individuals with little or no understanding of the advanced statistics or decision theory upon which these tools are based are available. And, with business globalization, people (distributed project-team members) have become, to a much greater extent, a fungible resource.

Figure 1: Three issues that can contribute to a project's success or failure.

Security

Enterprise-level project management systems typically include, but are not limited to, the collaborative use of packages such as:

  • Microsoft Project Server
  • Microsoft Project Professional
  • Microsoft SharePoint Portal Server
  • Microsoft SQL Server
  • Microsoft Exchange
  • Microsoft Visual Studio Team Suite (used to develop custom Web Parts for SharePoint)
  • Microsoft Team Foundation Server (used for further collaboration among developers)
  • Palsade @Risk

Each of these applications has plenty of endogenous security built in, right out of the box. My concern in this article is the exogenous security that you must provide, in addition, so that unauthorized individuals don't have access to your project management applications and data. Security is a big, open-ended subject. What I'll do here is make the point that you can't assume that, just because you implement a number of layers of de rigeur, "by-the-book" security practices, your data is safe.

To that end, I'll focus on system authentication and authorization and data encryption using digital certificates (the foundation of Public Key Infrastructure, or PKI). These are electronic credentials, issued by a certification authority (CA), that are associated with a public and private key pair. The certification authority certifies that the person who has been issued a digital certificate is indeed who he or she claims to be (see Reference 1 for further details). First, a little background information on, and then, how you might get a false sense of security from using PKI.

Digital certificates are important because today's password authentication schemes are little more than security placebos. They perversely inspire abuse, misuse, and criminal mischief by deliberately making users the weakest link in the security chain. You're far more secure with a layered approach to authentication—one that starts with a digital certificate.

More than any other security protocol or technology available today, PKI can define trust in a granular way. You can use its strengths to protect information about the status of your project from outside competitors or even inside personnel who might misuse information about your work-in-process. But, because of PKI's mystique, the all-too-frequent careless use of PKI can lead to unwanted consequences. (See Reference 2 for an account of what to believe and what to disbelieve about what you've been told by PKI marketers.) Today, the user interface to your PKI-based security system often starts with his or her use of a smart card.

A smart card is a programmable device containing an integrated circuit that stores your digital certificate. These portable cards serve as positive, non-refutable proof of your identity during electronic transactions. As such, they allow you to digitally sign documents and e-mail messages, encrypt outgoing e-mails to be deciphered only by their intended recipients, authenticate into a domain (certificate logon), and automatically log into Internet and Intranet Web sites. To use a smart card, a user must be issued a smart card certificate by his or her certificate authority. Smart cards traditionally take the form of a device the size of a credit card that is placed into a reader, but can they can also be USB-based devices or integrated into employee badges. And, smart cards can be combined with a PIN (which you can think of as a password) to provide two-factor authentication. Physical possession of the smartcard and knowledge of the PIN must be combined to authenticate successfully.

So far, so good; but, there's more. The U.S. National Institute of Standards and Technology (NIST) specifically states as one of the many features that smart card chips are "tamper resistant." However, a student at Princeton University, Sudhakar Govindavajhala, heated a smart card with a lamp and exploited it (http://news.com.com/2100-1009_3-1001406.html). Heating caused a bit in the internal state that controls some security processing to fail, thus giving access to data that was previously secured. Smart cards are a great way to add a second method of identity authentication. But, the premise that a smart card is more secure than any other—as this story shows—is not always correct.

Project management files can be saved by using the security features found in the database. But, copies of these files sometimes exist outside of the database and should be protected using another function of PKI—encryption. But, be forewarned: You can't know for certain that an encrypted file is secure. For one thing, the Google desktop search can get into your encrypted files without the password. The Google desktop search (beta .9) does not actually get around the encryption. It simply indexes the information while you are logged in. When you are logged in, you automatically have access to the encrypted files and so do any programs running on the machine under you. So much for counting on encryption to protect your stolen laptop!

And, people from other companies or other branches of your own company—with certification authorities of their own—sometimes may collaborate with you on your project. The resulting need for interconnectivity inevitably leads to users of different PKIs needing to communicate with each other (see Figure 2). Reciprocal ("cross") certification allows clients of two separate certification authorities to interact securely. Because certification standards may vary from one PKI to another, before establishing a cross certification process, the two PKIs should compare policies to ensure the appropriate degree of trust exists between them.

Figure 2. Qualified Subordination to Limit Trust to Specific CAs

In some situations, two organizations may want to restrict the cross-certification to specific CAs or to specific portions of the CA hierarchy; for example, when an organization uses outside consulting services. If cross-certification were implemented at the root level (as shown by the dashed arrows in Figure 2), the consultants would have complete access to your network. So, cross-certification at subordinate CAs (as shown by the solid arrows in Figure 2) should be used to restrict their access to those parts of your network actually required. Lastly, the cross-certification can be qualified—that is, limited to certain uses. This process, called qualified subordination, is effective in managing and limiting trust. See Reference 1 for more on cross certification. And, an easy-to-read, non-technical, and very comprehensive account of these and other security issues is available at http://www.netcollege.co.kr/marketing_team/2part/CISSP_Summary_ver_2_0.pdf. Bottom line: Relying on endogenous security without understanding the shortcomings of exogenous security can and will give you a false sense of security.





Page 1 of 2



Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Sitemap | Contact Us

Rocket Fuel