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

General Introduction to Intrusion Detection and Collaboration Systems

It is inevitable that collaboration systems within an organization at some point will become compromised for any number of reasons. Although there may be numerous appropriate counter-measures set up in order to prevent SharePoint and network intrusions, it is never possible to have 100% secure collaboration system regardless of the industry that your organization is involved in.

Network Based Intrusion Detection and Host Based Intrusion Detection

Intrusion detection can basically be defined as setting up either a Network-Based Intrusion Detection System (NIDS) or Host-Based Intrusion Detection System (HIDS) which will allocate the exposure of assorted natures of data such as system logs, pertinent audit data, or network traffic that transverse through a pipe.

NIDS is preordained to target protection of an entire network segment, and SharePoint IW client machines are generally transparent to the intrusion detection process since it subsists at a high level. This is emblematic for organizations that necessitate implementation of mass protection and require that an IDS sensor (the concept of which will be covered in a later section) be placed on each individual network segment. HIDS is meant to target a single IW host machine in order to offload processing to the client machine and provide encryption levels (application level in essence) inspection of transferred packets. The latter of these austerely means that the IDS is specifically targeted to require inspection of collaboration traffic that may be encrypted, and will, in essence, provide application layer intrusion detection security.

Intrusion Types That Can Involve An IDS

There are variety of intrusion types that a IDS will compose and display to the administrator of SharePoint:

  • SharePoint Server Environmental Errors
  • SharePoint Configuration Errors
  • Race Conditions
  • Access Validation Errors
  • Condition Handling Errors
  • Buffer Overflows Targeting SharePoint
  • User Based Input Validation Errors
  • Boundary Step Through Conditions
  • IP Based attacks (SYN / other flag attacks)
  • Denial of Service Attack Targeting SharePoint Servers
  • Port redirection
  • Man-The-Middle-Attacks
  • Viruses and Trojans

The Modules That Assemble An IDS System

The IDS system has three major components that compose it:

  • A Sensor (also referred to as an agent in some contexts) the sensor purely amasses the relevant intrusion information (typically, there are certain IDS systems whose sensor may offer other functionality) and pushes to the analyzer, the second object within the intrusion system. The sensor also has a sensor rating which determines the amount of packets that can be analyzed before they are simply dropped by the sensor for analysis, since there is a threshold of information for which the sensor can handle the load for. For this reason, flood attacks are very common against IDS’s as primary attack launching point to bypass the IDS packet inspection routines (regardless of the inspection techniques being used, which are discussed more thoroughly shortly). This can be counteracted by implementing suitable rate limiting which throttles the amount of bandwidth that can enter a network before handshake requests are simply dropped to ensure that only appositely loaded injected traffic, that which can be handled, is analyzed by the IDS.
  • An Analyzer the analyzer receives data from the sensor and parses it to determine whether the information constitutes an actual attack or a false positive (legal traffic which becomes registered as an actual attack, there are essentially for groupings of packet analysis which are discussed shortly). The analyzer characteristically uses the concepts of signatures which can ascertain the validity of traffic and the proceedings that should be taken (such as a TCP reset, block the sending host, executing alerts for example) if a frame is determined to be of malicious origin and function. From a high level standpoint, blocking the host can be the most critical step since it can impede flood attacks, and ensuring the administrator doesn’t receive millions of alerts when an attack is occurring that are sponsored by the IDS system.
  • A Security Interface –  the security analyzer is a software or hardware device that can output legitimate attacks or false positives to the SharePoint administrator to determine what actions if any should be taken. There are several concepts that the Security Interface will supply, such as tracking user actions in an audit trail, allowing forensic event reconstruction if an attack does occur, activity monitoring for real time scrutinizing of tribulations as they occur, and trailing if intrusion detection events do occur. In essence, these all manufacture the concept of violation reports, which can determine whether there have been attempted breaches and unauthorized access attempts.

IDS Object Technology

Profile Based Intrusion Detection (PBID) ( a.k.a Anomaly Detection) Using PBID there are profiles setup throughout the system, which determines the thresholds of activity. If an activity passes the thresholds defined by the profiles than the IDS will trip an alarm to alert the administrator of the system. Using these boundaries an enterprise baseline can be established for what is legitimate and illegal activity throughout the environment.

Signature Based Intrusion Detection (SBID) SBID is based on patterns and pattern matching. There is a set of rules that build an algorithm up, this algorithm is compared against the traffic patterns within a network. If the pattern is matched, then the alert is tripped and the SharePoint administrator is notified.

Signature based Intrusion detection is extremely common, and are based on the concept of recognition. The signature, as stated before, will define the rules that will generate the logic of determining a packet violation. After the sensor does inspection on the packet, the analyzer uses the defined recognition (signature based) rules which are able to determine the legality of the packet. There are various types of signatures that exist, notably:

  • State
  • Sweep
  • Flood
  • Atomic
  • String
  • Service

To see how a signature based attack works, examine the concept of a LAND attack which implements an impossible loop of an IP packet. This is down by streaming TCP SYN packets with malformed destination and port address so that the values of both are set to the numeric of the host being attacked. For some TCP/IP protocols, this causes a confusion of the protocol handler, which causes infinitely repeated connection wreaking havoc on the host machine. For a signature, the IDS can analyze whether the TCP packet has well-formed source and destination fields before forwarding the frame, if it matches the signature of a typically land attack, a TCP reset can be performed to drop the packet.

