Presenting the Keynote And Breakout At TechFuse 2009

I will be presenting the keynote and a breakout session at Techfuse (NOT TechEd) on Tuesday, March 17, 2009 in Brooklyn Park, MN.

My keynote sessions synopsis is (taking into account I despise esoteric keynotes that are full of marketing, I choose a more pragmatic path :) )


Building a Commissionable, Development Aware Virtualized SharePoint Environment


Constructing a commissionable collaboration environment that lessens friction for at-will server provisioning is commonly one of the most time-consuming tasks when designing a SharePoint environment targeting flexibility however controlling proliferation. There are certain components required from both a development and architectural perspective; operating systems, applications, service packs, and updates being a few examples. Reproducing these environments on a repetitive piece-meal basis can be attributed to one of the most inefficient processes in an organization, frustrating for both the operations and development departments.

There are several compelling reasons for an organization to virtualize a SharePoint environment. From a cost perspective the immediate benefit of a reduced hardware footprint coupled with lessened physical space requirements, arguably these are the most visible. Furthermore, management and maintenance of the virtualized SharePoint environment is eased, allowing service levels to increase since servers can be provisioned for everything from implementing redundancy to providing siloed testing environments for component testing.

Microsoft System Center Virtual Machine Manager (VMM) 2008 out of the System Center Server Management Suite provides a powerful virtualization scheme (utilizing hypervisor-based virtualization) allowing a commission and decommissioning architecture that, when coupled with SharePoint, provides redundant operations architecture and adaptable development environments to properly support an SDLC. As opposed to scaling tasks that normally takes weeks, VMM allows SharePoint architects to provide a robust solution set to tackle time consuming tasks in a fraction of the time.

The first portion of this session will demonstrate building virtualized SharePoint environment following down to the metal best practices. The preliminary design will be in accordance with simple small farm architecture. Scenario based implementations will follow to demonstrate the introduction of new servers into the environment, along with the benchmarks advised in order to govern the provisioning procedures. From an operations standpoint, this should equip the audience with enough information in order to start to build self-sustaining performance metrics and the associate required actions in order to maintain desirable operational service levels.

The second portion of this session will describe best practices approaches to provide organizational developers with an appropriate development environment that follows a prescribed lifecycle. While the operational component will heavily focus on roles, utilizations, and responses, the development end will focus on maintain a structured SharePoint development process. The preliminary design will demonstrate single instance virtualized development sandboxes, with integrated a conflict reduction architecture pushing to a centralized build machine (for build and testing before sending to QA) leveraging Team Foundation Server.  Using build events, a structured process will also be demonstrated in order to examine how to automate orthodox build pushes, tackling a majority of deployment scenarios. This should equip both the operations and development audience measures with an agreeable approach that eases both parties rhythmic daily tasks.

For my breakout session I will be presenting on SharePoint security froom both an architectural as well as development perspective.

You can find out more about TechFuse here, and it will be hosted at The Northland Inn in Brooklyn Park:


Is SharePoint Going To Die?

I get asked this question a lot, I generally suspect it is because at first glance with SharePoint it takes a fair amount of resources to run a well-architected, organized, and maintained portal for an arbitrary organization, which I think is partially accurate. However, I don’t consider that is a fault of SharePoint as a product, rather I just believe that it is collaborative software as a whole breed being introduced to virgin organizations. As the breed continues to grow and evolve, becoming more of an arm of the enterprise body, I think that is bound to become even more complex and involved, demanding more resources form the organization. Quite honestly, I would not be surprised if larger companies started to dedicate more committed personnel into their communication and collaboration initiatives by the creation of entirely new positions that are responsible for those types of tasks.

Anyways, back to the question. To be honest, it usually just isn’t that one, it is usually a twofold one.

The first question is:

1) If and when do you think SharePoint is going to die?

Shortly followed by the second:

2) What are we going to do if SharePoint dies?

My first answer is I don’t think SharePoint is going anywhere for quite some time. The reasons for this are kind of disjointed, long, and numerous, so I will keep it to what I consider being one of an important three.

