Securing SharePoint 2013: Understanding Authorization and Permissions - Part 2

This post is the fourth in a series where I introduce concepts and considerations for security in Microsoft SharePoint 2013.  These articles serve as an introduction to those new to SharePoint or to those that have SharePoint up and running but are looking at built-in features and third-party solutions to secure their sensitive information.

---

 

Understanding Security Scopes and their Limits

Understanding SharePoint permissions and using them effectively means you need to understand the concept of "security scopes" and their limits.  When unique permissions are assigned to a container or item, SharePoint creates what is called a security scope. This is an important concept to understand because there are limits to how many security scopes can be created, and there are limits to the size of the security scope before SharePoint performance starts to be adversely affected.

 

Each site collection initially contains one (1) security scope, related to the initial permissions at the site collection level. Each time permission inheritance is broken a new security scope is created. So, in Figure 1 above, the “Demo” site collection has four security scopes: one at the site collection level, another at the site level, another on a library, and a fourth on a document. All other sites, libraries, documents and items in the diagram inherit their permissions and therefore no security scope is created for those levels. The size of the security scope refers to the number of principals in the security scope. Remember, a principle is a user, group or claim. To view another example, refer to Figure 2 below to see how security scopes are created as permission inheritance is broken.

In previous versions of SharePoint, there were various limits documented around how many security scopes a library or list should contain before performance would be adversely affected. These numbers tended to vary depending on the article and there was a lot misunderstanding around them. In SharePoint 2013, each list or library can contain up to 50,000 security scopes before performance begins to be impacted (this change actually came about in SharePoint 2010, Service Pack 1 and the latest cumulative updates, but it has only been documented in SharePoint 2013). This is a significant improvement over previous versions and when you think about it, it’s a very large number to work with. This means that a single library can have up to 50,000 documents or items which each have their own unique permissions. In addition to this, a library can also contain other documents which inherit permissions from the library level (or site or site collection).

 

In order to actually create unique permissions on up to 50,000 documents or items in a library/list, a SharePoint farm administrator must adjust a setting called the “List View Threshold”. Modification of this setting requires these steps:

1.      Log into the SharePoint Central Administration console

2.      Click “Application Management” on the left hand side, then click “Manage Web Applications”

3.      Select the web application you wish to modify

4.      In the ribbon click “General Settings” to activate the menu

5.      In the menu select “Resource Throttling”

6.      Find the “List View Threshold” setting and modify it to the appropriate value (the default is 5000)

If you do plan to modify this setting to support more unique permissions, ensure that your environment is sized appropriately to handle the additional query load. As well, ensure that you test your environment under realistic conditions with this setting in place to ensure that users will not be affected by potential performance issues.

 

Another important limit to understand in SharePoint is the size of the security scope.  The size of a security scope refers to the number of users or groups assigned with unique permissions for a particular scope.  Limits on this size have remained consistent between SharePoint 2010 and SharePoint 2013. Each security scope can contain a maximum of 5000 principles. This means, each time you specify unique permissions on an item or document there can be no more than 5000 users, groups or claims specified. Once again, in reality this is quite a large number to work with.

 

These limits of course depend on the architecture of your SharePoint 2013 farm and the hardware/configuration used. For more information on SharePoint 2013 boundaries and limits please refer to the following Microsoft article:

http://technet.microsoft.com/en-us/library/cc262787.aspx.

Limited Access Permissions

When permission inheritance is broken and unique permissions assigned to a particular item, let’s say a document, SharePoint will automatically create what is called a ‘Limited Access” permission on its parent and all the way up the hierarchy up to the root site collection. The Limited Access permission will contain the same principles (users, groups and claims) as the unique permission assigned, however using the pre-defined Limited Access permission level. The purpose of this Limited Access permission is to give the user just enough permissions to navigate to the item on which they were just granted permissions (even if they did not have access to the folder, library or site previously). This occurs automatically, as part of the process of assigning unique permissions.

 

The challenge with Limited Access permissions is that they never get removed or cleaned up in any automated way. Even if you cause a particular document or item to re-inherit permissions from its parent library, the limited access permissions will remain in place. Therefore, it is important to monitor how many Limited Access permissions are created because this does contribute to the limits discussed in the previous section.

 

The following diagram illustrates how security scopes and Limited Access permissions are created:

 

 

 

Figure 2. SharePoint security scopes are created when permission inheritance is broken.

There has been quite a bit of literature written in recent years about security scopes and their limits, not all of it accurate.  I highly recommend that you review the latest document from Microsoft (link above) on the limits in SharePoint 2013 because that will be the most up to date documentation.

 

   -Antonio

 

Securing SharePoint 2013: Understanding Authorization and Permissions - Part 1

This post is the third in a series where I introduce concepts and considerations for security in Microsoft SharePoint 2013.  These articles serve as an introduction to those new to SharePoint or to those that have SharePoint up and running but are looking at built-in features and third-party solutions to secure their sensitive information.

---

 

