Archive for May, 2009
Using VRIO analysis for IT Project Selection
The fact that information technology departments are swamped by requests for services on a daily basis is well known. Many of these requests are for projects. These requests are often not put through a filter to determine the relative value of one project over the next. The larger your projects, the more time and effort should be put into the selection of the projects. Oftentimes the tool sets for selection are lacking. Some organizations use SWOT analysis to select projects or an SCP model. There may also be a generic multi-criteria model utilized. I will talk about product selection using such a model in a later post. One analysis that is oftentimes overlooked is VRIO (aka “VIRO” for easier pronunciation). All of the previous serve as good starting points for filtering projects. However, VRIO can assist further. VRIO stands for the following:
Valuable – Is the project valuable to the organization? Can the value be quantified in any way? For example, you might identify projects tied to the balanced scorecard metrics, or they may be tied to a particular department or sales region success metric. If the project helps move that metric in a positive manner it is valuable. This may also be tied to process improvement and/or automation. Of course, to determine this value, the organization has to know which metrics are important and has to be able to measure them with some level of accuracy. If your company has the ability to do this, then definitely focus on aligning your IT projects with improving those metrics!
Rare – Rarity has to do with whether or not the competition has a similar resource. Rarity might be tied (probably briefly) to a unique software or technology stack, particular experts within the organization, contractual arrangements with suppliers, etc. In the context of project selection, is it something everyone else is doing or has done, or will this lead to an outcome that provides a unique capability.
Imitable (or “Inimitable” depending on context) – This deals with resources that are difficult or impossible to imitate or substitute. A concept known as “path dependence” sometimes plays a role here because even a direct duplicate of processes and resources may not produce similar effects across companies. This is the most difficult in IT project selection because almost any IT technology stack can be reproduced by a competitor. Installing the latest OS or the most popular DMS does not make you competitive. It may be a baseline for competition, but it is easily imitable. Full systems, people, processes, software, hardware and data, are harder to copy completely. For this case, it might be helpful to attach a time component. For example, can it be imitable within a year or two? If not, then by all practical assessments, it is inimitable because of the technology product lifecycles and the unique processes and people put in place during the development of the system.
Organization Ready – Is the organization ready to capitalize on the project? Projects can be suggested for a variety of reasons, but the organization has to be ready to grasp the opportunity if it meets the three previous requirements.
So, for the purpose of IT project selection, consider filtering projects first by whether they are valuable and rare, then by whether they are inimitable within the context of the time horizon selected. If the answer to these three is yes, it is obvious the organization should be ready to sign off on such a project.
Why shouldn’t I store SSNs in databases?
I get this question a lot more than I would expect. There are still many misconceptions from clients, students and even developers about what is ok and what is not when storing sensitive data in web applications. This is particularly problematic for small and medium sized businesses that may not have the resources or expertise to put the appropriate security mechanisms in place. This is especially true in a business where capturing SSNs are a necessary part of doing business.
Almost all of us have personally identifiable information stored in a database somewhere on the Internet. Quite commonly this information is stored in the public view in the form of social networking sites like Facebook or Twitter. However, the real litmus test of data sensitivity for consumers is whether or not the information may be used to compromise the user’s identity. There are certain security standards in place to help with this such as HIPAA or PCI.
Your web host is PCI compliant. You’re using Zen Cart, osCommerce, or a COTS e-commerce solution. Your database is mySQL and you have SSL running to protect the transport. By all practical measures your e-commerce environment is secure.
However, if a compromise should occur no one can steal your customer’s identity by simply finding out their name and address. Anyone can find that easily via the white pages, Google or any number of other mechanisms. To steal my identity, the attacker would also have to also know something unique about me. In fact, they may need multiple unique pieces of information to effectively steal my identity (my billing history, my SSN, mother’s maiden name, etc.). Anyone can get names and addresses from any list provider.
Credit reports with billing information can be had. The brokering, and compromise, of SSNs has been around for a while… maybe you’ve heard of the ChoicePoint debacle?
The latter is the worst, because if a database is compromised, and SSNs get out in the open, they are very difficult to change. If a piece of data, like a credit card, is compromised then the problem can be contained. Simply change the number, reverse the charges and open a criminal investigation. If an SSN is compromised, it cannot be changed easily and may be utilized until the criminal is caught. The criminal may also sell this data to others.
The risk to any company collecting data is enormous, but even more so when collecting SSN data. The question of how to shift this risk is answered by the process used for collection and whether or not the data is stored. There are ways to protect the SSN using well known techniques like AES encryption. These are built into some databases or can be coded fairly easily.
Unfortunately to decrypt the data, to view the clear text after initial encryption, requires a developer to use encryption methods which allow for the data to be decrypted. This mechanism can also be attacked by compromising a password for the administrative interface where the SSN is viewed. If an authorized human can view it, a hacker could view it also.
For something with a well known pattern, like an SSN, it is also possible to do a brute force or dictionary attack to compromise the SSN if the encryption algorithm is known or can be guessed.
Let’s say a hacker, we’ll call him Bob, compromises your database and gains access. However, you have encrypted the data using a built-in algorithm. Good for you, the clear text identifying data is not in the open… yet. However, Bob knows there are a few limited mechanisms used for encryption (AES for example). Bob also knows there are a limited number of numeric combinations for SSNs. So, Bob can write a program to run through all possibilities, encrypt them with various algorithms, and then match the encrypted string in your database. By matching these, Bob knows what the SSN is because he knows the starting clear text. Because the information is stored in the same DB Bob also has matching names and address data. Obviously, if it is stored in clear text, Bob has a much easier time.
So, how do we defeat Bob the hacker? Here are some suggestions and more are welcome:
- Use an API from a credit reporting agency. This shifts the risks to the credit reporting agency because the SSNs are never stored. You can still do a credit check based on information entered by the user.
- Add “salt” to the original SSN string if you are storing an encrypted version. This can be done at time of encryption and means the dictionary attack won’t work in a feasible amount of time with a strong salt value.
- Set up a separate encrypted database for SSNs. This keeps the data separate from your main e-commerce system and allows additional security measures to be put in place.
The good news is that hackers don’t often waste their time on small and medium sized companies, unless they are small to medium sized hackers. The prize is simply not big enough. Unfortunately, automated scripts can help hackers find vulnerabilities to exploit, which includes your web site. Follow some of the suggestions above and you can feel more comfortable conducting business online where SSNs are required as part of the transaction.
Migrating all web assets to Wordpress
It has been a while since I have posted, mainly because life got busy right around our trip to Singapore and they haven’t let up since. Now that I have a little break, I just wanted to post as a promise and/or reminder that I’m migrating all my web assets from my other domains to this site. Soon, all relevant domains will be pointed here and I will utilize the Wordpress platform to manage my content. Also, this will be where I post topics of interest based on my consulting and teaching activities, including whitepapers, case studies and more. So I look forward to filling it up with good, useful content as well as general updates about me and the family, as well as my various hobbies and ideas. So, stay tuned. The first order of the day is to transfer some domains and possibly backfill some of the months where there are no content 