Web Service Security And SharePoint

Web Services, SharePoint, and Building Business Data Interoperability

Web services are becoming increasingly more commonplace within every business environment in numerous industries, and are particularly common within a SharePoint environment for a variety of different purposes. With the introduction of any new technology, as web services are to several enterprises, always brings into light new security issues that must be dealt with. Although Web services provide excellent transfer interoperability with various types of business data to expose and serve in relation to our SharePoint portal, there is also the need to harden and secure these Web services in order to mitigate any risk to SharePoint as well other business applications.

Back to the Basics: What Constructs a Web Service

In order to understand how we can secure web services, we must firstly examine exactly what constructs a web service, how it interacts, and how it functions.

Web services are composed of two main pieces of functionality, two main actors in the aggregate process. There is the web service provider, which is going to provide the stream of data, and the other end of this relationship is the Web service consumer, which is the client which is consuming the provided data. Building on these two actors, there are four main pieces of technology that allow list type of beneficial relationship to exist. The first of these is the Universal Business Registry (UBR).

The Universal Business Registry is the piece of technology that will allow a user to query for specific Web services based on explicitly supplied criteria. It is the third party mediator between the consumer and the supplier, allowing a consumer a uniform location to look for Web services of varying natures provided by several different businesses. The UBR is typically the first player in the Web service process; a user will query the UBR and attempt to find a Web service defined by their unambiguous requirements. Once a user supplies the conditions to the UBR, the UBR will return a list of services that the user can consume, and the user will select the most appropriate Web service to their need. Throughout the UBR query process, the protocol that is being used is UDDI (Universal Description, Discovery, and Integration). This is the same protocol that is going to be used when attempting to start the foot printing process to begin to gather information about different Web services.

After Selecting the Service

Now that user has selected the service that they wish to consume it will ask the UBR to supply an endpoint for their selected Web service for proper consumption. Once the user has the endpoint it can effectively start consuming and leveraging the Web service it has selected coupling with a reader or other API of choice. This endpoint is built upon a technology called WSDL (Web Services Definition Language) which will describe how these services are structured deployed, accessible, and proper usability. Throughout this entire process the HTTP protocol that is being used is known as SOAP (Simple Object Access Protocol) which piggybacks on top of each CTP packets to provide the underlying communication that we need.

Similar to any other type of attack on a SharePoint portal, the first action a malicious user will take is to gather as much information and research as possible in order to gain a knowledgeable standpoint about their target.

Just like with any other Web asset, there are methods and actions that will allow the user to fingerprint and gain more insight into a Web service in order to properly structure an attack.

Why Application Layer Firewalls Just Aren’t Enough

The only way to ensure a SharePoint portal is properly secured is by ensuring that any information that we expose in the portal is also secured. SharePoint is a web application, and therefore will typically always function over the standard HTTP ports, 80 and 443. Web services also function at this level which provides a majority of there benefits over other methods of data transmission. But with this comes evident security issues. Because most security appliances and applications try to examine packets that transfer over other ports often times web servers traffic is difficult to decipher as benign or malignant because it functions exactness aim as a SharePoint a HTTP traffic.

The most typical way to protect a SharePoint environment is by implementing some type o application layer firewall. This application layer firewall typically does packet inspection on the varying types of traffic that are passed through it, however for the reasons described above and Web services acting as a HTTP traffic is difficult for a firewall to distinguish between malicious traffic.

Three Main Pieces

There are three main pieces an attacker will take when trying to maliciously expose a Web service for whatever purpose.

  1. Web Service Footprint Done against the UDDI ( Universal Description, Discovery, and Integration)
  2. Web Service Discovery Queried against the UBR (Universal Business Registry) in order to expose endpoints for service consumption
  3. Web Service Fingerprinting Done Against the Web Service discovery URL in order to expose the technology that builds the web service

The first portion of any attack is information gather reading. In regards to Web service is relatively easy for a user with little or no knowledge about a business to find Web services will by that organization. Although list type of data is typically in a protected repository because the purpose of Web services is to promote interoperability through an open standard it becomes increasingly easy for knowledgeable user to gain valuable insight into what organize a and start to gather relevant information.

The Four Structures of the UBR

