deg sharepoint & .net application hosting standards & policies

1 DEG SharePoint & .Net Application Hosting Standards & Policies

DEG SharePoint & .Net Application

Hosting Standards & Policies


Document History

Date Version Author(s) Description30/12/2010 0.1 Farouk Sabry Initial draft for review and discussion

02/02/2011 0.9 Farouk Sabry Reorganizing the document contents andadd the items in a form of Checklist

13/02/2011 1 Farouk Sabry Juma comments are updated09/03/2011 1.1 Aliasgar Khozem Contribution from Development Team13/3/2011 1.2 Ahmed Kamal Add the Business Standards and Policies

13/3/2011 1.2 Abdul Nasser Ahli Review the Business Standards andPolicies Part

31/03/2011 1.3 Farouk Sabry Adding minor points and clarifications toInfrastructure part.

Approval list

Date Name Title Signature


Table of ContentsTable of Contents ..........................................................................................................................................3

1 Introduction...........................................................................................................................................5

1.1 Purpose and Scope........................................................................................................................5

1.2 Audience........................................................................................................................................5

1.3 Assumptions ..................................................................................................................................5

2 Business Standards & Policies ...............................................................................................................6

2.1 Business requirements standards .................................................................................................6

2.1.1 Business requirements content.............................................................................................6

2.2 Website Standards and Guidelines .............................................................................................10

3 Development Standards & Policies .....................................................................................................10

3.1 SharePoint Standards & Policies .................................................................................................10

3.1.1 General ................................................................................................................................11

6.1. ..........................................................................................................................................................11

3.1.2 Security................................................................................................................................12

3.1.3 Session management ..........................................................................................................13

3.1.4 Validation ............................................................................................................................13

3.1.5 Sensitive data ......................................................................................................................13

3.1.6 Exception handling ..............................................................................................................14

3.1.7 Branding ..............................................................................................................................15

3.1.8 Quality Assurance................................................................................................................15

3.1.9 Deployments .......................................................................................................................16

3.1.10 Solutions..............................................................................................................................16

3.1.11 Features...............................................................................................................................16

3.1.12 InfoPath ...............................................................................................................................17

3.1.13 Source Control.....................................................................................................................17

3.1.14 Web parts ............................................................................................................................17


3.2 .NET Standards & Policies............................................................................................................18

3.2.1 Auditing and Logging...........................................................................................................19

3.2.2 Authentication–Forms.........................................................................................................20

3.2.3 Authentication–Windows....................................................................................................21

3.2.4 Authorization.......................................................................................................................21

3.2.5 Code Access Security ...........................................................................................................22

3.2.6 Data Access..........................................................................................................................22

3.2.7 Exception Management ......................................................................................................23

3.2.8 Input/Data Validation..........................................................................................................23

3.2.9 Impersonation/Delegation ..................................................................................................24

3.2.10 Parameter Manipulation .....................................................................................................24

3.2.11 Sensitive Data......................................................................................................................25

3.2.12 Session Management ..........................................................................................................25

3.2.13 Deployment Considerations................................................................................................26

3.2.14 Communication Security .....................................................................................................26

4 Infrastructure Standards & Polices .....................................................................................................28

4.1 Documentation............................................................................................................................29

4.2 Hosting Environment...................................................................................................................30

4.2.1 Security................................................................................................................................31

4.3 SharePoint Deployment Process .................................................................................................31

5 Appendix A: Environment Specifications ...........................................................................................33

5.1 Testing Environment ...................................................................................................................33

5.2 Production Environment .............................................................................................................33

6 References...........................................................................................................................................34


1 Introduction

1.1 Purpose and ScopeThe purpose of this documents it to define DEG standards and policies for SharePoint &

.Net hosting.

This document will give a brief about DEG SharePoint hosting environment and themethodology used for deploying any SharePoint web application. The audience might need toadd more security points beyond these recommendations or adapt them in other ways to meetthe up to date website and web server security.

This document may be used for enhancing security on existing and future Web server systemsto reduce the number and frequency of Web-related security incidents.

1.2 AudienceThis document, while technical in nature, provides the background information to help

readers understand the topics that are discussed. The intended audience for this documentincludes the following:

Web Application developers, when going to develop a secure SharePoint 2010 webapplication to be hosted on DEG servers.

Functional Team, they have to pass this document to the external departments orvendors and force them to follow the standards and policy items.

System engineers and architects, when designing and implementing Web Applications

Webmasters, when creating and managing Web Content

Security consultants, when performing security audits to determine information system(IS) security postures

Program managers and information technology (IT) security officers, to ensure thatadequate security measures have been considered for all phases of the website’s lifecycle.

1.3 AssumptionsThis document assumes that readers have some minimal operating system, networking and

Web server expertise.

The practices recommended in this document are designed to help mitigate the risks associatedwith SharePoint 2010 Web applications.

Whenever the word SharePoint appears in the document, it means SharePoint 2010 even it isnot stated.


2 Business Standards & Policies

