CFS Security Strategy.docx

cfs security guidedraft cfs security guide last revised:02/17/12draftrevision control document title:cfs security guideauthor:cfs project teamfile reference:cfs security guide.docxdatebyactionsection06/08/10y hepperlerelease of new documentall07/14/10y hepperleadded level 1 process 3.13section 3.1301/07/11y hepperleadded process monitor information section 3.1401/10/11y hepperleadded level 1 security structureappendix d01/25/11 y hepperleremoved references to credit card numbers as they are not stored in cfs.added verbiage re: non-production level 1 column data scrambled.appendix bsection 3.13 03/01/11a. harwoodadded sod and sensitive data informationpages 7 905/06/11y. hepperleupdate data warehouse securitysection 8.005/13/11a. harwoodupdated sod proceduressection 4.405/16/11l. horanupdated data warehouse security (roles)section 8.006/13/11a. harwoodupdated sensitive table names appendix b06/16/11a. harwoodupdated appendix d by adding csu_ft_setup to csu_qry_tree_bnkl1appendix d09/08/11a. harwoodupdated appendix d by adding csu_hr_dist_vw and csu_labor_dist to csu_qry_tree_lcdl1appendix b02/17/12a. harwoodadded cfscsu_pt_devadmin role campus access to assign process scheduler admin required settings for primary permission list process profile added vndr_bank_acct to level 1 query tree for ap added appendix e regarding approval process for changes to cfs security not already covered in this guidesection 4.3.2appendix ereview/approval historydatebyactionpagescfs steering committeestrategy approved for releaseallgroup / campusreview and inputallsenior director cmsjessie lumreview and inputalltable of contentspage1.0introduction11.1document purpose11.2document scope12.0roles and responsibilities13.0peoplesoft application security23.1overview23.2distributed security administrator request process23.3authentication23.4user ids33.5roles and permission lists43.6role grant43.7password management63.8requesting new or modifying users63.9deprovisioning oprids63.10row level security73.11peoplesoft query74.0level 1 and sensitive data84.1confidential tables84.2sensitive data definition84.3access to level 1 and level 2 records sensitive data84.4segregation of duties95.0cfs process monitor access106.0cfs application security change control187.0infrastructure197.1database management system198.0data warehouse security199.0incident management20appendix a: functional aspects of cfs security21appendix b level 1 and sensitive tables24appendix c campus codes and abbreviations25appendix d level 1 roles, permission lists and query trees26appendix e approval process for modifications to cfs security35last revised: -01/25/111.0 introduction1.1 document purposethis document details the operations of the cfs common financial system (cfs) security concepts as outlined in the cfs information security strategic plan document (posted under access and security). it will address the peoplesoft application security as well as oracle database security. the roles and responsibilities defined in the strategy document will be addressed in more detail in this document. the initial sections of the document provide background and generalized recommendations concerning security.1.2 document scopethis document provides a guideline to the operations of security for the cfs environment, how that is maintained and administered for campus development and production environments as well as centrally managed security. it is intended to be an operational guide.2.0 roles and responsibilitiesthe project team roles and their respective responsibilities for ensuring the integrity of cfs and ancillary systems are briefly described below outlined below: the central security administrator (csa) will provide central guidance and direction for the cfs security administration. this position will work with co, campus staff, and the central security review team to validate security design and provide post-implementation support. cms technical services will manage the production infrastructure associated with the application and web tiers supporting the cfs environment with direction from the central security administrator. the distributed security administrators (dsa) are responsible for working with the campus application owner/leads to ensure that the end-user security they have designed has been implemented and meets campus business requirements. - limitations cannot create other dsa accounts cannot create or modify query access groups with level 1 data- responsibilities campus sod monitoring and compliance campus user security campus roles and permission lists the campus application owner/lead (e.g., accounts payable or general ledger lead) is responsible for understanding the cfs application modules under their control (e.g., accounts payable or general ledger). this position is the business owner. the central security review team is responsible for recommending and/or reviewing cfs security changes including campus specific security requests.3.0 peoplesoft application securitythis section describes, at a high level, the decentralized peoplesoft security, campusbusiness unit security and application security model.3.1 overviewthe cfs team has developed a peopletools and application security model for cfs with the assistance of several campuses. campuses have the practical expertise and will be the primary architects of cfs security. this will be an ongoing effort as more campuses are brought online to cfs. any changes to this plan will be managed by the central security administrator with the assistance and guidance of a central security review team. the goal is to maintain cfs security as consistent as possible given that business practices are not common throughout the csu. any changes reviewed and approved by the cfs central security review team will be migrated into production on either of two migration days, tuesday or thursday. 3.2 distributed security administrator request processcampuses need to: complete the cfs dsa request form posted on the cms/cfs website obtain campus approval from the campus authorized cfs security user access requester open service now type/category/subcategory: access request/problemcms - cfssecurity csm action request - cfs security administration form (posted under cfs access request forms) csm final review and implementation3.3 authenticationthe cfs peoplesoft system will be accessed through the csu portal, which will be responsible for primary authentication. the cfs peoplesoft system has single sign-on (sso) with the csu portal. users that are successfully logged into csu portal can access resources in cfs peoplesoft application based on roles defined in cfs.tasks associated in preparation for accessing cfs via the csu portal have most likely been completed or are underway by the managers of the campus directory services and/or the identity management. please contact those resources to validate that your directory is in fact configured to access cfs via the csu portalfollowing authentication methods are supported by csu portal: shibboleth authentication campus portal single sign on (currently peoplesoft enterprise portal and uportal are supported) cfs authentication modelauthentication activity in cfs:1. users access main page or csu links (csu portal or campus portal) and enter campus credentials2. custom sso module will authenticate with respective campus authentication provider3. for shibboleth, campus identity provider will validate with campus directory4. authenticated users will be authorized to view protected cfs contents5. user profile syncs with csu super directory6. access to cfs application3.4 user idsthis section describes the process of managing peoplesoft user ids.the initial user to be established in cfs will be the distributed security administrator. this user is created by the central security administrator. once this user has been created and the role assigned they are then responsible for creating their campus users and providing appropriate access. an individual user id will be created for each individual requiring access to the peoplesoft system. this provides the ability to maintain clear audit trails of individual activity. thus, unique and independent user ids help support accountability. 3.4.1 user id naming conventionpeoplesoft user ids can be up to 30 characters in length. however, for cfs user ids are restricted to 11 characters to make them easier to administer. the following mandatory naming convention is to be followed: 2 digit campus code + 9 digit emplid (appendix c campus codes and abbreviations) format: ccxxxxxxxxx campuses with less than 9 digits emplid will have leading zeros. for non campus employees, campus security administration has to create temporary ids that adhere to the naming convention.3.5 roles and permission liststhe cfs security strategy is designed for minimal “centralized” control of day-to-day campus operation support. the cfs infrastructure simplifies campus security administration through delivery of role-based security templates, and using the “silo” concept of assigning unique sets of permissions lists for each role definition. whether it is a cfs role or customized campus role definition, each role will have a unique set of permission lists. however, the number of permission lists assigned to each role definition will be capped at 12 or fewer. 3.6 role grantall roles created by cms central or specific roles and permission lists created by campuses will be reviewed by the central security review team to determine whether existing security will work or if a campus role can be converted to a cfs delivered role. once a role has been added to production the csa will add that role to the distributed security administrator role grant. if a role is truly campus specific then it must be supported by the campus. these roles can be developed in the campus development environments facfsdva and tested in facfstsa. once completed the campus security should be packaged and submitted via the comr process.3.6.1 role naming conventiona series of roles have been developed and a set of templates created for delivery to the campuses. all roles are initially delivered as cfscsu_ to identify the template as one of the standard (unmodified) sets delivered. if the delivered template is modified at the campus level, the role must be renamed to cfscam_ where cam is the standard campus abbreviation, as listed in appendix a.role names are structured as cfscam_md_name_# where:standardidentifiesdescriptioncfscam_md_ name_#environment identifies the role as associated to the cfs environmentcfscam_md _name_#role owner identifies the owner of the role roles will be delivered as cfscsu_ to indicate the role as a delivered cfs role template. campuses that modify delivered role templates will apply their standard campus abbreviation. (i.e. cfsfre_ ) the underscore is always used to separate the first identifiers from the rest of the name.see appendix a for standard campus abbreviations cfscam_md _name_#primary module the module abbreviation identifies where the majority of the processing occurs. for example, if an accounts payable processer also has views to accounts receivable, but the primary data entry is conducted in accounts payable, the roles module abbreviation would be ap.see appendix a for standard module abbreviationscfscam_md _ name_#the name of the business process and the number of roles delivered to meet the needs of that business process area. provides a short description of the role. provides how many different roles have been developed and delivered to handle all the different business needs within that particular area. zero always indicates a unique role (the only one delivered) for the business need.examples cfscsu_am_propinv_0 one role delivered to handle property inventory cfscsu_ap_base_1cfscsu_ap_base_2two roles delivered to handle ap base processing. in general, the lower the number, the fewer the permissions i.e. data entry at a “1” vs. correction mode at a “2”. see description for details of what each role contains.3.6.2 permission list designdesign guidelines permission lists will be named using information from the folder label (aka main menu folder) and the role name assigned. a permission list name is limited to 30 characters (this is a peoplesoft restriction). permission list prefix requires 10 characters which leaving 20 characters to identify it. this can be quite limiting and may be resolved by hyphenating the name. number of permission lists allowed per role is 12 or less. basic folder labels used throughout cfs are purchasing, accounts receivable, accounts payable, asset management, general ledger, set up financial and peopletools.permission list naming structurecfsaaa_xx_01234567890123456789 whereaaa = campus prefix xx = menu folder label which consists of- am (asset management)- ap (accounts payable)- ar (accounts receivable)- bi (billing)- gl (general ledger)- po (purchasing)- pt (peopletools such as security, process scheduler, portal, app engine, etc)- su (set up financial)- zm (miscellaneous menu/components) any other menu components that are not listed in the 1st 8 bullets points above will be assigned here. example: project costing, it asset management, etc.- zr (reporting tools, process group, query, nvision, xml publisher, tree mgr, etc)- zc (customized menu/components) all csu customized menus and components will be assigned here. example: cdip 01234567890123456789 = role name where this permission list is assigned 3.6.3 sample permission listrole = cfscsu_am_base_01 will need 4 permission lists to track all the navigation paths shown below. here are the 4 permission lists created for this role:1. cfscsu_am_am_base_01 (all asset management links are assigned here)2. cfscsu_po_am_base_01 (all purchasing links are assigned here)3. cfscsu_su_am_base_01 (one set up financial link assigned here)4. cfscsu_zm_am_base_01 (it asset management and project costing assigned here)3.7 password managementpeoplesoft password management feature will not be used. users will use campus authentication provider credentials to login to cfs. the assumption is that campuses are following password management policies per the california state university system-wide information security policy.the distributed security administrators will be responsible for locking accounts in cfs for users that are no longer allowed access to cfs. additionally a user purge process will be performed by cms central to remove these accounts based upon a yet to be established timeline.3.8 requesting new or modifying usersin keeping with the decentralized cfs security model it will be incumbent upon each distributed security administrator to add or modify cfs users. the dsas are granted the ability to manage individual user accounts in cfs including creating new users or deprovisioning user profiles.3.9 deprovisioning opridsper section 3.8 oprids will not be deleted in an automated fashion for the near term. dsas will secure oprids by locking user accounts if they no longer have job responsibilities requiring cfs access. the campus dsa must remove all roles attached to that respective user profile once the account has been locked.3.10 row level securityrow -level security will not be supported in cfs at this time. in cfs, the business units and setids are assigned to the users via the primary permission list. a default campus specific primary permission list would be assigned to each new campus user. for applications that are not delivered with built-in row-level security functions, cfs will implement training and a certification process for users requiring access to these applications. additional security will be implemented to protect tables that contain sensitive data.3.11 peoplesoft queryquery development and procedures are outlined in the cfs query development guide. each campus will have its own query profile. all campuses will share the same query access group tree and will have its own query access group. cfs central team will design and maintain the query tree.cfs security requires query developers to implement security views where prompts for business unit and setid are required. developers will need to create three security views, which must begin with “sp_”. a peoplesoft process will be run during the migration of the query from a nonproduction to production environment. this process will search for prompt tables that start with sp and convert it to either the _oprvw or _clsvw, depending on the security setup. the format of the security view must be sp_descr_xxxvw, where descr is a meaningful description of the query and where xxx is either opr, cls, or the non security view. the “_oprvw” is used for security based on operator id. the “_clsvw” is used for security based on permission list. the “_nonvw” is used for instances where security is not implemented.cfs will provide three types of query access:1. the first is the run only query access where users can run predefined queries. 2. the next level will be access provided to a control group at each campus providing the ability to create private queries but no ability to turn a private query into a public query. 3. a very limited set of users will have the ability to create public queries in a campus developme