Native Cryptography in SP Doc Libs and Lists (RSA WebPart Test)

Privacy is important, especially in a collaborative environment such as SharePoint where users are heavily empowered with actions that can directly effect sensitive files and file containers. The most typical way to protect privacy for file types is to implement a form of Multi-Level Access Control, and/or native encryption components that are easy for users to understand, ones that are perferably built directly into familiar toolsets such as Office (as is the case with IRM).

End to end encryption solutions aren’t a native thing to SharePoint (outside of WRM / IRM, which aren’t “native” in the sense in that they aren’t outright built into the product COTS, they require further configuration). Furthermore, there are a lot of side effects of going down a standard encryption road when examining a collaborative cryptographic solution, most we see when using IRM encryption envelopes. When I say standard road, I mean just using a client level encryption solution (something running on a user desktop), an arbitrary scramble method / encryption algorithm, by which I mean something like:

Symmetric Encryption

(Block and Stream Ciphers)

Asymmetric Encryption

Rijndael

Diffie-Hellman

Twofish

ELGamal1

Blowfish

Elliptic Curve Techniques

DES

Paillier Cryptosystem

TripleDES

PGP

RC2

Vectors and Salts

and then re-upload the document to a document library whereby you are responsible for key maintenance between an unknown amount of parties. The most obvious problem that is spawned is encrypted content cannot be read by the SharePoint gatherer since it does not sponsor anything besides plain-text reads.

For my final paper for my Masters (I am doing my degree in Applied Mathematics / Cryptography) I received approval from my professor to move forward with creating /verifying an end-to-end cryptography solution that solves all these issues and stays within the native SharePoint framework. I am not sure how / what it will look like yet, how it will be invoked, or any of the architectural considerations of it yet. My only stipulation is that it is easy, and directly available from within the SharePoint interface.

The aggregate objective of the solution, eventually (this is probably down the road a little bit), is to exhibit the feasibility of extending a native Microsoft Windows Server operating system and Microsoft Office SharePoint Server (MOSS) environment such that it enhances global security of federal Multi-Level Security (MLS) systems which are historically built on the Bell-LaPueda model. This technique should eventually leverage a lattice MAC (Mandatory Access Control) based Multi-Policy Access Control (MACM) object labeling controls regulated by comprehensive security policy implementation. The standard notion of Discretionary Access Controls (DAC) that the Microsoft Server System currently provides are incontestably bound to native Windows Identities, allowing users management of individual objects, expressed as P=SxOxA where s translates to the subject, O to an arbitrary set of objects, and A to access modes. Use MAC MACM this instead promotes M=(S,O,A,SA,f,R), such that S is the set of subjects, O is the set of objects, A is the access mode set when a subject accesses object: SxO {, {r},{w},{e},{a},…..}, SA is the security attribute, f is the security functions, R is the set of security rules that prescribe the constraints conditions of how subjects access objects. Using this model, it is possible to procure the federal notion of no-read-up and no-write-down.

The security attribute can be defined in tuple format: SA={L,A} such that: L is the security level of an entity, denoting the security right of the entity. Different security levels are comparable. Defining “” is a partially ordered on the set of the security level, if the security level of entity i ()

