qual017 proj security design and overview · web viewthe design should also enable easy addition of...

[Project Name]

Security Design & Process Overview

Document OverviewPrepared By:Prepared For:Date Created:Last Updated:

RASCI Alignment(R)esponsible Technical Lead/Technical Analyst(A)uthority Technical Manager/Business

Owner(S)upport: ITPD Team(C)onsult: Security Administrator, Director of

Enterprise Systems, Manager of Network Security, Director of Integration

(I)nform: Project Manager, Security Administrator, Director of Enterprise Systems, Manager of Network Security, Director of Integration

< Note that this deliverable is a joint Technical/Functional deliverable and the Functional Team should be consulted regarding content>

Security Design PROJECT NAME

Revision Log

Revision Date Initials Description of Revision1.0 10/29/2008 Initial Draft1.1 10/6/2009 AL Technical team review changes1.2 10/12/2009 AK Minor updates, added business owner to RASCI, added

instruction verbiage changes, add reference to various security acts that need to be considered.

1.3 8/16/10 LD Added note that this is a joint deliverable

File Name: QUAL017_PROJ _Security design and overview_20091009_v1 0_1.2.docx of 9Last Saved: 10/12/2009 8:34:00 AM

Security Design PROJECT NAMETable of Contents

1) OVERVIEW:

1.1) PURPOSE

2) SECURITY DESIGN PRINCIPLES

2.1) NAMING STANDARDS 2.2) SECURITY MODEL 2.3) INFRASTRUCTURE SECURITY 2.4) APPLICATION SECURITY PROVISION

3) INTERESTED PARTIES IN SECURITY AND RECOMMENDATIONS

3.1) RESPONSIBILITIES 3.2) RECOMMENDATIONS 3.3)RESPONSES

4) APPLICATION SPECIFIC SECURITY ADMINISTRATION

4.1) OWNERSHIP 4.2) ROLES AND RESPONSIBILITIES 4.3) PROCESS FLOWS FOR SECURITY ACCESS 4.4) SECURITY MAINTENANCE/AUDITS

5) SECURITY DEFINITIONS

DOCUMENT SIGNOFF

File Name: QUAL017_PROJ _Security design and overview_20091009_v1 0_1.2.docx Page 2 of 9Last Saved: 10/12/2009 8:34:00 AM

Security Design PROJECT NAME1) Overview:

1.1) Purpose

The intent of this document is to provide guidelines for ITPD projects in regards to security design and associated work processes. Personnel, who support the design, implement or maintain any part of application security should reference this document and all associated reference and support documentation.

<Instructions for areas in question or requiring more details are provided at the beginning of each section where appropriate and are colored in blue and should be deleted after completing the document. This includes this particular paragraph. Remember, areas can always be flagged as N/A, but be prepared to defend that decision.>

2) Security Design Principles

<The following are examples of the principles that should be considered when defining the Infrastructure and Application Security models for each project.>

Design and implementation of access controls must support the rapid deployment of the applications.

Design of processes must specifically address requirements for authorization and authentication

The access controls to be designed must be closely aligned to the business processes. These controls must facilitate and not hamper the business functions.

The extent of preventable access controls should be designed with due consideration to other integrity controls that will be in place. Access controls should compensate and complement other controls such as monitoring, remediation and/or mitigation of the current risks identified.

The Security Design deployed will comply with internal and external auditing guidance and compliance, where known.

The access controls designed should be flexible and enable growth. Ease of future additions of new organizational restrictions is desired. The design should also enable easy addition of other modules in subsequent phases.

The design should always lead to efficiency in on-going application security maintenance and administration. Therefore, we will always attempt to minimize the total number of customer-defined roles within the system landscape.

The security role design should be easily migrated and upgradeable to enable smooth administration, system performance and flexibility.

2.1) Naming standards

<Determine if the naming standards apply to this project.


Security Design PROJECT NAMEA naming convention or standard has been used in developing the security roles and related components. This standard assists in identifying the access privileges that are granted from an intuitive or implied perspective.

Standards applicable to Security as defined by IT SERVICES Security area should be included in the design document if applicable.

[Insert appropriate naming convention standards such as CNET ID, user role names, etc]>

2.2) Security Model

<The Security Model should contain guidelines and documents that address the security concerns defined below. Make sure that if any of the appropriate security restrictions apply to this project (HIPAA, FERPA, GLB, IPPA, etc.) then you explicitly should include items in the model that speak to those particular items.>

Security Risks – An in depth risk assessment of security related risks needs to be conducted to identify and define mitigation strategies for the following types of Risks:

o Audit provisions o Ownership of mitigationo Legal impacts of Security risks

<[Insert tables/reference diagrams to explain security model such as roles/profiles, etc. Ensure the model addresses authorization and authentication needs]>

2.3) Infrastructure Security

Infrastructure Security – The security guidelines need to be specified for the area surrounding and supporting the application. This will include items such as the Physical Architecture and Logical Architecture design documents, and how security is addressed in each area. Security access and enhancement forms should be defined to identify the processes to be followed for gaining access and upgrading the Infrastructure.

o How many environments will need to be supported and how does security differ between them

o Physical Architecture design guidelines and documents (e.g.firewall)o Logical architecture design guidelines and documentso Audit provisionso Process flows for Infrastructure enhancementso Change Control procedures must be defined and followedo Test case preparation for security validation

<[Insert schematics such as flows, tables, etc to describe infrastructure security from an authorization and authentication perspective]>

2.4) Application Security Provision

Application Security -. The security guidelines for the application, the forms that will be used, and the security roles should be defined in this area. <Examples are:>


Security Design PROJECT NAMEo Logical model of security in the native (out of the box) application framework,

including specific handling of authentication, authorization, etc…o Authorization components and procedureso Authentication procedures and roleso Roles, priorities, dependencies, and profiles associated with the security within the