Authorization is an important concept to consider when securing sensitive information in Microsoft SharePoint. Looking at this concept broadly, it’s helpful to understand the differences between authentication and authorization. As mentioned, authentication is the process of determining if a user is who they say they are. Authorization is the process of determining what resources a user can access and what actions can they perform with those resources. Just because a user has access to a system doesn’t necessarily mean they should have complete access to everything within that system.

Within Microsoft SharePoint, authorization is enforced through permissions. With SharePoint 2013 there are some important new changes that are important to understand.

Understanding Permissions
The underlying permissions system within SharePoint 2013 is, in most respects, the same system it has always been. Permissions can be used to secure access to any item or document within SharePoint, as well as any container (folder, list, library, site, site collection).

A permission has 3 components:

§  An information object to which it is assigned (item, document, or container)

§  A principal (user, SharePoint group, AD group, or a claim)

§  A permission level (read, full control, contribute, design or a custom permission level)

Permissions are assigned to items, documents or containers by selecting a user or group and then selecting a permission level. For example, items or containers could have the following permissions assigned to them:

§  User John Smith has Read access to a document

§  AD Group Finance has Full Control access to a library

§  SharePoint Group Project_Team has Contribute access to a Folder

§  User Engineering_Contractor has Contribute access to a site

As an advanced feature, SharePoint 2010 and 2013 allow a permission to contain a “claim” instead of a user or group. As described earlier, a claim is a trusted user attribute that is retrieved when that user logs in. Attributes could include data like the user’s email address, their group memberships, their security clearance, etc.

A permission containing a claim would look like the following:

§  Users with the claim Security_Clearance=Secret have Read access to a document

In this example, when a user logs into SharePoint, if an attribute is retrieved about that user which contains the value Security_Clearance=Secret then the user will be granted Read access to the document. SharePoint needs to be configured for Claims Based Authentication for this to occur.

 
Hierarchical Permission Model
SharePoint 2013 continues to have a hierarchical permission model, which means permissions are organized according to a hierarchy. Permissions are initially assigned by SharePoint at the site collection level. As a result, all sites, libraries, lists, folders and content below that site collection will automatically receive those permissions. The lower level containers or items “inherit” their permissions from the level above if no specific permissions are assigned to that object.

At any level within SharePoint, a user can break permission inheritance and assign specific permissions to that level. For example, a site collection called “Demo” contains a SharePoint group called “Demo Members” which has been assigned with the Read permission. So, any member of the “Demo Members” group will have read permissions to the site collection and anything below it. The “Demo” site collection contains 3 sites, one which breaks permission inheritance so that members of the AD group “Finance_Team” has Edit permissions. As a result, all content below this site (all libraries, folders, content, etc.) will inherit the “Finance_Team” permission from their parent site, unless something below the site also break inheritance.

The following diagram illustrates this point:

Figure 1. SharePoint containers and items with broken permission inheritance.

   -Antonio

Securing SharePoint 2013: Plan for Authentication

This post is the second in a series where I introduce concepts and considerations for security in Microsoft SharePoint 2013.  These articles serve as an introduction to those new to SharePoint or to those that have SharePoint up and running and are looking at built-in features and third-party solutions to secure their sensitive information.

---

 

Microsoft SharePoint 2013 comes with a variety of authentication options to fit your organization’s requirements. At its most basic level, authentication is the process of determining that a user is who they say they are. This usually occurs at login, and typically with a simple username/password match. So, when a user presents a username and password, SharePoint will then verify that the username/password combination matches what it has in its database. If it does then the user is authenticated.

Considering authentication a little more broadly, authentication can also be seen as the process of validating a user’s identity against an identity provider. Identity providers include Active Directory - Directory Services (AD DS), LDAP directories, or Active Directory Federation Services (AD FS). The use of identity providers becomes important when we look at new methods of authentication like Claims Based Authentication, which is discussed further below.

Within Microsoft SharePoint, the authentication method is configured uniquely for each web application. It’s important to note that authentication is configured when a web application is created through the Central Administration console. However, it cannot be modified through this console after a web application has been configured. To modify the authentication configuration of an existing web application, a SharePoint farm administrator will need to use the appropriate PowerShell commands.

Very similar authentication options are available in Microsoft SharePoint 2013 compared to those that were available in SharePoint 2010. However there are 2 big differences:

1.      When creating a new web application in SharePoint 2013 the default authentication method is now Claims Based Authentication.

2.      The configuration options for Windows Authentication has been removed from the Central Administration console. It can only be done through Windows PowerShell.

The authentication options available in Microsoft SharePoint 2013 are: 

§  Claims-Based Authentication (SAML Token Based)

Microsoft introduced Claims Based Authentication as an option in SharePoint 2010, in part to better support third-party authentication providers and multi-vendor environments that support internet, federated partners, or cloud computing models. Traditional authentication mechanisms did not support these environments well. With claims based authentication, once authenticated a user obtains a digitally signed security token from a commonly trusted identity provider. The token contains a set of attributes about the user—or claims—and each claim represents a specific piece of data about the user such as their name, group membership, role, title, security clearance, or even age. Applications like SharePoint which support claims based authentication receive a security token from a user, as opposed to credentials, which they use to determine user access to resources. This can be accomplished without having to make separate queries to directory services such as Active Directory.

