ARB Security Solutions -- SharePoint Security -- Adam Buenz [SharePoint MVP]

Change Management For SharePoint Security Policies (Diagram)

Change Management For SharePoint Security Policies

Introduction - SharePoint Security Policy Checklist	The [SharePoint Portal Owning Organization] SharePoint Security Polices provide the operational detail required for the successful implementation of the SharePoint Security program. These security policies were developed based on, and cross referenced to, the Security Policy Standards. In addition these policies have been developed by interpreting HIPAA, and other legislation and legal requirements, understanding business needs, evaluating existing technical implementations, and by considering the cultural environment.
Changing Environment	The business, technical, cultural, and legal environment of [SharePoint Portal Owning Organization] , as it relates to information technology use and security, is constantly changing. The SharePointSecurity Policies will be revised as needed to comply with changes in law or administrative rules or to enhance its effectiveness.
Technology Neutral	These polices are technology neutral and apply to all aspects of information technology. Emerging technologies or new legislation however, will impact these practice standards over time.
Ownership and Approval	The SharePoint Security Polices are owned by [SharePoint Portal Owning Organization].
Change Drivers	A number of factors could result in the need or desire to change the SharePoint Security Polices. These factors include, but are not limited to: Review schedule New legislation Newly discovered security vulnerability New technology Audit report Business requirements Cost/benefit analysis Cultural change
Change Process	Updates to the [SharePoint Portal Owning Organization] SharePoint Security Policies, which include establishing new policies, modifying existing policies, or removing policies, can result from three different processes: At least annually, the [SharePoint Portal Owning Organization] SharePoint administrator, or designate, will review the SharePoint Security Policies for possible addition, revision, or deletion. An addition, revision, or deletion is created if it is deemed appropriate. Every time new SharePoint technology (webpart, site definition) is introduced into [SharePoint Portal Owning Organization] a security assessment must be completed. The result of the security assessment could necessitate changes to the SharePoint Security Policies before the new technology is permitted for use at [SharePoint Portal Owning Organization] . Any user may propose the establishment, revision, or deletion of any practice standard at any time. These proposals should be directed to the [SharePoint Portal Owning Organization] SharePoint administrator who will evaluate the proposal and make recommendations to the [SharePoint Portal Owning Organization] management.
Change Distribution and Notification	Once a change to the SharePoint Security Policies has been approved by [SharePoint Portal Owning Organization], or designate, the following steps will be taken as appropriate to properly document and communicate the change: The appropriate [SharePoint Portal Owning Organization] SharePoint administrator Security web pages will be updated with the change Training and compliance materials will be updated to reflect the change The changes will be communicated using standard [SharePoint Portal Owning Organization] communications methods (internal cable TV system, announcements web part, newsletters, and communications meetings)

SharePoint Security Policy Checklist

Introduction - SharePoint Security Policy Checklist	The SharePoint Server Security Policy Checklist provides a concise view of the state of [SharePoint Portal Owning Organization] security policy development and implementation for an organization.
Required Policies	The SharePoint Server Security Policy Checklist indicates which policies are required by default by [SharePoint Portal Owning Organization] and which policies are optional based on the SharePoint resources used by an organization. For required policies indicate “yes” in each column where the column heading indicates a true statement and a targeted completion date in each column where the column heading indicates a condition that has not yet been met.
Optional Policies	This portion of the SharePoint Server Security Policy Checklist is for those policy areas that may be required depending on the SharePoint resources in use for [SharePoint Portal Owning Organization]. For these policies examine the requirements statement associated with the policy. If the policy is required based on the requirements statement, complete the remaining columns as indicated above. If the policy is not required based on the requirements statement simply mark the Required column “no”.
Analysis Matrix	The Analysis Matrix .is provided as a tool to assist with the completion of the SharePoint Server Security Policy Checklist. This matrix describes security elements, gives an industry best practice of the intent of the security element, indicates where the policy for a security element is most likely to be documented, and provides locations to document dates and plans.

Policy Checklist	Required	Published	Approved	Adopted	Communicated	Revised