application.o Audit provisionso University of Chicago existing guidelines should be defined if they will impact the

security model o Custom modifications made or anticipated for security related data or processeso Security team (members and roles)o Change Control procedures must be defined and followedo On-boarding of new users/administratorso Application Security Trainingo Test case preparation for security validationo Naming conventions for Security related items

<[Insert schematics such as flows, tables, etc to describe application security from an authorization and authentication perspective]>

3) Interested parties in security and recommendations

<This section provides an overview of the technical aspects associated with security design and deployment. The below paragraphs should include the people that you contact, their recommendations related to the project and the Technical team responses to those recommendations. Currently the folks filling these roles in IT SERVICES: Security admin: likely someone in the business, Manager of Network Security: Shelley Rust, Director of Integration: Tom Barton. IT SERVICES has no director of enterprise systems, but consider talking to David Trevvett (head of Admin Systems.)>

3.1) Responsibilities

Security Administrator Responsible for the maintenance of users. Responsible for proper retention of communications and request forms and signed audit

review reports Responsible for all actual build of all roles Responsible for the final verification of correct design approach

<Director of Enterprise SystemsProvide strategy enabling security service to the internal and external security customer in

analysis, design, delivery and support.>

Manager of Network Security Provide advice to project team.

Director of Integration Provide advice to project team.

Other) placeholder) Provide advice to project team.


Security Design PROJECT NAME3.2) Recommendations

<Enter here the answers received from the meetings with people on 3.1>

3.3)Responses

<Enter here the actions that technical team will take based on recommendations on 3.2>

4) Application Specific Security Administration4.1) Ownership<Application Security Ownership must be assigned during the initial phases of the project to ensure that the function is fully operational when the application is installed. Security Access rules and procedures must be included in the design.

The University believes that business sponsors have ultimate responsibility for the applicable security that relates to their area of ownership. This role can be delegated to a designee or designees. However, business sponsors must be accountable for the actions of their designees.>

4.2) Roles and Responsibilities<The Roles and Responsibilities of the Security team can vary by project, but the general functions defined below should be included when defining responsibilities for both the application and the Infrastructure supporting the application. The number of roles will increase or decrease accordingly based on the size and complexity of the Security needs.>

Creation of new role Delete role Modify role Adding Users Deleting Users Modify users Transferring Users Granting Additional Access Exceptional Access

4.3) Process flows for Security access

<Insert diagrams for Process flows for gaining access to the system. Please make sure you include the flows for System Administrators as well as everyone else.>

4.4) Security Maintenance/Audits

<The frequency of the Security maintenance, and the type of maintenance required to ensure that the application and Infrastructure remain secure should be identified prior to the initial implementation of the application. Minimally, the security of the application should be tested on a quarterly basis. Maintenance for application platforms will impact the frequency and content of the maintenance.


Security Design PROJECT NAMEOnline applications may require more frequent security maintenance since the environment changes more rapidly than other platforms.>

Perform ongoing self-audits on a regular basis using the automated Audit tools and processes. These audits include the following:

Review and sign-off by business owners of users that have access to their owned roles; Review and sign-off by business owners that contents of their owned roles are correct; Review and sign-off by business owners that users allocated to roles with audit transactions

are authorized and should have such access to these transactions. Conduct Source Code/penetration testing review and approval.

These self-audits are performed by providing reports to applicable security owners. The Business Owner or Team Lead will review and sign-off on the results. The Security Administrator consults with the stakeholders during the review process to advise or take action as might be necessary.

In addition to self-audits, other internal and external audit groups may also audit security.

5) Security Definitions

<The following are examples of the key terms that are used in Security design. Please add/delete items as you see fit.>

Role: A role is a collection of individual activities that are routinely performed together. This is the combination of one or more transactions and authorization objects into a group recognized by the system or are affiliated in some way.

Data Element: Describes the role of a domain in a certain business context for the benefit of the dependent fields and determines how these fields are to be displayed on the screen.

Authorizations: The basic building blocks of security and are implemented to allow access to data elements

Authentication: The method used to confirm that access is granted to the correct individual.

Preventive Access Controls: Proactive and often programmatic measures that provision with exclusivity or prohibit entirely the progression of certain actions or activities. Common examples include: user exits, security, configuration, and workflow.

Detective Access Controls: Reactive and often manual measures to monitor historic actions or activities which have transpired. Common examples of detective controls include: activity reports, budget reviews, plan verses actual analysis & alerts. These controls when documented and applied against a Segregation of Duties at the user or role level are referred to as Mitigating Controls.

Position: Correspond to the various job functions found in the business. As multiple access capabilities may be necessary to perform all the business functions/tasks within a position, a position may contain one or many Roles, which together result in all the access capabilities authorized and required. Positions and their relationships to roles are maintained outside the SAP System.

Special Use Role: A role that often contains sensitive or restricted transactions and/or objects. These roles are assigned directly to the user master and not associated with a position. These are granted to users based on need and ability to perform some transactions.


Security Design PROJECT NAME


Security Design PROJECT NAMEDocument Signoff

Phase: Plan and AnalyzeThe (Deliverable Name) document has been reviewed and found to be consistent with the specifications and/or documented project requirements. The signature below documents acceptance of this document and/or work product by the signing authority

Organization: University of Chicago________________ Contractor________________

Approved by:

Signature: ___________________________________________________________________

Name: ______________________________________________________________________

Title:

Date:


Approved by:

Signature: ___________________________________________________________________

Name: ______________________________________________________________________

Title:

Date:


Approved by:

Signature: ___________________________________________________________________

Name: ______________________________________________________________________

Title:

Date:


qual017 proj security design and overview · web viewthe design should also enable easy addition of...

Documents