When discussing how Web service at a very basic level works, one of the key components between a provider and consumer was the universal business Registry. As discussed the UBR axes the mediator allowing businesses a place to expose Web services and a client a place to search and determine methods to consume those exact same Web services. Just as a person can do a whois check against the public Registry in order to gain more insight into such things as IP addresses, a user can query that UBR in order to gain the same type of insightful information. But there are several different queries that a user can in bulk on the UBR in order to gather some information. The four structures that are available are the business entity, business service, binding template, and the technical model also known as the tModel. How users will interact with the UBR is typically provided through an application programming interface supplied by the same company that provides the Web service. Since the protocols that are being used for this type of transmission are HTTP and SOAP, these application programming interfaces will have direct hooks into the same types of protocols. The API will incorporate into the W. STL in order for the user to extract the endpoint information so that they improperly consume the Web service. Since while we are foot crane we are attempting to gain more insight into a specific Web service is necessary to leverage these application program interfaces.

When beginning to footprint process just like a normal user we are going to query the universal business Registry in order to expose a list of all available Web services. The first that in actual footprint process is Web service discovery in order to expose the endpoints. The endpoint will contain the most relevant information about the Web service including the IP host address as well as other information about the location of specific resources. Without having this endpoint information the process of information gathering is infinitely more difficult and will not allow a user to enumerate through the different Web service information.

Share

Hybrid SharePoint With SElinux Theory of Operation

Multi-Level Security Domain SharePoint

To promote apposite security implementation of security centric SharePoint environments (those which are focused on sheltered implementations) it is necessary to build an environment that implements multi-security domain access along with diverse security mechanisms that will provide a basis to procure the concepts provided in the CIA triad. Like researched in previous articles, there is an overall concept in computing security architecture known as the CIA triad which procures the subjects of Confidentiality, Integrity, and Availability (CIA) which afford the underlying basis for security conceptualization. Within an environment that promotes multi-level security domain access, there are other minor objectives that are introduced to build the aggregate CIA concepts since the environment becomes more finely tuned and the overall level of security system awareness becomes more robust and detailed. Throughout this article, I will present the Theory of Operation of building a such environment, and the considerations and implementation concerns that are presented with such a solution.

Introduction to the Theory of Operation

The Theory of Operation behind a Hybrid SELinux / SharePoint scheme provides the basis for procuring a proper implementation that conforms to the CIA triad while providing the mechanisms that are necessary for data carry over, while maintaining globally maintainable security policies that conform to a classification (an environment that inherits sensitivity labels) based environmental standards. This initial introduction to the Theory of Operation presents solely the basis for developing the environment, and in subsequent sections the exact compilation and deployment will be presented and examined. Several portions of the Theory of Operation may prove theoretical and touch on concepts not immediately available within an arbitrary technology; however the aggregate presentation will procure a concrete, usable solution.

Introduction to Machine Virtualization, and the need for Machine Virtualization

Virtual machines are increasingly common throughout enterprise environments for obvious hardware consolidation benefits; however, one of the most overlooked benefits that virtual machines can provide is that of security considerations. The Hybrid environment presented is excursively based on such a concept, since virtualization will build the option to use Windows Server 2003 on SElinux hooked Redhat / Fedora Core 3 kernel.

The most obvious benefit that is received when implementing virtual machines is that of complete data isolation, since, in essence, all data stored within an arbitrary virtual machine is considered to be segregated from the other environmental assets unless otherwise bound. The isolation also extends out to services and processes on the machine, in that there can be specified running of the services that are contained, in which services can be manipulated at runtime without affecting other various services.

Whereas the most secure environments are those whose domains are segregated because of the physical separation of machines, these are also the most difficult to transverse data through. In essence, when separating the machines physically, we are establishing multiple security zones within an environment. In order to achieve this otherwise, it would require separate processing mechanisms for each domain. Using virtual machines however, a SharePoint administrator can instead setup various security zones based on requirements that exist on the same hardware, whereas various domain security zones can exist in complete isolation, although procured on the same physical machine. For each security zone that is implemented, a separate security policy can and should be implemented which provides overall control in relation to the security domain. The security policies that are implemented are structured around the concept of Mandatory Access Control principles, so that they are not only applied for the objects that exist on a specific virtual machine, but the processes that exist within a specific virtual machine. By implementing this concept of MAC, one can be assured that between two various SharePoint environments, data cannot be transverse between the two, unless stated within the MAC based global security policy.

Although this all sounds great for federal and highly regulated enterprise environments, a rather rudimentary, be at although important, question remains. The concept of MAC was invented a very long time ago, why hasn’t it been implemented in rudimentary Windows based environment previously? There are two major answers to this question. The first is that direct hooks that would otherwise override the DAC controls that predominantly dominate the Windows security architecture are forbidden and would be a legal problem (discussed more exhaustively in a subsequent section), and secondly, MAC can become increasingly difficult to implement and maintain, and security policies tend to can be complex for an administrator to understand with granular training in such.