I think at the current moment a lot of people are buying into SharePoint as a secondary piece of software; however it is slowly engraining itself into corporations as becoming more of an operating system or some other type of central nexus for Office clients. So whereas you say Some Portal Thing, some might say the Beginning The Web Enablement of Office. You say it’s just a floating piece of software, I say it is a platform bringing important business concepts, and important business initiatives, (i.e. we can just say simply collaboration as an example of this), to a company. I don’t consider it to simply by a tool, I believe it brings more to the table then that. It breeds ideas and concepts, it doesn’t just simply provide some piece of functionality.

Familiarity I also think is a big portion. I think that following its proper deployment, it sort of builds dependencies from users, once people really start to become intertwined in it, taking that functionality away would be nothing but detrimental to a company. While I think this is mainly because of the familiarity talked about in the above, I believe that in a lot of the ways SharePoint tends to force business process creation within a company where they might not have existed previously. Familiarity too also spawns from the administration standpoint. I mean, you get WSS with Server 2003, and you already know Server 2003, so why not expand that knowledge to engrained products?

While these are kind of an abstract reasons, we can also look at it empirically as simply a sunk investment in Office, organizations already have a high familiarity and usage rate of Office versus other client office suites, and therefore it only make sense to harness that experience against more radical technologies that improve the overall information worker experience. I mean, nuff said right?

Lastly, I think that it is becoming much easier to develop (arg) in comparisons to past versions (2003 was torrential even though that was partly the fault of Visual Studio at the time). While the portability of WebParts against the new framework is consistent so movement between CMS framework assuming it is .NET would be minimal, I think that SharePoint handling a lot of the things I normally hate as a developer such as site design, etc. is kind of nice (even though I don’t think this makes up for the lack of a visual design surface in some type of IDE). Because there is some cost associated with developing against SharePoint (since you might be using SPList’s for data storage etc.) and familiarity has been grown while the application is housed in the company portal, this also makes SharePoint a rather permanent addition to a companies IT organization.

There are a bunch of other reasons, I am sure; however these were the big three that I could think of off the top of my head. I think the big thing to consider is either software dies, or it improves. The best mentality to take away from this is a platform, not typically secondary application software, tends to have a high chance of survival, meaning it tends to continue to innovate. We have seen this leaps and bounds between the versions of SharePoint.

As a side note, in my opinion it often makes sense for a lot of organizations to buy into the stack of a company as well, sometimes it is just easier and makes better business sense from an upgrade, maintenance, and support standpoint (I am not saying it is for all organizations since some seem to do fine with a combination of OpenOffice and LifeRay or JBoss Portal).

Anyways, I might expand on this post later, I am tired of writing this now though.


SharePoint Security Software And Research view

What is the audience of the MOSS and WSS v3 SharePoint Security Software?

  • An executive who desires a quick overview of the findings and recommendations of security assessment and audits, as well as proper implementation of SharePoint security
  • A manager tasked with interpreting the findings of the collobration platforms assessment and deciding what action to take based on the recommendations, along with pre-emptive security consideration for a Microsoft Office SharePoint Server and Windows SharePoint Services
  • A technical staff member tasked with understanding the issues presented in a security assessment and implementing specific security recommendations based on presented best practices. This technician (typically the SharePoint administrator), will often time take the SharePoint Security Best Practices and mold them to their specific industry and organizational structure.