Some of the more traditional Windows domain authentication protocols, such as NTLM and Kerberos, may also be used along with claims-based authentication. When using these protocols in conjunction with claims based authentication, SharePoint 2013 will make an authentication request using the classic protocol and the response (a Windows NT Token) will then be translated to a new SAML token by the SharePoint Security Token Service (STS).

As mentioned, claims based authentication is now the default authentication method within SharePoint 2013 when new web applications are created. This, combined with the fact that classic Windows Authentication has been removed from the Central Administration console and is only configurable through PowerShell, is a significant move by Microsoft. It indicates that Microsoft believes strongly in the power and robustness of claims based authentication and that it is highly recommending claims based authentication moving forward.

§  Forms-Based Authentication

Forms-based authentication validates users that enter their credentials (usually) on a web login form. It is typically used in extranet deployments of SharePoint, where external users need to log in to access SharePoint resources but those users do not have accounts in Active Directory.

Forms-based authentication is enabled through claims-based authentication and the use of a custom ASP.NET membership and role provider. Forms-based authentication can be used against credentials that are stored in various accounts sources including: a database (such as SQL Server), an LDAP directory, or even Active Directory.

§  Classic Windows Authentication

Classic Windows authentication makes use of the classic Windows authentication protocols that are supported by Windows domains to validate user credentials, such as NTLM, Kerberos, Digest Authentication and Basic Authentication. This is sometimes referred to as Integrated Windows Authentication.

Configuring Classic Windows Authentication for a SharePoint 2013 web application requires the use of PowerShell as the configuration interface has been removed from the Central Administration console.

In addition, it’s important to be aware that several caveats exist when continuing to use Classic Windows Authentication with SharePoint 2013 web applications. For example: if migrating a system using Office Web Apps with a SharePoint 2010 web application with classic mode authentication, the SharePoint web application must be migrated to the 2013 claims-based authentication method for it to continue working with Office Web Apps. Viewing and editing with Microsoft Office Web Apps will not work on SharePoint 2013 web applications that use classic mode authentication.

§  Anonymous Authentication

SharePoint 2013 also supports Anonymous Authentication for users who do not need to authenticate any credentials in order to access site resources. Anonymous Authentication is often used for public facing SharePoint sites.

Anonymous Authentication is disabled by default.  It must be enabled on each web application separately by performing the following steps:

1.      In the Central Administration Console select Application Management on the left side and then select Manage Web Applications

2.      Select the web application you are interested in, then select Authentication Providers in the ribbon, select the zone and then check Enable Anonymous Access

3.      Click Anonymous Policy in the ribbon bar

4.      Select a network zone and an Anonymous User policy

Once these steps are complete, site owners or site collection administrators for specific sites still need to enable anonymous access for individual site collections or sites.  Until this is done, no site collections, sites or libraries will be available for Anonymous Access.  This is accomplished through the following steps:

1.      A site collection administrator accesses the site targeted for Anonymous Access

2.      Select Site Settings and then select Site Permissions

3.      In the ribbon select Anonymous Access

4.      Finally select if an anonymous user can view the entire site or simply lists or libraries

For additional detailed information on the authentication options available in Microsoft SharePoint 2013, please visit the following Microsoft TechNet article:

http://technet.microsoft.com/en-us/library/cc262350.aspx.

   -Antonio

A First Experience with Microsoft Office 365 and SharePoint Online

Early this year I had my first experience with Microsoft Office 365, in particular with SharePoint Online, and I have to say the experience was excellent.  To set the stage, due to the nature of most of our customers at the time (primarily military and government) I typically worked with on-premises SharePoint deployments, but I was researching the capabilities offered by SharePoint Online for a specific project I was assigned and I needed to get up and running quickly.

The setup process was simple, fast and without any hassles.  It took about 45 minutes to get a new Office 365 tenant setup and using SharePoint Online.  SharePoint Online is part of Microsoft Office 365 and your first step to getting setup is to purchase an Office 365 subscription, which can be done here:  http://office.microsoft.com/en-us/business/compare-office-365-for-business-plans-FX102918419.aspx.

 

As it was my first experience, I signed up for a free trial which is also possible at this site.  When purchasing a subscription there are several plans to choose from, starting as low as $5.00 per user per month (for the Small Business subscription) and ranging up to $20.00 per user per month (for a full blown Enterprise E3 subscription).  There are several levels available between those depending on your needs and your business.

Once you’ve registered for a trial or purchased a subscription, you’ll be taken to an Administrative Center portal page.  This page allows you to manage all administrative functions for your shiny new Office 365 tenant.  It contains a number of tasks you need to perform to get setup – these include:

·        Adding Domains

Adding a domain is one of your first steps.  If you already own a registered domain name you may use it.  The Administrative Portal guides you through the process of verifying ownership and setting up the appropriate DNS records to point to your Office 365 tenant.

 

·        Adding User Identities