2.1 Business requirements standardsThis section describes the mandatory and optional contents that should be included in the businessrequirements document written by the government department.

The eServices team will assure that the business requirements document contains the points asillustrated in the following table.

2.1.1 Business requirements contentSection Sub-Section Description Mandatory

/ Optional

Introduction background Introduce the Organization and describe itscore business and customers.

Explain why the need has aroused to developor redevelop the website at this stage.

Mandatory

Business Objectives Describe the important business objectives ofthe website in a way that is quantitative andmeasurable.

The value it provides to customers and to thebusiness.

Also include what should this website achievein order to be considered successful.

Mandatory

Customer or Market Needs Describe the needs of typical customers orwebsite visitors, including needs that are notyet met by existing systems.

You may wish to describe problemscustomers currently encounter that the newwebsite will (or will not) address and how thewebsite would be used by customers.

Optional

Suggested Launch Date Is there a date or special event that will drivethe “opening” date for this site?

If so then what is that date or event?

Optional


If not, what is the proposed schedule forlaunch?

Current State Analysis Describes existing website, domain, hostingand identifies limitations and problems. Usingpage layout along with its item descriptionmatrix.

Mandatory,ifapplicable

WebsiteSpecification

Type of Site Mention whether this is a portal, ecommerce,informational, promotional, survey, etc.

Mandatory

Stakeholders The website has a number of differentstakeholders -: (amend as appropriate)

- existing customers

- existing suppliers

- new/potential clients

- other

E.g. The main audience is…….

Mandatory

Language Specify whether the site will be in onelanguage or bilingual; specify how togglebetween languages needs to beimplemented.

Mandatory

Web design Divided into two main parts:

1. Look & Feel