This promotes a new-read-up rule denoting that a subject s S is granted read access to object o iff f(o) f(s). No write-down rule denotes that a subject s S is granted write access to object o iff f(s) (f(o)

I started toying with the idea last night, just working with getting an RSA encryption engine to take a sample plain text string in a TextBox child control. Most importantly I spent some time building some foundational abstract base classes to provide a Multiple-precision shared library (for for multiple-precision floating-point computations) and a Barrett modular reduction library to implement Barrett’s Modular Reduction Method for RSA . Although the encryption exponent is pretty tiny for the test, the plain text conversion for my shared components was successful, however this is only 10% of the battle obviously (I was mainly interested in the web basd encryption performance, I would like to eventually integrate instruction level parallelism). What I plan on ultimately doing is building this concept into a complete multi-level system with the native encryption components. In aggregate, the solution should facilitate Enterprise Content Management (ECM) and Team Virtualization (eTV) using Microsoft technologies as the institutional foundation using partitioned layers of classification as well as native encryption features. The purpose of the encryption functions with Microsoft Office Server System will be to provide practical applied cryptographic functions (again, taking into account instruction level parallelism and memory bandwidth) while maintaining the two most important concepts to cryptography, privacy and correctness. Below is my example SharePoint WebPart that I have been playing around with.

(Select Image To Expand)

I started to push the data back and forth between list items and as I expected, the universal issue of not gathering encrypted items was encountered. I am pretty sure I can get around this with floated carrying key tokens however, so that the gatherer will basically have a Skelton key to the documents that it wishes to implement full-text indexing against, which although will need to be looked at for security vulnerabilities, is really the only feasible solution that comes to mind. I think for most organizations, this will be a good solution. Although I was just pushing the data back and further programmatically, I plan on making the encryption option a item-level context menu or something along those lines.

As always, good security software is always open-source. When this project (which, for the paper / research thesis is taking on the name CryptoCollaboration) becomes production and has been somewhat tested for my grading, it will be released to the public open at no cost, probably under a GNU license.

Share

Formal Security Models and SharePoint

Formal Security Models and SharePoint

A security model is an abstract layer to security that provides multiple levels of security in which a user cannot read or manipulate data through the user of tiers. Security models are based on principles of creating multiple levels of objects and subjects, by which there can be a conceptual approach made to securing SharePoint.

Bell-LaPadula (BLP) Security Model

BLP is a security model that relies on the overlying concept of state machine concepts, and focuses mostly on the C on the CIA triad.

By leveraging the concept of state machines is that a machine change can only occur at discrete points in time and that when the state of a machine can only be altered by a state transaction.

This allows the environment to capture itself in its initial state where it is considered healthy and secure, and repeatedly capture the snapshots of the machine which are its states. This allows analysis of machine as to whether a state transaction has placed the machine in a insecure state, and ensures that the machines starts securely, commit actions securely, and allow objects to be manipulated in a secure state.

The way that the model works is:

  • No reading from lower levels to upper levels
  • No writing from upper levels to lower levels

Data can move between various levels, however how this data is moved is defined by transition functions. These functions ensure that the initial security state of the data is maintained, and the destination security state can also be considered concerned.

There are three multi-level properties that exist in he BLP model:

Discretionary Security Property (DS) specify the discretionary access control by using an access matrix

Simple Secure Property (SS) transition function that states that a subject trying to access an object at higher level is not permitted

Star Property transition function that states that a subject trying to write down to an object at a lower level is not permitted

Leveraging this particular security model means that a user will not be able to push or pull various objects beyond their related security levels. This is particuarlly helpful within organizations that must maintain a classification system, since users will not able to write sensitive information where other users whom don’t meet the classification standard would be able to read it, as well users that are at a lower level are not able to directly access information that is beyond there classification level.

Biba Security Model

The Biba security model is in essence the opposite of the BLP system, since it promotes no reading down and no writing up. The transition functions of the Biba system are:

  • Simple Integrity A subject at a high level of integrity is not able to read the objects that exist at a low level of integrity
  • Star Integrity A subject cannot write objects from a lower level of integrity to a higher level of integrity

The way that the Biba model functions is on the concept that objects which spawn from a lower level of integrity can’t be pushed to a higher level which might pollute a higher level of integrity. By insuring that information can only travel from higher levels of integrity to those at a lower level, safeguarding the environment.

Clark-Wilson (C-W) Security Model

The Clark-Wilson model focuses on the I on the CIA triad. To promote the integrity of the environment, the Clark-Wilson model focuses on two main objectives:

  • Internal and external consistency
  • Managing changes for users, unauthorized users should make no changes and authorized users should not make unauthorized changes

The central portion that builds the C-W model is the need for consistency, as stated in the above there are two types of consistency that exist:

  • Internal Consistency Security policies of the operating system that are related to SharePoint
  • External Consistency Internal state of the system as it related to end-users that are controlled by either SharePoint or other software products.

There are two main operations that provide the basis for the C-W model:

Separation Of Duties (Promotes External Security) By having a true separation of duties for users, it can be ensured that not one person has complete control over a system and that there are always failover mechanisms that are in place

Well-Formed Transactions (Promotes Internal Security) Data or data processes is never directly controlled by users, however they have access to applications that can manipulate these assets. It is important to note that the user will never have access to the data directly.

Share

SharePoint Server Hardening Policy Template

Introduction – SharePoint Server Hardening Policy SharePoint servers are depended upon to deliver business data in a secure, reliable fashion. There must be assurance that data integrity, confidentiality and availability are maintained. One of the required steps to attain this assurance is to ensure that the SharePoint servers are installed and maintained in a manner that prevents unauthorized access, unauthorized use, and disruptions in service.
Purpose The purpose of the [Organization] SharePoint Server Hardening Policy is to describe the requirements for installing a new SharePoint server (whether front-end web, job, index, or database) in a secure fashion and maintaining the security integrity of the existing SharePoint servers and application software, both standard as well as purchased components.
Audience The [Organization] Server Hardening Policy applies to all individuals that are responsible for the installation of new SharePoint property, the operations of existing SharePoint property, and individuals charged with SharePoint security.
SharePoint Server Hardening Policy
  • A server must not be connected to the [Organization] network until it is in a [Organization] accredited secure state and the network connection is approved by [Organization].
  • The SharePoint Server Hardening Procedure provides the detailed information required to harden a SharePoint server and must be implemented for [Organization] accreditation. Some of the general steps included in the SharePoint Server Hardening Procedure include:Installing the Windows server operating system from an [Organization] approved source
    Applying Microsoft SharePoint and other relevant supplied patches, service packs, and hotfixes.
    Removing unnecessary software, system services, and drivers
    Setting security parameters, file protections and enabling audit logging
    Disabling or changing the password of default accounts
  • [Organization] will monitor security issues, both internal to [Organization] and externally, and will manage the release of security patches on behalf of [Organization].
  • [Organization] SharePoint administrators will test security patches against [Organization] core resources before release where practical.
  • [Organization] may make hardware resources available for testing security patches in the case of special SharePoint applications and update.
  • Security patches must be implemented within the specified timeframe of notification from [Organization].
SharePoint Server Hardening Policy Supporting Information
  • All SharePoint software programs, SharePoint applications, Web Part / Application source code, Web Part / Application object code, documentation and general operational data shall be guarded and protected as if it were [Organization] property.
  • The department which requests and authorizes a SharePoint application (the site / application owner) must take the appropriate steps to ensure the integrity and security of all SharePoint Web Parts and application logic, as well as data files created by, or acquired for, SharePoint applications. To ensure a proper segregation of duties, owner responsibilities cannot be delegated to the SharePoint server custodian.
  • The [Organization] SharePoint network is owned and controlled by [Organization]. Approval must be obtained from [Organization] before connecting a device that does not comply with published guidelines to the network. [Organization] reserves the right to remove any network device that does not comply with standards or is not considered to be adequately secure.
  • [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