Next you’ll need to add users to your Office 365 deployment.  You can add users one at a time, specifying various attributes for each user.  Alternatively you can add users in bulk by uploading an appropriately formatted CSV file.  As well, depending on your subscription you can Active Directory Synchronization to allow existing users to use their existing AD credentials to access SharePoint Online (only available with an Enterprise level subscription plan).  As well, you can enable Single Sign On through Active Directory Federation Services (ADFS) to allow users to access SharePoint Online using their existing credentials and not requiring them to enter their credentials again. In order to enable Active Directory Synchronization and Single Sign On there are a number of steps to complete, and you should follow the Microsoft guidance provided on these very helpful articles:  Prepare for Single Sign On http://technet.microsoft.com/en-us/library/jj151786.aspx and Using Active Directory with Microsoft Office 365 http://channel9.msdn.com/Events/TechEd/NorthAmerica/2011/SIM320. 

 

·        Configuring a SharePoint Team Site and Web Site, or Adding Additional Sites

Once SharePoint Online is setup it will contain 2 sites by default: a team site and a web site.  A team site is an internal SharePoint site, where teams and groups of users can exchange documents, connect with one another, store and retrieve content and generally collaborate.  A web site is a SharePoint site which represents a public facing web site for your business, where external partners and customers can retrieve information about your organization.  SharePoint Online provides both sites by default, and allows you to create additional SharePoint sites as needed from the available templates.  These default sites as well as new sites can be configured as needed, with additional libraries, lists, views, apps, web parts, etc.  At this point you can configure the default sites, or add additional sites for various purposes.

 

·        Creating Groups and Configuring Permissions

Once end users are created it will be necessary to configure those users with the appropriate permissions to access the content they need to perform their daily tasks.  The simplest and most manageable strategy to accomplish this is through the use of groups.  As opposed to assigning permissions to users directly, it is recommended that administrators create security groups, they add end users to those groups and then assign permissions to the groups. When first starting out with SharePoint Online this is an effective strategy to allow administrators to more easily track of which users have access to specific sites or content.  Security groups can often represent teams or roles within the organization that have certain types of access to content – for example, finance team members can be part of a “Finance” group that has the Full Control permission level assigned to the organization’s financial documents. 

SharePoint Online uses the same permission model as on-premises deployments.  So, administrators can expect to work with permission levels which are assigned to security groups or users and to content, and which are made up of predetermined permissions like View, Open, Edit, etc.  As well, they can expect to work with permissions that are inherited from libraries, lists and sites, or with unique permissions that are assigned to specific information objects like documents.

·        Configuring External Access (if required)

If required by the business, an administrator can configure SharePoint Online to allow external users to access the organization’s SharePoint Online sites.  This can be configured through the Administration Center portal by accessing Settings and selecting Manage External Users.  Once configured here than individual site collection administrators or site owners are able to configure external users to access to their site collection’s sites (it is still disabled by default and must be configured for each site collection).  They must provide the email address of each external user that is to be granted access, and they are able to send email invitations to these users to access content which has been shared to them.   This is an extremely useful option if you have business partners outside of your domain that you wish to have access to specific content within some specific site collections.

·        Adding Content to SharePoint Online

At this point you’ll likely want to start moving content into SharePoint Online.  Once you’ve figured out which content needs to move into SharePoint, you have several options available for uploading content:  uploading a single document at a time, uploading multiple documents at one time, accessing SharePoint through the Windows Explorer view to add multiple files and folders at one time, or dragging and dropping multiple files onto a SharePoint 2013 library in the web browser.  Typically, you need to think about moving other forms of content as well, such as announcements, contacts, lists, business data, databases, appointments and even business workflow.

There are of course many other options available during the setup process which are not discussed here, including configuring Microsoft Exchange for business email, Microsoft Lync for unified communications such as online chat and Skype, as well as enabling mobile access.  As well, it’s important to understand that before proceeding to get your entire organization up and running with Microsoft Office 365 and SharePoint Online, many of these steps require careful planning to ensure that they fulfill the business needs of the organization - for example:

·        Understanding which features are included with each subscription and selecting the plan is right for your business

·        Determining which users need access to SharePoint Online, which user attributes are important to configure for those users and determining if single sign on is a real requirement for the business

·        Determining which types of team sites are needed, and by which user communities

·        Determining if all corporate content needs to move to SharePoint Online, or if some content that has not been accessed for a long periods of time can be archived instead

·        Etc…

The main point I wanted to get across in this article is that Microsoft has made the process of getting up and running with Office 365 and SharePoint Online extremely easy.  As I started off mentioning, I was able to easily get a demonstration SharePoint Online instance up and running, with some users, some required customizations and some sites and content in about 45 minutes following many of the configuration steps mentioned above.  This was possible even without having much knowledge about Microsoft Office 365 and SharePoint Online to start off with. 

I highly recommend you go through the process yourself and learn all that Microsoft Office 365 has to offer – you can begin here: http://office.microsoft.com/en-us/business/compare-office-365-for-business-plans-FX102918419.aspx.

   -Antonio

Securing SharePoint 2013: It All Begins with Deployment

