Office 365 Security Series Primer

Collaborative technology has a unique way of exposing security flaws owing to the sheer everyday enterprise user consumption and the potential value of sensitive or propriety business information to an attacker. The security strategy that a SharePoint architect implements has to remain fluid, graceful and expressive in order to compensate for continuous technology changes. SharePoint as a distributed system combines various resources, progressively growing by provisioning on-demand solutions for the enterprise. In order to maintain uninterrupted and secure operations, proper security services must be implemented since SharePoint is subject to the same threats as other software that operates in the open Internet and networking environment. To increase the overall enterprise SharePoint security posture it is necessary that better security properties ranging from strong authentication and to adaptive content governance be implemented.

This threat landscape is also shifting as SharePoint offers entry for different types of devices and technology, such as mobile devices. Every environment that becomes SharePoint supported introduces new security needs, requirements, and difficulties.  Collaborative organizations and technologies indeed face numerous challenges in the field of security.

As can be evidenced with the new features added to the most recent version of SharePoint the collaborative technology industry is leaning to an IT concept known as consumerization. More enterprise users are experiencing technology innovations in areas such as social media before the technology, and even its baseline concepts, are available and supported by an enterprise. As a result, technology requirements within an organization are becoming more driven by employees, rather than strategic infrastructure decisions made by characteristic IT stakeholders.

The most evident example of this is enterprise users are increasingly demanding a collaborative infrastructure where both a personal and work life can be managed from one point. Utilizing social networking technology skills gained outside the organization this is considered excellent from an organization perspective, since it leads to better business information sharing, more effectual decision-making, and enriched business relationships. However, with the good comes some bad. While there are well-defined benefits of some of these innovation integrations, several security risks such as unauthorized, unmonitored, and uncontrolled use can increase the IT and business risks in areas such as confidentiality of intellectual property and business information.

Exploring the explosion of enterprise in interest in collaboration and social shared tools provide an attacker different avenues than previously available to harvest valuable business information due to the enhanced social features. There were several social tools built into the 2010 revision of SharePoint, but they have been increasingly refined in the recent release. Even lacking technical ability, often times finding valuable information can simply be time and patience since it might be casually and carelessly distributed. This type of data varies, however can tamper with company operations and expose or steal sensitive information. Collaboration and social sharing tools open up new avenues for an attacker to steal propriety or confidential business information or disrupt business operations. Social messages surfaced in SharePoint can be inadvertently used in order to spread malware more effectively and additionally through more multiple devices. Sensitive business information can be accidently disclosed between businesses connections since due to the tight restrictions generally placed on internal data being loosened in favor of the openness of the social media world. Controlling the security mechanisms that drive social sharing tooling is also an issue. A majority of these services are provisioned outside of an enterprises control, therefore compensation to govern these has to be adapted within the enterprise.

The concept of consumerization has also pushed the boundaries of normal collaboration to a readily increasing concept known as borderless collaboration. SharePoint is especially common in this arena as the mechanisms to quickly stand up externally facing environments that respects various security integration are relatively well-known. While extending collaboration can procure additional benefits, such as something as simple as increasing communication levels with business partners and customers, it also introduces new challenges. Various security tasks exist, ranging from simple tasks like whom should have access to what within SharePoint to how should user business information be kept confidential.  The most important benefit of a borderless collaboration initiative is to solve the challenges of an increasingly mobile, collaborative and virtual workforce.

SharePoint security threats come in many forms. However it is important to remember that SharePoint is merely an ASP.NET application, and thus subject to all if not most of the same core vulnerabilities that affect its baseline components. All of the layers that make SharePoint a functional software product, such as SQL server and IIS are subject to distinct vulnerabilities. This leads to a fair amount of threats being considered practical against a SharePoint environment, the platform technology volume is so large. As a result, one of the greatest skills that can be mastered is differentiating between what is a practical threat, what is considered to be a threat, and what should actually be ignored. Each SharePoint environment is in general unique, and used for a different purposes. Security strategies to secure this data have to be adaptive as well to properly achieve organizational security goals. When considering SharePoint security it is important to not get fastened to strictly considering the technology security. While there are several layers that build up SharePoint security it is equally important to secure the tools and content that interact and run on the SharePoint platform. For example, there are many avenues for a SharePoint architect to surface information in SharePoint, either through WebParts or perhaps third party enterprise application integration components. However simply surfacing this data creates a potential security vulnerability since the information could be confidential data or describe sensitive business functions. Supporting restrictions that grant the only the level and types of content is as important as technology stack vulnerabilities.