Includes the graphic design for all webelements – such as Theme, color schemes,logos, scrolling and resolution, etc.Emphasize those elements that distinguish itfrom previous websites. Include those designelements that will be global over all pages ofthe site (logo, background, copyright, etc.

2. Page Layout

Details of the home page layout and thefollowing level pages (both informational andservices) structure should also be included.This section should include the graphicdesign of the page layout diagrams togetherwith the item description.

Mandatory


Refer to Website Standards and Guidelinesfor more details.

Site Structure Provide the details of how all the content fitstogether.

This logical hierarchical structure for pageswill dictate the names of the navigationbuttons and the linking between the variouspages on the web site.

It is also required to include site structurediagram(s) (site map).

Mandatory

Content Give an indication of type and expectedamount of content that will be included on thesite and how often it will change. E.g. the sitewill include:

- Text (number of physical pages…whatformat(s)?)

- PDF files (number and average size)

- Still photographs (number and format(s))

- Computer graphics (Existing… do you wantus to design/create them?)

- FLASH or Shockwave animations (numberand length)

- Video clips (how many…how much totaltime…what format?)

- Audio clips (how many minutes…)

- Other content types.

Mandatory

Functional features Include functional feature such as

1. Search requirements for internal andexternal searches.

2. Navigation requirements.

3. Notification requirements such email orSMS.

4. Other functional features like forums,discussion boards, RSS feeds and otherfeatures.

Mandatory


Secured Area Include details of secured area (passwordprotected access), if any.

Optional

Administration This is applicable only in case of customizedwebsite or portals, such as preferences,theme and skin changes and so on.

Optional

Non Functional Requirements List any known Non Functional Requirementsthat are imposed by the website owner suchas:

Hosting environment,

Content management.

Standards that have to be met,

Technology constraints,

Browser capability,

Security,

Accessibility,

Expected number of visitors/hits,

Performance,

Scalability,

Availability,

Content Migration from older site,

Integration requirements, etc.

Mandatory

WebsiteReleases

Scope of Initial Release Describe the intended major contents andfeatures that need to be included in the initialrelease of the website. Refer to the site mapdocumented earlier.

Mandatory

Scope of SubsequentReleases

If multiple phases of the website areenvisioned over time, indicate which contentand features will be deferred to later releases.

Optional

Limitations and Exclusions Identify any website features, components ortasks that the site owner might anticipate, butwhich are not planned to be included in thenew website. E.g. DEG will not beresponsible for content upload, etc.

Optional


2.2 Website Standards and GuidelinesThe website standards and guidelines for the Government entities are divided into four distinctcategories (Common Look and Feel, Website Content, Website Design, and General standards,guidelines, and issues) which all Government entities need to follow.

Some of the categories are more technical in nature than others and all efforts are made tokeep the content easy to understand for nontechnical audience.

Dubai eGovernment website standards and guidelines are explained into details in the websitestandards and guidelines documents, which are available in both Arabic and English languagesand can be downloaded from Dubai eGovernment Corporate website.

Arabic version :http://www.deg.gov.ae/SiteCollectionDocuments/Content/English/Websites%20Standards%20and%20Guidelines%202010%20_AR.pdf

English version :http://www.deg.gov.ae/SiteCollectionDocuments/Content/English/Website%20Standards%20and%20Guidelines%202010%20_ENG.pdf

3 Development Standards & PoliciesMicrosoft best practicing for security and code standards must be used for web applicationdevelopment. You can refer to the following links

Coding Techniques and Programming Practices

http://msdn.microsoft.com/en-us/library/aa260844(v=VS.60).aspx

Security Guidelines: ASP.NET

http://msdn.microsoft.com/en-us/library/ff649487.aspx

The developer must follow the code standards and best practices published by Microsoft forbuilding SharePoint web applications.

3.1 SharePoint Standards & PoliciesThis section organizes the code acceptance checklists by the following categories: security,session management, validation, sensitive data, exception handling, Web parts, documentation,and general software development best practices.

The development team will assure that the web application must pass the following checklist

http://www.deg.gov.ae/SiteCollectionDocuments/Content/English/Websites%20Standard

http://www.deg.gov.ae/SiteCollectionDocuments/Content/English/Website%20Standards

http://msdn.microsoft.com/en-us/library/aa260844



This section of the code acceptance checklist contains suggested items to help ensure thatsolutions that are submitted for deployment in SharePoint environment have been developed byusing best practices for software development.

3.1.1 General

Check Description

[ ] Assemblies include declarative security attributes (with SecurityAction.RequestMinimum) to specifyminimum permission requirements.

[ ] .NET Framework 2.0, 3.0, 3.5 or higher is used

[ ] Using a single .NET Framework version. Do not mix multiple versions.

[ ] The code is 64 bit compatible.

[ ] Your application does not try to directly access any SharePoint databases. Data stores in SharePointdatabases are only updated by using the SharePoint object model.

[ ] You avoid hard coding strings and labels. You use resources or language files instead.

[ ] When referencing the SPWeb or SPSite objects, you employ a using statement or, alternatively, youuse an explicit call of the .Dispose method to ensure proper use and disposing of the memory objects.

[ ] You use caching as appropriate to reduce unnecessary round trips. For Web parts, you expose thecache expiration (duration) as a Web part property.

[ ] When packaging your solution, you include a Code Access Security policy for the solution and, ifnecessary, include your assembly in the Safe Controls list though the solution.

[ ] When logging code, you use the Portal Log class to log the SharePoint Unified Logging Service (ULS)logs.

[ ] If you need to update multiple list items by using remote code, you use the Web service to update listitems. You only use SPListItem.Update() if you have to update more than one item at a time by usinglocal OM-based code.

[ ] When using the Count property of a SPListItemCollection, you only call it once and then store it in avariable that you can refer to when looping. You do not call it inside a loop.

[ ] The solution uses the AppSettings object to implement XML mapping. (This can be provided by usingthe settings persistence framework in .NET 2.0, 3.0, or 3.5.) The solution avoids creating custom XMLfiles and a strongly typed object for XML mapping.


[ ] Installation and deployment logging are provided in the event logs to enable appropriate operationaltroubleshooting during installation and un-installation.

[ ] Un-installation of a web package must remove any customization, Configurations and changes done byit.

[ ] Do not edit out of the box files

[ ] All new functionality and customizations must be documented

[ ] Site and list templates must be created through code and features (site and list definitions).

3.1.2 SecurityThis section of the code acceptance checklist contains suggested items to help ensure thatsolutions that are submitted for deployment in a SharePoint environment have been developedby using best security practices.

Check Description

[ ] The application uses an inclusion list (known, valid, and safe input) rather than an exclusion list(rejecting known malicious or dangerous input).

[ ] All user input is encoded when displayed to clients.

[ ] Plain text passwords are not present in Web.config, Machine.config, or any files that containconfiguration settings. Utilities such as Aspnet_setreg.exe and Trustee or the identity setting inAppPool on IIS 6.0 or IIS 7.0 are used to encrypt credentials.

[ ] If cookies contain sensitive data, they are marked secure.

[ ] Input surfaces in Web parts and other customizations include boundary checks, input data integritychecks, and appropriate exception handling to protect from cross-site scripting and SQL injection.

[ ] You avoid using AllowUnsafeUpdates. You use ValidateFormDigest() and, if necessary, use elevatedprivileges to interact with SharePoint objects. In cases where AllowUnsafeUpdates must be used, youensure that AllowUnsafeUpdates is set to False in your try-catch-finally block, or you use a Dispose()method (as required by the IDisposable interface) to avoid security issues.


3.1.3 Session managementThis section of the code acceptance checklist contains suggested items to help ensure thatsolutions that are submitted for deployment in SharePoint environment have been developed byusing best practices for managing sessions.

Check Description

[ ] Session state is strong, unpredictable, and protected from unauthorized access or replay attacks.

[ ] Session lifetime is limited to 30 minutes maximum of inactivity.

[ ] Session identifiers are not passed in the URL, and the ASP.NET feature, cookie less session, is notused.

[ ] The session state service is disabled if not used.

3.1.4 ValidationThis section of the code acceptance checklist contains suggested items to help ensure thatsolutions that are submitted for deployment in SharePoint environment have been developed byusing best practices for validating input.

Check Description

[ ] Input validation is applied at all identified entry points (including form fields, query strings, cookies,HTTP headers, and Web service parameters).

[ ] The ASP.NET validateRequest option is enabled, if possible.

[ ] Data is validated for type, length, format, and range.

[ ] Security does not rely on client-side validation. Instead, validation is performed on the server side.

[ ] The application consistently uses standardized input validation such as RegEx throughout.

3.1.5 Sensitive dataThis section of the code acceptance checklist contains suggested items to help ensure thatsolutions that are submitted for deployment in SharePoint environment have been developed byusing best practices for protecting sensitive data.


Check Description

[ ] The application does not log sensitive data in clear text.

[ ] Sensitive data is not stored in cookies.

[ ] Sensitive data is not stored in unencrypted, hidden form fields or query strings. It is maintained byusing server-side state management.

[ ] SSL, IPSEC with encryption, or application layer encryption prior to transmittal is used to protectsensitive data during transmission.

[ ] Sensitive data is not cached. Output caching is off by default.

[ ] Sensitive data that is transferred via e-mail uses S/MIME encryption or Information RightsManagement (IRM), depending upon the intended recipient.

3.1.6 Exception handlingThis section of the code acceptance checklist contains suggested items to help ensure thatsolutions that are submitted for deployment in SharePoint environment have been developed byusing best practices for handling exceptions.

Check Description

[ ] The application uses a standardized approach to structured error and exception handling throughout.

[ ] Error-handling code inherits from the SPException class to maintain a consistent SharePoint look andfeel for errors.

[ ] The application fails securely in the event of error and exceptions.

[ ] Exception conditions do not allow a user to bypass security checks to run privileged code.

[ ] The application returns generic custom error messages to the client.

[ ] The code uses exception handling. The code catches only the exceptions that you know about. Forexample, do not use try{} catch(Exception ex){} unless you throw the error again.

[ ] If code uses exception filters, it is not sensitive to filter execution sequence (filter runs before finally


block).

[ ] Application errors do not contain sensitive information or information that could be used to exploit thefault. .

3.1.7 BrandingCheck Description

[ ] A consistent user interface should be leveraged throughout the site. If a custom application is createdit should leverage the same master page as the site.

[ ] Editing out of the box master pages is not allowed. Instead, duplicate an existing master page, makeedits, then solution package the master page for feature deployment.

[ ] All Master Pages should have a title, a description, and a preview image.

[ ] All Page Layouts should have a title, a description, and a preview image.

3.1.8 Quality AssuranceCheck Description

[ ] Custom code must be checked for memory leaks using SPDisposeCheck

[ ] False positives should be identified and commented.

[ ] Provide an Installation Guide which contains the following items (Note this relates to SharePointDeployment Standards):

Solution name and version number.

Targeted environments for installation.

Software and hardware Prerequisites: explicitly describes what is all needed updates,activities, configurations, packages, etc. that should be installed or performed before thepackage installation.

Deployment steps: Detailed steps to deploy or retract the package.

Deployment validation: How to validate that the package is deployed successfully.

Describe all impacted scopes in the deployment environment and the type of impact.


3.1.9 DeploymentsCheck Description

[ ] All custom SharePoint work should be deployed through SharePoint Solution (.wsp) files.

[ ] Do not deploy directly into 12-Hive Folders. Instead deploy into a folder identified by Project Name

3.1.10 SolutionsCheck Description

[ ] Solutions must have a unique GUID within the farm.

[ ] Ensure that the new solution version number is incremented (format V#.#.#).

[ ] The solution package should not contain any of the files deployed with SharePoint.

[ ] Referenced assemblies should not be set to “Local Copy = true”

[ ] All pre-requisites must be communicated and pre-installed as separate solution(s) for easieradministration.

3.1.11 FeaturesCheck Description

[ ] Features must have a unique GUID within the farm.

[ ] Features with event receivers should clean up all changes created in the activation as part of thedeactivation routine.

[ ] The exception to this is if the feature creates a list or library that contains user supplied data. Do notdelete the list/library in this instance.

[ ] Features deployed at the Farm or Web Application level should never be hidden.


[ ] Site Collection and Site Features may be hidden if necessary.

[ ] Ensure that all features you develop have an appropriate name, description, updated version numberand icon.

3.1.12 InfoPathCheck Description

[ ] If an InfoPath Form has a code behind file or requires full trust then it must be packaged as a solutionand deployed through Central Administration.

[ ] If an InfoPath form does not have code behind and does not need full trust the form can be manuallypublished to a document library, but the process and location of the document library must bedocumented inside the form.

[ ] Just add the documentation text into a section control at the top of the form and set conditionalformatting on that section to always hide the section, that way users will never see it.

3.1.13 Source ControlCheck Description

[ ] All source code must be under a proper source control (like TFS or SVN).

[ ] All internal builds must have proper labels on source control.

[ ] All releases have proper labels on source control.

3.1.14 Web partsThis section of the code acceptance checklist contains suggested items to help ensure thatsolutions that are submitted for deployment in SharePoint environment have been developed byusing best practices for developing Web parts.

Check Description

[ ] Custom Web parts (including resource files) are contained within a SharePoint Feature and are


packaged as a SharePoint solution in order to be deployed.

[ ] The configuration of Web parts that are being deployed gives the administrator the flexibility ofdeploying to the Web application level or lower.

[ ] You use the SharePoint Web part infrastructure's standardized set of connection interfaces for Webparts to exchange information with each other at run time.

[ ] Source code for third party Web parts solutions, whenever possible, is provided with adequatedocumentation to ensure good technical support.

[ ] All custom Web parts utilize the SharePoint architecture to ensure consistent behavior across theapplication for functionality such as single sign-on, feature deployment, and so on.

3.2 .NET Standards & Policies

Check Description

[ ] Security decisions should not rely on client-side validations; they are made on the server side.

[ ] The Web site is partitioned into public access areas and restricted areas that require authenticationaccess. Navigation between these areas should not flow sensitive credentials information.

[ ] The identities used to access remote resources from ASP.NET Web applications are clearly identified.

[ ] Mechanisms have been identified to secure credentials, authentication tickets, and other sensitiveinformation over network and in persistent stores.

[ ] A secure approach to exception management is identified. The application fails securely in the eventof exceptions.

[ ] The site has granular authorization checks for pages and directories.

[ ] Web controls, user controls, and resource access code are all partitioned in their own assemblies forgranular security.

[ ] Pascal and Camel casing for naming identifiers are used. Hungarian Notation are not used

[ ] Abbreviations are used with care


[ ] Use Pascal casing for naming source files

[ ] Use appropriate prefix for each of the UI element

[ ] Each file shall contain a header block for copyrights ,file information, updates and changes

[ ] XML tags for documenting types and members are used.#region to group non-public members

[ ] Browsers compatibility is taken into account

[ ] Declare and initialize variables close to where they are used.

[ ] Always use the built-in C# data type aliases, not the .NET common type system (CTS)

[ ] Only declare member variables as private.Use properties to provide access to them with public, protected, or internal access modifiers

[ ] Declare read-only or static read-only variables instead of constants for complex types.Avoid direct casts.

[ ] Avoid creating recursive methods. Use loops or nested loops instead

[ ] Use the ternary conditional operator only for trivial conditions. Avoid complex or compound ternaryoperations

[ ] All flow control primitives (if, else, while, for, do, switch) shall be followed by a block, even if it is empty.

[ ] If you must provide the ability to override a method, make only the most complete overload virtual anddefine the other operations in terms of it

3.2.1 Auditing and LoggingCheck Description

[ ] Health monitoring is used for logging and auditing events.

[ ] Application is instrumented for user management events such as authentication success and failures,password resets, password changes, and account lockout.

[ ] Application is instrumented for unusual activity such as multiple login attempts and replayedauthentication tickets.

[ ] Access to significant business logic is instrumented.


[ ] Access to audit and log files are restricted, with application accounts having write access,administrative accounts having full access, and operators have read access.

[ ] Application and audit events are logged on separate protected server.

[ ] Events are logged with appropriate levels of information to reconstruct system activity.

[ ] High volume, per-request events are captured with performance counters.

3.2.2 Authentication–FormsCheck Description

[ ] Membership providers are used instead of custom authentication.

[ ] SSL is used to protect user credentials and authentication cookies.

[ ] If using SSL is not possible, the SlidingExpiration attribute is set to false and limited authenticationcookie time-outs are used.

[ ] User login information is validated using the Regex class and/or your custom validation code.

[ ] Hashed password format is specified in provider configuration.

[ ] Passwords are not stored directly in the user store; password digests with salt are stored instead.

[ ] Strong passwords policies are enforced.

[ ] Access to the credential store is limited to application account.

[ ] Authentication cookies are not persisted.

[ ] Authentication cookie is encrypted and integrity checked.

[ ] Authentication cookies are restricted to HTTPS connections only by using the requireSSL attribute.

[ ] Site is partitioned to restricted areas and public areas.

[ ] Absolute URLs are used for navigation where the site is partitioned with secure and non-securefolders.


[ ] httpOnlyCookies attribute is set to true on authentication cookie to prevent client side script fromaccessing the cookie.

[ ] Unique cookie names and paths are used.

3.2.3 Authentication–WindowsCheck Description

[ ] Windows authentication is used where possible.

[ ] Strong passwords policies are enforced.

[ ] Impersonation is used only when original caller's security context is required for downstream tier forauditing or authorization.

[ ] Impersonation token is not created by using LogonUser API.

[ ] Protocol transition is used when multiple identities need to access downstream resources.

3.2.4 AuthorizationCheck Description

[ ] URL authorization is used for page and directory access control.

[ ] File authorization is used with Windows authentication.

[ ] Appropriate ACLs are configured on Web site files.

[ ] Role manager, instead of custom code, is used for roles authorization.

[ ] Role caching is used if role store lookup is too costly.

[ ] If role caching is used, authorization cookie is restricted to HTTPS connections by using therequireSSL attribute.

[ ] If using SSL is not possible, the cookieSlidingExpiration attribute is set to false and limitedauthentication cookie time-outs are used.

[ ] The authorization cookie is not persisted on user machine by setting the createPersistentCookie


attribute to false.

[ ] Authorization cookie is protected for tampering and reading information.

3.2.5 Code Access SecurityCheck Description

[ ] Code access security is used when applications need to be isolated from each other.

[ ] The chosen trust level does not exceed your application's requirement.

[ ] If your application needs additional permissions, a custom trust policy is used.

[ ] Applications are isolated using Medium trust in hosted environments.

[ ] Attribute allowOverride is set to false in the machine-level Web.config file to ensure developerscannot change the trust level of their application.

3.2.6 Data AccessCheck Description

[ ] Connection strings are encrypted in configuration files using the Aspnet_regiis utility and ProtectedConfiguration providers.

[ ] Connection string information is encrypted using strong encryption (for example, 3DES).

[ ] Connection to database is used with least-privileged service account.

[ ] Windows authentication is used when connecting to SQL Server.

[ ] Trusted service accounts are used to connect to SQL Server.

[ ] Mirrored local accounts are considered as an alternative if domain accounts cannot be used.

[ ] Strong passwords are used and enforced.

[ ] If SQL Server authentication is used, the credentials are secured over the network by using IPSec orSSL, or by installing a database server certificate.


[ ] Credentials in SQL connection strings are protected in configuration files.

[ ] SQL queries use parameterized stored procedures and type-safe SQL parameters.

[ ] Dynamic queries that accept user input are used only if stored procedures cannot be used.

3.2.7 Exception ManagementCheck Description

[ ] Structured exception handling is used.

[ ] Generic error pages with harmless messages are returned to the client.

[ ] Global error handlers are used to catch unhandled exceptions.

[ ] Set mode attribute in customErrors to On to prevent displaying detailed error messages to the caller.

[ ] Exception details are logged on the server.

[ ] Throw informational exceptions and always log that an exception is thrown

[ ] Only throw exceptions in exceptional situations.

For more information regarding exception handling check out the following .

Microsoft MSDN article: http://msdn.microsoft.com/en-us/library/5b2yeyab(VS.80).aspx

3.2.8 Input/Data ValidationCheck Description

[ ] Free form input is sanitized to clean malicious data.

[ ] Application does not rely only on request validation.

[ ] All the input is validated for length, range, format, and type. Input is checked for known valid and safedata and then for malicious, dangerous data.

[ ] Input from all the sources including query strings, cookies, and HTML controls is validated using theRegex class and/or your custom validation code.

http://msdn.microsoft.com/en-us/library/5b2yeyab


[ ] Application does not rely on only client-side validation.

[ ] If input file names are required, they are well formed and are verifiably valid within the applicationcontext.

[ ] Untrusted output is not directly echoed back to the user.

[ ] Output that contains untrusted data is encoded with HtmlEncode and UrlEncode.

[ ] Constrain and sanitize input data to avoid SQL Injection and Cross Site Scripting

[ ] Use type-safe SQL parameters for data access

[ ] Use an account that has restricted permissions in the database

[ ] Avoid disclosing database error information

3.2.9 Impersonation/DelegationCheck Description

[ ] Tradeoffs associated with use of impersonation are fully understood.

[ ] Use of LogonUser is avoided where possible.

[ ] Programmatic impersonation is avoided where possible.

[ ] Threading issues have been considered if impersonation is used. If impersonation token is to bepassed to newly created threads, the ASPNET.config is configured correctly.

[ ] Impersonation is reverted by using finally blocks.

[ ] Exceptions while impersonating are not allowed to propagate.

3.2.10 Parameter ManipulationCheck Description

[ ] Security decisions are not made based on client parameters.


[ ] All the input parameters are validated for type, length, format, and range.

[ ] Sensitive data is not stored in view state.

[ ] View state is encrypted if it does contain sensitive data.

[ ] Page.ViewStateUserKey is used to counter one-click attacks.

[ ] Query strings with server secrets are hashed.

3.2.11 Sensitive DataCheck Description

[ ] Plaintext passwords are not used in configuration files (Web.config and Machine.config).

[ ] Sensitive data that is stored in .config files are encrypted using Protected Configuration providers.

[ ] Platform features are used and custom key management is avoided.

[ ] Sensitive data is not passed across pages; it is maintained using server-side state management.

[ ] Sensitive data passed over wire is secured using SSL or IPSec where appropriate.

[ ] Sensitive data is not cached.

[ ] Sensitive data is not stored in cookies, hidden form fields, or query strings.

[ ] Output caching for pages that contain sensitive data is turned off.

[ ] Sensitive data is encrypted in the database.

3.2.12 Session ManagementCheck Description

[ ] Application does not rely on client-side state management options.

[ ] Windows authentication is used to connect to Microsoft SQL Server state database.

[ ] Session state connection strings are encrypted using protected configuration providers.


[ ] Out-of-process state service is protected.

[ ] Access to state data is restricted.

[ ] SQL Server session state is protected.

[ ] The session cookie is protected using SSL on all pages that require authenticated access.

[ ] The session state service is disabled if not used.

[ ] The session state service (if used) runs using a least-privileged account.

[ ] The communication channel to state store is encrypted (IPSec or SSL).

[ ] Session state port is changed from default of 42424.

Avoid using cookie less session management

3.2.13 Deployment ConsiderationsCheck Description

[ ] Least-privileged service account is used for running ASP.NET applications.

[ ] Configuration sections that contain sensitive data are encrypted using protected configurationproviders.

[ ] Keys are stored in machine-level key store for application on dedicated server or multiple applicationsthat run under the same identity.

[ ] Keys are stored in user-level key store for applications running in a shared hosting environment.

[ ] Protected file types are blocked using HttpForbiddenHandler.

[ ] The same machine keys are used consistently across all servers in a Web farm.

[ ] Configuration settings are locked by setting allowOverride to false where appropriate to enforcepolicy settings.

[ ] Set mode attribute in customErrors to On to prevent displaying detailed error messages to the caller.

3.2.14 Communication SecurityCheck Description

[ ] Appropriate mechanism of secure communication (IPSec or SSL) is used, depending on application


requirement.

[ ] For communication between Web browser and Web server, SSL is used when pages need to beencrypted and you need to guarantee that the server to which you send the data is the server that youexpect.

[ ] For communication between servers, IPSec is used when secure server-to-server communication isrequired.

[ ] For communication between servers, SSL is used when an application does not trust otherapplications on a server.

[ ] Pages that use SSL are optimized.


4 Infrastructure Standards & PolicesThe developer must keep in consideration the following points and make sure that the web applicationmust pass the infrastructure check list.

a) The environment is not a dedicated hosting but it is a shared hosting one for .Net webapplications and SharePoint 2010

b) Microsoft best practices for development must be followed to make sure that theapplication is secure, compatible and suitable for migration to new releases and updateswithout any issues and without major customizations.