This post is the first in a series where I'll introduce various concepts and considerations for security in Microsoft SharePoint 2013.  These articles will serve as an introduction to those that are either new to SharePoint, or to those that have SharePoint up and running and are looking at the various out-of-box and third-party options available to secure their sensitive information.

---

 

Securing Microsoft SharePoint starts at the time of deployment. When first deploying SharePoint to a staging or production environment there are specific best practices that must be employed to ensure a secure and well managed environment. In particular, using appropriate user accounts for various necessary functions is a critical step. This concept is not new to Microsoft SharePoint 2013 as it also applies to Microsoft SharePoint 2010. However, it is of significant importance and therefore deserves mention again.

The purpose of using multiple accounts is to ensure proper separation of responsibilities and activity auditing. Best practices recommend that least privilege user accounts are used for specific deployment and management functions. In other words, specific user accounts are created for very specific functions and those accounts are granted only the privileges required to perform that function—nothing more.

There are varying views on how many user accounts are necessary when deploying Microsoft SharePoint, but most experts agree that at minimum 3 different accounts are necessary to deploy SharePoint to enterprise environments.

1.      Setup User Account
This account will be used specifically for running the SharePoint setup wizard, the product configuration wizard and for installing any patches, service packs, cumulative updates or hot fixes. You must login with this account when running the SharePoint setup and configuration wizards, or if you are installing any updates.

This account must be a domain user account and added to the local Administrators group on each server in the SharePoint farm.  An example of how this account is often named is: domain\sp_setup_user

The Setup User Account should not have any special administrative privileges on the SQL Server system as long as SQL Server is on a separate system or VM from the SharePoint servers. When running the SharePoint setup and configuration wizards, these processes will use the Setup User Account credentials to create databases and SQL logins for other SharePoint accounts. However, despite the lack of administrative privileges to the SQL Server system (as recommended above), before starting to setup SharePoint, you must assign the Setup User Account to the securityadmin and dbcreator roles in SQL Server.

2.      SQL Server Service Account
This account is used specifically by SharePoint when it tries to access data from SQL Server. The SharePoint setup wizard will request this account during the setup process, so you should create it before you begin the SharePoint setup. It needs to be assigned to MSSQLSERVER and SQLSERVERAGENT services when you install SQL Server. An example of how this account is often named is:  domain\SQLService

The account requires no special domain permissions. This account will be given all appropriate rights to SQL Server during the SQL Server setup process. Best practices dictate that this account needs to be a user account in the Active Directory domain and it should be secured according to your IT security policies.

3.      SharePoint Farm Account
This account is the farm administrator’s account and it is all powerful within SharePoint. This account will be used by the Farm Administrator to login to the SharePoint Central Administration console. This account is used to actually run the SharePoint farm. For example, during the setup and configuration process, several critical SharePoint services (including the timer service) will be configured to use the Farm Account as the identity under which they run. An example of how this account is often named is: domain\sp_farm_user

When running the Product Configuration Wizard, you will be asked to specify this account. The wizard will use the credentials you are logged in as (that is the Setup User Account) to give the Farm Account ownership of the Config database.

There are some exceptional cases where additional user accounts are needed when deploying SharePoint. For example, if specific SharePoint services require their own account for specific auditing and security purposes. For each SharePoint deployment accounts, there are some general best practices to consider:

• All accounts should be Active Directory domain accounts, so that credentials, password expiry, and general user account management can be centralized. Local user accounts on the servers involved should not be used. This is especially important in the case of critical infrastructure like SharePoint.

• Do not use personal accounts when deploying SharePoint. The Setup User Account becomes owner of the SharePoint farm. The Farm Account becomes dbowner of the SharePoint Config database. There are many places where the account, and its email address, get integrated into the farm. Ensure that you use a dedicated account for the Setup User Account in particular, so that the farm isn’t owned by your personal account which has privileges on other systems. In addition, personal accounts change if your role changes, so it is important that a personal user account is not left owning the SharePoint farm.

• Configure one centralized email account for all managed service accounts—do not use a personal email address. The setup user account (and other service accounts) should have an email addresses reflecting that they are part of the SharePoint infrastructure. For example, assign all accounts the address “sharepointservice@company.com” as the email address in Active Directory. When SharePoint sends out periodic notifications related to server health and maintenance, with just one centralized email address, all notifications related to SharePoint will go to a single email inbox that can be monitored by the entire SharePoint team.

User account best practices are also covered in great depth in the Microsoft SharePoint 2013 Deployment Guide, which can be downloaded from here:

http://www.microsoft.com/en-us/download/details.aspx?id=30384.

SharePoint administrators are encouraged to review the necessary details in this comprehensive document to determine the user account requirements for their environments.

 

   -Antonio

Protecting Your Social Media Accounts from Hacking

So, this post is not about SharePoint; but it is a computer security topic that is becoming increasingly important in our social media charged world: How to protect our many social media accounts from hackers.

I came across a great article in the Globe and Mail recently, that I wanted to share with people which presents 10 concrete steps to protect businesses from having their social media accounts hacked. 

