Many organisations, taking SharePoint on for the first time, opt to go for a single server instance deployment of SharePoint. However, they find it easy to forget in the heat of getting a single SharePoint production environment deployed, that without defining a fully available topology that one may be creating a single point of failure scenario.
This is because the application, services and data is located on one server, which then leads to a serious risk of no SharePoint availability to the user-base if that server becomes unavailable.
Yes, SharePoint can have all services running on one server, however security and availability is a key facet in ensuring an effective and productive platform. In too many cases still, organisations adopting SharePoint for the first time start from a single server platform. Why? Maybe they wish to ‘trial’ SharePoint features, or maybe even because the budget is not enough to stretch the architecture, or perhaps because capacity planning was not done in the outset. Additionally, these are not scaled out to handle the increased user-base and/or their requirements. Whatever the reason, there is critical availability risk.
Considerable publicity has been given in recent years to the lack of security definitions and policies concerning the security of assets relevant to Content Management Systems (CMS). Because of the centralisation of assets into these CMS’s it has become more and more apparent that the risks to organisations have grown. And SharePoint, being a centralised collaborative technology means that more connected and critical assets.
Therefore, it’s no surprise that this has made organisations more conscious of the need to make their SharePoint systems more available. Most breaches of availability, however, are not dramatic; rather, they are minor incidents, errors and omissions which can accumulate into serious losses, if they occur regularly. It is a responsibility to consider architecting SharePoint which are more secure against such events.
An organisation can state they have a 100% available SharePoint environment if neither its ability to attain its corporate objectives nor its ability to survive can be adversely affected by an unwanted event. An organisation may be secure against some threats, but insecure against others. No organisation can be 100% secure, however, much planning is undertaken and much money is spent on countermeasures. Any organisation, or indeed any person, is liable to suffer from unwanted events.
SharePoint system security can be defined similarly. A SharePoint installation is a combination of many assets and resources (e.g. hardware, software, people, data, procedures, infrastructure facilities) designed to perform and provide collaborative services to the business. A SharePoint system is secure against say a particular threat (e.g. fire in the communications room where your production SharePoint environment is located) if countermeasures have been taken to reduce to an acceptably low level the amount of loss which the threat may be expected to cause (e.g. the same SharePoint environment is replicated either via Storage and/or Physically located in another building) over a given period of time (e.g. a week). There are three types of loss which an organisation does not want its SharePoint system to suffer:
- Loss of availability and/or
- Loss of integrity (i.e. accuracy)
- Loss of high impact content
Whilst some of the SharePoint sites may not contain anything which is considered high impact, but even so, the first and second applies to any site. A loss of availability, integrity of confidentiality, whether accidental or deliberate, whether for a short or long time, will adversely affect organisational effectiveness, productivity and much more.
A threat to Sharepoint is any event whose occurrence would adversely affect one or more of the assets or resources which make it up. For example, what happens if all of a SharePoint farms SQL content databases are stored on one SQL server which isn’t backed up? What happens if all SharePoint services are running on one server and that server suffers a disk crash? What happens if the DNS server is unavailable? What happens if someone deletes an important file in a document library and no one notices for over a month?
Each of these assets is threatened by one or more of the following unacceptable events:
- Interruption
- Disclosure
- Modification
- Removal
- Destruction
And these unacceptable events can happen accidentally or be deliberately contrived. Thus, there is a large number of ways in which the security in a collaborative and such an integrated platform such as SharePoint. Examples of some of the possible breaches of security are:
- Accidental interruption of communication
- Accidental destruction of hardware
- Accidental modification of software
- Deliberate removal of programs
- Deliberate disclosure of information
There are three other categories of accidental threat:
- Those involving the malfunction of some component (e.g hardware or software fault), as opposed to an accidental misuse of a component (which is a threat caused by a person)
- Those which occur naturally and which damage or destroy equipment, buildings and other physical assets. Floods, hurricanes, fires, snow, ice, earthquakes etc. belong in this category.
- Those which affect people and their capacity to do their normal work, Death, injury and disease belong to this category.
Where to begin
Therefore, in working with the business there needs to be a review of the SharePoint platform, and focus on any instances of its design for all possible breaches of security (i.e. all events, both deliberate and accidental, which can adversely affect the assets of SharePoint) and develop a strategy to prevent or minimise losses to the organisation as a result of any breach. Here’s a number of things that should be done:
- Get a list of all assets in your SharePoint platform.
- Where is the capacity plan – if you have not done this, do it, if you have it, review it critically. You are looking for any points where there could be a fail – look not just at the SharePoint servers, look beyond to ISA, AD, DNS, Exchange, SQL. Look beyond into Search connections, external contact sources. Examine your firewall and proxy. Examine third party connections; for example, Web applications that have their own functionality that may impact on SharePoint.
- Once you have identified these, list against each all possible known failure points. Review issues concerning connectivity to these services. Dig up and audit logs concerning a failure to connect and document them. Audit all backups and schedules – identify a priority backup path.
- Examine the sites, list those which have critical / confidential / both, contact the owners and get a business SLA recovery identification. Define your topology to ensure high impact content can be provided in the event of a disaster. Review the server provision of your SharePoint environment and plan to scale as necessary/
- Create a risk management plan; now that you have identified known threats (and please note the list is NOT exhaustive); now is the time to select countermeasures for each issue.
- Implement; Review, Review and Review again. Your SharePoint instance will grow; you must ensure that your SharePoint Security plan grows with it.
This area is pretty much overlooked, but is vitally important because of the increased scale of Social Networking and the development of CMS platforms, particularly SharePoint in being in the centre of a vastly connected infrastructure in an Enterprise. The major concerns of any security policy (i.e. avoidance of errors and recovery in the case of a breakdown) are not in any sense new; they are an essential part of any system.