Acceptable Use	Yes
Account Management	Yes
Admin/Special Access	Yes
Change Management	Yes
Disaster Recovery	Yes
Incident Management	Yes
Password	Yes
Physical Security	Yes
Privacy	Yes
Security Training	Yes
Software Licensing	Yes
Virus Protection	Yes


Intrusion Detection · Required for networked environments.
Portable Computing · Required for organizations supporting laptops, PDA, or other portable devices.
Security Monitoring · Required for networked environments.
Server Hardening · Required for environments with servers.
System Development · Required for environments where software is developed
Vendor Access · Required for environments where access to or from entities external to organization is required. Outsourced maintenance, management, and network services must be considered.

Analysis Matrix Security Element	Industry Best Practice	Location	Last Revision Date	Implementation
Policy Development and Evaluation Process	Documented development process for the continual updating and review of security policies and procedures and compliance. Includes process for the continuous review and measurement of policy effectiveness.
Ethics Policy	Documented high-level statement of ethics standards.
Security Policies
Acceptable Use	Documentation presenting general guidelines defining scope, behavior, and practices for uses; monitoring of compliance; and polices pertaining to special access users.	Acceptable Use Policy
Account Management	Documentation requiring standards and procedures for the creation, distribution, revocation of user accounts.	Account Management Policy
Proprietary Information	Documentation establishing responsibility and appropriate measures for protecting proprietary information from disclosure or modification.
E-Mail Access and Use	Documentation presenting general guidelines defining scope, behavior, and practices for uses; monitoring of compliance; and polices pertaining to special access users.	Acceptable Use Policy
Escalation Procedures Incident Reporting Incident Handling Incident Investigation	Response plan for handling and resolving security incidents.	Incident Management Policy
Internet Access	Documentation presenting general guidelines defining scope, behavior, and practices for uses; monitoring of compliance; and polices pertaining to special access users.	Acceptable Use Policy
Portable Computing Policy	Documentation presenting general guidelines defining scope, behavior, and practices for uses; monitoring of compliance; and polices pertaining to special access users.
Passwords	Documentation requiring standards and procedures for the composition, creation, distribution, use, and revocation of passwords.	Password Policy
Privacy	Documentation establishing responsibility and appropriate measures for protecting private and personally identifying information. Minimum efforts may be required by legislation.	Privacy Policy
Security Training	Awareness and training program in information security and the protection of information resources for personnel who come in contact with sensitive resources.	Security Training Policy
Software Licensing	Documentation establishing responsibility and appropriate compliance measures.
Voice Mail Access and Use	Documentation presenting general guidelines defining scope, behavior, and practices for uses; monitoring of compliance; and polices pertaining to special access users.	Acceptable Use Policy Special Access Policy
Physical Security
Basic Physical Security	Controlled building access, mandatory access controls for information systems; policy for use of controls and penalties for non-compliance.	Physical Security Policy
Natural Disasters	Documented plan for the recovery of critical business functions in the case of flood, fire, loss of environmental controls, or power loss.	Backup/Disaster Recovery Policy
Data Access
Data Classification	Documentation policies and procedures for the classification, identification, and handling of sensitive information.
Data Retention	Documented policies and procedures for the archival and retention of sensitive data.
Disposal of Sensitive Data	Documented policies and procedures for the destruction of media containing sensitive data.
Integrity and Confidentiality	Controls for the assurance of data integrity, including those that pertain to confidentiality and privacy compliance policy.	Vendor Access Policy Security Monitoring Policy Virus Protection Policy
System Security Tools Intrusion Detection Security Monitoring Virus Detection	The use of audit controls and tools to periodically review security compliance.	Security Monitoring Policy Intrusion Detection Policy
Systems Development
Development Procedures	Documented policies and procedures governing acceptable standards of testing and documentation, as well as those for the lifecycle that places a system into production.	System Development Policy
Systems Administration
Responsibilities and Roles	Documented policies that define the roles and responsibilities of system administrators and their relation to the computer systems and network infrastructure in their care.
Contingency Planning
Contingency Planning	Documentation establishing responsibility for policies and procedures and mechanisms for the creation, testing, and revision of contingency plans for business critical systems.	Backup/Disaster Recovery Policy
Backup	Policies and procedures and mechanisms for the archival, retention, and recovery of data. Periodic testing of recovery schemes.	Backup/Disaster Recovery Policy
Off-Site Backup	Copies of backup media and logs are stored off-site in a secured facility on a regular basis. Policies and procedures exist governing the transfer and handling of media.	Backup/Disaster Recovery Policy
Maintenance
Equipment	Computer equipment is maintained in accordance with manufacturer’s recommendations. Records of faults or suspected faults are maintained. Critical systems are under maintenance contract in proportion to their significance.	Server Hardening Policy
Software	Policies and procedures for the monitoring of patch and vulnerability information sources, their review, remediation, and the creation of new baseline information for updated systems.	Change Management Policy Server Hardening Policy