Every standard SharePoint web request begins the same way. A user, or subject, issues a request to access a SharePoint system. Before SharePoint provides access, a challenge is issued requesting the user to provide a public declaration of who they are. While there are multiple avenues a user can leverage to make this public declaration, such as manually keying values in to client based digital certificates, every approach translates to a user’s identity. An identity in the context of SharePoint is simply stating an assertion about the user. SharePoint issues the question “Who are you”, the user is responding with “I am this”.

Establishing the identity of the requesting user is only a small portion of the process. Following, the determination of whether the credentials being presented can be verified, or Authentication (AuthN in shorthand notation) occurs. After responding to the “Who are you” question from SharePoint, SharePoint issues the question “OK, prove it?” in order to verify that the requesting user is valid and not a malicious party forging an attack. AuthN can incorporate multiple authenticators such as passwords or certificate private keys. AuthN allows SharePoint to not directly possess the required secret, however the mechanisms to verify it’s authenticity.

Following authentication, Authorization (AuthZ in shorthand notation), controls the resources that the user is allowed to access. Whereas authentication is the verification of the identity assertion, authorization is the verification of permission. Authorization always precedes authentication.

Anonymous authentication means that a user has already authorized but not authenticated, bypassing the authentication step.

A real world example of an authentication and authorization relationship can be found when considering a bank. A bank customer may visit to withdraw funds from an account. Upon the member issuing the withdrawal request, the teller will ask the member for identification in order to verify the member is whom they say they are, such as a driver’s license. Following approval and verification of the identity, the authentication request funnels to the credit accounts that are valid for the member. Importantly, accounts that are not part of the member accounts are kept separate. If a non-member attempts to access the same account, their credentials will not process pass the authentication process since they are not considered authentic.Authorization differs from authentication because it is the determination of whether the login is allowed. Closely coupled to the concept of authentication, both authorization and authentication must return true to create a connection to a system such as SharePoint.

Consider this same situation from the bank teller’s perception. The teller controls and regulates access to the account, allowing users to access the funds in an account by authorizing them. The question that the bank teller answers is “Is this the owner of the account?” The bank teller does not have any proof that the presented identity, in this case a driver’s license, is valid. It would not be possible, as the bank teller was not responsible for issuing the driver’s license. The bank teller however trusts that licensing department that is responsible for issuing the license. The licensing department is considered a recognized, trustworthy source of information. The bank teller could optionally reject the presented license for a multitude of reasons, however not because of a known, trusted source. For example, an expired expiration date or a pictured that appears to be dated on the license may require the bank teller to inform the customer that the identity needs to be updated. Another institution could optionally provide identity in place of the driver’s license, such as a passport. The important factor is whether a trusted institution has issued the identity. Critically in this example, the bank teller doesn’t have to understand the process that the bank customer went through to get their license or how the bank customer came to prove their identity to get their license. The bank teller simply knows that the institution that issued the license is trusted.

Summarizing what has happened under the in the customer/teller interaction:

  • The bank teller does not verify the identity directly, rather uses a trusted institution and its issued documents metadata.
  • The bank teller doesn’t need the identifying document in a particular format, as long as it is trusted. A passport, driver’s license, and several other formats would be acceptable to the bank teller.
  • The bank teller is indifferent to how the identifying document was procured or the process that the customer went through to get the document.

This process exists in many common circumstances such as going to the liquor store or going to a movie theater, both are similar transactions that require presenting authenticating trusted identification from the customer. This process is extremely efficient, which is the reasoning behind SharePoint following a similar pattern when it comes to identity. In essence, the identity layer is decoupled from the application layer.


SharePoint 2010 Business Connectivity Services Security Best Practices – Permissions And Authorization

The various permissions associated with Microsoft Business Connectivity services are all associated in various ways. This can be with an individual account, a group account, or a claim with several different levels of permission in place for a given object within a metadata store. It is crucial that the settings for permission for any object in Microsoft Business Connectivity Services is done correctly. This will allow it to create solutions for securing access to external data. The strategy for permissions needs to be carefully evaluated during the planning stages. It is a good idea to provide specific permissions to each user or each group. The goal is to offer credentials that provide only the privileges that are necessary in order for them to perform necessary tasks. The overall security strategy you have is important. Don’t overlook the value of it for your external systems too. The way in which you will set permissions up can vary by business and implementation purpose. Take various security models and features into consideration before you decide how you will proceed with it.

