Process Document. Scope

Transcription

1 Process Document Subject: BCIT Access Management Process Process Number: I Department Name: Information Technology Version: 1.4 Original Issue Date: Revision Date: 03/22/2010 Process Owner: Controls and Compliance Process Contact: BCIT Controls and Compliance Purpose The purpose of this document is to outline the BCIT processes for managing access levels including new hires, job changes, requesting additional access, access removals, and reviewing access to Brunswick applications. Applicability The BCIT Access Management process document applies to all domestic and international Brunswick employees and temporary users that require access to any/all IT systems regardless of the division or site location. Scope This document describes the process established to request, approve, remove, or transfer user access to Brunswick applications. It also defines the risks involved in this process, controls established to assure the integrity of the production environment and the testing procedures established to monitor the effectiveness of those controls. Processes 1) Access Requests (New or Additional access)...4 a) General Requirements:...4 b) Access Request Submission:...4 c) User & Approval Types:...4 d) Direct Leader Approval:...4 e) Business Owner Approval:...5 f) Security Administrator:...5 2) Access Removal ( Control C7 )...6 a) General Requirements:...6 b) Access Removal Submission:...6 c) Security Administrator:...6 d) Inactive Account Removal:...6 3) Access Reviews ( Control C3 and C5 )...7 a) General Requirements...7 b) Prepare documents:...7 c) Business owner review:...7 d) Security Administrator: Payment Card Information Requirements.8 BCIT Access Management Process Page 1 of 9

2 Definitions Business Day: Monday - Friday from 8:00am to 5:00 pm local time, excluding companyapproved holidays. Business Owner Those individuals who are responsible for a given business process or financial/operating cycle. A list of business owners for each application should be available by system. Expedited Request Access requests that require immediate attention. This type of request should only be used in terminations, or for granting access to assist in the restoral of a service. Direct Leader A person whom a user reports to regardless of title e.g., Leader, Supervisor, Manager. Generic User Account An account used by multiple users and is not defined as belonging to a single user. Key System Any system that contains highly sensitive/confidential information or a system where the main function is to store or alter financial data. Privileged User Persons with authority to maintain and configure applications and systems. e.g., DBA, Network admin, Windows admin, Developer Security Administrator Persons who manually fulfills approved user access rights to applications or systems. Signature A person s consent regardless of format (hand written or electronic). System Accounts A unique account designed to allow communication between systems or applications and is not utilized by any individual. User The recipient who an access request is intended for and who will use the access to carryout their job function. BCIT Access Management Process Page 2 of 9

3 Risk & Controls Matrix Access Management Risk and Control Matrix Risk P Prevent D - Detect Process Policy Control Systems Controls R1: A user or Security administrator may gain access or elevated privileges beyond what they need in order to perform their specific job R2: A security administrator may bypass the approved access management policy, process, and procedure R3: Terminated employees may retain their system access past their employment period R4: Contractors, either terminated or who have fulfilled their obligations may retain their system access past their agreed upon contract period R5: Generic accounts may be created and used in situations where it is not permissible according to the Access Management Policy C - Controls 1.C.i P-A.1 C1 All Access requests must be approved by the appropriate individuals before access is granted P P 1.C.ii No C2 All The implementer of access must be different than the approver(s). P 3 No C3 Key System and user accounts with access to critical financial transactions/functionality, and generic accounts are reviewed on a D D D D D quarterly basis by the designated business owners. 3.C.ii.4 P-B.8 C4 Key As part of the periodic access review, generic accounts will be reviewed and cross checked against applicable risk acceptance to D D ensure documented mitigation is taking place 3 No C5 All Privilege IT access will be reviewed on a periodic basis D D D 2.D P-D.1 C6 Network Accounts are removed or disabled after 90 days of inactivity D D 2 No C7 All A request for access removal must be submitted and removed once the access is no longer required for an individuals job responsibilities P P R Recommended Controls and Monitoring activities R1 All Produce & review a report that displays all termination requests for a given period. The frequency should be at least monthly, but may be D D daily or weekly. R2 Key When an access removal request is submitted based on a termination request, and advisory notice is distributed to the security administrator P P R2 Key Accounts are removed or disabled after 90 days of inactivity D D BCIT Access Management Process Page 3 of 9