SharePoint Security Policy Index

SharePoint Policy Template Index

SharePoint Security Policies are management instructions indicating a course of action, a guiding principle, or an appropriate procedure that is expedient, prudent, or advantageous. Policies are high-level statements that provide guidance to workers who must make present and future decisions. It would also be correct to say that these SharePoint policies are generalized requirements that must be written down and communicated to certain groups of people inside, and in some cases, outside, the organization. Although SharePoint security policies vary considerably by organization, they typically include general statements of goals, objectives, beliefs, ethics, controls, and worker responsibilities.

Policies are higher-level requirement statements than standards, although both types of management instructions require compliance. Policies provide general instructions, while standards provide specific technical requirements. SharePoint standards cover details such as systems design concepts, implementation steps, software interface mechanisms, software algorithms, and other specifics. Standards provide a measure for comparison in quantitative or qualitative terms. Standards would, for example, define the number of secret key bits required in an encryption algorithm. Policies, on the other hand, would simply define the need to use an approved encryption process when sensitive information is sent over public networks such as the Internet from your SharePoint environment.

Standards will need to be changed considerably more often than policies because the manual procedures, organizational structures, business processes, and information systems technologies mentioned in standards change so rapidly. This is in contrast to policies, which are intended to last for many years.

Policies are generally aimed at a wider audience than standards. For example, a policy requiring the use of computer virus packages would apply to all personal computer users, but a standard requiring the use of public key digital certificates could be directed only at staff that conducts organizational business over the Internet.

Policies are distinct from, and at a considerably higher-level than procedures, sometimes called SharePoint standard operating procedures (SSOP). Procedures are specific operational steps or methods that workers must employ to achieve a certain goal. A policy statement describes only the general means for addressing a specific problem. Policies should not become detailed or lengthy, otherwise, it becomes a procedure or can become too intermingled with procedures. For instance, in many information technology departments there are specific procedures for performing back-ups of server hard drives. In this example, a policy could describe the need for back-ups, for storage off-site, and for safeguarding the back-up media (using encryption, physical security, etc.). A standard could define the software to be used to perform back-ups and how to configure this software. A procedure could describe how to use the back-up software, the timing for making back-ups, and other ways that humans interact with the back-up system (how to get approvals by management, how to transfer the storage media to a transportation company, etc.).

One of the common problems observed in policy development and review involves the combination of policies, standards, and procedures in a single document. When it comes time to update the document, the process is needlessly time-consuming and confusing. This is because the three different types of documents all have different levels of detail and focus on different things.

The combination of policies, standards, and procedures in a single document is also not recommended because it can make the location of relevant information much more difficult for the reader. This combination approach also is inefficient in terms of distribution because a lot of irrelevant information is sent to people who really don’t need it. To simplify document maintenance, usage, and cross-referencing, be sure to use separate documents for policies, standards, and procedures.

Policies are also different from controls (also known as countermeasures, security measures, and safeguards). A control is a device or a mechanism used to regulate or guide the operation of a machine, apparatus, or system. An example of a control would be encryption of sensitive data stored on floppy disks. In many cases, policies provide broad objectives that are met with controls. For instance, a policy prohibiting actual or apparent conflicts of interest could be partially met via a control requiring employees to sign a statement indicating they have read the code of conduct and agree to comply. Likewise, in many instances, control measures are dictated directly by policy. For example, a requirement to sign a statement of compliance with a code of conduct might itself be a policy.

