Introduction to MOSS Security Architecture

The Microsoft Office Server System (SharePoint 2007) has many exciting new security mechanisms built into it that allows one to build a highly guarded collaboration environment that provide a unique, fluid user experience for all of the stored content. In previous versions of SharePoint, sometimes implementing very granular security options had the negative side effect of degrading the rich communications and collaborations feature of the product, required heavy development efforts, or additional hardware and software purchase.

Changes To The MOSS Security Architecture

There are however unique security features built into MOSS currently that allow one of the most robust, however secure, information worker centric environments to procure virtual teams within an organization. Building on technologies such as Windows Rights Management, Information Rights Management, and powerful permissions management, many afflictions that typically affect collaboration platforms can be solved through intuitive, internal security mechanisms.

Some of the MOSS security architectural possibilities are very industry exciting, specifically for those organizations that have to conform to certain business and legal regulations that stipulate certain privacy and security requirements, providing built in mechanisms for such popular regulations such as HIPPA and SOX.

Examples of Enhanced Security Provided by ASP.NET 2.0

Some of the greatest security enhancements in MOSS spawn from its new architecture and web application structure.

Since SharePoint relies on view states by default, and in the new version of Sharepoint this is protected through various hashing mechanisms through minor effort can be encrypted using some attributes, most notably the viewStateEncryptionMode attribute in machine.config of your SharePoint server.

Since one of the greatest enhancements is the introduction of forms based authentication possibilities into a SharePoint environment, forms authentication cookies and related authentication tickets are encrypted instead of being stored in plaintext, protecting authentication assets.

There are several options for enabling a session states (regardless of where the session information is stored), and therefore out-of-process session state assets are protected by the ASP.NET 2.0 framework, the backbone of MOSS.

For the pluggable authentication options of MOSS, if you are implementing a membership and role provider that is outside of the realm of the default windows authentication routines (which is, by default enabled), the related role manager cookies are encrypted. Along the same lines, if you have anonymous MOSS zones or a perimeter facing site with anonymous authentication enabled, those relevant cookies can be encrypted. For the membership providers, since they are stored in a variety of different systems, these passwords are stored hashed, if a heightened security option is more desirable, these passwords can be encrypted as well.

Why Was The Security Architecture Of SharePoint Changed?

There are several stages in order to implement sheltered knowledge management systems and secure collaborations environments, regardless of network architecture and operational access goals. SharePoint attacks are becoming increasingly relevant towards business operations and strategic business data warehousing as the product becomes increasingly commonplace throughout a variety of industries for an assortment of reasons.

Steps In Securing a SharePoint Environment

The first step in securing a SharePoint environment is to implement standards and policies with an environment, and just having these policies in place is not enough, they have to be enforced and adhered to by both portal users and administrators. These policies can vary in purpose and intent, as shown here in this index of SharePoint policies.

The second step is to investigate, implement, and maintain sister security and disaster recovery based server systems that will integrate and enhance your environment on a variety of levels.

Most Popular Security Shifts in SharePoint

Being built upon the new ASP.NET 2.0 platform offers SharePoint some unique security features that birth the possibility of several very lucrative environments. The two that are immediately evident are:

Forms-Based Authentication (FBA)

Pluggable Provider Model (Membership, Role, Session, and Profiles)

These two new options are incredibly popular options since they were the most requested features in previous version of SharePoint, and coupling the two options allows users to have an extranet / perimeter facing deployment that is unique and tailored to each specific instance.

Reasons SharePoint is Subject For Attack

The two most commonplace reasons SharePoint is a subject for attack are:

Data Theft Since SharePoint acts as an aggregator and warehouse for several layers of business information, a third party may try to capture vital enterprise data for any number of purposes, ranging from sale of this information to competitors or simply trying to pry into day-to-day operations.

Corporate Espionage Taking down a portal from an operational standpoint for businesses that are heavily dependent on it for operations can prove disastrous, and beneficial to a competitor that can take advantage of a weakened business state. This type of intended disruption has been well-documented throughout history through other systems (mostly through the battles between smaller communications companies in California, see here for more information regarding those DDoD attacks), and has translated over to SharePoint environments.

There are three main levels (tiers) of SharePoint security each of which has to be tackled individually and methodically maintained (loosely based on the OSI model):

Network Level

Web Application Level

Database Level

However, with certain procedures in place the threats to a portal can become vastly mitigated and an organization can collaborate in confidence.