What is the purpose of SharePoint Security research, and How Does the Best Practices Guide and SharePoint Security Toolkit help in securing a SharePoint environment?
The purpose of MOSS and WSS v3 security research and software development (such as various pieces of SharePoint Security Software) is to identify any root cause of inappropriate behavior observed in the collobration software and identify whether it represents a possible security vulnerability to the SharePoint platform. Various pieces of SharePoint security software provides mechanisms to deal with arbitrary security concerns and architectural considerations, providing SharePoint administrators and developers the faculities to discover, research, and rememdy various security and custodial issues. If a software vulnerability is confirmed, the following action is to test and document this vulnerability and assist Microsoft in securing the software, thus protecting the customer base from abuse, as well as integrating the concern into the SharePoint Security Best Practices Guide. When a major issue is easily translated into a software requirement (such as issues that don’t generally imply a methology or something that is a complete human-oriented process) the is built into the SharePoint Security Toolkit WinForms Application as a “Security Module”. An example of a security module would be a page validator that consumes a arbitrary SharePoint WebForm, a packet sniffer, or a SharePoint centric log parser. It is atypical for a module in the toolkit to be programmed as a web based module since the access to the toolkit is restricted to the server, since most of the application hooks will rely on being on the machine.
What is the overall purpose of the SharePoint Security Best Practices Guide?
With an ever increasing amount of information in organizations being transmitted and collobrated on within a Microsoft Office Server System environment, it is important that security be considered in every phase of network and application design, as well as in maintenance. Although it is common that much organizational emphasis be placed on such things as physical networking and remote access methods, it is imperative that the core application security infrastructure of SharePoint not be overlooked. The SharePoint Security Best Practices Guide provides the human recommended human oriented tasks (i.e. such as proper configuration of forms based authentication), where as the SharePoint Security Toolkit provides application based mechanisms that allow a person to automate and investigate security based SharePoint issues.

A More Granular Explanation of the SharePoint Security Best Practices Guide

SharePoint quickly becomes the lifeblood of organizations once the user adoption process is realized and absorbed and virtual teams are finally built and solidified. Great care and focus must be taken to properly secure it to ensure that business data is safeguarded and that each aspect of the SharePoint infrastructure is accounted for and maintained.

This security best practices guide takes a look at every aspect that might afflict an organizations security beginning with the first line,the perimeter. Although many think that as long as the perimeter is secure the job is done, perimeter security is only a small piece of overall security.

Security and complexity are often inversely proportional. Every step taken whether it’s vulnerability and risk assessment, security policy and procedure development, deployment of mechanisms or user education should be as straightforward and simple as possible. The more cryptic the instructions and procedures, the more room for misunderstanding and misapplication.

The SharePoint Security Best Practices Guide takes this into consideration by providing easy to use guidelines for every level of SharePoint administrator. SharePoint security best practices provide a recommended method to handle a task, rather than presenting all of the options available. The recommendation might depend on your configuration environment, so the guide and presented tools need to be molded to a particular organization and are presented as independent to industry.

To explain this concept a little further, best practice recommendations can serve as guidelines for organizations, to assist them in providing timely and helpful information while involved with the SharePoint environment. Unlike many best practices, however, these recommendations do not contain all the practices that should be observed, but attempt to build a framework for any organization, in any industry, to build upon and make their own. Information-handling practices and SharePoint technology are changing rapidly, and organizations should continuously review and update their own situation to ensure compliance with the laws and principles of security and collaborative environment protection. It is recognized that specific or unique considerations, including compliance with other laws, may make some of these practices inappropriate for some organizations, and all legal regulations should be observed and taken into the arbitrary scenario. Implementing an effective SharePoint security program is essential for an organization to fulfill its responsibilities towards the individuals who entrust it with their personal and business information.

Why We Are Rethinking SharePoint Security
Perhaps the most compelling reason to rethink the security of SharePoint is to get a collaboration and communications platform with greatly improved security and robustness. Although there are some approaches in dealing with SharePoint security, building an overall security architecture can be extremely important. Typical collaboration security is more resembling of a growing mass of band-aids than a plan.
Our research takes a broad definition of security and robustness. The traditional focus of the security research community has been on protection from unwanted disclosure and corruption of data. We propose to extend this to availability and resilience to attack and failure. Any SharePoint platform should attain the highest possible level of availability, so that it can be used for critical activities, and it can serve in times of crisis.

Some of the actual security problems that plague information workers today are also not in SharePoint environment itself, but in the IW’s computers that attach to the SharePoint server. Therefore it is necessary to address security and deal with issues in the end-nodes as well as the network. Although a serious challenge, an opportunity to reach beyond the traditional network research and engage operating systems and distributed systems design.

The most vexing security problems are not just failures of technology, but result from the interaction between human behavior and technology. For example, demanding better identification of all SharePoint users, it might make tracking attacks and abuse easier, but loss of anonymity and constant surveillance might have a very poor effect on many of the ways that SharePoint is used.