In general, policies state the areas on which management attention should focus. For example, a policy might dictate that all software be fully tested before being used for production processing. Management, in most instances, will need to make a number of decisions about controls in order to meet the requirements of a policy. For example, the control measures in support of this testing policy could include software change control systems, a standard development process methodology, documentation standards, and a set of standard testing procedures. The policy may be deliberately vague about the control measures to be used so that management retains the latitude to change controls as evolving technology and business conditions dictate.

Policy Templates

	SharePoint Portal Server Acceptable Use Policy Template
	SharePoint Portal Server Hardening Policy Template
	SharePoint Portal Security Training Policy Template
	SharePoint Portal Security Monitoring Policy Template
	SharePoint Portal Physical Access Policy Template
	SharePoint Portal System Development Policy Template
	SharePoint Portal Vendor Access Policy Template
	SharePoint Portal Account Management Policy Template
	SharePoint Portal Administrator / Consultant Access Policy Template
	SharePoint Portal Password Policy Policy Template
	SharePoint Portal Privacy Policy Template
	SharePoint Portal Backup/DRP Policy Template
	SharePoint Portal Intrusion Detection Policy Template
	SharePoint Portal Incident Management Policy Template
	SharePoint Portal Computer Virus Detection Policy Template

Using SharePoint to Build SOA (Services Oriented Architecture)

Definitions

SharePoint as a communications and collobration solutions provides robust faculities to build out scalable and extendable architectures that conform with SOA. We will begin by defining how we use the information architectures terms, information management, document management and content management. Because these terms are considered interchangeable concepts, it is best to clarify the definitions as followed:

Document Content – Typically, the human mind tends to separate a document from the actual contents. So for example, instead of saying, “I read what you wrote” we are saying, “We read the document”. Therefore, we are conveying that we not only saw the document, but we also read the contents.

Document Containers – Because of the existence of computers, the human mind has begun to regard documents and files as two different items. Instead of saying “The data is in that file” we say “The required data is contained within that document”. We have begun to distinguish between the container and the document.

Document Vehicles – The document has become a mode of transportation of its content. The age of electronic files or documents, allow for easy transportation via email. So now instead of searching for specific information to send electronically, you can send the entire document electronically.

In the above three descriptions you found three different document concepts. These documents could hold digital images or information; however, if there is no context within the document, it is nothing more than a data collection. Because of this analogy we have come to define the document as, a container that serves as an information vehicle, stored in a SharePoint document library. In regards to building our information architecture with SharePoint which can leverage the XML web service asset, when you have a document it is a river of characters, the structures internally come to serve as and information vehicle in regards to the data contained in the characters.

The main issue that causes a problem is that the human mind tends to be far too restrictive when it concerns the definition of a document. We appear to understand a document as something that is written on a piece of paper or that of its equivalent electronically. What is being described is that a document is not limited; it can mean a wide variety of things such as, instant messages, forum messages, e-mails, processes, graphics and many other forms of data.

You see, information that we gather is usually only derived from the typical document in small quantities. We tend to gather and learn more information in regards to other means such as meetings, discussions and email. We tend to only strive to learn what they give us, we typically do not step outside of context to gather information. Items such as a sales report, emails or a meeting can all contain knowledge that can be extremely valuable.

In general, companies tend to offer a variety of manuals, guidelines and visual guides that are written to guide a user in the direction of the way the company would like to run. This helps to ensure that nothing can be forgotten or left out because the documentation is always present. It is true that people tend to retain knowledge with the use of visual aids, this means not only the printed or written words but holds true for images as well. We develop visual cues that is geared to guide us with reading as well as maintain and understand the information. Cues are used as signals in understanding the information in a way that the creator has intended. For example, within a document if the creator emphasizes a word using Bold, Italics or Underlining it will draw the reader’s attention to the specific area. If a writer were to do all three at once, this would let the reader know to pay particular attention to that sentence.

