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.