There is a metadata store that is inside of each instance in the Business Data Connectivity Service. This includes the external content types, methods, external systems, and all the models which have been defined for the purpose of that store. There is a hierarchy among those objects used to determine which of them can be used to gain permission to other objects. Each of the objects will gain permission from parent objects. The idea is to set up the permissions so that all of the settings for children of a given item can be replaced by those of the parent object. There are four permission levels that may be set for the metadata store: Execute, Set permissions, Edit, and Selectable in clients.
There are many objects that have to be taken into consideration to determine what type of permissions to set. As you go through them you will be able to determine what is best for you to use.

External Content Type – The external content type offers a collection of metadata that can be reused. This metadata defines one set of data from others that are used with external systems. All of the connectivity information that is related to certain groups of data is maintained here. There aren’t any edit permissions with the external content type. However, the setting can be used for permissions linking to child objects in the metadata catalog. The user is able to execute permissions and create external lists in client permissions. The user is able to set permissions with external content type.

External System – The external system is a metadata type of support for sources of data. They can be modeled like a database, web service, or .NET for connecting purposes. The user is able to edit the external system so that the permissions are accessible though SharePoint Designer. There aren’t any execute permissions or selectable permissions with the external system. However, the settings can be used to gain permissions to child objects that are part of the metadata catalog. The user is able to set permissions on the external system.

Metadata Store – This is the collection of .XML files that are stored in the Business Data Connectivity Service. Each of them contain definitions for external systems, external content types, and all the models. The user is able to create new external systems if they wish. There isn’t an execute permissions with the Metadata Store. However, it can be used to create permissions in child objects according to what is listed in the metadata catalog. There aren’t any selectable clients in permissions either. Yet the settings can be used to create permissions along with child objects in the metadata catalog as well. The user has the ability to set permissions on any object within the Metadata Store.

Method – The method is the type of operation relating to an external content type. The user is able to edit the method being used. There aren’t any execute permissions or selectable in clients permissions available in method. However, the user is able to set permissions for it.

Method Instance – The method instance is a description for how to use a given method with a given set of default values is in place. The user can edit the method instance. They can also use execute permissions. However, there aren’t any selectable in client’s permissions. The user is able to set permissions on the method instance.

Model – The model is a .XML file that has sets of descriptions for one or more of the external content types. It also contains descriptions for their external systems that relate to it. All of the information that is specific to a given environment including authentication is stored here. The user can edit the model file if they wish to do so. There aren’t any execute permissions or selectable permissions for models. However, the user can change and set the permissions in the models as they see fit to do so.

There are more than just general capabilities when it comes to setting the permissions that were described earlier. There are special permissions to consider with the Business Data Connectivity Service as well:

  • Application Pool Accounts This pertains to front end servers and they must have the same permissions as Farm Administrators to the Business Data Connectivity Service. This is necessary in order to create deployment that will be based on Microsoft Business Connectivity Services.
  • Farm Administration They will have full permission to access the Business Data Connectivity Service. This is so they are able to properly maintain, fix, and update the service as needed. The Farm Administration doesn’t have the ability to execute permissions though on any object in the Metadata Store.
  • SharePoint Designer Users They will be given a series of permissions for the entire Metadata Store. This includes the ability to edit, execute, and select clients. They aren’t given permission though to set permissions. It is possible to limit the permissions of the SharePoint Designer to a subset for the Metadata Store as well.
  • Windows PowerShell The users are Farm Administrators and they have the ability to operate various commands with the Business Data Connectivity Service.

There are plenty of common tasks that take place in the Business Data Connectivity Service. Here are the permissions that are necessary in order to be able to perform them:

  • Adding a new object in the Metadata Store The user has to edit permissions on the parent metadata object.
  • Adding external content type to a model the user has to edit permissions on the model.
  • Deleting an object from the Metadata Store The user has to edit permissions on that object. This includes the parent and all of the child objects.
  • Deploying a package This is generated by the application pool account used by the front end server. This has to have full permissions to the Business Data Connectivity Service for this task to be completed.
  • Exporting models The user has to edit permissions on the model and for the external systems that are within that model.
  • Importing models The user has to edit permissions for the Metadata Store. The user that imported it will typically be the one given permissions for such roles to take place.
  • Setting permissions on the Metadata Store To initially get the Business Data Connectivity Services permissions have to be set. They are empty after first and the Farm Administration has to go to the Metadata Store and install those initial permissions.