SELinux, although considered somewhat complicated, can alleviate a majority of these issues, particularly with the use of virtual technology. This is the reason for this particular choice of technology. In a separate article, I will detail how another technology, AppArmor, can be used for somewhat of the same purpose.

Carrying Over the CIA Triad Concepts

The three subjects from the CIA triad are carried over when leveraging a MAC worthy technology such as SELinux. These are availability, where the SharePoint assets are accessible to the requesting parties in a timely manner, confidentiality where the information that is stored in SharePoint is available only to the properly authenticated SharePoint users, and integrity where SharePoint information can only be modified or altered by entities that are authorized are all still relevant goals to achieve. However within a multi-security environment a few more minor security concepts introduced, namely the following three, which although relate to the CIA triad, deserve individual mention:

Authentication ensuring that subjects are appropriately identified by the collaboration system and that their passed identity is not a fictious one

Authorization ensuring that subjects are authorized to perform their relevant requested actions on the system and that they have proper access rights to do so

Domain Separation For proper SharePoint information assurance, it is necessary to package SharePoint data into various domains that procure specific levels of security and assurance. Preventing leaking of information across these security domains is a very important concept to ensure, and all information that transverses between domains be scrubbed by appropriate mechanisms.

What Types of Exploitations Can Be Mitigated?

There are several types of exploitations that can be mitigated when implementing a multi-level domain access architecture. The first of these is a global privilege escalation, by which a user will execute an application that will run under privileges that it normally wouldn’t have the option of running under. The second is the Assumption of Atomicity, in which a security check is basically bypassed. Typically this is during a sliding window when the check is executed, when the exploit is called directly during that sliding window down time which would otherwise cause that check to detect the user interaction. Programs can also be trusting of the execution environment, so that all children application of a parent application will immediately inherit the permissions of their parent. These programs could also be accessing resources that are leveraging shared libraries which could in turn infect users across a variety of parent applications.

As stated in several other articles, the main purpose in a multi-level security environment is to procure an environment where there can be properly structured Mandatory Access Control.

Why Mandatory Access Control and The Mandatory Access Control Theory of Operation

The entire theory of operation for using a hybrid environment of SharePoint and SELinux is based upon the concept of procuring an environment that allows the birthing of Mandatory Access Control. The reason that Mandatory Access Control is at the heart of the theory of operation for the SELinux / SharePoint architecture is that conventional methods of DAC have proved to provide lower levels of unusable levels of object security. For a collaborative environment to be truly secure, it is necessary for it instead to have the option of not binding an identity to a system object but in effect provide segregation of various pieces of information in order to highlight the Confidentiality present within the CIA triad. This in turn would al the birthing of more effective measures that would promote the concept of integrity of the overall, aggregate system. The failure in DAC that ensues is due to the fact that DAC allows system decisions to be executed with the presence of simply an identity of a user, as well as the ownership of arbitrary files and objects that exist within the system. The concept of DAC is easily built up conceptually within the Windows Server architecture, the root account, typically a system account which has in essence the permissions that are granted to the local administrators security group, owns the system, whereas there are subsequent child users that can mimic this role, as well as sub users that are assigned arbitrarily to other roles within the server system. This is a faulty concept in that it allows various users to execute an N number of arbitrary programs and applications that might prove malicious to the collaboration environment, as well as it empowers various users (which can become somewhat impossible to track the granted permissions) power to give an N number of users access to the environment, and in this access to the objects and files that are housed within that system and all subsequent chains. Beyond this, there can always exist a power user, or a malicious root user, whom may corrupt a system needlessly for whatever intents and purposes. The concept of CAS (Code Access Security) also begins to take a small role because in code access security where are examining what foreign assemblies a specific binary may touch during run time execution, and within a DAC sponsored environment it is typical that the execution of relevant processes will simply inherit the permissions that are sponsored by the user (or, in effect, how the arbitrary process is tripped). This leads to inherit flaws within the environment since once the malicious process is tripped it can manipulate other objects permissions, its own permissions, or other subjects within the system’s permissions. This can easily lead to corruption of permissions within the environment, and in effect circumvent the granular permissions that are typically set within a network regarding the user of processes and objects. The inherent flow of DAC is that because of the sponsorship that is given to users they are allowed free reign within the enforcement of a possible corporate policy (not taking into consideration DRM such as IRM which can enforce somewhat global policy enforcement through a system but typically targeted for offline client access).