There are specific design challenges in building a secure and robust SharePoint environment:

  • Any set of “well-behaved” hosts should be able to communicate among themselves as they desire, with high reliability and predictability, and malicious or corrupted nodes should not be able to disrupt this communication. Users should expect a level of availability that matches or exceeds the telephone system of today.
  • Security and robustness should be extended across layers. Because security and reliability to an end user depends on the robustness of both the network layer and the distributed applications.
  • There should be a reasoned balance between identity for accountability and deterrence and privacy and freedom from unjustified observation and tracking.

What is the attacker perspective used during security research?
During some of the development of the SharePoint Security Management Studio, various methods of vulnerability research is done starting at the web application level. Any of this exploitive testing of SharePoint software is done blind (black box), i.e. as an unauthenticated, unauthorized user attempting to subvert the platform, and in this case, gaining unauthorized access to the server or working through methods of privilege escalation.

Confirmation of exploitation and further research into the exact methods to exploit the platform is performed as a fully authenticated, administratively authorized user. This access is, however, in no way needed in order to execute various security methods (such as those that would allow unauthorized code to execute on a server, XSS, etc.).

What is the difference between white box and black box security testing?
In the above, there was a mention of black box testing. Within the security community, there are two approaches to penetration and vulnerability testing: “black box” and “white box“. Black box implies that when doing the penetration testing there is no previous knowledge of the environment to be tested other than the name of the company. White box implies significant background knowledge of the environment including the type of network, SharePoint version , application server platform , database platform, load balancers, firewalls, and other MS server systems that are involved.

What is the standard process that is used during SharePoint and WSS Security research?

1) Plan The Security Research and Scope
We mostly use black box approaches, however firstly it is best to determine if it’s a black box or white box approach, realizing that the black box approach is just a matter of minutes away from the white box approach. This helps to validate the security methodologies that we are recommending for perimeter based SharePoint deployments whereby an external user my attempt to gain access. Following, we typically decide what the success criteria are. Plot out whether known exploits will be performed and to what extent. The plan typically includes working with an internal member to monitor the work either via an IDS or manual monitoring so as not to adversely affect operations.

2) Gather Information About The Target, and Weave Information Into Aggregate Plan
The gathering information is often times called reconnaissance against the target. After obtaining IP address information, the next step typically involves scanning the range for listening ports and services, OS fingerprinting, grabbing banner information that might include contact information, running an SNMP sweep looking for public community strings, and gathering any other information that might come in handy when validating recommendations being placed into the SharePoint Security Best Practices Guide, and when building functionality into the SharePoint Security Toolkit.

3) Verify Approaches, Vulnerabilities, and Information
This is typically called analysis and can be accomplished in a number of ways, but all have to do with scanning the target IP range and comparing that information found to a vulnerability database for matches.

4) Perform Security Intrusion and Verify Approaches
The exploit(s) are framed around the vulnerabilities found. This is a pretty straightforward step, however determines whether the security portion should be crafted in to the SharePoint Security Toolkit, or whether it requires documentation into the SharePoint Security Best Practices Guide.

5) Cleanup the SharePoint Server
This is about cleaning up log files and making sure whatever settings or parameters were changed during the test are set back to their original condition. This requires excellent documentation during the test and work with the system and network administrators afterwards to make sure that the situation is satisfactory upon completion and is vital to determining whether the found portion should be integrated into any of the tools found on this site.

6) Report Out, Integrate Findings
The final report must map the findings (vulnerabilities found, exploits performed) to the risk the company might realize if the threats were realized. We also provide a remediation roadmap based on “best practices” and be available to discuss the various technology options and costs. At this point the various findings are integrated into one of the assets on this site, and the information is published.

The 90/10 Rule of Vulnerabilities and SharePoint Security Testing
The old 90 / 10 rule also applies to occurrence of critical vulnerabilities, meaning 90 percent of vulnerability exposure is caused by 10 percent of critical vulnerabilities. This means that ten percent of critical vulnerabilities cause nearly all exposure. This means that targeting initial remediation efforts on critical vulnerabilities with the highest degree of exposure are the most important focus to have when working with SharePoint vulnerabilities.