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

The OSI Model and SharePoint

The OSI Model and SharePoint

The OSI model is the standard when it comes to routing, switching, and broad-spectrum application services, along with supporting conventional networked services. It spans the entire network computing infrastructure to provide a standard by which network and application engineers, as well as SharePoint architects can communicate pertinent information back and forth between each other leveraging a common standard. Although selected layers may prove to abstract for a SharePoint architect to be particularly concerned about, they nonetheless provide a positive insight into the network and application architecture that fabricate the backbone of how SharePoint operates and functions at a multiplicity of levels.

Layer 1 The Physical Layer

The first layer of the OSI model is the physical layer. Relative to SharePoint, the physical layer deals with the actual data rates and physical connectors while erect the inclusive collaboration environment. At the physical layer, there is the defining of how the actual bits that SharePoint creates (at a very high level, translated to a very low level) is converted into voltage and transmitted across a physical medium. This is a very granular level that SharePoint architects rarely see, since it will determine the transmission medium including whether it is a thinnet, thicknet, or Unshielded Twisted Pair (UTP) that SharePoint will employ. The overall concept, at a high level, is how SharePoint will function at the physical link in a networked environment.

There are several network devices that define the physical layer, such as:

  • Hubs
  • Repeaters
  • Multiplexers
  • Network Interface Cards

Along with these physical devices, there are several protocols that operate at this level, such as:

  • ATM
  • BRI
  • X.23
  • PRI
  • E1
  • E3
  • 10BaseT
  • 100BaseT
  • 10Base2
  • 10Base5
  • OC-3
  • OC-12
  • DS1
  • DS3

Layer 2 The DataLink Layer

The DataLink layer contracts predominantly with topology and frame handling. In this, there are certain other things defined such as the physical network addressing, line discipline, notification of network errors, delivery of frames in ordered pairs, and network data flow control. SharePoint architects will have relatively no interaction with the DataLink layer, since it is either handled by network engineers or through automation provided by network devices.

The DataLink layer will bestow the workings of certain resolution protocols such as the Address Resolution Protocol (ARP) and Reverse Address Resolution Protocol (RARP) which interrelate with the two sub-layers that the DataLink supplies, the Media Access Control layer (MAC) and the Logical Link Control (LLC) layer. MAC interacts with the Physical layer in that it provides physical addresses for resolution to transpire. The MAC address are 12 hexadecimal digits, the first 6 that defined by the IEEE, and the latter six defined by the vendor, all burned into Read Only Memory (ROM) of the arbitrary machine. The LLC talks up in the OSI model by instantiating a uniform interface that procures independent LAN media access to procure flow control and sequencing services.

The network devices that exist at the DataLink Layer of the OSI model are:

  • Bridges
  • Switches

The protocols that exist at the DataLink layer are:

  • SLIP
  • PPP
  • RARP
  • SLARP
  • IARP
  • SNAP
  • BAP
  • CHAP
  • LCP
  • LZS
  • MLP
  • Frame Relay
  • HDLC
  • BPDU
  • LAPD
  • ISL
  • MAC
  • Ethernet
  • Token Ring
  • L2F
  • L2TP
  • PPTPFDDI
  • ISDN

Layer 3 Network Layer

The Network Layer of the OSI model defines the injected information of the sent packets and frames so that they can be properly routed throughout the network to the correct destination sets. For SharePoint architects this is typically where content routers can be inserted. As well, securing routers is imperative to collaboration environments since compromising the router can eventually lead to concessions with the aggregate collaboration environment.

The Network Layer is fundamentally accountable for next-hop resolution and addressing, which build the principals of routing and switching. As broad network problems arise they are also resolved at this level, such as when there is network congestion (if multiple packet injections institutes a traffic bottleneck) that occurs that is affecting normal operations. After the segment are received from the Transport Level of the OSI model, it is pieced into Maximum Transmission Units (MTUs), which will consecutively classify the thresholds for the sized packets that are allowed to cross an arbitrary network medium. After the packet is sent, it is moreover reassembled at this level.

As well, the Network Level also has several duties related to the subnet, including how information packets are routed from the source to the destination, using an arbitrary set of routing logic that is up to the network architect to decide on, and the related node metrics.

The devices that operate at the network layer are:

  • Routers