c) Free Third Party and Open Source content management tools like (.Net nuke, Joomlaand etc…) are not allowed.

d) The updating content process must be done through secure web administration interfacewhich is developed by the web application developer or through the defaultfunctionalities of SharePoint server.

e) The hosting environment is SharePoint 2010, so DEG will only accept web applicationsdeveloped for SharePoint 2010.

f) SharePoint out of the Box functionalities should be used rather than free third party toolsor custom developer code.

g) For SharePoint 2010 any custom solution and custom web parts will be accepted only ifthey are Sand Boxed and accordingly Infrastructure Team will not install any customsolution or web part directly to the hosting farm. i.e any solution or web part will bedeployed by the developer through the solution gallery in the site administrationinterface.

h) Creating another SQL database for the web site is not allowed, the developer must usebuilt in capabilities of SharePoint lists.

i) Infrastructure Team will not edit or change the web.config file. The developer isresponsible to make any changes in the web.config file by a sandboxed solution anddeploy it through the site administration. (You can refer to Microsoft guide for SandboxedSolutions)


j) Any changes in the SharePoint core files, configuration files and resources files areprohibited.

k) Manual copy, copy command, xcopy command and batch files are not allowed foradding files to the 14 hive, assembly folder, windows system, site virtual directory, orSharePoint core folders.