4 1) Access Requests (New or Additional access) a) General Requirements: i) All requests must be submitted in written or electronic format For expedited requests please follow the procedures documented for the application/system in which the request is for. The request must still meet the requirements of this process and be submitted within 2 days after the initial expedited request. ii) Submit with enough lead time so the request may flow through the approval process ( at least 5 days ). After all approvals are obtained, IT requires two weeks to complete the request iii) All approvals and pertinent information must be maintained in accordance with the Brunswick retention policy iv) If at any time information is changed or added within the request, all previous approvals become void. The request must be routed back through the process to gain the approvals. v) The implementer must not be one of the approvers. b) Access Request Submission: i) Users requesting access shall adhere to the following guidelines: 1. Request detailed with enough information that allows the request to be approved ( this is the minimum ) a. Privilege level being requested e.g., read-only, write, execute, administrative b. Privilege type e.g., developer, administrator, user, super user c. Environment e.g., development, test, production d. Clear reason of why the level of access is needed e. Specifically detailing the exact resources/areas needed for access f. First name, middle Initial, and last name of the person needing the access g. Date the access is needed h. Person user reports directly to e.g., leader, supervisor, manager c) User & Approval Types: i) Approvals for users requesting access shall adhere to the following guidelines ( Control C1 ): Access Request Type User Type System Type Approval Level New User Request User Non-Key Direct Leader New User Request User Key Direct Leader & Business Owner New User Request Privileged User All Direct Leader & Business Owner Additional Access User Non-Key Direct Leader Additional Access User Key Direct Leader & Business Owner Additional Access Privileged User All Direct Leader & Business Owner ii) If the Direct Leader and Business Owner is the same person, then only one approval is required. iii) If one of the approvers is also the implementer, then one of the following must occur( Control C2 ) 1. An Additional signature from: a. An individual at the same level as the Direct Leader b. A higher level leader than the Direct Leader OR 2. Send the request to a different implementer d) Direct Leader Approval: i) The user s direct leader or next higher manager must approve all requests for new or additional access. ii) Before approving, the user s direct leader will ensure the request: 1. Has all required fields completed 2. Is specific Exact resources/areas must be identified within the request for access. a. Requests to clone an existing users access is prohibited according to policy BCIT Access Management Process Page 4 of 9

5 i. Example: Setup a new User account with the same privileges or access like John Smith. ii. It is acceptable to provide the approving direct leader with the details of an existing users profile to enable the direct leader to properly review existing access and determine the appropriate level of access for the new user request. 3. Suitable Matches the user s job responsibility without granting the user more access than is required to carry out their daily activities. e) Business Owner Approval: i) The business owner(s) of defined Key systems must approve all requests for new or additional access requested. ii) Before approving the Business Owner will ensure the request: 1. Is clear 2. Does not create a logical segregation of duties violation with respect to established key financial systems 3. Is Suitable Matches the user s job responsibility without granting the user more access than is required to carry out their daily activities. 4. Approved by the direct leader of the individual ( if not the same as the business owner ) 5. Is for a specific person or doesn t violate the rules regarding generic accounts as specified in the access management policy. iii) If denied, the business owner will communicate this information back to the user s direct leader or authorized approver. f) Security Administrator: i) Grant new or additional access only after the request has been approved by the appropriate levels based off the chart in 1C 1. Under no circumstances will a security administrator provide a new account or new level of access for a user before the request has gone through the approval process. ii) Implement the access request within department standards or SLA s. iii) Communicate to the recipient that the request has been implemented. 1. For new hires, the security administrator will notify the user s direct leader the request has been completed. 2. If the access request is implemented before the new hire s start date, the security administrator will inform the new hire s direct leader the proper procedure for getting the login credentials 3. If the access request is implemented after the new hire s start date, the security administrator will communicate directly to the user following the protocols defined in Brunswick s password policy. a. Login credentials will only be given to the recipient to whom the request is intended. iv) Note the following within the request 1. Any special comments regarding the implementation 2. That the recipient was communicated their new login information where applicable 3. Sign and date the request stating it has been completed BCIT Access Management Process Page 5 of 9

6 2) Access Removal ( Control C7 ) a) General Requirements: i) An access removal request must be submitted in the following situations 1. A users job responsibilities change and certain access is no longer needed in their new job function 2. A user is terminated 3. A contractors services are no longer needed within the organization ii) Expedited disabling of access my be done verbally and then followed by a formal written or electronic request The removal of the account will not happen until a request has been submitted and received by the Security Administrator b) Access Removal Submission: i) The request for removal of access must contain the following information 1. First name, middle Initial, and last name of the users access being disabled 2. Users location 3. Date of the request 4. Date the access needs to be disabled 5. Person user reports directly to e.g., leader, supervisor, manager 6. Reason why the access is being removed EG. Termination, Job Transfer c) Security Administrator: i) Once IT is notified, the security administrator has until the close of the next business day to disable access to Network/VPN and key applications ii) Access to be disabled within 5 business days of notification for all non-key systems iii) Note the following within the request 1. Any special comments regarding request 2. Sign and date when the access is removed d) Inactive Account Removal: i) If a network account is inactive during the last 90 days, the security administrator will either disable or remove the account depending on the system requirements. 1. Where possible, this should be automated and done daily. If this is not possible a manual review must occur within the following guidelines a. For key systems, this review may happen every week (Optional) b. For non key systems this review must happen every quarter ii) Accounts that are exempt from this rule must be periodically: 1. Re-approved by the same level as required to grant the access 2. Reviewed and updated iii) The security administrator shall document and retain evidence as per the prescribed procedures. BCIT Access Management Process Page 6 of 9

