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 :) )

Title:

Building a Commissionable, Development Aware Virtualized SharePoint Environment

Summary:

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:

Share

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.

Share

SharePoint Intrusion Detection Policy Template

Introduction – SharePoint Intrusion Detection Policy Intrusion detection plays an important role in implementing and enforcing a SharePoint organizational security policy. As SharePoint grows in complexity, effective security measures must evolve.
Purpose SharePoint-aware intrusion detection provides two important functions in protecting the SharePoint environment:

  • Feedback: Information as to the effectiveness of the IDS and associated components. If a robust and effective IDS is in place, the lack of detected intrusions is an indication that other defenses are working.
  • Trigger: a mechanism that determines when to activate planned responses to an intrusion incident.
Audience The [Organization] SharePoint Intrusion Detection Policy applies to all individuals that are responsible for the installation of new SharePoint resources, the operations of existing SharePoint resources, and individuals charged with SharePoint resources security.
SharePoint Intrusion Detection Policy
  • Operating system, user accounting, and application software audit logging processes should be enabled on all host and server systems for internal customers.
  • Alarm and IDS alert functions of backbone firewalls and other network perimeter access control systems must be enabled, and monitored by the SharePoint administrator.
  • Audit logging of any firewalls and other network perimeter access control that may lead or display business data from the SharePoint environment must be enabled.
  • Audit logs from the perimeter access control systems must be monitored/reviewed daily by the SharePoint administrator.
  • System integrity checks of the firewalls and other network perimeter access control systems must be performed on a routine basis.
    Audit logs for servers and hosts on the internal, protected, network must be reviewed on a weekly basis. The SharePoint administrator will furnish any audit logs as requested by [Organization] management.
  • Host based intrusion tools will be checked on a routine.
  • All trouble reports should be reviewed for symptoms that might indicate intrusive activity.
  • All suspected and/or confirmed instances of successful and/or attempted intrusions into the SharePoint environment must be immediately reported according to the Incident Management Policy.
  • Users shall be trained to report any anomalies in system performance and signs of wrongdoing to the [Organization] Help Desk.
SharePoint Intrusion Detection Policy Supporting Information
  • Any and all [Organization] SharePoint security controls must not be bypassed or disabled.
  • All [Organization] SharePoint users are responsible for managing their use of SharePoint and are accountable for their actions relating to SharePoint security. Users are also equally responsible for reporting any suspected or confirmed violations of this policy to the appropriate management responsible for SharePoint security incident handling.
  • The integrity of [Organization] SharePoint software, utilities, operating systems, networks, and respective data files are the responsibility of the server custodian department. Data for test and research purposes must be de-personalized prior to release to testers unless each individual involved in the testing has authorized access to the SharePoint data.
  • [Organization] server custodian departments must provide adequate access controls in order to monitor SharePoint systems to protect business data and associated programs from misuse in accordance with the needs defined by owner departments. All SharePoint access must be properly documented, authorized and controlled, following [Organization] standardized processes.
  • All [Organization] departments must carefully assess the risk of unauthorized alteration, unauthorized disclosure, or loss of the data within the [Organization] SharePoint environment for which they are responsible and ensure, through the use of monitoring mechanisms such that [Organization] is protected from damage, monetary or otherwise. SharePoint owners and server custodian departments must have appropriate backup and contingency plans for disaster recovery based on risk assessment and business requirements.
Disciplinary Actions Violation of this policy may result in disciplinary action which may include termination for employees and temporaries; a termination of employment relations in the case of contractors or consultants; dismissal for interns and volunteers; or suspension or expulsion in the case of a student. Additionally, individuals are subject to loss of [Organization] SharePoint access privileges, civil, and criminal prosecution.
Compliance / Regulation Contributed to by this Policy
  • Copyright Act of 1976
  • Foreign Corrupt Practices Act of 1977
  • Computer Fraud and Abuse Act of 1986
  • Computer Security Act of 1987
  • The Health Insurance Portability and Accountability Act of 1996 (HIPAA)
Share