SharePoint Web Part Security

Some History

One of the first things I learned related to the topic was that when one says they are using SharePoint, from an administrator or developer’s perspective that is not enough information. SharePoint, depending on a point in time since 2001, means either SharePoint Team Services (STS) or Windows SharePoint Services (WSS), and either SharePoint Portal Server (SPS) or Microsoft Office SharePoint Server (MOSS). Of course there are many other derivatives when you account for versioning and service packs, and which release of the ASP.Net framework you are developing against. To be clear, on my current project we are using the ASP.Net 3.0 framework to develop custom web parts for WSS 3.0 and MOSS.

This document is the result of having some experience with SharePoint, random reading and some strong distillation of much more comprehensive resources on the topic (see sources below).

Web Part Intro

SharePoint web parts are ASP.Net server controls that are placed in web part zones of web part pages that reside on a SharePoint site (whew!). I’ve heard them described as widgets for ASP.NET. Consider them as a way to package functionality for SharePoint users.

Some web parts are included in WSS when you buy Microsoft Server 2003; WSS comes with Server 2003. Many more web parts are available when you buy MOSS in addition to WSS. Developers are able to create custom web parts that run on WSS and MOSS. However, custom web parts developed with the more extensive MOSS libraries will only run on MOSS.

Web Part Security

The fundamental security principle at the heart of web part security is adhering to a policy of least privilege. The SharePoint administrator needs to protect the local server resources by restricting the operations of web part code (i.e. assemblies), regardless of whether the code is operating with malicious intent or not. Developers should ensure that their web parts only have access to those resources required to perform their operations. The developers are really in the best position to make this call.

Establishing Trust

The ASP.Net Common Language Runtime (CLR) provides for code access security (CAS) with respect to web parts. CAS is also referred to as policy-based security, and employs a mechanism that restricts the operations allowed to be run by an application based on a user configurable policy that is enforced by the CLR. As a result, the reach of web parts into local resources can be controlled; managing risk. Java uses a similar mechanism.

The fundamental concept behind CAS is associating a level of trust with a web part. There are five trust levels that can be assigned within ASP.NET (full, high, medium, low, minimal) and two additional, extended levels provided through WSS (ww_medium, wss_minimal). If that web part attempts to perform an unauthorized action against local resources, the CLR will throw an exception. By default, SharePoint comes with a policy that invokes wss_minimal, allowing slightly more liberty than ASP.Net minimal, but still quite restricted.

There are a few ways to manipulate trust levels or potentially turn off CAS all together. You can raise the entire trust level within a SharePoint instance. You can deploy your web parts in the Global Assembly Cache (GAC). You can create your own policy.

Raising the trust level for a particular SharePoint instance is accomplished by editing the web.config file and deploying your web parts to the \bin directory. All web parts in /bin will have the same level of trust. This is easy to do, but you may not want to have all web parts to have the trust.

Deploying to the GAC is accomplished by placing your web parts in the \windows\assemblies. All web parts deployed to the GAC have a trust level of full and are available to all instances of SharePoint within the WSS implementation. Installing to the GAC should be done with consideration given the principal of least privilege. Web parts in the GAC will more than likely be running at a higher level of trust than required, as well as being accessible more widely than necessary.

Creating your own policy allows you to define the trust level on a web part by web part basis. The level of trust would only be limited by the permissions of the user running the web part. This method provides the highest level of granularity, but requires the most effort on your part (no pain, no gain!). To modify trust in this manner, the recommended approach is to include a CodeAccessSecurity section in the manifest.xml file included in the deployment package (.wsp) of your web part.

Sources

A Developer’s Introduction to Web Parts, Andy Baron, MCW Technologies, LLC

http://msdn2.microsoft.com/en-us/library/ms916848.aspx#sharepoint_northwindwebparts_topic20

Microsoft Windows SharePoint Services and Code Access Security, Maurice J. Prather, Suraj Poozhiyil, Andrew M. Miller, Microsoft Corporation

