I Actually Like CAPTCHA

So I worked on the CAPTCHA field control last night, and got enough to where it compiled correctly (after its conversion from a WebPart), and actually deployed it alright. I still have some cleanup to do since I would rather reduce the code bloat that is in right now left over as remanants from the intial WebPart idea. Either way it worked, so I am happy.

So I sent it out to a friend last night in Arizona since he is generally pretty forgiving if I break something in his system, somewhat important since I really didn’t test that much outside of my local VM development environment. While it worked ok, he basically said he just plain doesn’t like the idea of CAPTCHA.

His basic reasons behind not liking it is because CAPTCHA images become increasingly difficult to read (due to text warping), and posting a comment can start to become a battle when trying to start a discussion. His main point is that the verification system should begin interrogation on the machine, not with the user.

I agree and I disagree with his statements. The CAPTCHA field control is meant as a first step in the right direction, and is something that will always be under development. Eventually, the SBSP bundle (which includes the CAPTCHA control) will include more elegant, neat solutions. One that I had in mind is a cryptographic solution that instead leverages AJAX or something similiar for verification. On a certain time increment, SharePoint will select a chunked number request (similiar to something like a GUID). When a listform page is called from a SharePoint site object, the AJAX call will firstly run decryption routines on itself, then on the stored GUID, and retrieve the GUID value which does some general pattern matching. No match, no comment post. Time-outs would also be clutch to ban IP’s.
These things are planned, however will not be built into the first release of SBSP. They will eventually be there though.

Share

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

What is ISA server, and what does it have to do with SharePoint?

 

* This article was written in the context of Internet Security and Acceleration (ISA) 2006, a technology now considered deprecated with the introduction of Forefront Threat Management Gateway (TMG). Variations may exist. *

The Several Hat of the SharePoint Administrator

 

Often times, one person is tasked within an organization to be responsible for several platforms. If you have MOSS 2007, you also might have a range of other sister server platforms such as EPM, DPM, LCS, MIIS, or a variety of supplementary Microsoft platforms. The one server that is characteristically common within an external, as well as internal, facing SharePoint deployment is ISA server 2006 for its inherent security routines and web caching solutions, along with several other security options that can be typically of interest to SharePoint administrators such as honey pots and intrusion detection systems.
 
What is ISA server 2006?
ISA Server 2006 plays a very vital role with your enterprise, particularly when leveraging its security framework with your communications and collaborations platform since business critical data and enterprise processes will eventually be housed there. In relation to SharePoint, the main feature that we are looking to implement will be secure application publishing, in the current circumstance, MOSS 2007 (or SharePoint 2003 if currently not planning on an upgrade). It is important to realize that ISA has several other purposes and applications within an enterprise, however since the context of this site is SharePoint security, the main focus will be on leveraging ISA to securely use a SharePoint framework.
 
Mitigating Risks Leveraging ISA Server 2006 in Regards To MOSS (SharePoint 2007)
As part of any integrated security planning and implementation, it is necessary to take certain precautions to mitigate several risks to protect your corporate network. Implementing SharePoint within your environment can have several implications, depending on the context of what features an organization seeks to gain out of a SharePoint rollout. However, it is clear that several legacy business processes when it becomes a de facto standard within an organization will be placed moved from paper to electronic, streamlining them, but also placing them in a container with more points of access for an attacker to take advantage of. Bring processes out of the physical realm a majority of the times will cause more visibility into them, therefore bringing other points of access for an attacker to expose. This becomes increasingly important if you have any type of compliance or regulatory issues that will effect your business operations, SOX and HIPPA being the most common in relation to SharePoint and because SharePoint is so common within the healthcare field. This by no means implies that there aren’t other regulations to consider when implementing SharePoint, specifically within governmental and financial fields (such as consideration of the US Patriot Act), all of which should be examined prior to the rollout to ensure complete compliance upon initialization of the implementation.
 
Protecting Against Exposure in Regards to MOSS Mobility Controls
Because of the built in mobility controls with SharePoint, this risk becomes even greater since it will allow you to expose your portal at a more granular and prevalent level (those directories that exist within /m), carrying its own application richness nevertheless its own implications. Combining this valuable mobile functionality with the probability with a new external (or internal portal that may face attacks) facing functionality leveraging the numerous new SharePoint authentication controls (authentication in MOSS has more internet style controls), there is a higher possibility that an attacker will try to take over your portal.
 