The protocols that can execute at the network layer are:

  • IP
  • BOOTP
  • DHCP
  • OSPF
  • EIGRP
  • IPX
  • ICMP
  • RIP
  • ISIS
  • ZIP
  • DDP
  • X.25

Layer 4 The Transport Layer

The transport layer provides the essential transport services for end-to-end data movement, along with establishing the entail connections that are needed for the data transport to occur by establishing a logical link between the two. In essence, the transport layer is responsible for all activities related to the massaging of data between two endpoints by assimilating data from the Session Layer and breaking it into lesser units and passing it to the network layer, and then assuring that the data is routed correctly. SharePoint architects tend to have very little interaction with this layer since it is mostly automated by the appropriate network devices and for adjustments requires an understanding of the Cisco IOS. The transport layer provides another layer of abstraction in order to accommodate for changes to the physical network.

The Transport layer is most known for its function related to TCP. The transport layer will subdivide user-buffer datagrams, into network-buffer datagrams, and implement that necessary transport protocols for the data transmission to occur. As stated before, TCP exists at this level, as well as User Datagram Protocol (UDP). Between these two protocols, the largest difference is the concept of speed and reliability. UDP simply makes a handshake with low overhead transmission services and is essentially stateless with no error checking. The TCP protocol however keeps a running tally of the packets being delivered and the order that the packets are sent with granular error checking, sent via sockets. This in essence, means that TCP is a stateful protocol.

Protocols that are used at the transport level are:

  • TCP
  • UDP
  • SPX
  • ATP

Layer 5 The Session Layer

The session layer is mostly responsible for establishing and maintaining the inclusive connection between two network enabled hosts, providing the facilities for preserving the connection during the transport of the data as well as controlling the drop of the connection if it is needed. For SharePoint architects the session layer typically interacts with how relevant SharePoint frames and dropped and managed at the network level. This is not implying anything regarding session stating or viewstates, since this are application specific settings.

The Session Layer does three main actions related to sessions:

  1. Establishes the Session
  2. Maintains the Session
  3. Drops the Session

Involved with the session process are the recognition and identification of the parties involved in the packet inter-exchange so that participation of the session parties can be maintained. To promote the quality of the session (QoS) there is a synchronization check that occurs by injecting checkpoints into the transmitted data streams in order to detect whether a session fails so that the last checkpoint can be reloaded into the session stream for transmission, this provides a rudimentary form of fault-tolerance.

In a networked computing environment, the session layer enables two client machines to establish a germane session to implement conventional data transport as well as time-sharing and file transport between client machines. As opposed to the Transport Layer of the OSI model that can still provide ordinary data transport the session’s layer can also implement dialogue control in order to procure bi-directional traffic control and keep a tally of the clients that are involved in a traffic push.

The protocols that are used in the session layer are:

  • DNS
  • RPC
  • SQL
  • NFS
  • SSL
  • TLS
  • SSH
  • ASP
  • RADIUS

Layer 6 The Presentation Layer

Layer 6 of the OSI model, the Presentation Layer, is the primary means of representing data in a standard structure that can be translated into sensible data once it is received at the destination. The presentation layer is genuinely where the SharePoint architect will begin to interact with the OSI model since it is where relevant SharePoint frames are converted into the service that build the presentation layer of the application.

During this frame resolution process, there is a translation procedure that occurs between the format that is provided by the network and the format that is parsed by the application. This provides a uniform method of conversion, whereby all data passed through the OSI model can be translated into a common format through the use of protocol conversion, character conversion, data encryption services, graphic commands, and data compression.

Layer 7 The Application Layer

The Application Layer provides the support needed to provide support to services that will generate the user interface from relevant application services. The application layer should not be confused with the tangible user interface, but is instead the application interface that will in turn impart support to the user interface. This is where the ASP.NET framework will reside since it is the service that services the SharePoint framework, but does not actually generate the user interface.

The Application Layer will provide the network access flow, overall flow control, and general error recovery after the transmitted data has reached this level.

The protocols that are used in the Application layer are

  • HTTP
  • NNTP
  • DNS
  • SMTP
  • DNS
  • FTP
  • TFTP
  • BOOTP
  • SNMP
  • RLOGIN
  • MIME
  • NFS
  • Finger
  • Telnet
  • NCP
  • SET
  • SMB
Share