http://msdn2.microsoft.com/en-us/library/ms916855.aspx

Phone Systems - Interesting??? - Part Deux

Yes, well, telephone solutions for small to medium sized businesses continue to be interesting. If you recall from the previous post on this subject, I had been leaning towards the use of VoIP for our new business phone system. I was under the impression that since residential services based on VoIP seem to be killing plain old telephone service (POTS), that the same should hold true for businesses. The fact that we would not require dedicated POTS lines and private branch exchange (PBX) gear must make VoIP the cost winner, right? Not quite.

Continuing with the idea the VoIP was way to go, I attempted to determine whether or not using Skype rather than a hosted VoIP service was viable. The savings offered by a Skype solution were attractive. However, Skype relies on third party solutions to pull together the crucial auto-attendant, and directory services. The results of using these third-party applications were disappointing. I tried both Call Butler, and Pretty May, and both were not functional or reliable enough to be used in a business environment. I believe that Skype-based solutions or equivalents are very promising, and will be widely accepted at some point in the next year or so. If a Skype-based solution is not feasible at this point, then perhaps the $1000 per month (plus hardware costs) for a T1 and hosted VoIP with calling plan offered by Verizon should win out. However, this seemed pricey.

I subsequently reviewed a proposal I had received from an Avaya distributer prior to going down VoIP road. The price quoted didn't seem right; too cheap. It was around $500 a month for a T1 and a PBX with all the functionality offered by a hosted VoIP solution (except for the potential to have snappy ring tones). I continued to work with this person and to get the best solution for us at a price comparable to the cost quoted by Verizon. The result is two T1s bonded together using special hardware resulting in a 3 Mbps symmetrical Internet connection , 6 POTS lines feeding an Avaya PBX, 10 phone instruments, a polycom speaker phone, and spare ports to support additional phone instruments. The price appears to be between $1000 and $1100 per month. Same functionality. Twice the speed and capacity to the Internet.

Verizon's prices for business-class hosted VoIP were inline with the hosted prices quoted from another provider, so it seems like, at this price point, our company is better off with a more traditional business phone solution at this point in time.

Since we have another month or so before we need to make a commitment to Internet and phone services, I will continue to investigate alternatives, and monitor the progress of solutions based on Skype and equivalents. Stay tuned....

Phone Service - Interesting???

Our company is in the process of acquiring some new office space. This space will be turn-key, meaning the building owner will demolish and then build-out the space to meet our needs. However, among other things, we are still on the hook to address our voice and data communications needs. It is my goal to establish the best voice and data communications solution for our company with respect to the upcoming move.

My first thoughts during this pursuit related to the convergence of voice and data communications facilitated through Voice over Internet Protocol (VoIP). Whatever Internet access we acquire, it has to accommodate both voice and data connectivity. The features and prices of VoIP-based services available to businesses blows away the dedicated, expensive, feature poor, solutions available the last time I dealt with business phone systems (quite a while ago). There are surely other economies and benefits realized in going this route too, so I just accepted this and ran with it.

My first actions were to contact VoIP providers or resellers, and learn more about business VoIP services by asking questions and comparing the features and options being offered. Several things became clear to me right away. Not the least of which is that VoIP has got to be killing Plain Old Telephone Service (POTS). It was also apparent that all of the actual VoIP service features (unified messaging, follow-me, multi-ring, etc., etc., etc.) would be quite similar regardless of who we went with. I needed another way to categorize the various vendors of VoIP, and I decided to capture the pros and cons related to the ways in which VoIP services would be provided. General to all of delivery methods is the use of a T-1 (1.54 Mbps, symmetrical) for connectivity to the Internet and/or VoIP provider, as well as the costs of the calling plan. The four categories I came up with are hosted, managed, do it yourself (DIY), Internet-based.