When we use visual aids within the structure of a document we are enabling the mind to process it and understand the content at a better rate. However, it is important to use these visual aids with caution, the format requires that the reader be able to recognize the cue and understand it. When using written words in your document structure, people generally make use of captions, emphasis, titles and headings, these are things the mind typically understands. For other documentation, the reader may need to be able to understand the vocabulary that is used within the document. For example, a computer, if you use a workflow diagram, the computer will not understand the cues you are giving it. It will need to know what to do when it encounters this vocabulary as well as how to recognize it. This is the same scenario as markup, you are giving the processor a cue to the action or actions you need it to perform on the content.

Management of content requires information to be organized in an upstream manner. This has to occur in a way where the individual ingredients of the content is able to keep each identity until the time of use. Doing so will allow the client to individually choose them or the ability to combine them when they feel it is necessary. This type of organization creates a clear and precise choice for the user, as well as allowing the information to be configured in a different manner for reuse.

We will now take a look at a few topics that are closely related to each other, these will include upstream content organization, then we will investigate the impact they have on authors.

Structure plays an important role in all types of documentation. For instance, when sending an e-mail to a colleague or client we will structure it in such a way that is appealing to the reader. We will spend time thinking of a title that is catchy and give great thought to the recipients of the e-mail. Rather you know it or not, this is structuring.

When looking at it in terms of content management, we but begin to understand that the text within the document cannot be a group of characters, instead we must understand that the content is made up with the following:

Specific content building blocks or pieces of information
A reference or references of other pieces of information with the same content or outside of it.
Specified rules that state how the blocks can be created and the configuration of the content.

Packaging is just as important, each block of information must have a package that will allow the information to be stored, delivered, and moved without losing any of the content or damage to the content. In general, every block of information must have the ability to be independent, if the information is generally part of a whole, the relationship of all aspects needs to be known.

Packages that we create typically share properties and characteristics that are important to each other. It is important to maintain predictability with any type of content processing. You must be able to understand and describe the characteristics so offer this predictability. To better understand this, consider a word processing package template. In order to maintain a certain model of use, you must pay close attention to all particular details. By leveraging SharePoint and SharePoint XML web services, you are allowing this type of predictability that is needed.

This type of packaging and content are made useful in a variety of aspects in the world today. Many people create various items for users such as, form letters, templates and models. These are typically provided bundled with an application or the user will have the ability to create their own structure using any tools that are built in the application, for example, application programming languages or macro editors. When a user conforms to any of these molds they are establishing structure, that are similar to database form fields, and all of the content becomes managed within the mold. No matter the tools used or the approach that is used the goal remains the same:

The ability to eliminate tasks that are repeated when creating text of similar structure
The ability to maintain control over the way the information is provided.

The molds are typically created to use with presentations, however many people feel they are used to receive content that is predefined and of a type that is expected. In general, these are created prior to the texts that are to use them. It is important that if you should find yourself using a structure feature that is provided by a commercial package of word processing, that you be certain to use design features instead of default. Specifically, you should try to map their use with the structure within your content.

One of the first steps to take in regards to content management is to knowledge molds that any enterprise would use or create. It must be understandable, because if the content is not created correctly the first time, time has just been wasted because of the damage repairs.

Here are some important things you should remember:

Be certain the content works well with the mold. If it does not work, you should not break the mold, search for another mold that will allow the content to work well. For example, if you have a mold that is created for an email you will not be able to fit a sales report into that mold.

Be certain that contents can still be identified by the ingredients, a user should be able to specifically identify an area of text that give a description of your process or holds your forecast in sales.

Knowledge molds should create an environment for an author that will allow them to be concentrated on the content instead of the structure. Additionally, it should provide support in the areas of validating and adding any information in regards to reference.

Proper labeling will allow for a package to be identified in the proper manner. It is important to note that even though the labeling and packaging may be clear, it does not allow for identifying the quality of the content. It is important to understand and manage how your content will find the way into the package. You will need to manage who is allowed to put the content in, how to apply the quality controls, a required sell by date and what will allow you to determine that the content processing is completed.