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.


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.


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 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.


Introduction To IPSec

Introduction To IPSec

For most organizations, the C and I of the CIA security model (confidentiality and integrity) when traversing a network medium, or collaboration environment, are exceedingly imperative. Therefore, it is crucial to protect frames as they are funneled during transit between various machines on your SharePoint network.

The protection schemes defined will typically take place at the Layer 2 or Layer 3 of the OSI model which has been detailed in previous articles (please read the OSI model and SharePoint article for a better idea of how the OSI model is structured). Although there is obviously a layer of abstraction between the assorted OSI layers and the ones that SharePoint primarily interacts with (those related to interface transformation), it is nonetheless an important concept to understand in relation to proper security implementation for your SharePoint environment.

IPSec As A Network Security Protocol
IPSec is a principal network layer security protocol, and it allows the idea of multiple as well as concurrent tunneling schemes. The chief purpose of IPSec as a security protocol is to procure functionality that will encrypt and authenticate various IP packets as they are transmitted across an arbitrary medium, particularly those that are involved with your calibration environment.

Although an add-on is obtainable for legacy IP schemes such as the IPv4 standard, IPSec is built directly into the IPv6 standard (which is a common future rollout for organizations), procuring a more uniform, secure transmission security protocol. Although there are other germane network security standards (discussed in other articles) such as PPTP and L2TP, these protocols were mostly targeted at dial-up functionality such as VPN’s, whereas IPsec was built from the ground-up as a networked computing standard for a true associated environment.

Though it is still possible to use IPsec on VPN targeted environments (across IPSec-compatible VPN devices that are implementing on the DMZ a.k.a. a VPN gateway), IPSec is not a multi-protocol based standard and is targeted for strictly for IP encryption, although IPSec is based on a modular framework and allows several levels of flexibility to work with its base characteristics.

Tunnel and Transport Mode
There are two focal operational modes that exist with IPSec, Tunnel Mode and Transport Mode. Tunnel mode means that the complete layer 3 packet is encrypted and packaged in the IPsec packet. Transport mode means that the layer 3 payload is encrypted, however the IP headers are left as they are during a customary transport instantiation.

Authentication Header and Encapsulating Security Payload

There are two security protocols that manufacture IPSec, Authentication Header (AH) and Encapsulating Security Payload (ESP). Authentication Header is the protocol which provides data origin authentication, anti-replay, and connectionless integrity. The overall concept to understand regarding Authentication Header is that it provides no confidentiality services, and is not meant to target this specific faculty by design. Encapsulating Security Payload provides data origin authentication and anti-replay as well, but also provides faculties for confidentiality and connectionless integrity, and therefore has some facets that differentiate it from its former.

Security Associations
A security association in the realm of IPSec is a relationship that is procured between two or more entities, and provides the description as to how the entities will leverage the relevant security services that subsist in order to assemble secure communications.

Internet Key Exchange (IKE)

The security associations that are described in the above section require that there be existent a protocol that can facilitate the negotiations between entities that leverage the various described security associations. The IKE process requires that the relevant IPSec systems authenticate relevantly in order to establish the sharing of pertinent keys. There are two strategic phases that are involved in the key exchange in the IKE progression:

Phase 1
Between two applicable peers, the IKE will generate a secure channel known as the IKE security association, described in the above section more exhaustively. During this process, the Difffie-Hellman key agreement is leveraged.

In phase 1, there are three major methods that are used when authenticating to IPsec cohorts, pre-shared keys where the party will manually enter the key value, RSA signatures which leverage digital certificates sponsored by an RSA signature, and RSA encrypted nonces, which will use RSA encryption to encrypt a nonce value (random numeric).

Phase 2 During Phase 2, IKE will perform handshaking of security associations and engender the relevant key material needed for the IPSec service. The sender of the handshake will present a singular transform set (or more if needed as determined by the IKE process) which are leveraged in order to tolerate a combination of transforms regarding relevant settings. As well, the sender of the handshake will designate the data flow for which the transform set should pertain to.

The receiver of the handshake will transmit one transaction set that will specify the reciprocally arranged transforms and relevant algorithms for the established session. Lastly, there may be a new Diffie-Hellman key agreement established or the one generated from the phase one can be inherited.

The IPsec Process

The IPsec process can commonly broken down into five major steps that generate the overall process, including pertinent handshaking and termination proceedings.

  • Initialization Relevant traffic that deems it is necessary will instantiate the IPSec service. The service can be tripped by constructing an IPSec security policy that will trip the IKE process.
  • Phase 1 of IKE The authentication process that IKE users will authenticate the parties involved and the initial negotiation of the IKE will begin. This negotiation will be leverage by Phase 2 of the IKE process.
  • Phase 2 of IKE IKE will broker the negotiation of the security associations and there will be a generation of security associations of relevant peers.
  • Data Transfer The actual data is transmitted based on IPSec and the relevant IKE settings.
  • Tunnel Drop The IPSec security associations are dropped for any number of reasons as determined by the transaction state