7 3) Access Reviews ( Control C3 and C5 ) a) General Requirements i) Access reviews will be completed on the following schedule User Type System Type Review Period Privileged User Key Quarterly Privileged User Non-Key Semi-Annually Financial Impacting Key Quarterly Generic Key Quarterly ii) A documented list of Business Owners or the delegates authorized to do the review must be maintained This document should be reviewed and updated on a periodic basis iii) This review is for ensuring that an individual does not have access outside of what is required to execute their job function. If additional access is required, the access request process must be followed ( Section 1 ) b) Prepare documents: i) Security administrators will produce documentation for the following reviews 1. Existing accounts with access that impact financial statements. 2. Existing accounts with privileged access. 3. Generic accounts. ii) Documents shall be submitted to the appropriate reviewers with enough lead time to allow a reasonable time period for review A specific due date to complete the review must be identified. iii) Review documentation should: 1. At a minimum be for the production environment Must include the environment being reviewed in the documentation 2. Be specific and detailed Denote each type of access e.g., read-only, write, execute or administrative. 3. Be system generated where applicable If the documentation of existing user accounts is not system generated, there must be a method to reconcile the accounts. 4. Clearly identify users including if possible job titles or role. Does not apply to the generic account review 5. Include groups and the individuals within those groups where applicable Does not apply to the generic account review c) Business owner review: i) Business owners are required to review existing access to ensure only properly designated persons and generic accounts have access. Examples: 1. Terminated employees have been removed 2. Access is appropriate for job responsibilities 3. Access for employees who have transferred jobs is still appropriate ii) The minimum that should be checked: 1. Does current user access matches the user s job role 2. The access is the minimum that is required and is commensurate with the users job responsibilities 3. Does not create a logical segregation of duties violation with respect to established key financial systems 4. The generic account falls within the allowed guidelines or has proper approval documented iii) Business owners must clearly indicate the access that should be removed as a result of their review Examples: 1. Remove entire account BCIT Access Management Process Page 7 of 9

8 2. Remove write access for a specific menu option iv) Business owners must complete the review and submit a signed and dated document to the security administrator(s) within a pre-defined timeframe. v) The business owner shall communicate directly to the affected user in the event access is changed for any reason. d) Security Administrator: i) Security administrators must process all requested removals/changes resulting from the business owner s quarterly review within the same timeframe as required by the Access removal section. ii) Security administrators must indicate that the access change has been implemented. 1. Notate any special comments regarding the implementation 2. Sign and date the request stating it has been completed iii) A second report as described in section 3b should be generated after implementing the removal of access iv) Security administrators must retain all user access quarterly review documentation according to Brunswick retention policies. 4) Payment Card Information Requirements (applicable only to Brunswick Bowling and Billiards retail operations in North America) a) Required Automated Access Request Process i) Automated access request processes must be used for provisioning and de-provisioning access to all systems and applications designated by the business as subject to the requirements of the PCI Standards. ii) This process must be designed to control and document the requirements for access provisioning and de-provision stated in this document. b) 90 Day Inactive Account Removal i) If a system or application account is inactive during the last 90 days, the security administrator will either disable or remove the account depending on the system requirements. 1. Where possible, this should be automated and done daily. If this is not possible a manual review must occur within the following guidelines a. For key systems, this review may happen every week (Optional) b. For non key systems this review must happen every quarter ii) Accounts that are exempt from this rule must be periodically: 1. Re-approved by the same level as required to grant the access 2. Reviewed and updated iii) The security administrator shall document and retain evidence as per the prescribed procedures BCIT Access Management Process Page 8 of 9

9 Related Documents A. I Brunswick Access Management Policy B. L Record Management Information Lifecycle Management C. I Password Policy D. XXXX - IT System\ Application Owner (Under Development) E. XXXX - Key Applications (Under Development) Revisions, Dates and Author Date Revised By Revision Comments Version Number Ryan Lanier Initial BCIT Consolidated version Ryan Lanier Updated header and formatting Ryan Lanier Updated Definitions, Sections: 1.C.i, 1.C.ii, 2.C.i, and change term waiver to risk acceptance throughout the document 3/16/10 Emily De Binder Added section 4 for Payment Card Information requirements 3/22/10 Emily De Binder Add 90 day inactive requirement for PCI BCIT Access Management Process Page 9 of 9