Why Even Attack SharePoint? 
So why is SharePoint a lucrative attack point for a person with malicious intent to gain access into, and possible corrupt. There are two main points of interest from an attacker standpoint in relation to SharePoint. Since SharePoint plays the role of an information repository, an attacker could potentially desire to gain business information for a multitude of arbitrary reasons. This could range from a lot of different points of interest, from blackmailing a company to gain this information back to a secondary company getting a competitive advantage onto another company. The second main reason is corporate espionage, taking down SharePoint, on a large scale could cause business interruptions, massive loss of data, or a platform to attack other sister server systems that might house the same type of sensitive information. For example, with the archiving agent with Live Communication Server it is feasible that once an attack gains a point of entry within the SharePoint environment that they may also have access to these archived records, which could expose a business further, or have an employee possibly covering their tracks from past malicious intent.
 
What Are the Benefits of Implementing ISA server with SharePoint?
  1. Enabling and monitoring access to SharePoint
  2. Implementing cryptographic solutions
  3. Leveraging Web Farms and Load Balancing
  4. Providing Secure and Fluid External Access to your SharePoint Portal
  5. Implementing Several Types of Access Such As Smart Cards and Biometrics
  6. Track User Traffic
  7. Implement Plug-ins such as Intrusion Detection, Honey pots, and Other Functionality
What are the benefits of leveraging ISA server 2006 with SharePoint 2003 or MOSS (SharePoint 2007)? There are several, in regards to SharePoint there are clear hooks that exist between SharePoint and ISA that allow you to face your portal in a variety of fashions depending on your corporate need. One of the largest problems when leveraging ISA server 2004 was that although the process of setting up listeners and routing was straightforward, SharePoint implementations were never very generic and varied to heavily for a standardized process, however with ISA server 2006, publishing your communications and collaborations network including exchange and ISA server are extremely simple.  The second largest problem was setting up a secure implementation that leveraged a certain level of cryptographic methods, most notably SSL. However, as attacks become more sophisticated, it becomes possibly to implement cryptographic cloaking which can overcome packet inspection at the firewall level, compromising communications. However, ISA server with advanced SSL bridging allows an administrator to further protect a network while maintaining stateful packet inspection. Thirdly, SharePoint implementations often take advantage of sophisticated farming solutions that can exist in the amount of n servers, Web Publishing Load Balancing can make this easier to execute with a SharePoint environment. Fourthly, facing a SharePoint portal externally for 24×7 employee access is fairly common since it becomes a platform to build virtual teams with throughout the enterprise. This poses a multitude of problems, including but not limited to several windows of access (multiple logins) and pass-through link translation from multiple levels. ISA provides mechanisms to solve all of this, to ensure constant and fluid access to your SharePoint Portal at all times. Fifthly, providing mechanisms for several types of access, such as those with Smart Cards, is necessary within several organizations, particularly those within the governmental sector. ISA helps to translate these authentication types into your portal so that the facilities exist so that there are adaptable ways to authenticate to the portal. Sixthly, maintaining inspection and providing mechanisms to properly troubleshoot ISA, and authentication to your portal related problems, usually requiring using tools such as the SSL diagnostic tools or other third party products. ISA provides interfaces to your requested and responded packets so that you can properly implement and repair any issues that may arise within your network related to your security and web caching solution so that you can ensure that your portal is always secure, yet available. Seventhly, and lastly, ISA provides mechanisms to monitor and report on traffic within your SharePoint portal so that as a SharePoint administrator at all times you can watch traffic footprints and report on any problems as they may arise. These ISA interfaces are not technically difficult to invoke and massage to gain insight to certain activities, ensuring security of your portal at all times and providing faculties by which a SharePoint administrator can report on portal activities.
 
Maintaining Stateful Packet Inspection
One of the largest security mechanisms used with corporate network security in regards to publishing SharePoint servers is packet inspection through HTTP protocols, it is pretty default or is hopefully part of the current network configuration. This is related to the firewall level, and therefore is not typically aware of malicious activity at the application level, so therefore is indifferent to any type of attacks that would happen against your SharePoint environment at that particular level. The main feature that we need is stateful packet inspection that will promote application layer filtering mechanisms since this will make our security configuration more aware of our communications and collaborations platforms.
Share