Category Archives: Multi-Level Security Research

Multi-Level Security Research For SharePoint Introduction

Multi-Level Security is an important concept for several flavors of industry, but most importantly those that exist within the federal government. The concept of Multi-Level Security is built upon the model that were firstly built on the Bell-LaPueda model, which in general, simply laid the foundation for read/write access across logical boundaries.

As with any security model, there are two important concepts that are typical involved, the object, or the asset that a requesting party wants access to, and the subject, which is the querying party for that specific asset. Regardless of how the request is routed, these two concepts are a constant within any security model proof.

Microsoft Windows is natively tied to the concept of Discretionary Access Control, since security levels are irrevocable bound to native Windows Identities, which, for federal sectors and certain industries that have to comply with various types of regulations, can be rather restricting and make management of objects an increasingly difficult task. The concept of Multi-Level security, or can be generally called Mandatory Access Control, builds upon the concept that arbitrary personnel are tagged with a classification. Whether it is secret, top-secret, or public. In this sense, the concept of Multi-Level Security, is Multi-Level in general hierarchy. Looking at the initial diagram depicted, we can see that there are two main actions. The first of those are the requestors, those that are querying to access a specific asset that exists on the MOSS server at a high level, which is noted as the Sigma to keep the context of the diagram somewhat bland for applicability purposes. SharePoint has the capability to store user information, as well as access controls to the backend databases, and therefore provides the medium between the actual user requests and the serving of the requested object. The second is the receiver, which are the low level of requestors that can have an arbitrary numeric as well. Hence, we have High systems denoted as S, and low systems that are denoted as R. The communication between the two is all mitigated with SharePoint as the general medium between the two objects.

Share

The CIA Triad and SharePoint

The propriety information that SharePoint propagates and builds upon is the essenc collaboration enabled organization. Protecting this information should be the primary goal of an organizational after the proper enablement of it, safeguarding it from intruders and attacks that may have malicious intent. This is especially pertinent in the case of SharePoint where the integrity of the stored business data is nothing but operationally critical. In this, a simple principle should be maintained. Users that can access the data should be able to do so easily and efficiently, whereas users that are not authorized to do so cannot. In order to enforce a certain standard, it is wise however for one to take this concept of security beyond a rudimentary level of access control mechanisms, since attacks can occur at the pipe, post transit, as well as when in archived storage.

The concept of the CIA triad is one of the methodologies that are immediately available to empower a user to properly structure their SharePoint security strategy. Within the concept of SharePoint which builds upon various objects having the option of being secured, this means that a SharePoint administrator must look at all of these objects when positioning himself/herself to secure SharePoint.

The CIA triad is composed of three main layers:

  • C – Confidentially
  • I – Integrity
  • A – Availability

How the CIA triad is applied to an organizational is a molded basis. It is never a uniform application since it requires taken each individual company and applying it as an aggregate framework. For each organization that implements SharePoint, the overall goals that they wish to achieve will be different, as well as the limits that the CIA objectives can touch tend to be excluded against the overall business strategy of the company. Whenever applying a security protocol however, it is best to think that the you are doing it to preserve a layer of the CIA triad.

Confidentially

Within any organization, the concept of confidentiality is ever present. Particularly in a SharePoint environment where the nature of the system is to aggregate business data this is an ever increasing problem that needs gentle application. The basis of confidentiality is that the base of a certain object, whether it is a Microsoft Office Word document, list item, or any other arbitrary SharePoint item, has not in any way shape or form been compromised by another party, and is only available to parties that require access to this data. The latter in general means that only trusted parties are the ones that have access to that data. There are a multitude of ways that a person may breach confidentially, whether it is through technical or social means, either through hacking and sniffing to calling up a support representative of a company and social engineering their way into the data that they wish to get access to.

Every party can be susceptible to committing an act that would breach confidentiality. Since SharePoint at its essence is a self service system, it is particular vulnerable to site / site collection owners causing the breach, particularly through social engineering tactics. Although an exact example of this is fairly impossible to give, it would in general just be an attacker posting as a trusted user attempting to gain access to a site collection. The problem with social engineering in the realms of creating the most secure collaboration systems is that it is often an endeavor that companies are not willing to pay for, since it results in high user training costs and proper security training.

Integrity

Somewhat related to the concept of confidentiality is the subject of integrity. When a individual posts a certain business asset to a site collection, there is the understanding that the data will not be tampered with either after-post or while the upload is happening. if the data is committed by any of these two breaches, the data is considered to be of failed integrity.

Integrity can be defined very simply as data that party A commits to SharePoint will never be modified or destroyed by any unauthorized party. Therefore, there are typically two points during the data transmission process where the breach of integrity could occur. When uploading a document to SharePoint from the origin to destination site collection, the user is assured that

  • the document during transmission will do so without any unauthorized tampering or modification
    where the document is stored is the target site collection without doubt. Otherwise the integrity of the arbitrary business asset is forfeited.

Establishing the concept of integrity is relatively simple for one to do. There are three main principles that are typically implemented against a SharePoint framework in order to achieve this:

  1. LUA (Least User Access) – The user only will need access to certain site collections. Spreading privileges to think will cause breaches in integrity.
  2. Rotate Duties – Rotate the site collection administrator permissions within an arbitrary web application in order for absolute control to be difficult to maintain
  3. Separate Duties – One person should never have complete control over the SharePoint environment. This task should be split across multiple parties to ensure failover points and separate trust within the collaboration environment.

Availability