l) Any customization or configuration must ONLY affect your web application NOT anyother site.

m) An initial site quota of 500 MB will be assigned by default to the web site.

n) The department must provide DeG with the disk storage requirements for the site if it isan intranet portal.

o) “MySite” feature will be allowed only if required and upon approval from DeG topmanagement.

4.1 DocumentationThe infrastructure team will accept only adequate documentation to ensure that

customizations are installable, supportable, and well tested. Furthermore, documentationindicates that all errors that are generated by the customizations are properly described anddiagnosed. This section of the code acceptance checklist contains suggested items to helpensure that solutions that are submitted for deployment in SharePoint environment have beendeveloped using best practices for documentation.

Check Description

[ ] A proper, detailed deployment document is provided.

Explaining the required steps and configuration for the web application deployment like Email, UserAccounts, Search Settings...etc.

[ ] Customizations are accompanied by installation instructions that detail how to install and uninstall thepackage. Architecture diagrams that are related to the installation of the solution are included. If it isnot possible to roll back a solution, this must be explained in the installation instructions so that youcan discuss the risks and prepare a plan for a system recovery.

[ ] The deployment document and the deployment package should be delivered to the Infrastructure


team two working days before the deployment date on test environment and three working daysdeployment to production.

[ ] Updates and customizations are accompanied by a documentation, test cases documents and results.