http://www.theglobeandmail.com/report-on-business/small-business/sb-tools/top-tens/ten-ways-to-protect-your-workplace-from-twitter-hacking/article14084647/

Social media accounts present hackers with another attack vector by which to compromise organizations.  Often, due to social media still being quite new for many businesses, they lack corporate security policies around social media - policies like who can use those accounts, how are those accounts secured, what type of corporate information can be shared via social media, etc.  Sometimes, due to the often informal nature of social media, individuals may feel that these accounts fall outside the realm of corporate information security.  However, social media and their related accounts (Facebook, Twitter, Instagram, etc.) can often be easy inroads into a businesses' computer infrastructure for those that would either steal corporate intellectual property, or try to compromise computer security for other criminal purposes.

The article goes through 10 best practices which are very practical steps that I see many large enterprises adopting in my own work.  Some of them are very common sense but quite critical to organizations protecting their information:

• Provide employees with easy to follow guidelines
• Define what's confidential

Some of the other steps discussed are slightly more nuanced but definitely important to include when developing a corporate security strategy:

• Look at your employees differently
• Be social but be smart
• Don't link all your accounts

Overall, if you or your business engage in social media at all, I highly recommend giving this article a thorough read.

In the spirit of full disclosure, the article happens to be written by my wonderful wife Laura Maio (twitter: @LJMaio).  :-) 
   - Antonio

How to Disable the Windows Explorer View in SharePoint

In working with several customers to secure sensitive information in SharePoint, we've found that there are times where some customers still want to use the Windows Explorer view in SharePoint. This is due to a couple of reasons:

• The fact that many users are used to copying/moving files and folders through an Explorer window.
• Its one of the only ways in SharePoint to copy multiple folders at a time into a SharePoint library.

However, we have found that the Windows Explorer view does have several inherent security holes and these holes do pose significant risk to customers in the military or DOD environments. For example, if SharePoint permissions only give a user read access to a file, often users are still able to rename the file through the Windows Explorer view. In some cases users with read access to certain files are even able to delete those files.  There are other similar holes.

As well, Microsoft has stated that when using claims based authentication with SAML security tokens that the Windows Explorer view in SharePoint 2010 does not work:  http://technet.microsoft.com/en-us/library/hh706161.aspx.  It goes on to say that this feature (and others) do not work because claims based authentication does not generate a Windows Security Token which is required for this feature.  From my experience in this situation the explorer view partially works in that it can be accessed but it does not respect ACLs correctly.

As a result, we often recommend to customers that they "turn off" the Windows Explorer view in SharePoint and force users to use the web view. With SharePoint 2013, this option is even more viable because the web view now allows users to drag and drop files from their Windows desktop into the web browser and have those files copied into the SharePoint library. An awesome feature if I may say so!

"Turning off" the Windows Explorer view is a bit of a misnomer though. There is no way, that I can find to completely turn off the Explorer View to SharePoint from the SharePoint server. However there are several methods for preventing end users from accessing these Windows Explorer view. This blog post will describe each of these methods in detail.

Method #1

Administrators can disable access to the Windows Explorer view by modifying the “User Permissions” on the web application. This is done within Central Administration:

• Click Manage Web Applications and select your web application
• Click the User Permission button in the ribbon
• Find the “Use Remote Interfaces” permission in the list and uncheck it (this will also automatically uncheck the “Use Client Integration Features” permission as well)

This will disable the “Open in Explorer” button in the SharePoint ribbon for all libraries in all sites in the web application.

There is a problem with this method though - it also disables all access to open documents in SharePoint from the open dialog in MS Office applications. As well, access from SharePoint Designer and access from all client object model applications will be also be disabled. Please note that the Open Dialog, like the Windows Explorer view also does not fully respect SharePoint permissions. So, this method may or may not work for your environment.

Method #2

I have found that simply removing the “Open in Explorer” button all together from the SharePoint ribbon can be an effective way to prevent access through the Explorer view. There is a good blog post here on how to accomplish this here.

[previous link was incorrect - this is now fixed]

This method is effective because you open Windows Explorer on your desktop and paste the URL to a SharePoint library Windows will automatically open a web browser and navigate to the SharePoint web view of the library. It does not actually open in Windows Explorer. This allows the open dialog in Windows to still navigate to a file in a SharePoint library and open it, but prevents users from effectively using the Explorer view.

This method of course may not be fool proof, meaning a malicious user may still find a way around it. However it would cover 95% of cases where end users are simply trying to open documents that they are permitted to access. As well, this method still allows users to open SharePoint documents from the Open dialog in MS Office applications, SharePoint Designer and client object model applications.

Method #3

A third method that is effective and allows you to still maintain client object model access and access through the Microsoft Office open dialog is the following procedure which modifies the permissions required to access the Open in Explorer button. This procedure will result in the “Open in Explorer” button in the SharePoint web interface to still be visible and enabled, but to only be accessible by users that have the “ManageWeb” permission on the site. This would allow you to configure SharePoint to allow site owners to have access to the Windows Explorer interface, but not regular users that only have contribute permissions. Follow these steps to accomplish this:

• On the SharePoint 2010 server navigate to the folder \Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\CONTROLTEMPLATES
• Make a copy of the file DefaultTemplates.ascx
• Open DefaultTemplates.ascx in Notepad:
• Search for the following string ID=”OpenInExplorer”
• Below that string change PermissionString=”UseClientIntegration” to PermissionString=”ManageWeb”
• You will find 2 instances of ID=”OpenInExplorer” – you’ll need to make the change in both places
• Save the file and issue an IIS Reset

You’ll then find that a user that is a site owner can click on the “Open in Explorer” button and still access SharePoint through the Explorer interface, but users that are not site owners (or who do not have the Manage Web Site permission) can click on the button but they’ll get an “Access Denied” message. This works even if a user tries to create a shortcut to a URL and access the Explorer view from that shortcut, or if they try to map a network drive to the SharePoint library URL - if they don't have appropriate permissions they will receive an "access denied" message:

Method #4

A 4th and probably more extreme method is to in fact disable WebDAV itself on the IIS Web Server. To accomplish this follow these steps:

• Click the Windows "Start" button on your Web server, and select "Administrative Tools." Click "Internet Information Services Manager" to open the configuration utility.
• Click the Web server name in the left panel. A list of websites expands. Click the website name you want to edit, and click "Web Services Extensions" in the website directory.
• Right-click the WebDav entry in the list of extensions, and click "Prohibit," then click "OK" to confirm that you want to disable WebDav.

Please note: I have not tested this last method myself so your mileage may be different. Ensure that if you go this route that you fully test the SharePoint server and determine if access to files through other mechanisms (MS Office Open dialog, SharePoint Designer, client object model applications) is also affected. As well, these instructions may vary slightly depending on your version of IIS.


- Antonio

Today's Presentation at SPTechCon: Introduction to Security in Microsoft SharePoint 2013

Thank you to everyone that attended my session this morning at SPTechCon Boston 2013.  We had a pretty packed room and some really great questions.  I really appreciate everyone making the time to attend at 8:30am after the excellent party that Axceler hosted last night.

Its been an awesome show here!  This is my first time speaking at SPTechCon and I have to say that the show staff have provided great support to the attendees and the speakers.  Big thanks to Dave, Staci, Katie and their crew.

In addition to the conference site, my presentation slides can also be found here: 

Introduction to Security in Microsoft SharePoint 2013

My contact info is in the slides and on this site.  Please do reach out if you have any questions or feedback at all.

Enjoy the rest of SPTechCon and Boston.
   -Antonio

Why do Enterprises or Governments secure their information?

This post is the first in a series that will review fundamental security features in Microsoft SharePoint 2013.

When I speak about SharePoint security I often start off with a discussion about why organizations secure their information. What really drives people to implement secure measures to control and govern information?  For a business owner or C-level executive it may be obvious, but for the average employee it may not be.

To be clear, this article is not intended to deal with people’s personal information. It specifically talks to how enterprises or governments deal with and secure their sensitive internal business information. So let’s begin here...

What drives people to secure information?

We’ve all heard statistics about how the information we’re creating and storing is growing at an exponential rate. Many of us now regularly measure database sizes in Petabytes. In fact, most enterprise content is unstructured data (ex. documents) which of course poses its own challenges for management and security. In a 2013 eWEEK article, Gartner analysts predicted that enterprise data will grow by 800 percent over the next five years, and that 80 percent or more of that new data will be unstructured.

We often hear how organizations are centralizing the storage and access to information in order to promote better collaboration, but for many this raises security concerns that must be dealt with – by the way, SharePoint provides just such an excellent platform on which to accomplish this.  We also know that every organization has some meaningful amount of information that is considered sensitive. We often hear about how that sensitive information must be secured, controlled and governed. 

However, for many individuals who own or have responsibility for this information usually treat its security as an afterthought. Why is that? With all the statistics and talk about the amount of information we’re generating, how centralizing it promotes collaboration but raises security concerns and with the large amount of that information that’s considered sensitive to organization, why is its security not top of mind.

From my experience in the security industry over the last 15 years, working with many large organizations around the world and with many individuals who own content or are responsible for content, I’ll put forward a theory: people feel a true need to secure information when they have a personal connection to it, when they truly understand the risk which exposure of that information poses and when the impact of such an exposure affects them directly.

Rarely do people secure information for the good of securing information or because it’s the right thing to do. There are of course exceptions, but in general people are looking out for themselves, not the good of the organization. This isn’t a pessimistic view. I believe it’s just natural human behavior... at least it is today. Culture is slowly changing on this front so who knows how people will feel or think of securing information in the next few years.

Let me summarize the cases in which I have seen people really driven to secure their information. I have found that certain people (outside the security industry) will be driven to secure information for very specific reasons. I’ve categorized each as a set of risks and summed them up in a high-level driver.

1. Reducing Your Liability
For many industries, the exposure of sensitive corporate information can have very negative impacts to business. The risks include:

• Compliance violations that result in extremely heavy fines (depending on the industry)
• Sanctions and legally imposed restrictions on business
• Loss of business reputation (this could be bad PR and of course possibly result in loss of customers)