Availability is a problem that occurs within any collaboration environment, and can be an operational killer. For a collaboration environment to properly build out virtual teams, it is essential that the SharePoint network have optimal uptime. Although availability does encapsulate the point of making sure that the environment is stable and maintained, it also houses the fact that users should be able to quickly get to the information that they require with little waiting time. The concept of availability is usually subject to calculating the Quality of Service that one can provide to their SharePoint users. The concept of QoS means that a standard will be maintained for all natural disasters, against technical attacks that may effect availability (such as a Denial of Service attack), and that a redundant collaboration environment is architected in order to promote the highest level of failover.

Share

SELinux Permissions Management and Creation

SELinux Permission Management and Creation

As stated in other articles, there are two main concepts that exist in MAC architectures, subjects and objects, both of which are intrinsic to understanding the aggregate concept of SELinux architecture. Objects are simply assets that exist on the system, such as files. For each of these objects, there are permission sets that are associated with them that control the access and actions that subjects have in relation to those specific objects.

In SELinux, objects are grouped into the concept of object classes, and all objects that exist in an object class are of a type. Just like in OOP programming in the .NET framework that SharePoint builds on, an object class allows the instantiation of objects, and each instantiation represents an individual object. For administrators of SharePoint, it is easiest to think of this in terms of the file system as opposed to that of a programmatic object model, where you might have a folder of related files, which is the object class, for each file in that folder that you can individually instantiate, is an object. For access to the various objects, there are rules that are applied when access to the object is demanded to subjects, and these rules are constructed by the overall security policy. Although, it is important to understand that the concept of object classes extends to networking assets such as sockets, any type of communication that would in turn expose resources that exist at the OS kernel level. Ergo, the important thing to grasp is that for each object, it is typically grouped into a relevant object class, and for each of the object classes there are rules that are applied which build into the parent concept of SELinux security policies.

Permissions to objects are in an easy to read and create syntax. First we have to define whether the process is allowed or denied, the subject that the rule applies too, the object class file, and the permission rules that will generate the rules that define the access control in the object / subject relationship (this relates to the concept of type enforcement access control). With type enforcement access control, you define the source, target, object, and the permissions, which we can see translate to the above concept nicely.

Making new object classes in SELinux is fairly straightforward, and similar to how one constructs classes within .NET compliant languages. As stated previously, it is important to realize that several of the OOP rules that we see within such languages as C# still exists in SELinux since the concept of classes and objects is somewhat, if not, identical.

To declare a new object class names (which is known as a class declaration statement), for example declaring an object class sharepointsecurity, we can simply execute:

Class sharepointsecurity

We can see that the declaring a new class for consumption entails using the keyword class and then stating what the class name is, keeping in mind that the class name must be of ASCII characters and numerical standards. Unlike C# though, there is no terminating character to the class creation statement. But like C# and .NET OOP programming practice in general, there are individual namespaces that are made for relevant classes.

Defining SELinux security policies means building the structures that will build the permission sets related to the object classes. The object classes are typically already defined by the file system, however in order to construct and apply the relevant security policies to the hybrid SharePoint environment it is necessary to research and analyze the object classes that exist within the environment.

Now we have the object classes that are relevant to the policies that we are construct in our environment, either specific or not specific to our SharePoint implementation. Now that we have objects and objects classes, it is necessary for one to declare the permissions that are related to those objects by defining the sets. Similar to group and individual groups within Active Directory within a Windows Based environment (i.e. you can compile an AD group in windows and bind it to an object, or declare a domain account that has access to that object), SELinux offers two main methods of binding relevant permissions to an object within the system. The first of these is known as common permissions.

Common permissions can easily be thought of as associating permissions with a group in relation to an object class.  When creating common permissions, we are creating permissions that are associated instead with a more than one class, as opposed to specific permissions which are bound to a specific class. Declaring common permissions is a relatively simple class and resembles class declaration in C#. The structure is easy to follow, we declare that we are stating common permissions, declaring the set name, and then declaring the object classes that the permissions apply to. The important thing to grasp with common permissions is just that they apply to more than one object class.

Common myexamplepermissionset

{

Read

Write

 

Link

Execute

}

In the above example we are declaring the common permission name by using the common keyword and stating what the common permission set name is. The common name can be ASCII characters, numbers, dashes, or periods, and the permission set can be ASCII characters, numbers, dashes, or periods as well.

Now that we have seen that we can declare a permission set that is common, they have to be bound to a specific object class. The way that this is done is by using an access vector statement. We must associate it with an object class because although we have declared the permission set it is simply an asset that can be associated with an object class, however this is not implied. Meaning, once we associate the common permission set with the object class is when we truly see the effect that they can have, until then they simply exist and have no real effect on the overall hybrid SharePoint environment.

To associate the permission set with the object class is a relatively simple task, we have to declare the object class, and then define the permission set that we wish to bind to the object class. To create an access vector statement that would cause the sharepointsecurity object class to have class myexamplepermissionset permission would look like the following:

Class  sharepointsecurity {  myexamplepermissionset }

We are basically defining the object class and the permission set that we wish to bind, in essence this looks very similar to the C# syntax, the only difference is that there is no terminating character present.

The concept of inheritance is well known is C#, and it is no different in SELinux. Indeed, permission sets are also subject to the concept of inheritance.

Class sharepointsecurity

Inherits myexamplepermissionset

{

execute

mkdir

}

If we instigate the following example of inheritance, we are easily associating the shared permission set myexamplepermissionset with the object class sharepointsecurity, along with the custom permission set that we are defining inbetween the brackets. So, we can inherit an already defined permission set, and extend the permission set with any custom permissions that we wish to define by placing them in the ending statement parameters. This doesn’t mean that you have to extend an object class when inheriting a custom permission set, you can easily just inherit a permission set to an object class after its creation by excluding the statement as defined between the brackets. In the above example, we could modify it to look like:

Class sharepointsecurity inherits myexamplepermissionset

In this, we are simply inheriting the permission of myexamplepermissionset and not including any other custom permission such as execute or mkdir.

Share