[ ] Updates are accompanied by a list of all dependencies. This could include account/passwords, Webservices, databases, other solutions or Features, patches, tool sets or libraries, and otherdependencies.

4.2 Hosting EnvironmentThe developer must know that DeG hosting environment is a shared hosting not a dedicated servers.The web application will be hosted over a two web front end servers and hardware balanced. Thissection of the web application acceptance checklist contains suggested items to help ensure thatsolutions that are submitted for deployment in SharePoint environment have been developed to complywith DeG hosting environment security and standards.

Check Description

[ ] The web application is compatible with DeG hosting environment (refer to “Appendix A: EnvironmentSpecifications”)

[ ] Remote Desktop Administration or Web Server storage access is not allowed.

[ ] File Transfer Protocol (FTP) access to the web servers is not allowed.

[ ] No file Uploads and attachments to a folder on the server hard disk.

The uploaded files should be uploaded to the backend database and following the best practice andguild lines provided by the “Development Team”.

[ ] The web application development process & usage of environment resources should be considered,as this is a shared hosting environment.

[ ] No SQL server access via SQL management tools, the web developer should develop his own secureweb interface to get or read any data related to the web site SQL database.

[ ] No Audio/Video Streaming

[ ] All web application files are located under one parent folder.


4.2.1 SecurityCheck Description