There are four main types of identification for the IDS to work with when executing:

  • True Positive Traffic that is malicious, and identified by the IDS as such
  • True Negative Benign traffic that is defined as legitimate
  • False Positive Legitimate traffic that is determined as an attack
  • False Negative Attacks that are not determined as an attack by the IDS, but should be

An IDS builds upon all of these types of identification to compose the identification traffic portion of the IDS system.

IDS Modes (Active and Passive Mode)

There are two major modes that IDS’s run in, passive and active mode.

Passive mode – means that the sensor of the IDS makes a stamp of traffic packets as they are swept and performs sniffing of the traffic packets at the copy level to offload the analysis allowing a much deeper scrutiny. This way, the sensor can dedicate all the processing that it necessitates in order to analyze the packet at any amount of depth. After the packet is determined as legitimate, it is dumped, wiped from memory, and the next packet is assimilated from the buffer. If the packet is determined as illegal, it can alert the administrator. Passive mode is not meant to do TCP resets or other relevant prevention tactics, and can inadvertently send malicious packets to the host since they packets are stored in memory, instigating some latency. On the OSI model between switches and hubs, the IDS sensor is typically bound to the switch. If it is instead bound to a hub, the frames can be forward frames through all destination ports (through a broadcast), whereas switches typically only forward frames to the singular destination host, whether it is through a port or set of ports.

Active Mode in essence provides a more intensive process of inspecting the traffic packets. When the packet is received by a sensor that is running in active mode, it is inspected, goes through Quality of Service, other miscellaneous functions, then the packet is lastly passed to the IDS. Once it goes through all inspection, the packet can be forward to the destination, however if it is deemed illegal, there can be a number of intelligent actions that take place such as a TCP reset. Although active mode on an IDS is the most security mindful setting, it is very process intensive, and require, particularly with rule base signature types, that there be less inspection as packets come through to procure the most proper operational state of the environment.

Honeypots and Honeynets

One of the largest features that an intrusion detection systems habitually supplies is the concept of a honeypot or honeynet. The major difference that exists between the notion of a honeypot and honeynet is that a honeynet purely exists on a much larger scale. Whereas a honeypot can exist solely to target SharePoint as an application, a honeynet targets an entire network segment, and mimics the production system to a large extent since it will appear, and typically mirror, an inclusive network system. Since the honeynet should have no legitimate traffic, all ingress and egress traffic should have the attack pattern of a malicious user, no actual users should be using the network.

This, in essence, is the sacrificial lamb that an organization will simply give to an attacker which is typically less securely configured than the sensitive networks, however typically has the same SharePoint implementation as the production network, however not stored with as sensitive of data. The goals of a honeypot are to lure an attacker from the production SharePoint target, provide analyze of methods being used against on organization, take action against an attacker before the real production SharePoint environment may become compromised, and verify the location and identities of attackers that wish to compromise organizational security.

Honeypots because of how they are constructed, provide no legal recourse since there is no financial loss being incurred by the victim organization. Although this may be true, the methods and tactics that can be learned from implementing a honeypot make it a worthwhile endeavor to setup for any organization. Beyond this implication of no legal action being able to be taken, there is also the issue of the attack claiming entrapment and privacy concerns. Although this may seem backwards, simply placing a banner informing the would be attacker that they are accessing a secure system provides the legal forthright needed to circumvent this headache and possible pursue certain legal actions.

Intrusion Prevention Systems (IPS)

This is not to say that Intrusion Prevention Systems (IPS) is not a valid concept that can be implemented in a collaboration environment. Since an IDS will log and parse various intrusion attempts, the IPS lives behind the IDS and provides logic which builds automation to instinctively respond to attacks. The IPS will determine based on the logic and metrics provided by the IDS whether the traffic is legal, and based on rules can bounce pack a packet request to the client machine. Overall, this process simply brings an automated, intelligent process to the concepts provided by the IDS, all of which will procure the overall intrusion system. The methods and process that the IPS uses is relatively straightforward:

  1. A request is sent from the client machine to the system which has the IDS setup
  2. The IDS intercepts the packets, and using something like stateful packet inspection, determines if it is a malicious packet or not
  3. If the packet is determined to be malicious, it is sent to the IPS by the IDS
  4. The IPS will analyze the packet further, and make several decisions, such as if it is an attack what attack it could be, how the attack would affect client systems, and what is the intended route of the packet
  5. The IPS will examine the destination of the packet, and see that if this packet is sent to the client machine, whether it can be compromised
  6. If there is no direct match between the two, the packet could not switch an attack, the packet is allowed through
  7. If there is a direct match between the two, the packet is dropped and rules can immediately state that no further packets are going to be accepted from the sending machine (TCP reset and Blocked Offending Traffic [BOT]). As well, there can be session log files and other log files created relevant to the request.
  8. As well, there are conditions whereby the IPS can determine that a hotfix or patch can resolve the issue being presented by the malicious packet, and therefore install it on the client machine.

This concept can be extended by performing Penetration Testing of SharePoint to ensure that you are conforming to all known vulnerabilities and exploits, guaranteeing all weaknesses of the system are conformed to. There are several articles on the site that talk more in-depth about the concept of penetration testing and how to facilitate it.

Share