Wednesday, September 22, 2010

Known ASP.NET vulnarability (Includes MOSS 2007 and 2010) - Microsoft Security Advisory (2416728)

Microsoft published the following vulnerability on their technet site @ http://www.microsoft.com/technet/security/advisory/2416728.mspx  on Sept 20th, 2010.

Executive Summary

Microsoft is investigating a new public report of a vulnerability in ASP.NET. An attacker who exploited this vulnerability could view data, such as the View State, which was encrypted by the target server, or read data from files on the target server, such as web.config. This would allow the attacker to tamper with the contents of the data. By sending back the altered contents to an affected server, the attacker could observe the error codes returned by the server. Microsoft is aware of limited, active attacks at this time.
We are actively working with partners in our Microsoft Active Protections Program (MAPP) to provide information that they can use to provide broader protections to customers.
Upon completion of this investigation, Microsoft will take the appropriate action to help protect our customers. This may include providing a security update through our monthly release process or providing an out-of-cycle security update, depending on customer needs.

For more information, you can read
http://www.microsoft.com/technet/security/advisory/2416728.mspx

After this incident was known, the first impression was that it would not effect MOSS 2007 and MOSS 2010. But that is not true. If you are using MOSS 2007 or 2010, then you have a work around as described in the blog @ http://blogs.msdn.com/b/sharepoint/archive/2010/09/21/security-advisory-2416728-vulnerability-in-asp-net-and-sharepoint.aspx

Please remember that this is only a work around and wait for the ASP.NET security patch release from Microsoft.

Tuesday, September 7, 2010

Why FAST or Google search over MOSS Search 2007/2010?

I was building a search indexer and handler against our enterprise knowledge repository content system a year back. Our knowledge repository has different types of content i.e. structured content like HTML, XML and unstructured content like PDF, MS-WORD, and other office documents. This is when I have learnt the usefulness of search engines like Google and FAST (FAST is now Microsoft owned).  Both Google and FAST have gained a lot of popularity in the last few years. Google (the best in the web search) provides a sharepoint plug-in. FAST has the sharepoint web parts for searching. The advantages of using specially FAST over MOSS search are:

Scalability: Scalablitily is defined in two ways. One way is system scalability and availability i.e. MOSS has only one index server with a single point of failure where as FAST introduces the distributive model (cluster) for indexing. Second way is: Query Scalability i.e. howmany queries per second (QPS) can be handled by a search server? MOSS search server does not define this particular parameter where as FAST claims that it is 1000's QPS.

Navigation: MOSS only supports a shallow faceted search solution by the best bets on the metadata. FAST supports a deep faceted search solution model and therefore provides a slice and dice of the search results through the deep navigation.

Federation: MOSS supports federation with out mixing the results from various data sources and navigation components.Therefore, it displays the results seperately. FAST supports a true (advanced) federation including sending the search queries to different web search APIs and mixing the results. For ex: if you have a site like hotwire or priceline for users to book air line tickets, you have to search different carriers (like Delta ,AA, US Airways, etc..) but also you can provide search results from your partner search sites like orbit, hotwire, and priceline in a unified way.

Relevancy and Ranking (Weights): I have found it very difficult to fine tune the relevancy on search results in MOSS 2007. FAST has a management GUI to setup the rules.

Advanced Indexing and Document Processing: MOSS does not have the capability to index unstructred content like PDF, MS-WORD, or other office documents where as FAST will let you index the unstructred content.

To be completed: Why Google over MOSS?

http://www.google.com/enterprise/whygoogle.html

Other useful resource to learn more about sharepoint search community tool kit,

http://sct.codeplex.com/

Friday, September 3, 2010

How to plan and architect migration projects?

Almost every organization in the universe have to go through the rewrite or migrating their existing  projects or products to a new platform either to increase the business revenue or better fit in to their enterprise infrastructure. Whatever may be the case, if you do not plan and execute correctly, you will end up in a shanty town and waste your investment and resources for no good reason. In the worst case, you will be fired. In my experience, I have seen developers, engineers, and analysts plan their migration with out investing much time upfront in planning and architecture. Most of the times, they want to replicate exactly the same functionality that is existing with out paying any interest in how they can improve the performance, interoperability, portability, reduce the complexity of the integrated systems by loose coupling, increase the ROI, and of course, better the user experience. Probably it is not all their fault as lot of other factors and constraints can guide what you do at work. But, it can cost dearly to the enterprise in the long run. I know a critical project that has been migrated from one platform to other platform and is put in to production. After it reached to production, many issues were seen and fixed at that point of time. After my interactions and interviews with the developers, I have learnt that their primary assigned function is to sit down and code to replicate the functionality of the modules with out considering any bottlenecks. By the time it is realized, luckily it was not too late and most of the performance and architectural issues have been resolved by the project team. Now the question you should ask your self is, do you want be in this position? What point of time in the project you like to address? It is no brainer and we all agree that it should be done upfront? But the million dollar question is... Are developers/analysts/architects doing that?  Therefore, if you are a developer/ analyst and want to become a good technical/business architect ( or have to wear architect hat) then consider the following before starting any coding on your project especially migration projects:

1. Goal of the migration project
2. Understand the scope and vision of migration project and its requirements.
3. Know your business stakeholders and end-users.
4. Think big and out of the box: Remember that your objective is not to replicate the existing architecture and functionality but improving the quality, performance, and experience. Sometimes, business and project manager can only think in one direction and your value will be known to business and IT only if you are innovative.
5. Forget the current architecture for a while and define the target architecture. Also, while defining the target architecture, DO NOT think about the implementation details. You need to consider and understand the following during your design phase:

  •  Data Architecture: define the information flow from point A to point B. Who uses and owns the data?                                        Where is the data stored? and How it is stored? When it is used?
  •  Application Architecture: define the application design, security, development and deployment model, system integration, patterns, and frameworks.
  • Technology Architecture: understand your organization's hardware and network infrastructure. In most cases, your architecture should fit to your organization's hardware and network. In exceptional cases, if necessary, you should be recommending the changes to your existing infrastructure.   

6. Do the risk analysis in both source and target architectures and implementations.
7. Find the gaps, opportunities, and solutions.
8. Choose a SDLC process (waterfall, iterative, or agile) that fits to your organizational culture and project requirements. If you want to follow a complete architectural development lifecycle, frameworks like TOGAF and Zachmann can help you to solidify your process.

9. Understand that a project success depends on what I call "Four C' principles" i.e. Culture, Collaboration, Communication,  and Commitment will let you use your resources i.e. people, processes, tools, and standards in an effective way.