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.