[Project Name]
Security Design & Process Overview
Document Overview
Prepared By:
Prepared For:
Date Created:
Last Updated:
(R)esponsible
(A)uthority
(S)upport:
(C)onsult:
(I)nform:
RASCI Alignment
Technical Lead/Technical Analyst
Technical Manager/Business
Owner
ITPD Team
Security Administrator, Director of
Enterprise Systems, Manager of
Network Security, Director of
Integration
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
1.0
1.1
1.2
10/29/2008
10/6/2009
10/12/2009
Initials
AL
AK
1.3
8/16/10
LD
Description of Revision
Initial Draft
Technical team review changes
Minor updates, added business owner to RASCI, added
instruction verbiage changes, add reference to various security
acts that need to be considered.
Added note that this is a joint deliverable
File Name: QUAL017_PROJ _Security design and overview_20091009_v1 0_1.2.docx
Last Saved: 10/12/2009 8:34:00 AM
Page 2 of 9
Security Design
PROJECT NAME
Table of Contents
1) OVERVIEW: .................................................................................................................................................................. 4
1.1) PURPOSE..................................................................................................................................................................... 4
2) SECURITY DESIGN PRINCIPLES ............................................................................................................................ 4
2.1) NAMING STANDARDS ................................................................................................................................................. 4
2.2) SECURITY MODEL ...................................................................................................................................................... 5
2.3) INFRASTRUCTURE SECURITY ...................................................................................................................................... 5
2.4) APPLICATION SECURITY PROVISION........................................................................................................................... 5
3) INTERESTED PARTIES IN SECURITY AND RECOMMENDATIONS .............................................................. 6
3.1) RESPONSIBILITIES....................................................................................................................................................... 6
3.2) RECOMMENDATIONS .................................................................................................................................................. 6
3.3)RESPONSES.................................................................................................................................................................. 6
4) APPLICATION SPECIFIC SECURITY ADMINISTRATION ................................................................................ 7
4.1) OWNERSHIP ................................................................................................................................................................ 7
4.2) ROLES AND RESPONSIBILITIES ................................................................................................................................... 7
4.3) PROCESS FLOWS FOR SECURITY ACCESS..................................................................................................................... 7
4.4) SECURITY MAINTENANCE/AUDITS ............................................................................................................................. 7
5) SECURITY DEFINITIONS .......................................................................................................................................... 8
DOCUMENT SIGNOFF .................................................................................................................................................... 9
File Name: QUAL017_PROJ _Security design and overview_20091009_v1 0_1.2.docx
Last Saved: 10/12/2009 8:34:00 AM
Page 2 of 9
Security Design
PROJECT NAME
1) 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.
A 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.
File Name: QUAL017_PROJ _Security design and overview_20091009_v1 0_1.2.docx
Last Saved: 10/12/2009 8:34:00 AM
Page 2 of 9
Security Design
PROJECT NAME
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 mitigation
o 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
o
o
o
o
o
o
How many environments will need to be supported and how does security differ
between them
Physical Architecture design guidelines and documents (e.g.firewall)
Logical architecture design guidelines and documents
Audit provisions
Process flows for Infrastructure enhancements
Change Control procedures must be defined and followed
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:>
o
o
o
o
o
Logical model of security in the native (out of the box) application framework,
including specific handling of authentication, authorization, etc…
Authorization components and procedures
Authentication procedures and roles
Roles, priorities, dependencies, and profiles associated with the security within the
application.
Audit provisions
File Name: QUAL017_PROJ _Security design and overview_20091009_v1 0_1.2.docx
Last Saved: 10/12/2009 8:34:00 AM
Page 2 of 9
Security Design
o
o
o
o
o
o
o
o
PROJECT NAME
University of Chicago existing guidelines should be defined if they will impact the
security model
Custom modifications made or anticipated for security related data or processes
Security team (members and roles)
Change Control procedures must be defined and followed
On-boarding of new users/administrators
Application Security Training
Test case preparation for security validation
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 Systems
 Provide 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.
3.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>
File Name: QUAL017_PROJ _Security design and overview_20091009_v1 0_1.2.docx
Last Saved: 10/12/2009 8:34:00 AM
Page 2 of 9
Security Design
PROJECT NAME
4) Application Specific Security Administration
4.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.
Online 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.
File Name: QUAL017_PROJ _Security design and overview_20091009_v1 0_1.2.docx
Last Saved: 10/12/2009 8:34:00 AM
Page 2 of 9
Security Design
PROJECT NAME
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.
File Name: QUAL017_PROJ _Security design and overview_20091009_v1 0_1.2.docx
Last Saved: 10/12/2009 8:34:00 AM
Page 2 of 9
Security Design
PROJECT NAME
Document Signoff
Phase: Plan and Analyze
The (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:
Organization: University of Chicago________________
Contractor________________
Approved by:
Signature: ___________________________________________________________________
Name: ______________________________________________________________________
Title:
Date:
Organization: University of Chicago________________
Contractor________________
Approved by:
Signature: ___________________________________________________________________
Name: ______________________________________________________________________
Title:
Date:
File Name: QUAL017_PROJ _Security design and overview_20091009_v1 0_1.2.docx
Last Saved: 10/12/2009 8:34:00 AM
Page 2 of 9