VoIP Delivery Method	Pro	Con
Hosted	No equipment to maintain Ease of administration Service level agreements (SLA) One stop shopping Ease of scalability Features of high-end equipment Offsite PBX Low upfront cost Flexible (not much to own)	Limited choice of customer premise equipment (CPE) Highest Monthly fees
Managed	More CPE choice Monthly (lease) fee maybe less than hosted	On-site PBX (failure and access issues) Limited SLA Scalability costs Multiple management points Less flexible (tied to a vendor)
DIY	Least monthly fees Potentially more configurable Most CPE choices	All maintenance and scalability costs On-site PBX No SLA Most upfront costs No one-stop shopping Multiple management points Least flexibility once system is in
Internet-based (e.g. Skype, Packet8, Vonage-like)	Least expensive Most portable Very little, to no CPE	No SLA Potentially much less reliable Potential call quality issues Multiple management points

In an attempt to cut to the chase, I don’t believe our company wants to deal with running our own switch (DIY) and the difference in price between managed and hosted is not so great that we should take on the additional burden to pocket the savings. In fact having an hourly employee or the vendor spend a half-day per month on the phone system would wipe out that savings ($100 - $150/hr).

The interesting thing to me is the difference in monthly savings when comparing an Internet-based solution to the hosted solution. Particularly if your company does not rely on the business phone system as their primary means of contact or a revenue generator. For instance, the use of Skype numbers coupled with a product like CallButler (http://www.callbutler.com/Default.aspx) to provide “store font” features could provide saving of several hundreds of dollars per month when compared to hosted services. Skype also provides a free “Business Control Panel” to centrally manage Skype accounts within the company. The recent introduction of WiFi Skype phones overcomes one of my initial concerns as well; being tethered to the computer for phone calls.

I will attempt to calculate the savings of using Skype versus a price we’ve been quoted for hosted business phone services:

• SkypeOut - $30 per year * 35 accounts = $1050 – All calls within the U.S. and Canada with calls outside the U.S. and Canada typically $.02 per minute
• SkypeIn (with voicemail) - $38 per year * 35 accounts = $1330
• Skype Business Control Panel - Free – Centrally manage Skype accounts within the company
• CallButler Unlimited for Skype - Currently in Beta, but expect to cost around $300 (one-time fee)

Estimated yearly cost to the company for telephony using a Skype-based solution would be around $2500. The estimated cost of using a hosted business phone service would be about $6000. The $3500 would go a long way towards the bar tab at the Christmas party, or perhaps we should spend on additional bandwidth.

I will write again once I’ve done a bit more research on the Skype-based solution. I’ve downloaded CallButler Unlimited for Skype (CBU4S) BETA.

TrueCrypt Use within an Organization

Summary
TrueCrypt is a highly regarded, free, file system encryption solution that can be used on Microsoft Windows, or Linux operating systems. The documentation that comes with it is excellent , so please refer to it in order to become familiar with the terminology and basics use (e.g. creating file-based “containers”) of TrueCrypt.

I’m going to document how an administrator might deploy TrueCrypt within their organization to protect information residing on the hard drives of employees’ laptop and/or desktop computers. The primary feature covered here is the ability of an administrator to maintain (escrow) a master key that could be used if recovery of the encrypted information becomes necessary and the employee/information holder is not available. I believe that these procedures would be one way of supporting the information protection policy of a corporation.

Basic Idea
Prior to issuing a computer, laptop or otherwise, to an employee the administrator should use TrueCrypt to create a container on that device where the employee is expected to place information considered sensitive to the company and/or the company’s clients. This protects the confidentiality of this particular information if the hard drive were to fall into unauthorized hands when the computer is powered off or the container is not mounted. TrueCrypt is an excellent choice for this, but what happens if the employee gets hit by a bus, or forgets their TrueCrypt password?

The password and/or key file used during the creation of this container mentioned above will be the master key that should be held in escrow (with the volume header; mentioned later). Make sure that you are able to mount, and subsequently unmount the container using the master key before continuing.

With the container unmounted, and TrueCrypt still running, select the file used as the encrypted container. With this file selected you should click on Volume Tools. You will now want to Backup Volume Header. The volume header is what makes restoring this container using the master key possible. Therefore you will want protect this along with the master key (password and/or key file). I’ll suggest writing the volume header to some form of removable media.


Now that the volume header has been secured, within Volume Tools you can select Change Volume Password. Change the volume password to the password that you will give to the new user of the computer (container). Instruct the user to change the volume password to a password of their choosing. They should also backup the volume header after changing their volume password.

If the time comes when the administrator needs to recover the information encrypted in the container, they will need to start TrueCrypt, select the file used as the container, and select Restore Volume Header under Volume Tools. Once the original volume header is restored the master key will unlock the encrypted container.

Additional Thoughts
Getting the user to place the organizations sensitive information in the container, or alternatively a device (encrypted disk partition) may be easier said than done. It should be made clear to the computer user that they are responsible for safeguarding of the information residing on that computer, and using the file system encryption offered through TrueCrypt is a tool to help do this.

You will want to make the encrypted volume quite large; accommodating file system growth. You cannot resize the volume after it has been created.

The use of device-based versus file-based encrypted volumes supposedly offers better performance.

Once a volume is mounted, anyone logged on to that computer can see the contents of the volume.

OpenID - Maybe not so crazy

Quite a while ago I read a paragraph about OpenID. My initial reaction was something like "no way". However, I was recently encouraged by a colleague to have another look.

I must say that my initial reaction ("no way") was shaped primarily from reading "What is OpenID?" on the official OpenID website, coupled with a significant amount of personal experience/interest learning about information security systems. So, when I see the terms "Single Sign On (SSO)" and "authentication" and "identity" used in describing OpenID, I immediately thought that this solution was being considered as a means of establishing a high degree of trust. Continuing with this perception, the fact that OpenID is based on a completely decentralized authentication architecture, just didn't add up.

While looking at OpenID this time, I actually went through and tried to establish the worthiness of OpenID as it is being used today. Which is not, from what I've gathered , a mechanism to establish trust. The idea of using the criteria discussed in Bruce Schneier's book "Beyond Fear" came to mind, but I didn't feel that the five questions he uses when evaluating a security solution where completely appropriate when applied to OpenID as it is being implemented today:

What are you protecting?
What are the risks associated with what you are protecting?
How well does the solution address the risks?
What risks are introduced by the solution?
What costs/trade-offs are associated with the solution?

To establish the worthiness of OpenID in my mind, I answered the following questions:

What problem does OpenID solve?
Establishing an identity on multiple Internet-based services and all the associated issues (control of personal information, inconvenience of providing credentials, potential loss of password discipline)

How well does this solution address the problem?
OpenID does address the issues associated with having identity-related information stored on multiple services.

What risks are introduced by OpenID?
The risk of phishing attacks increases with this model, but as when using MyOpenID as your credential provider you can set a personal icon, as well as a feature called SafeSignIn to reduce the risk of phishing to an acceptable level (for me). Another risk is trusting this decentralized credential provider with any information that you provide. For instance, MyOpenID "promises" to honor your privacy.

What are the costs associated with OpenID?
From the perspective of the OpenID end user, there is no money involved. The software to be an OpenID server or relying party is free of charge as well. However, although the software is free to the developer, from what I understand implementing or integrating an OpenID server or service is not trivial.

You'll notice that I've rephrased the criteria to establish the worthiness of OpenID as a general system rather than a security-focused system. This, as I mentioned before, is because I am evaluating how OpenID is being used today. OpenID does not seem to be used to protect assets of significant value and therefore trust is not a big concern. However, having said that, I do believe that this framework could be applied today within an organization to establish a lesser degree of trust than made available through more centralized and costly approaches (e.g. PKI, Federated Identity, domain-based schemes). Along these lines, this framework could potentially be used as another type of centralized scheme. These scenarios would go against the "open" in OpenID; if that meets your needs, fine.

As OpenID matures the framework is expected to support the establishment of varying degrees of trust based on the sorts of credential providers that become available. It will be interesting to see the level of trust people will accept in an online environment using a completely decentralized security mechanism, as well as the exploits. It will also be interesting to see which service providers are willing to give up collecting phone numbers, street addresses, and so on, of consumers.

OpenID solves a common problem with little cost or risk involved. As a service provider, if you would benefit from providing an SSO environment to your consumers, and the value of your online assets is inline with the level of trust (low) established with OpenID, then I would suggest that using OpenID is not such a crazy idea.

What I like about Shmoo

Shmoocon is the East Coast's DEFCON. It is a conference where haxors and various other security players present their clever findings to a melting pot of enthusiasts hungry for wizardry. A couple of colleagues and I just returned from Shmoocon 2007 which took place this past weekend at the Wardman Park Marriot in Washington D.C., and felt that is was time and money ($150) well spent. It is my understanding that the lone objective of Shmoocon is to build the security community, and that any money left over after paying the bills goes to the Electronic Frontier Foundation (EFF) and perhaps other charities.

This was the 3rd annual Shmoocon, but the first one for me. I actually heard of this conference for the first time last year while at DEFCON. Word of mouth seems to be a good enough way to market this con. I understand that the first con had about 300 people, but the last one, and the one this year sold out. I would estimate the attendance to have been around 1000 to 1200 people. To land the tickets, I stayed up late and purchased them online (while celebrating the New Year) as soon as a block of tickets were released on January 1st; I missed out on a previously released block.

Enough background. If you're still reading this, you're probably wondering "what does he like about Shmoocon"? I'll break it down in the terms Shmoocon uses to describe itself; different, affordable and entertaining. This conference is not that different from DEFCON in concept, but far from what I think you would call normal if all you've been exposed to is FOSE or RSA, or some other multi megaCorp sponsored event; no suits; I liked that. This con keeps it real.

It is different in content as well. The three tracks (Build it!, Break it!, Bring it on!) covered topics ranging from physical security to security ethics; from hacking the airwaves to hacking disposable cameras; from entropy-based analysis of encrypted protocols to discussion like "Standard Bodies - What are these Guys Drinking?". To help solidify the essence of this conference, I'll share a stream of tools, comments and thoughts that registered with me in no particular order will in attendance:

network access controls fostering false sense of security - PCB Express - embedded web servers the size of an RJ45 coupler soon to be wireless - hard drive dissection - MHDD and Victoria - increased use of VMware in the community - lots of security related design flaws among Windows Mobile applications - SIPinator is cool - OpenWRT - SRTP - fwsnortbleeding snort - IPtables - PSAD - Netcat - Honeynet scan challenge - defense-in-depth - content filters less effective as more traffic is encrypted - statistical analysis of encrypted traffic - PISA - these shmoocon bags do make great six-pack coolers!

As you may have gathered, you can walk away with a sense of knowing a bit better where things stand in the security community, untethered from share-holder equity.

As far as affordable, we paid $150 to get in. Some pay less, some pay more; it has to do with how they make the tickets available. The bottom-line is that it is a huge bargain. Especially, if you happen to live in the D.C. metro area. We didn't stay at the Wardman Park Marriot, but it is a great place to operate out of on the first weekend of Spring.

Entertaining? Yes it was; a combination of hanging out at Times Square (closer to 42nd Street) and Oktoberfest (did I mention that the Shmoocon bags could hold a six-pack?). I loved that everyone seemed to have such varying personalities and background (Punk to CSO), but all were there with the common goals of soaking up some leet wisdom and insight, and having a good time.

Thanks Shmoocon. Well done!