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.

Share

SharePoint 2010 Large List Scenarios Best Practices

Plenty of large list scenarios exist and it all depends on the types of design decisions that are made. With a collaboration effort users will be adding content all the time and updating what is already there. This means you don’t want the list size to get too large per item. Otherwise it becomes extremely difficult to be able to filter content.

When you work with unstructured document libraries you need to be aware that there are limits and throttles in place. The offer protection for SQL Server brokering performance. As a result there can be times when you want to change the throttle to support a scenario with a smaller list in mind. As your list increases in size you need to be able to understand how information architecture and data access will affect it. Such information helps you to make decisions for the design of the list and to support various scenarios.

Let’s consider a few different scenarios:

Unstructured document library This can be offered with hundreds of items in the list. There isn’t any manager. With high reads and balanced adds and updates it is very versatile. You have to manually upload the new content. There can be tens of users at a time.

Collaborative large list Thousands of items can be in the list. There are information subject owners. High reads are possible and you will have more updates than adds. New content is manually uploaded. You can have hundreds of users at one time.

Structured large repository Tens of thousands of items can be in the list. There is a dedicated contend steward for the information to be managed. You will have very high reads, few additions, and you will have only a handful of updates. New contents can be both submitted and uploaded. There can be tens of thousands of users.

Large scale archive There can be millions of items in the list, with a team of stewards to manage them. There are low reads, low updates, and high adds. New content can be submitted. There are tens of thousands of users.

There are times when an unstructured document library should be used. Typically it is a good idea when you have a team that is working on something. It can hold thousands of documents and allow librarians to run through lists without any planning of operations in place such as the specifics of adding columns. There can be some problems though such as a user that gets a list view result that has more than 5,000 items in it.

That is why it is important for the monitoring libraries to approach the list view limit. Then they can keep a good idea on when any given document in a particular library is getting close to that limit. There can be hundreds of users for such a set up but few that will be using it all at the same time. With that in mind there isn’t too much trouble with loading a single library at any given point in time.

Yet there can be many of these types of libraries in place. Instead of planning to support specific scenarios though it should be set up to support a large number of such libraries.

When you leverage a collaboration library you offer large lists that can have hundreds or thousands of items stored in it. These types of large lists are very common when you are trying to offer solutions, for engineering purposes, and even for marketing or sales strategies. Users are able to continue adding and updating information. The structure and the management can be organized but there are many elements that are controlled by the users.

As a result of this lists often grow extremely quickly, and often beyond what was anticipated. This can also have many more types of changes on an administrative level than with a structured archive. That can include adding more folders or even deleting some that already exist. Such actions can be implemented as a method of preventing the list view limit from being exceeding as the size of the list continues to increase.

When a large repository is structured there can be thousands of items in place. The content is usually only submitted to users or the system once they have been finalized. They are often used for different types of record keeping. This can include archives, documents of great value that need to be stored, and many of the final documents that are displayed on the internet.

Such content is typically structured and easier to manage. As a result this makes it easier to control how quickly the list grows. There can be thousands of users that access it all at the same time. There are many more people actually reading the materials though than writing it. While updates do occur they are only occasional.

With a large scale archive you can have millions of items if you need to. They can be on one large list or broken down into several smaller lists. There can also be many site collections if you like. The idea is that you will have very few amounts of reads going on or updates. This is a general type of storage facility for documents. You may not use them often but you do need to retain them for long periods of time. This includes those that may be audited for a period of up to certain amount of years. Search is used to retrieve such documents when you need them.

Share