[ ] Using of custom error pages, and make sure that any error message is not revealing any of the serveror environment information.

[ ] No access will be given to the anonymous user to any folder on the server disk

[ ] Using least privileges accounts.

[ ] User Credentials and sensitive data are encoded or sent over a secure layer

[ ] All anonymous forms have human being verification.

4.3 SharePoint Deployment Process1- The deployment process will pass through two phases, Deployment on test environment and

Deployment on Production.

2- The website will be deployed on test environment, for testing purposes; this test will run by thedevelopment team, Infrastructure Team, Functional team and the customer. The deployment processnormally is 3 working days task if there are no issues found.

3- The Infrastructure team will start the deployment once they received a helpdesk call for thedeployment from the development team.

Deployment Process steps:

1- Infrastructure Team creates the default web application which is used for the Public web site and isallowed for anonymous access.

2- Extend the web application which will be used by site administrators and it will not be available forpublic and anonymous access is not allowed.

3- The port used for both (Web application and the Extended one) is port 80 and different headers areused to identify them. For example we use “www.samplesite.ae” for public and “admin.samplesite.ae”for administration. The admin website will be accessed over https for security through ISA server.

4- Infrastructure Team will create a blank web site or based on any template as specified by thedeveloper.

5- Infrastructure team will create two user accounts for the web site. One as author and the other one asadministrator.