These are of course very significant risks to the business - they are liabilities to the business. I group these types of risks under “Reducing your liability”.

Exposure of this type of information may be malicious, but more likely it will be inadvertent or accidental. A business owner or a C-level executive will likely be very concerned about such risks and be driven to secure sensitive information in order to protect the business. Business owners, C-level executive, board members are typically very motivated to reduce these liabilities. This is typically because they are better positioned to understand the risk and the impacts can directly affect them personally (bottom line, law suits, the buck stops with them, loss of employment, etc.).

The same risks exist for government departments, when you consider government departments can have their budgets cut, such exposures can hit the media very hard or department heads can lose their jobs.

The average employee may or may not be concerned about these risks to the business or department. Depending on the employee, they very likely don’t even understand how these impacts can affect the business nor what information is sensitive to the business.

2. Protecting Your Investments
This particular category of risks typically applies to enterprises, much more so than governments. The risks include:

• Loss or theft of intellectual property (know how, designs, plans, budgets, vision documents, etc.)
• Exposure of customer lists
• Exposure of acquisition/merger information or budgetary/accounting data
• Loss of competitive advantage
• Compromising of internal (or external) business systems – which could have a trickle-down effect of loss of customers of course

Once again, a business owner or C-level executive will likely be very concerned about such risks and be driven to secure sensitive information in order to protect the business. This type of data loss or exposure of sensitive information can greatly affect the business’ performance. For these types of individuals their compensation or bonus is typically highly tied to the business’ performance. A CIO or CISO will typically be measured critically (or terminated) when these types of exposures occur.

For a typical employee, although part of their salary/bonus might be tied to company performance that percentage is typically much lower than that of executives. As well, they often will not understand which information is sensitive and how the loss of that information will affect the business. Unless you have a clear way to identify which information is sensitive and can effectively educate employees on how they should handle that information, their ability (and desire) to help protect against data loss will be limited.

3. Public Safety or Mission Success
This category typically applies to government agencies like departments of defense throughout the world, Homeland Security in the US, as well as other government departments. The risks include:

• Exposure or theft of classified mission data (which can compromise military missions and endanger personnel)
• Exposure of homeland security information (which can endanger the general public)
• Compromising of critical government services and security systems

In these cases, the personnel that deal with the data involved are typically well trained in how to handle this type of sensitive information. As well, often people go into these areas of work because they have a desire to be part of the public service, or they wish to work in a military or service that protects the public safety. As such, this particular category may be an exception to the theory I put forward earlier. 

There have been some high profile leaks of classified government information in the last few years, but in general the people that work and deal with this type of information do tend to protect it because they understand the very negative and dangerous impacts that can happen with its exposure and because typically protecting this information is the right thing to do.

4. Health Information
This represents a new risk category in recent years that I’ve been researching lately. I’ve been to a few sessions that specifically talk about the impacts that can occur when personal health information is stolen or exposed. This leans more towards the personal information side (which I said I wasn’t going to talk about) because we are talking about personal health information. However, it’s included here because it affects the companies and government agencies which store/manage that information.

For example, in the state of Florida a personal health identity can be illegally purchased for approximately $56,000. For a non-insured individual purchasing such an identity they can make use of it to illegally get health care, causing the original owner of that insurance plan to have their premiums used without their knowledge. Even more dangerous than that, the person illegally using the health identity can cause data within the health record to be modified. For example, if their blood type is type A and that gets applied to the original health record, but the original owner has type B-negative. If the original owner of the insurance plan is then in an accident and needs a transfusion, this record modification could have extremely dangerous consequences.

In this case, government agencies and health care organizations that manage personal health information must insure that proper security measures are put in place in order to prevent these types of risks or exposures from happening. In these cases, typically both the administrators and the employees working in the health care industry do care about these types of risks, and are starting to get a sense for the very dangerous impacts that can occur. The health care industry has traditionally been slow to adopt technology solutions, but that has been changing in recent years.

Overall
(I realize this first post in fact has nothing to do with SharePoint, but I believe these concepts are important to understand when we generally look at implementing security measures.)

To summarize, in many businesses and organizations the average person tends to feel a true need to secure information when they have a personal connection to it, when they truly understand the risk which exposure of that information poses and when the impact of such an exposure can affect them directly.

The ideal situation in any organization would be if each and every individual does in fact care about securing and properly handling sensitive information. This is really what we should be striving for, and many of organizations are starting to tackle this head on.

We have found that the best way to achieve that is to involve all employees in the organizations security strategy. This is done through education, as well as traditional security mechanisms - education of employees so that they understand which information is sensitive and how they should handle it, and so that they are aware of the very real impacts of information exposure, both to the business and to them personally. As well, make employees accountable when they handle sensitive information, and that accountability needs to be obvious (for example, if someone prints a sensitive document their name should be stamped all over it, so that if they leave it in a hall way everyone knows who left it).

This type of education and accountability helps ensure all employees feel the real need to secure the organizations information and its one of the best lines of defense against both inadvertent and malicious exposure of sensitive information.