The largest goal that we seek to implement with a MAC based system is an overall security policy implementation that will enforce global rules across an environment. By using a detailed security policy that conforms to corporate goals and security requirements that assimilate regulatory and legal compliance requirements, we can ensure:

  • Secured Applications Are Protected
  • Separation of Privileges That Promote Sandboxed, Untrusted Application Execution
  • Vital and Essential Processes Are Assured Processing Space
  • Partitioning of Permissions Between Various Applications
  • Controlling Processing Limits
  • Control Privileges and Prevent Various Types of Privileges Escalation

The last of these are a significant security enhancement as opposed to DAC which is prime for an attack that would otherwise allow the concept of privilege escalation. DAC may immediately prove the first line of defense against attacks (in that objects and the system will still be bound to an identity.

This is not typically present within the OS’s that are provided by Microsoft since Windows Server is a closed kernel product, and to procure this type of security would require that there be direct hooks into the kernel, in effect negating the option for a developer to provide a hardened version of Windows that would otherwise be MAC compliant. Active support from the kernel is required at run-time for proper MAC to operate, since application layer mechanisms would could easily be circumvented because they are just that, assets that exist at the application level. However, by using Trusted Computing Mechanisms that are rather hooked into the hardware interface, one can provide the goals that we seek the building out a classified SharePoint environment, that of confidentiality most importantly, integrity of the data that is being stored within SharePoint, and the necessary separation of domains that will complete the CIA triad to provide assurance.

Transfer Data between SharePoint Security Domains

Within an arbitrary SELinux/SharePoint environment, there will eventually be the need for the option of traversing of data between various security domains, such as those that are classified and those that are unclassified. These is especially true when establishing an environment in SharePoint where a certain instance on a virtual machine that is deemed classified is transferring data to another that is deemed unclassified by definition. Since the overall Theory of Operation of a Hybrid SharePoint environment is that which utilizes various virtual machines in order to procure an environment that allows true classification of data, this is a present and substantial argument. This domain crossing can at times prove to be a hardware device, such as a perimeter based security device, perhaps something like a rudimentary firewall, however regardless of mechanisms of transfer, it is necessary to establish a data transfer functionality that will allow data to flow through defined, finely tuned, processing stages. This highly relates in the CIA triad to the concept of confidentiality, whereby the need for information to be secured throughout the entire information flow process is assured from start to finish. This is a built in concept within SELinux, which helps us to easily facilitate this.

Example of Security Based Enhancements Real World Application

A tangible example is often helpful when attempting to conceptualize the security benefits that SELinux provides. Assume that there is user A, which intends to trip a certain process, let’s assume a copy of a binary from unclassified SharePoint environment A to classified SharePoint environment B. The copy process, should, in essence, only have access to the specific binary it needs, not all binaries that exist within a computer, a typically problem that exists when leveraging a service account. In effect, the ownership of the assemblies should be properly separated, as opposed to universal access to what may be potentially unsafe information to share. By leveraging the concept of MAC, the copy process that is executed would provide a sandbox that allows the copy process to only touch and execute within its limits and permissions, it will only be allowed to perform the actions as defined with a security policy. Therefore, the copy process would become exploited by a malicious user, the only process that the malicious user could perform would be those that are deemed necessary be the service, regardless of the user account that the process is running under. This is regardless of as well if it is a service account that is offered root privileges on the environment. All objects are given a security policy defined sensitivity label that will determine how the process will interact with the system and the actions that are allowed on those arbitrary objects, allowing a tuned mechanism of control. The security context as presented with the copy argument can as well be presented to the networking concepts that may be related to a collaboration environment such as relevant ports, which can be bound to a security context as defined by a security policy. One of the largest reasons that an overall web server becomes compromised is that they are exploited initially through a port that is considered benign, whereas later the attacker once comprising the initial port will following open another port on the web server to execute further attacks on the SharePoint environment. In regards to the UNIX permissions that are existent within the SELinux environment, those permission still exist (the UNIX read/write, etc. permissions), however they are instead subject to the same security policies as discussed in the above section. The flow of access/denial is relatively straightforward and simple to follow the standard access / deny concepts exist. Since the deny UNIX will not allow any interaction, this does not require the consultation of the SELinux security policy, whatever it may be. However, if a successful access attempt is made, then the SELinux policy is consulted before access is granted.

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