www.samplesite.ae


6- Configure site search, the site developer must configure the web part that used for showing searchresults to read from a specific scope that predefined in the deployment document.

7- Infrastructure team will configure the AAM and publish the web site through the ISA server.

8- The customer should create two DNS A records as followsCreate A record www.samplesite.ae 213.42.85.27Create A record admin.samplesite.ae 213.42.85.26

9- The developer will access the site and start the deployment of any web part and any custom solutionthrough the solution gallery in the site administration interface and using SharePoint designer (Thedeveloper must make sure that these customizations are compatible with Sandboxed techniques, asDEG will not run or install any web part, features or custom solution to the farm.

10- Do final test for the site and Go live.

11-12- If the site was already developed and packaged,

a. Infrastructure team can restore the website through STSADM commandb. Infrastructure Team will not run any other commands to add solutions or customizations all

these jobs will be done by the vendor through the site administration interface and sandboxedsolutions

www.samplesite.ae


5 Appendix A: Environment Specifications

5.1 Testing EnvironmentThis environment is for testing the website deployment and functionality beforedeploying it on the production environment. It is composed of

a. One IIS server on windows 2008 R2 platform with IIS7 and latest .Net frameworkb. Two Web Frontend servers (SharePoint 2010 / Arabic language on windows

2008 R2 x64 platform) and one of them is functioning as index.c. One SQL 2008 server with SP1

5.2 Production EnvironmentThis environment composed of:

1- Two load balanced IIS servers with windows 2008 x64 SP2 each.2- Two load balanced Web Frontend servers with SharePoint 2010 / Arabic

language pack on windows 2008 R2 x64 platform.3- One Index server.4- SQL Server Cluster 2008 with SP2 for each machine.


6 References

SharePoint Sandboxed Solutionshttp://msdn.microsoft.com/en-us/library/ee536577.aspx

SharePoint Deployment Guide and Checklistshttp://office.microsoft.com/download/afile.aspx?AssetID=AM102552101033

Sample code acceptance checklist for IT organizationshttp://technet.microsoft.com/en-us/library/cc707802(office.12).aspx

Security Guidelines: ASP.NET 2.0http://msdn.microsoft.com/en-us/library/ff649487.aspx

Security Checklist: ASP.NET 2.0http://msdn.microsoft.com/en-us/library/ff649452.aspx

http://msdn.microsoft.com/en-us/library/ee536577.aspx

http://office.microsoft.com/download/afile.aspx

http://technet.microsoft.com/en-us/library/cc707802

